Sim, dá para operar o AWS Management Console em uma rede isolada, mas só quando a arquitetura cobre três frentes ao mesmo tempo: conectividade privada via AWS PrivateLink, resolução DNS correta e políticas que limitem quem pode entrar e a quais contas a sessão pode chegar. Na prática, esse desenho faz mais sentido para times de segurança, plataformas críticas e ambientes regulados que precisam administrar recursos sem abrir navegação geral para a internet. Desde 15 de junho de 2026, a AWS passou a permitir que 100% do tráfego de navegador do console siga por VPC endpoints para consoles suportados, o que mudou bastante o desenho de ambientes sem saída pública.
O que realmente importa antes de começar
- O recurso não é só rede. Ele combina isolamento de tráfego com controles de acesso por conta, organização e origem de rede.
- Em rede totalmente isolada, o endpoint
console-staticdeixa de ser opcional. Sem ele, partes da interface não carregam. - Multi-Region tem uma nuance importante. Os endpoints
consoleesignindevem existir em cada região usada, mas oconsole-staticpode ficar em apenas uma região. - Nem todo console funciona igual. Há suporte parcial por serviço, alguns recursos ficam degradados e o Billing console não está disponível nesse modelo.
- DNS decide se o desenho funciona ou falha. Dentro de uma VPC isolada, o Private DNS costuma bastar; em redes corporativas conectadas, split-horizon DNS vira requisito.
O recurso é útil quando o objetivo é controlar o navegador, não apenas a API
Se a sua meta é impedir que administradores usem o console por qualquer rede ou qualquer conta, o AWS Management Console Private Access resolve um problema diferente de um simples endpoint de serviço. A AWS descreve o recurso como uma combinação de trusted identities, trusted resources, expected networks e network isolation, o que permite restringir o uso do console a contas conhecidas, redes esperadas e recursos autorizados.
Isso é especialmente útil quando a Interserv Cloud precisa desenhar ambientes com bastionless access, estações administrativas em sub-redes privadas e trilha de acesso previsível para auditoria. O ganho não está só em “tirar a internet”, mas em reduzir rotas paralelas de administração que costumam escapar do perímetro planejado. Essa conclusão decorre do próprio modelo de políticas e de encaminhamento privado descrito pela AWS.
Quais endpoints são obrigatórios em rede sem internet?
Em uma implantação realmente isolada, você começa por três interface endpoints: com.amazonaws.region.console, com.amazonaws.region.signin e com.amazonaws.region.console-static. A AWS informa que o terceiro é o responsável por conteúdo estático, como JavaScript, CSS, imagens e APIs específicas do console, por isso ele é obrigatório quando não existe acesso à internet pública.
O ponto que mais gera erro é assumir que isso basta para qualquer tela. Não basta. A própria documentação explica que o console faz chamadas diretas e chamadas proxy para serviços da AWS, então você também precisa criar VPC endpoints dos serviços que pretende administrar, como S3, KMS, EC2 ou CloudWatch. Sem esses endpoints, determinadas páginas abrirão com falhas, e isso é esperado em ambiente isolado.
Como fica o DNS em VPC isolada e em rede corporativa conectada?
Dentro de uma única VPC sem internet, a configuração tende a ser simples: com Private DNS habilitado nos endpoints, o resolvedor padrão da VPC já envia o tráfego do console e do sign-in para IPs privados, sem registros extras na maior parte dos casos. Esse é o cenário mais limpo para uma workstation administrativa hospedada em EC2 ou Amazon WorkSpaces.
Quando o acesso sai de uma rede on-premises via Direct Connect ou Site-to-Site VPN, o desenho muda. A AWS orienta usar split-horizon DNS para encaminhar domínios do console, sign-in, APIs de serviço e conteúdo estático para os endpoints privados corretos. Em ambientes multi-Region, também é preciso rotear prefixos regionais e lembrar que alguns consoles, como IAM, CloudFront e Route 53, ficam hospedados apenas em us-east-1.
Em ambiente multi-Region, preciso repetir tudo?
Não. Esse é um dos pontos em que vale fugir do resumo superficial. Para várias regiões, a AWS pede os endpoints console e signin em cada região que terá uso do console privado, mas o console-static atende conteúdo agnóstico de região e pode existir em apenas uma região. Na prática, isso reduz custo e simplifica operação, desde que o DNS esteja coerente.
Quais políticas realmente fecham o perímetro
Endpoint privado sem política continua sendo um corredor aberto. A AWS recomenda combinar VPC endpoint policies, IAM identity-based policies, resource-based policies, SCPs e RCPs para limitar de onde o usuário entra, quais contas pode usar e quais recursos consegue manipular. Esse encadeamento é o que transforma conectividade privada em controle efetivo.
Em projetos mais sensíveis, o padrão mais seguro é alinhar as mesmas restrições no endpoint do console e no endpoint de sign-in, evitando que o usuário autentique por uma rota e opere por outra. Também faz sentido usar condições de rede, como aws:SourceVpc, nas permissões de serviços compatíveis, porque o próprio fluxo do console privado passa a carregar esse contexto para parte das requisições.
Quais limitações você precisa aceitar antes de migrar
Nem todo console da AWS terá experiência idêntica nesse modelo. A documentação afirma que o recurso está disponível em todas as regiões comerciais, mas suporta apenas um subconjunto dos consoles, com casos de graceful degradation. Além disso, AWS CloudShell e a configuração Default Region podem ficar desabilitados, e o console de Billing não funciona por Private Access.
Há ainda dependências fora do escopo do recurso. Domínios como status.aws.amazon.com, health.aws.amazon.com e docs.aws.amazon.com não são suportados por esses endpoints, então uma rede 100% fechada perderá essas experiências, a menos que você crie saída pública controlada só para esses destinos.
| Cenário | O que costuma funcionar bem | O que exige atenção |
|---|---|---|
| VPC única isolada | Private DNS padrão, console e sign-in privados, operação centralizada | Endpoints dos serviços usados no dia a dia |
| On-premises com Direct Connect ou VPN | Uso do console sem navegação geral para internet | Split-horizon DNS e roteamento regional correto |
| Multi-Region | Administração privada de recursos distribuídos | Endpoints regionais de console e sign-in, dependências em us-east-1 |
Como fazer rollout sem quebrar o acesso administrativo
O melhor caminho é começar pequeno. Em vez de mover toda a administração para o modo privado de uma vez, crie uma VPC dedicada para estações operacionais, habilite os três endpoints básicos, publique os endpoints dos serviços críticos e valide tarefas reais, como acesso a EC2, S3, IAM, KMS e CloudWatch. Essa ordem é coerente com a arquitetura e limitações descritas pela AWS.
Depois, adicione políticas de bloqueio por rede e por conta, revise o DNS corporativo e só então expanda para outras regiões ou para redes on-premises. Se a sua organização usa IAM Identity Center, trate esse fluxo como exceção de projeto desde o início, porque a AWS alerta que o sign-in pode ser bloqueado quando o usuário já está autenticado pelo endpoint privado do console.
Quais erros aparecem com mais frequência no troubleshooting?
Os problemas mais comuns quase sempre caem em quatro grupos: endpoint ausente para o serviço acessado, Private DNS desabilitado, roteamento corporativo apontando para a região errada e política bloqueando sign-in ou navegação entre contas. Em todos esses casos, a tela do console pode abrir parcialmente, mas ações específicas falham porque a chamada de serviço não encontra um caminho privado válido.
Outro erro recorrente é interpretar uma limitação do produto como falha de rede. Se o time tentar usar Billing, CloudShell ou páginas dependentes de domínios não suportados, o ajuste não será no Security Group nem na route table. Será uma decisão de arquitetura sobre manter exceções controladas para internet ou aceitar a indisponibilidade desses recursos naquele ambiente.
Perguntas frequentes
Preciso criar registros DNS manualmente para o acesso privado funcionar?
Não. Em um ambiente isolado de uma única região, a documentação da AWS informa que o resolvedor DNS padrão da VPC já encaminha o tráfego para os endpoints corretos quando o Private DNS está habilitado. DNS adicional passa a ser necessário com mais frequência em redes corporativas conectadas por Direct Connect ou Site-to-Site VPN.
Em ambiente multi-Region, preciso repetir todos os endpoints em cada região?
Não necessariamente. Para usar o console em mais de uma região, a AWS orienta criar os endpoints com.amazonaws.region.console e com.amazonaws.region.signin em cada região necessária. Já o endpoint com.amazonaws.region.console-static é regionalmente agnóstico e pode existir em apenas uma região.
Todo serviço da AWS funciona pelo console privado?
Não. A AWS informa que o recurso está disponível em todas as regiões comerciais, mas apenas um subconjunto dos consoles é suportado plenamente. Além disso, alguns recursos podem ficar indisponíveis ou degradados, e o console de Billing não funciona por esse caminho.
Posso usar IAM Identity Center junto com o console privado?
Não. Se você usar VPC endpoints para o console, a AWS alerta que isso pode bloquear o sign-in no IAM Identity Center quando o usuário já está autenticado pelo endpoint privado. Nesses casos, o acesso ao IAM Identity Center deve usar o endpoint público de sign-in.
Quais dependências ainda podem exigir internet pública?
Não. A própria AWS documenta que domínios como status.aws.amazon.com, health.aws.amazon.com e docs.aws.amazon.com não são suportados pelo recurso. Em uma rede 100% isolada, você precisa aceitar a indisponibilidade dessas páginas ou criar uma saída controlada apenas para esses destinos.
