Clientes da AWS não conseguem se livrar do IPv4
(tty.neveragain.de)- A AWS vai cobrar US$ 0,005 por hora por cada endereço IPv4 público dedicado a partir de fevereiro de 2024, mas as limitações dos serviços da AWS dificultam que os clientes evitem esse custo migrando para IPv6
- A cobrança se aplica amplamente a Elastic Load Balancer, EC2/Elastic IP, tarefas ECS Fargate com IP público configurado, Global Accelerator, VPN site-to-site, RDS, Managed NAT Gateway e outros
- EC2, VPN, Transit Gateway, Direct Connect e Network Firewall funcionam com base em IPv6, mas serviços centrais como API Gateway, Lambda, ECS e App Runner rejeitam sub-redes somente IPv6 ou não as suportam corretamente
- Mesmo com a infraestrutura interna em dual stack, mais de 90% dos endpoints de API dos serviços não suportam IPv6, o que dificulta usar S3, Systems Manager, SQS e outros a partir de uma VPC sem IPv4 público
- Para clientes grandes, isso muitas vezes representa menos de 1% da fatura, reduzindo o incentivo à migração; já PMEs, hobbyistas e startups podem sofrer aumento de 10% a 30% nos custos, o que pesa mais
Cobrança de IPv4 público dedicado a partir de fevereiro de 2024
- A AWS vai cobrar US$ 0,005 por hora por cada endereço IPv4 público dedicado a partir de fevereiro de 2024
- Isso equivale a quase US$ 4 por mês e mais de US$ 40 por ano
- Vale para IPs pertencentes à AWS; endereços BYOIP, em que o cliente traz seu próprio bloco IPv4 público roteável, não serão cobrados
- A cobrança cobre uma ampla gama de recursos principais que usam IPv4 público diretamente
- Elastic Load Balancer
- Usa 1 endereço por zona de disponibilidade
- Exige no mínimo 2 e não permite desativar IPv4
- Instâncias EC2 e Elastic IP
- Tarefas ECS Fargate com IP público configurado
- IPs do Global Accelerator
- IPs de VPN site-to-site
- RDS
- Managed NAT Gateway
- Elastic Load Balancer
- Endereços IPv4 compartilhados ficam de fora
- Endereços compartilhados usados em distribuições CloudFront ou endpoints do API Gateway não entram na cobrança
- Endereços IPv4 públicos usados por funções Lambda fora da VPC também ficam excluídos
Configurações em que o custo aumenta bastante
- Um Elastic Load Balancer público distribuído em 3 zonas de disponibilidade terá aumento de mais de 50% no preço-base
- O Managed NAT Gateway terá aumento de cerca de 10% no preço-base
- O NAT Gateway não oferece redundância por zona de disponibilidade
- Se conexões de saída forem importantes, é preciso um NAT Gateway em cada zona de disponibilidade
- Dois padrões que desperdiçam muitos endereços são especialmente afetados
- Configurações com vários Load Balancers por VPC
- Isso acontece ao combinar vários templates do CloudFormation ou módulos Terraform, ou quando o controlador de ingress do Kubernetes cria um Load Balancer por serviço
- Um único Load Balancer pode atender várias URLs e serviços
- Configurações que anexam intencionalmente IPv4 público a instâncias EC2 e tarefas Fargate para evitar o Managed NAT Gateway
- Ironicamente, esse método ainda sai mais barato até chegar a cerca de 10 endereços IPv4 públicos por zona de disponibilidade
- Configurações com vários Load Balancers por VPC
Como verificar o uso atual
- O uso de endereços IPv4 públicos já está sendo contabilizado na conta
- No momento aparece como US$ 0, mas a partir de fevereiro de 2024 será cobrado a US$ 0,005 por hora
- Os caminhos para verificar são os seguintes
- Billing Dashboard > Bills
- Aparece como
PublicIPv4:InUseAddressna seção Virtual Private Cloud
- Aparece como
- Cost Explorer
- É possível filtrar para incluir apenas
PublicIPv4:InUseAddresse ver o uso por dia e por hora - Também é possível agrupar por conta membro
- É possível filtrar para incluir apenas
- VPC > VPC IP Address Manager > Public IP insights
- Mostra uma visão geral do uso de IPv4 público
- Essa parte do IPAM é gratuita
- Exibe apenas dados por conta e região, e não captura endereços usados temporariamente, então os dados ficam incompletos
- Billing Dashboard > Bills
Duas formas de adotar IPv6
- Como endereços IPv4 têm custo e endereços IPv6 são gratuitos, à primeira vista migrar para IPv6 parece a escolha natural
- No IPv6 não existe o conceito de endereço privado, então é possível evitar o Managed NAT Gateway e seu custo
- Há duas formas principais de adotar IPv6
- Dual stack
- Configura endereços IPv4 e IPv6 em todos os sistemas
- IPv6-only interno
- Usa apenas IPv6 internamente, deixando conectividade IPv4 só na borda ou no CDN que atende usuários finais
- Dual stack
- Um memorando da Presidência dos EUA afirma que operar em dual stack ficou complexo demais para manter e se tornou desnecessário, e que órgãos de padronização e grandes empresas de tecnologia começaram a migrar para implantações IPv6-only
- O suporte básico de rede IPv6 da AWS em si é relativamente bom
- É possível configurar instâncias EC2 somente IPv6 em sub-redes IPv6-only
- Funcionalidades esperadas em redes IPv6, como DNS local, serviço de tempo, configuração de host e segurança, funcionam
- VPN, Transit Gateway, Direct Connect e Network Firewall também suportam IPv6
O bloqueio do IPv6 aparece na hora de usar os serviços da AWS
- O gargalo aparece menos na rede em si e mais na etapa de conexão com outros serviços da AWS
- Serviços centrais como API Gateway, Lambda, ECS e App Runner rejeitam configurações de sub-rede IPv6-only ou geram erro
- O Elastic Load Balancer pode retornar erros como
Not enough IP space available
- O Elastic Load Balancer pode retornar erros como
- Mesmo configurar a infraestrutura interna em dual stack não basta
- Muitos serviços ignoram o fato de a sub-rede ter IPv6 configurado
- Em muitos casos, só conseguem se conectar a destinos IPv4
- Há muitos casos em que usar APIs de serviços a partir da VPC sem endereço IPv4 público é difícil ou impossível
- Executar
aws s3 lsem uma instância EC2 falha - O Systems Manager, forma recomendada para acesso e gerenciamento de instâncias, não funciona
- Uma tarefa ECS não consegue acessar o SQS
- Executar
- Segundo o estado do suporte a IPv6 na AWS, mais de 90% dos endpoints de API de serviços não suportam IPv6
- Endpoints SMTP do SES e endpoints de repositório do ECR também não funcionam, e o CloudFront não consegue se conectar a origins IPv6
- Não é possível iniciar tarefas ECS a partir do ECR, mas isso é possível com o Docker Hub, que suporta IPv6
- O Docker Hub aplica rate limit para pulls
O PrivateLink é uma alternativa, mas tem limitações de custo
- Muitos serviços podem ser acessados via PrivateLink
- Ele se conecta diretamente à VPC do cliente, então não exige endereço IP público
- Nem todos os serviços são suportados
- O PrivateLink cobra por serviço e por zona de disponibilidade
- Fica em cerca de US$ 9 por endpoint por mês
- Por exemplo, conectar Secrets Manager, EC2, SSM e SSM-Messages em 3 zonas de disponibilidade custa mais de US$ 1.200 por ano por VPC
- Há também cobrança adicional de tráfego
Por que a cobrança de IPv4 dificilmente levará à migração para IPv6
- Para clientes de maior porte, a cobrança de IPv4 normalmente fica em menos de 1% da fatura, então não parece uma mudança relevante
- Só esse custo dificilmente levará a um investimento significativo de engenharia
- Para PMEs, hobbyistas e startups, a tarifa pode aumentar a fatura em 10% a 30%
- Esses grupos têm forte motivação para adotar IPv6 e evitar o custo
- Mas, por causa das lacunas no suporte a IPv6 dos serviços da AWS, há poucas formas de escapar do custo do IPv4
- Considerando o custo recente para obter IPv4, a cobrança por endereços IPv4 pode até ser necessária
- Se o suporte a IPv6 em toda a AWS estivesse maduro, mais clientes poderiam migrar para ambientes IPv6-only
- Hoje é difícil tratar o IPv6 como cidadão de primeira classe na AWS, e nessa situação a cobrança de IPv4 torna menos atraente usar a AWS para contas pessoais, aprendizado, preparação para certificações e apoio a projetos open source
1 comentários
Opiniões do Hacker News
Há muito tempo, quando eu era desenvolvedor júnior na Amazon, havia um grande projeto interno para dividir todos os sistemas internos em versões por região e permitir chamadas entre regiões apenas por meio de gateways limitados
O motivo era que os endereços IPv4 internos tinham se esgotado
Quando alguém perguntou “não dava simplesmente para mudar para IPv6?”, o Principal PM responsável respondeu algo na linha de que “havia tantos equipamentos de rede internos atuais que não suportavam IPv6 que, para substituí-los, teríamos de comprar uma quantidade de equipamentos próxima da produção anual mundial e instalar tudo”
É fácil ver a Amazon como agindo de má-fé em relação ao IPv4, mas, considerando a escala dos sistemas da AWS, também é bastante plausível que substituir todo o hardware de rede antigo fosse um projeto grande demais para um prazo curto
Suspeito que fosse meio papo furado ou, no mínimo, uma forma criativa de embalar os fatos. Por exemplo, talvez na prática tudo tivesse suporte a IPv6, mas engenheiros de rede cheios de medo, incerteza e dúvida não quisessem ativá-lo
A maior parte dos equipamentos de rede que vi já era dual stack muito antes de o IPv6 ser usado de fato ao redor, e eu sempre achei que isso tivesse entrado por exigências do governo ou das forças armadas dos EUA
Não lembro quem era o PM desse projeto, mas foi nessa época que passei a respeitar de verdade o valor que um TPM podia gerar
É verdade que o custo e a necessidade de substituir equipamentos de rede foram um dos motivos fortes para não ir para IPv6. A Amazon usava equipamentos de rede projetados e fabricados internamente por vários motivos, e provavelmente ainda usa
Esses equipamentos tinham todos capacidade fixa de memória, então, para aumentar a memória o suficiente para lidar com tabelas de roteamento IPv6 etc., seria necessário substituí-los. Mesmo que tivessem escolhido apenas IPv6, o hardware existente não teria sido suficiente e, de qualquer forma, seria difícil passar sem dual stack IPv4/IPv6
Ela parece estar sempre em projetos de escala enorme, e IPv4 agora é uma parte pequena disso. Infelizmente não posso compartilhar alguns dos grandes projetos em que ela está trabalhando agora
Ela já reservou tempo algumas vezes para me dar conselhos sábios, e sou grato por isso
Com certeza eles já começaram o processo
Certo? É difícil imaginar a AWS enfiando a cabeça na areia e ignorando isso
Parece claramente contra os incentivos da AWS oferecer um IPv6 que funcione direito. As ferramentas de influência da AWS, como os critérios Well-Architected e certificações, empurram fortemente para a criação de um labirinto de redes 10.x RFC1918 com endereçamento ambíguo, em vez de arquiteturas no estilo da internet com endereçamento fim a fim
No mundo das recomendações da AWS, o próprio conceito de “endereço IP público” é um sinal de alerta, e a AWS até recomenda ferramentas que cobram a mais para exibir e “mitigar” esses endereços
Fazer o cliente gastar esforço construindo infraestrutura complexa em nome da segurança cria um forte efeito de lock-in. Mesmo que, na prática, isso prejudique a segurança por meio de complexidade desnecessária, ambiguidade de endereços etc.
Já nem dá para contar quantos produtos surgiram, como “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, “Virtual WAN”, e todos existem para operar IPv4 em grande escala
Se tivessem feito o IPv6 funcionar direito, literalmente nenhum desses produtos seria necessário
Em vez disso, o Azure também faz NAT em IPv6, então nem dá para usar IPv6 para evitar o NAT imposto pelo IPv4. Mesmo em 2023, eles continuam lançando novos produtos que não suportam IPv6 e provavelmente continuarão assim
A documentação ainda tem uma página inteira de limitações: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
Dá para ver como isso é absurdo se você imaginar que fosse a transição de IPX para IPv4. É como se essa página dissesse algo como “Limitações do IPv4: toda VM deve conter pelo menos um endereço IPX”
Não soa estranho? Em 1999, clientes estavam sendo migrados de IPX para IPv4, e o suporte a IPv6 apareceu por volta de 2001–2003. Décadas depois, ainda parece a era anterior à migração do Novell NetWare, quando se dizia “ainda nem tudo suporta IPv4, então precisamos de IPX+IPv4”
Essa lista está longe de cobrir todas as limitações. Como a maioria dos produtos PaaS não suporta IPv6, uma solução IaaS+PaaS acaba tendo de usar majoritariamente IPv4
Não entendo por quê, mas, até que alguma grande empresa de tecnologia promova endereçamento fim a fim como boa prática, não há escolha a não ser seguir a sabedoria convencional para não criar sinais de alerta
Os clientes querem suas próprias redes privadas para impedir invasões e vazamentos de dados mesmo em máquinas que não pertencem a eles. Além disso, querem colocar dentro dessa rede serviços PaaS bem completos, do tipo “baterias inclusas”
Meu palpite é que o motivo é mais banal. Considerando até a quantidade de serviços da AWS, suportar IPv4 é simplesmente mais fácil
Como cliente da AWS, eu gostaria de me livrar do próprio IP. Gerenciar um sistema de rede complexo composto por protocolos antigos como IP, BGP e DNS é perda de tempo
Bastaria associar uma identidade forte às cargas de trabalho e permitir aplicar por política apenas quais cargas podem trocar dados com quais outras
Como os dados vão de uma carga de trabalho a outra não deveria ser da minha conta; deveria simplesmente funcionar
Em vez de cair num datacenter virtualizado, isto é, num zoológico de componentes de rede imitada, elas abstraem tudo
Na prática, isso nunca funcionou direito e nunca vai funcionar. Há nuances e detalhes demais a considerar para executar e otimizar workloads reais
Pela minha experiência, o maior problema ao ir para somente IPv6 na AWS é que o GitHub ainda não funciona com IPv6. Inúmeros softwares presumem que conseguem se conectar ao GitHub para baixar alguma coisa
Dá para usar um serviço NAT64 público, mas ele não é muito confiável para usos sérios: https://nat64.xyz/
A AWS cobra valores absurdos pelo tráfego do NAT Gateway, e não sei se dá para configurá-lo para interceptar apenas o tráfego destinado a hosts somente IPv4. Se eu estiver errado, gostaria de saber
Fora isso, usar somente IPv6 na AWS funciona sem falhas e sai mais barato. O gateway de egresso para redes privadas é gratuito. Claro, isso parte do pressuposto de que você não se importa com IPv4
Na minha opinião, o verdadeiro problema é que Lambda e S3 não oferecem suporte a IPv6, e a AWS deveria primeiro tê-los tornado dual-stack e acessíveis via IPv6 antes de mudar os preços
Tecnicamente, o S3 até tem um endpoint dual-stack separado, mas isso não ajuda muito, porque, de qualquer forma, para lidar com essa mudança é preciso alterar a configuração da aplicação
Metade do motivo de a AWS estar relativamente à frente no suporte a IPv6, para começo de conversa, é o mandato de política do governo dos EUA para iniciar a migração
Do ponto de vista de custos, é verdade que a nova cobrança é irrelevante para grandes clientes, mas não se deve subestimar a força dos mandatos de política dos maiores clientes. Só a ameaça de criarem alternativas próprias para cumprir políticas já pode acabar fazendo a AWS elevar a prioridade do suporte
O lado do cliente, ou seja, dos usuários finais, parece estar indo bem. Basta ver que o Google hoje reporta quase 50% de tráfego IPv6 de usuários finais
Para mim, o pior é o CloudFront não oferecer suporte a IPv6 em origens personalizadas
Se você roda muitos contêineres Fargate separados como origem, precisa habilitar endereços IPv4 públicos, e em breve o custo de contêineres pequenos vai dobrar
A Amazon deveria fazer sua própria infraestrutura realmente suportar IPv6 antes de cobrar taxas extras pelo uso de IPv4 legado
Entendo que a Amazon criou um monstro gigantesco e que implantar IPv6 em inúmeros serviços é um trabalho enorme, mas não vejo motivo para o CloudFront não oferecer suporte a origens IPv6 já agora — ou melhor, desde ontem
Relativamente, nem parece tão difícil assim, e poderia ser uma boa ferramenta para contornar outras limitações
Sinceramente, até agora eu sentia que as decisões da Amazon, no fim, levavam em conta o melhor interesse dos clientes, mas agora não. Vejo isso como um mau sinal para o futuro
Ter uma concorrência real entre ISPs nos EUA teria ajudado muito
O lugar onde moro de aluguel fica num subúrbio perto de Seattle, mas ainda assim há apenas um ISP de banda larga de fato. Não é zona rural por definição nenhuma, mas a Comcast é a única opção. Preço e serviço refletem exatamente essa realidade
Não é que, por acaso, “só exista a Comcast”; é que, por regulamentação legal, “só existe a Comcast”
O curioso em reclamar da Comcast é que, quando eu usava Comcast, havia IPv6 nativo. Meu provedor atual só oferece IPv6 via NAT46
Tem desvantagens, como queda de desempenho durante chuva forte, mas já vi algumas avaliações positivas
A maioria não sabe que hoje existem duas internets IPv6. Há a do lado da Cogent e a do lado da Hurricane Electric; as duas têm porte parecido e se recusam a se conectar. Então é preciso saber disso e comprar trânsito das duas, ou comprar de uma rede que compre trânsito das duas
Pelo menos um grande operador que conheço ainda roda v6 sobre túneis. Em muitos lugares, o tráfego v6 segue rotas não ideais, e redes corporativas podem ter conexão v4 em cada datacenter, mas mandar todo o v6 para “aquela caixa embaixo da mesa do Dave”
Mesmo assim, medem a adoção de v6 em lugares como Google ou Cloudflare, onde equipes dedicadas garantem a entrega dos pacotes, e ficam se parabenizando
A expressão “não conseguem sair do IPv4” é adequada. Dá para criar uma VPC somente IPv6, mas coisas demais quebram, de vários serviços da AWS até repositórios de pacotes: https://blog.devopstom.com/ipv6-only-ec2/
No fim, é preciso ativar o IPv4, rodar você mesmo um gateway NAT64 ou confiar em um NAT64 operado por alguém: https://nat64.net e http://v4-frontend.netiter.com
Dizer que “no IPv6 não existe o conceito de endereço privado, então adeus ao Managed NAT Gateway e ao preço grandioso dele” pode até valer dentro da AWS, mas no IPv6 existem os endereços IPv6 locais únicos de fc00::/7 e, se você realmente ama NAT, também existe NAT66
Ainda assim, ULA não costuma ser recomendado, e NAT66… simplesmente não rola
Pelo que ouvi recentemente, a Microsoft fez o IPv6 do Azure todo centrado em NAT. Muito estranho