# IPv6 na AWS: dual stack, egress-only e o que ainda exige IPv4 > Monte subnets dual stack e IPv6 only na AWS e veja no teste o que não funcionou só com IPv6: ECR e GitHub travaram, sem NAT Gateway. - Autor: Henrylle Maia, consultor AWS - Publicado em: 2026-10-15 - Assuntos: Rede, Custos - URL: https://pages.formacaoaws.com.br/blog/ipv6-na-aws-dual-stack/ - Aula de origem: "Hora de migrar seus serviços de IPV4 para IPV6 na AWS?" (https://www.youtube.com/watch?v=fha-zInha1U) Dá para trocar o IPv4 público por IPv6 e escapar do NAT Gateway? Eu montei uma VPC com subnet dual stack e subnet só com IPv6, sem NAT Gateway, e testei. O ECR e o GitHub não funcionaram só com IPv6. Abaixo estão o desenho, as rotas e os testes, para você repetir. O ponto de partida é a cobrança do IPv4 público. A data e como contar os IPv4 da conta estão no post sobre o [IP público cobrado na AWS](https://pages.formacaoaws.com.br/blog/ip-publico-ipv4-cobrado-na-aws/). Aqui a pergunta é outra: vale migrar para IPv6? ## O que a AWS cobra e o caminho sem IPv6 A AWS cobra por cada IPv4 público: meio centavo de dólar por hora, perto de 4 dólares por mês por endereço. Um load balancer em duas AZs usa 2 IPv4 públicos. Uma EC2 com IPv4 público é mais um. O Free Tier cobre 750 horas, o que serve para teste. Antes de falar de IPv6, existe uma saída mais simples: mover o que não precisa de IP público para subnet privada. A instância com IP público costuma estar assim só porque o usuário precisa chegar nela. Se ela roda uma aplicação web, o certo é colocar um Application Load Balancer na frente e mandar as EC2 para as subnets privadas. Você ganha disponibilidade e perde a necessidade do IP público. O problema vem depois. Para uma instância privada se registrar em ECS, EKS, Beanstalk ou qualquer serviço fora da sua VPC, ela precisa de saída, e a saída é um NAT Gateway, que na minha conta custava cerca de 36 dólares por mês. Aí aparece a dúvida: dá para fugir do NAT com IPv6? ## IPv6 na VPC: o que muda em relação ao IPv4 No IPv4, a instância tem um endereço privado e, se você quiser, um público. No IPv6 não existe essa divisão: a instância tem só um endereço IPv6. O que a torna pública ou privada é a route table, ou seja, a sua configuração de rede. Dois conceitos resolvem o teste: - **Dual stack:** a mesma subnet trabalha com IPv4 e IPv6. - **Egress-only Internet Gateway:** serviço só para IPv6 que dá saída para a internet sem permitir entrada, e é gratuito. No IPv4 isso só se faz com NAT Gateway. ## Passo 1: desenhe as três subnets do teste Montei uma VPC com três tipos de subnet, como no desenho: 1. **Pública IPv4**, dual stack: a instância tem IPv4 público e IPv6. 2. **Pública IPv6**, dual stack. 3. **Privada IPv6 only:** a instância não tem IPv4, nem público nem privado. ![Os três blocos do teste na zona A: pública IPv4 e pública IPv6, ambas dual stack, e privada IPv6 only](https://pages.formacaoaws.com.br/blog/assets/posts/ipv6-na-aws-dual-stack/tres-subnets.svg) Além delas, uma máquina de entrada com IPv6 público, para eu chegar às outras por dentro da VPC. O teste: ver se a instância IPv6 only alcança o Amazon ECR, o registro de imagens Docker, sem NAT Gateway na rede. ## Passo 2: configure as route tables Cada subnet ganha a saída que o seu papel pede: - Pública IPv4: `0.0.0.0/0` apontando para o Internet Gateway. - Pública IPv6: `::/0` apontando para o mesmo Internet Gateway. - Privada IPv6 only: `::/0` apontando para o Egress-only Internet Gateway, sem Internet Gateway na tabela. ![As duas route tables IPv6: na pública, ::/0 vai para um igw; na privada, ::/0 vai para um eigw](https://pages.formacaoaws.com.br/blog/assets/posts/ipv6-na-aws-dual-stack/route-tables.webp) Nas três instâncias usei a mesma chave `.pem`. O Security Group da máquina de entrada abre só a porta 22 para IPv6, e o das outras duas aceita acesso a partir dela. No teste, não havia nenhum NAT Gateway na rede. > **Importante:** para o `aws ecr` funcionar, a role das instâncias precisa de permissão no ECR. Eu anexei a policy EC2 Container Registry Power User na role das duas. ## Passo 3: entre na rede por IPv6 Carregue a chave no agente e conecte na máquina de entrada pelo endereço IPv6 dela: ```bash ssh-add .pem ssh -A ec2-user@ ``` O `ifconfig` dentro da máquina mostra os dois endereços: o IPv4 privado e o IPv6. Ela é dual stack de propósito: entro por IPv6, mas ela precisa de IPv4 para sair por IPv4. A partir dela, conecte nas outras duas. Na dual stack basta o IP privado: ```bash ssh ec2-user@ ``` Na IPv6 only não existe IPv4 nenhum, então você usa o IPv6 dela no mesmo comando. ## Passo 4: teste o ECR nos dois lados O primeiro comando do `View push commands` do ECR, o que busca a senha de login, é um bom teste de conectividade: ```bash aws ecr get-login-password --region us-east-1 ``` Na instância dual stack, o comando voltou com a senha: ela alcançou o ECR. Na instância IPv6 only, o mesmo comando ficou tentando e não conseguiu. O ECR não trabalha com IPv6 only. Isso não é falha da minha rede. A AWS publica uma tabela de serviços com suporte a IPv6, com uma coluna para dual stack e outra para IPv6 only. Eu a abri na aula. ![A tabela de suporte a IPv6 da AWS em abril de 2024: EC2 aceita IPv6 only (Yes); ECS, Fargate e Lambda aceitam dual stack mas não IPv6 only (No). Confira a versão atual](https://pages.formacaoaws.com.br/blog/assets/posts/ipv6-na-aws-dual-stack/suporte-ipv6.webp) Na tabela que mostrei, o EC2 suporta as duas coisas, mas o ECS aceita dual stack e não aceita IPv6 only. O mesmo vale para Lambda, Fargate, RDS e Secrets Manager. Essa é a tabela que eu abri na aula, de abril de 2024, e a AWS atualiza a página conforme libera suporte. Confira a [versão atual na documentação da AWS](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html) antes de decidir. > **Importante:** não é só a AWS. Na instância IPv6 only, o `git clone https://github.com/henrylle/bia` também não andou. O GitHub também não suporta IPv6 only: a instância precisaria de IPv4. ## Onde isso me deixa No meu teste, a instância IPv6 only entrou pela máquina de entrada, mas não chegou ao ECR nem ao GitHub, e o ECS também não aceita IPv6 only. Eu não testei a saída dela para um destino que aceite IPv6 only. Então a pergunta "dá para largar o NAT Gateway?" depende de com quem a sua instância conversa. A provocação que eu deixo é outra: por que você usa tanto IPv4 público? Se a sua infraestrutura depende de IP público, provavelmente há um problema de arquitetura e de segurança. A cobrança da AWS, na minha leitura, foi positiva porque empurra para o uso de IP privado. **Fluxo:** Instância (subnet privada, só IPv6) → Route table (::/0 para o egress-only) → Egress-only Internet Gateway (saída sem entrada) → Serviço da AWS (só se aceitar IPv6 only) ## Checklist - Liste por que cada recurso tem IPv4 público e mova para subnet privada o que não precisa dele. - Coloque um load balancer na frente de aplicação web, em vez de expor a EC2. - Saiba que no IPv6 o que decide se a instância é pública é a route table, não o endereço. - Em subnet privada IPv6 only, use o `::/0` apontando para o Egress-only Internet Gateway. - Teste a saída antes de tirar o IPv4: rode `aws ecr get-login-password` e um `git clone` de dentro da instância. - Antes de migrar um serviço para IPv6 only, confira a tabela de suporte a IPv6 da AWS. Se o seu desenho tem NAT Gateway, IPv4 público demais ou dúvida sobre o que dá para migrar, vale revisar com alguém que já testou.