CloudFront VPC origins dual-stack: IPv6 até a origem privada, com ressalvas

VPC origins, lançado em novembro de 2024, coloca ALB, NLB ou EC2 numa subnet privada e faz da CloudFront a única porta de entrada. A conexão chega por uma ENI gerenciada pelo serviço, criada dentro da sua subnet, e o acesso é controlado por um security group que a própria AWS cria com o padrão de nome CloudFront-VPCOrigins-Service-SG. Até ontem essa ENI só falava IPv4.

Em setembro de 2025 a CloudFront ganhou IPv6 para origens customizadas, com três opções: IPv4 only (padrão), IPv6 only e dual-stack. O próprio anúncio excluía S3 e VPC origins. O que saiu agora fecha metade dessa lacuna: VPC origins aceitam dual-stack. A outra metade continua aberta, porque a documentação atual de IPv6 da CloudFront ainda lista IPv6 only como "excluding Amazon S3 and VPC origins".

Na prática, a mudança é um campo: ao criar a VPC origin, o console pede Origin type, e o padrão continua IPv4. Para o dual-stack funcionar, a subnet privada precisa de pelo menos um endereço IPv6 livre além do IPv4, porque é ali que a ENI do serviço nasce. Sem isso, a criação da ENI falha.

O que não muda: gRPC continua fora, triggers de origin request e origin response do Lambda@Edge continuam fora, Gateway Load Balancer não pode ser origem e NLB com listener TLS também não. Quem descartou VPC origins por um desses motivos não tem razão nova para revisitar.

Este é o ponto que o anúncio não deixa explícito e que importa para quem vai responder a auditoria. A documentação da CloudFront descreve o modo dual-stack assim: o serviço escolhe automaticamente IPv4 ou IPv6 na conexão com a origem para priorizar desempenho e disponibilidade. Ou seja, você não decide a família de cada conexão. A CloudFront decide.

Para a maioria dos sites isso é exatamente o comportamento certo. Para um time que precisa provar a um regulador ou a um contrato que o tráfego trafega em IPv6 até a origem, é um problema de evidência. Ligar o dual-stack não gera prova nenhuma; o que gera prova é medição.

O mesmo vale do lado do usuário. A própria documentação avisa que a CloudFront pode responder ao viewer em IPv4 quando os dados dela indicam experiência melhor, e que a fatia de IPv6 deve continuar minoritária porque nem toda rede de acesso suporta o protocolo. Duas decisões automáticas, uma em cada ponta, e nenhuma delas é sua.

O que eu faria: tratar "IPv6 ponta a ponta" como um SLO medido, não como uma configuração. Na borda, o campo c-ip dos logs padrão mostra a família do viewer. Na origem, os access logs do ALB mostram o endereço de quem abriu a conexão, que no caso de VPC origins é a ENI do serviço. A razão entre conexões IPv6 e o total, por dia, é o número que vai para o relatório. Se o requisito for IPv6 exclusivo, VPC origins ainda não atende: IPv6 only segue excluído.

A configuração na CloudFront é um campo. O trabalho de verdade está no VPC, e boa parte dele falha sem mensagem clara.

IPv6 no VPC e nas subnets: o ALB só aceita IpAddressType: dualstack se o VPC e as subnets dele tiverem bloco CIDR IPv6 associado, se as route tables rotearem IPv6 e se SG e NACL permitirem IPv6. Em conta antiga, criada só com IPv4, isso é um projeto, não um clique.

Endereço para a ENI: a subnet onde a VPC origin vive precisa de um IPv6 livre. Subnet /28 lotada em IPv4 já é um problema conhecido; no dual-stack a mesma conta se repete na outra família.

Security group da origem: a documentação dá duas opções. Prefix lists gerenciadas, e para dual-stack são as duas, com.amazonaws.global.cloudfront.origin-facing e com.amazonaws.global.ipv6.cloudfront.origin-facing. A documentação do VPC atribui peso 55 à lista da CloudFront, contra o padrão de 60 regras por security group, o que deixa 5 regras para todo o resto. A outra opção é referenciar o CloudFront-VPCOrigins-Service-SG: ocupa uma regra e restringe a origem às suas distribuições, não a qualquer distribuição da CloudFront. Eu uso essa.

NACL de saída: regras de entrada da NACL não são avaliadas para o tráfego vindo da CloudFront, mas as de saída são, no caminho de retorno, nas portas efêmeras 1024–65535. NACL guarda regras IPv6 separadas das IPv4. Quem liberou só 0.0.0.0/0 vai ver o handshake IPv6 morrer no retorno.

Aqui está o custo que não aparece no anúncio. Pelo procedimento documentado, atualizar uma VPC origin exige primeiro tirá-la de ser a origem padrão de qualquer cache behavior, depois desassociá-la de todas as distribuições que a usam, editar, esperar o status voltar a Deployed (até 15 minutos) e só então associar de novo. Em produção, isso é uma janela de indisponibilidade com hora marcada, multiplicada pelo número de distribuições que compartilham a origem.

Eu não editaria a VPC origin existente. O caminho mais seguro é criar uma segunda VPC origin, dual-stack, apontando para o mesmo ARN do ALB, e trocar a origem via continuous deployment da CloudFront: uma staging distribution recebe a origem nova, você testa com uma fatia do tráfego e promove a configuração quando os sinais estiverem limpos. O rollback é promover de volta a configuração anterior, sem esperar 15 minutos de propagação de VPC origin.

Os sinais que eu acompanharia na staging: 5xxErrorRate e OriginLatency da distribuição no CloudWatch, TargetConnectionErrorCount e HTTPCode_ELB_5XX_Count do ALB, e a proporção de conexões IPv6 nos access logs do ALB. Se a proporção ficar em zero, o problema quase sempre é SG ou NACL sem a regra IPv6, e a CloudFront cai para IPv4 sem reclamar, o que é bom para disponibilidade e péssimo para a meta.

Para quem compartilha VPC origins entre contas via AWS RAM, some a coordenação com o dono de cada distribuição consumidora.