Clientes da AWS não conseguem se livrar do IPv4

• A AWS anunciou que passará a cobrar pelos endereços IPv4 públicos a partir de fevereiro de 2024. A taxa será de US$ 0,005 por hora, o que resulta em cerca de US$ 4 por mês ou mais de US$ 40 por ano.
• Essa cobrança afetará serviços como Elastic Load Balancers, instâncias EC2, Elastic IPs, tarefas ECS Fargate com IP público, IPs do Global Accelerator, IPs de VPN site-to-site e Managed NAT Gateways. Endereços IPv4 compartilhados e endereços IPv4 públicos usados por funções Lambda fora de VPC não serão afetados.
• Embora muitos tenham recebido bem o anúncio por esperarem que ele incentive a adoção de IPv6, o autor argumenta que a cobrança não terá grande impacto nisso, já que muitos serviços da AWS ainda não oferecem suporte adequado a IPv6.
• O autor aponta que padrões de uso desperdiçadores, como manter vários Load Balancers por VPC e configurar deliberadamente IPv4 público em instâncias EC2 e tarefas Fargate para evitar o uso de Managed NAT Gateway, serão fortemente impactados pela nova cobrança.
• O autor afirma que é praticamente impossível operar apenas com IPv6 na AWS porque serviços essenciais como API Gateway, Lambda, ECS e App Runner ainda carecem de suporte a IPv6. Mesmo rodando internamente em dual stack, a maioria dos serviços da AWS ainda só consegue se conectar a destinos IPv4.
• O autor critica a AWS por apresentar a nova cobrança como um incentivo à adoção de IPv6, argumentando que não há como evitá-la porque a empresa ignorou amplamente o IPv6 por anos.
• O autor conclui que, embora a cobrança por IPv4 possa ser necessária diante do aumento recente no custo de obtenção desses endereços, ela não estimulará a adoção de IPv6 e ainda pode sufocar a inovação e tornar menos atraente ter uma conta pessoal na AWS.
• Esta é a primeira parte de uma série de posts no blog. Publicações futuras devem abordar com mais profundidade as opções relacionadas à adoção de IPv6 na AWS para tráfego de entrada e tráfego intra-VPC, tráfego de saída e problemas de programação de aplicações.

[GN⁺]

Comentários do Hacker News

• A Amazon está conduzindo um grande projeto para dividir todos os sistemas internos em versões regionais devido ao esgotamento dos endereços IPv4 internos
• A migração para IPv6 é impossível porque há muitos dispositivos de rede internos que não conseguem oferecer suporte a IPv6
• Como as ferramentas da AWS recomendam fortemente a construção de redes que endereçam de forma ambígua redes 10.x RFC1918, os incentivos da AWS não favorecem a oferta de um IPv6 funcional
• Um problema importante para usar apenas IPv6 na AWS é que muito software que tenta acessar o GitHub ainda não oferece suporte a IPv6
• Alguns clientes da AWS expressam o desejo de abandonar totalmente IP por causa da complexidade de gerenciar esses sistemas de rede
• O fato de serviços como Lambda e S3 não oferecerem suporte a IPv6 é um problema importante, e a AWS deveria tê-los tornado dual stack acessíveis via IPv6 antes de fazer mudanças de preço
• O principal suporte a IPv6 da AWS se deve em parte à ordem do governo dos EUA para iniciar a migração
• O fato de o CloudFront não oferecer suporte a IPv6 para origens personalizadas é um problema para quem executa muitos contêineres Fargate separados como origem
• A falta de concorrência entre ISPs nos EUA atrapalha a adoção do IPv6
• Configurar uma VPC somente IPv6 na AWS pode fazer com que muitas coisas parem de funcionar, desde vários serviços da AWS até repositórios de pacotes
• Como o IPv6 não tem o conceito de endereços privados, é preciso dar adeus ao Managed NAT Gateway e ao seu preço