IPv6 na AWS: dual stack, egress-only e o que ainda exige IPv4

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. 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.

1Desenhe 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.

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.

2Configure 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.

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.

3Entre na rede por IPv6

Carregue a chave no agente e conecte na máquina de entrada pelo endereço IPv6 dela:

ssh-add <chave>.pem
ssh -A ec2-user@<IPv6 da máquina de entrada>

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:

ssh ec2-user@<IP privado da instância>

Na IPv6 only não existe IPv4 nenhum, então você usa o IPv6 dela no mesmo comando.

4Teste 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:

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.

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 antes de decidir.

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.

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.