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

Desde 15/10/2026, a CloudFront fala IPv6 com ALB, NLB e EC2 em subnet privada, sem custo adicional. Isso acaba com a escolha entre origem privada e IPv6 ponta a ponta, mas dual-stack não é IPv6 garantido, e trocar uma VPC origin em produção exige desassociá-la da distribuição.

- URL: https://fernando.moretes.com/blog/cloudfront-vpc-origins-dual-stack-ipv6-ate-a-origem-privada-com

- Markdown: https://fernando.moretes.com/blog/cloudfront-vpc-origins-dual-stack-ipv6-ate-a-origem-privada-com/article.md?lang=pt

- Published: 2026-10-16T10:14:20.099Z

- Category: AWS & Cloud

- Tags: cloudfront, vpc-origins, ipv6, networking, security, alb

- Reading time: 7 min

- Source: [Amazon CloudFront announces dual-stack support for VPC origins](https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-vpc-origin-dualstack/)

---

Por quase dois anos, quem adotou VPC origins na CloudFront e tinha meta de IPv6 vivia com uma escolha ruim: manter o ALB em subnet privada e ficar no IPv4 entre a borda e a origem, ou expor a origem na internet para ter IPv6 ponta a ponta. O anúncio de 15/10/2026 desfaz esse dilema. A pergunta que importa agora não é 'dá para ter IPv6 até a origem privada?', é 'o que no meu VPC, no meu security group e no meu processo de mudança quebra quando eu ligar isso?'. É essa a pergunta que esta análise responde.

## Os números do lançamento

- **US$ 0**: Custo adicional. Dual-stack em VPC origins não tem cobrança extra; os endereços da ENI podem ser privados.
- **34**: Regiões comerciais. Todas as regiões com VPC origins, incluindo sa-east-1; quatro têm uma AZ de exceção.
- **55/60**: Peso da prefix list. A lista gerenciada da CloudFront pesa 55 contra o padrão de 60 regras por security group.

## O que mudou de fato

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.

## Caminho IPv6 ponta a ponta com origem privada

Cada salto onde o IPv6 pode cair para IPv4 sem aviso, e o controle que governa esse salto.

### 🌐 DNS e borda

- Route 53 alias A + alias AAAA (network)
- CloudFront edge IPv6 de viewer ligado (edge)
- Origin-facing escolhe IPv4 ou IPv6 (edge)

### 🟧 AWS: VPC privada (sa-east-1)

- ENI do serviço 1 IPv4 + 1 IPv6 livres (network)
- ALB interno IpAddressType: dualstack (compute)
- Target group IPv4 ou IPv6 (compute)

### 🔐 Controles

- CloudFront-VPCOrigins-Service-SG fonte da regra de entrada (security)
- NACL de saída efêmeras 1024–65535 IPv4 e IPv6 (security)

### Fluxos

- viewer -> r53: consulta AAAA
- viewer -> edge: HTTPS sobre IPv6
- edge -> ofs: cache miss
- ofs -> eni: conexão privada, família escolhida pelo serviço
- eni -> alb: permitido pelo SG do serviço
- alb -> tg: nova conexão, família do target group
- svcsg -> alb: regra de entrada
- nacl -> alb: caminho de retorno

## Onde ele brilha

- **Fim do trade-off:** IPv6 até a origem deixa de exigir subnet pública, internet-facing ALB e uma lista de IPs para manter.
- **Custo zero de licença:** nenhuma cobrança adicional, e os endereços IPv6 da ENI não precisam ser públicos.
- **Mesmo modelo de segurança:** o SG do serviço continua restringindo a origem às suas distribuições, agora nas duas famílias.
- **Brasil incluído:** `sa-east-1` está na lista, então workload regulado que precisa ficar no país não fica de fora.

## Dual-stack não é IPv6 garantido

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.

## Pré-requisitos de rede que falham em silêncio

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.

> **Limites que continuam valendo:** IPv6 only segue indisponível para VPC origins. gRPC e triggers de origem do Lambda@Edge não são suportados. Gateway Load Balancer e NLB com listener TLS não podem ser origem, e NLB precisa de security group anexado. E o IPv6 termina no ALB: a conexão com os targets usa a família do target group, então ALB dual-stack com target group IPv4 é IPv6 até o ALB, não até a aplicação.

## Migrar uma VPC origin que já está em produção

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.

## Como adotar sem janela de indisponibilidade

1. **Prepare o VPC**: Associe CIDR IPv6 ao VPC e às subnets privadas, ajuste route tables e confirme que cada subnet tem IPv6 livre para a ENI.

2. **Leve o ALB para dual-stack**: `aws elbv2 set-ip-address-type --ip-address-type dualstack` no ALB interno; decida à parte se o target group também vai para IPv6.

3. **Feche SG e NACL**: Entrada do ALB a partir do `CloudFront-VPCOrigins-Service-SG`; saída da NACL nas efêmeras 1024–65535 para IPv4 e IPv6.

4. **Crie uma VPC origin nova**: Origin type dual-stack, mesmo ARN do ALB. Não edite a existente; espere o status Deployed.

5. **Teste em staging e promova**: Staging distribution com a origem nova, tráfego parcial, sinais de 5xx e proporção IPv6; promova só com os dois limpos.

6. **Feche a borda**: IPv6 de viewer ligado e um segundo alias AAAA no Route 53 para cada nome alternativo; revise signed URLs com política customizada por `IpAddress`.

## Anti-padrões

- **Editar a VPC origin em produção:** o procedimento exige desassociar de todas as distribuições, e a espera de até 15 minutos vira indisponibilidade.
- **Declarar conformidade porque o campo diz dual-stack:** a CloudFront escolhe a família por conexão; sem medição nos logs, não há evidência.
- **Liberar as prefix lists quando a origem só atende CloudFront própria:** consome 55 do padrão de 60 regras e aceita qualquer distribuição, não só as suas.
- **Esquecer o target group:** ALB dual-stack com targets IPv4 entrega IPv6 até o balanceador, não até a aplicação.

> **Nota do curador:** Em ambiente financeiro eu ligaria isso primeiro numa distribuição de baixo risco, com staging e meta de proporção IPv6 escrita antes da mudança. Já vi migração de família de IP passar no teste funcional e falhar no primeiro relatório de auditoria, porque o fallback para IPv4 é silencioso por desenho. A lição: em rede, o que degrada sem erro precisa de métrica própria, senão você descobre pela pessoa errada. E eu não editaria VPC origin existente em hipótese alguma; criar outra e trocar por continuous deployment custa uma tarde e poupa uma janela de madrugada.

## Veredito

Adote quando houver requisito de IPv6 ponta a ponta, contratual, regulatório ou de plataforma, e a origem já estiver ou precisar estar em subnet privada: não há custo adicional e o modelo de segurança não piora. Espere se o requisito for IPv6 exclusivo, porque IPv6 only segue fora para VPC origins, ou se o VPC ainda não tem CIDR IPv6, porque aí o projeto é de rede e não de CDN. Em qualquer caso, crie uma VPC origin nova e troque via staging; não edite a que está servindo tráfego.

**Rating:** 4/5

## Referências

- [AWS What's New: Amazon CloudFront announces dual-stack support for VPC origins (15/10/2026)](https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-vpc-origin-dualstack/)
- [Amazon CloudFront Developer Guide: Restrict access with VPC origins](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)
- [Amazon CloudFront Developer Guide: Enable IPv6 for CloudFront distributions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-enable-ipv6.html)
- [AWS What's New: Amazon CloudFront announces support for IPv6 origins (09/2025)](https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-cloudfront-ipv6-origins/)
- [Amazon VPC User Guide: AWS-managed prefix lists and weights](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)
- [Elastic Load Balancing: Update the IP address types for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html)
- [AWS Networking & Content Delivery Blog: Combining Amazon CloudFront with Application Load Balancers](https://aws.amazon.com/blogs/networking-and-content-delivery/optimizing-application-performance-the-strategic-benefits-of-combining-amazon-cloudfront-with-application-load-balancers)