Retro: EMR Serverless em IPv6-only e a subnet que ficou sem DNS64

O ponto de partida é o que a própria AWS usa como exemplo de planejamento. Cada worker do EMR Serverless consome um endereço IP na subnet em que sobe, por meio de uma ENI. Uma aplicação com workers de 4 vCPU e teto de 4.000 vCPU chega a 1.000 workers, ou seja, 1.000 ENIs. Uma subnet /22 tem 1.024 endereços e 1.019 utilizáveis, porque a AWS reserva cinco. Com três aplicações dividindo as mesmas subnets e uma cota de 12.000 vCPU na conta, a recomendação da documentação vira 3.000 endereços livres por subnet, em pelo menos duas zonas de disponibilidade.

Em plataforma de dados de banco, isso costuma bater num muro: o bloco IPv4 da VPC foi negociado com o time de rede corporativa anos atrás, não sobrepõe com o on-premises e não cresce sem uma rodada de aprovação. É exatamente o caso que o IPv6 resolve. Uma subnet IPv6 da VPC é um /64, e a conversa sobre endereço acaba.

No cenário, o time decide ir direto para IPv6-only em três subnets, uma por AZ, criadas por um módulo de IaC. Duas foram montadas à mão no piloto e receberam DNS64. A terceira veio do módulo, que não sabia que DNS64 existia. Nenhum teste de integração pegou isso, porque o job de teste rodou duas vezes e caiu nas duas subnets boas.

Vale entender as regras antes de culpar a rede. Subnet só IPv4 roda como sempre rodou. Subnet dual-stack roda IPv4 até você ligar spark.emr-serverless.networking.ipv6.enabled=true no spark-defaults da aplicação (para Hive, hive.emr-serverless.networking.ipv6.enabled no hive-site). Subnet IPv6-only roda IPv6 sem propriedade nenhuma.

Quando o conjunto mistura tipos, a aplicação inteira roda no único modo que todas suportam. IPv4-only com IPv6-only é rejeitado na validação. IPv6-only com dual-stack roda tudo em IPv6-only, inclusive as subnets dual-stack, que então precisam cumprir os mesmos pré-requisitos. IPv4-only com dual-stack roda tudo em IPv4.

Três detalhes produzem incidente:

• O modo vale no start: uma aplicação em execução mantém o modo com que subiu. Você corrige a subnet e nada muda até o próximo stop/start.
• Um job, uma subnet: o job roda em uma única subnet escolhida da lista. Uma subnet defeituosa entre três falha um terço das vezes, e retry mascara.
• Dual-stack não prefere IPv6 por padrão: mesmo com o opt-in ligado, o engine usa IPv4 até você setar spark.emr-serverless.driverEnv.SPARK_PREFER_IPV6 e spark.executorEnv.SPARK_PREFER_IPV6. Setar isso numa subnet só IPv4 derruba o job.

A lição: o modo de endereçamento é estado derivado, não configurado. A API não deixa você declarar o modo; ela deixa você declarar subnets e deduz o resto. Estado derivado precisa de teste que prove a derivação em cada subnet, não na média.

A correção do DNS64 levou um comando. A remediação que impede a reincidência levou mais trabalho, e é ela que importa.

Módulo de subnet com contrato: o módulo de IaC passa a exigir, para toda subnet marcada como destino de EMR Serverless, assign_ipv6_address_on_creation = true, enable_dns64 = true, rota 64:ff9b::/96 para o NAT gateway e rota ::/0 para o egress-only internet gateway. O auto-assign só vale para recursos criados depois da mudança, então ligar tarde não conserta ENI que já existe.

Validação antes do apply: uma checagem no pipeline (policy as code ou um teste que lê describe-subnets e describe-route-tables) falha o deploy se qualquer subnet do conjunto não cumprir o contrato. Validação que roda depois do incidente é postmortem, não controle.

Canário por subnet: como o job escolhe a subnet e você não, crio uma aplicação canário com uma subnet só, uma para cada AZ. Um job Spark mínimo resolve e conecta nos endpoints de que o batch depende (catálogo, STS, KMS, o bucket de dados, o banco de origem) e falha alto. Roda antes da janela do batch e depois de qualquer mudança de rede.

JVM limpa: varredura em todas as sparkSubmitParameters e runtimeConfiguration atrás de preferIPv4Stack. Um contorno de 2019 não pode decidir a pilha de rede de 2026.

Nada disso é sofisticado. O custo dele não é escrever, é manter o contrato quando alguém criar a quarta subnet daqui a dezoito meses sem ler este documento.

"Sem custo adicional" é verdade para o recurso. Não é verdade para o caminho que o tráfego passa a percorrer.

Em subnet IPv6-only, todo destino que só publica registro A recebe um endereço sintetizado em 64:ff9b::/96, e essa rota aponta para o NAT gateway. O NAT gateway cobra por hora e por GB processado; a página de preços da VPC usa US$ 0,045 por GB como exemplo em US East (Ohio). Uma plataforma que lê 8 TB por noite do S3 e manda isso pelo NAT64 paga cerca de US$ 360 por noite só de processamento, algo como US$ 10.800 em 30 noites. O gateway endpoint do S3 na subnet do workload não pega esse tráfego, porque o destino deixou de ser um prefixo IPv4.

O S3 só atende IPv6 pelos endpoints dual-stack (s3.dualstack.<region>.amazonaws.com), e o cliente precisa pedir isso explicitamente. Antes de medir, não confie: compare BytesOutToDestination do NAT gateway antes e depois da troca.

Outros serviços exigem o mesmo cuidado. Na tabela de suporte a IPv6 da AWS, o Glue tem dual-stack e endpoint privado com IPv6, mas o endpoint público não; o Lake Formation também só tem IPv6 pelo endpoint privado. Em IPv6-only, isso quer dizer interface endpoint para catálogo e permissões, ou NAT64 pago em cada chamada.

E a segurança: a documentação do S3 avisa que políticas com aws:SourceIp só em IPv4 fazem clientes perderem ou ganharem acesso indevidamente quando passam a usar IPv6. Revise toda bucket policy antes da troca, não depois.