IPv4 e IPv6: como reduzir custos sem perder compatibilidade

Uma empresa mantém dez servidores na nuvem, cada um com um IPv4 público. Ao revisar a conta, percebe que paga pelos endereços além de computação, disco e tráfego. Surge uma possibilidade: usar IPv6 nos servidores e retirar os IPv4. Mas o site continuará acessível para quem usa uma rede que só oferece IPv4? E as integrações com pagamentos, email e backup?

Nesse exemplo hipotético, a economia depende de uma decisão de arquitetura. É possível adotar IPv6 e reduzir o uso de IPv4 público preservando o acesso dos usuários, desde que a solução cubra a entrada de conexões, a comunicação com a aplicação e a saída para serviços externos.

O que muda entre IPv4 e IPv6

IP é o protocolo que permite endereçar interfaces de rede e encaminhar pacotes entre redes. IPv4 e IPv6 são versões desse protocolo. O IPv4 utiliza endereços de 32 bits, como 192.0.2.10. O IPv6 amplia o endereçamento para 128 bits, como 2001:db8::10, conforme a especificação IPv6 da IETF. Os dois exemplos são reservados para documentação.

Um endereço maior oferece espaço para muito mais dispositivos e redes. Isso permite expandir a infraestrutura com menor dependência do compartilhamento de endereços IPv4. Não significa que todo dispositivo deva ficar acessível pela internet: roteamento e regras de acesso continuam sendo decisões separadas.

No IPv4, redes locais costumam usar endereços privados. Um roteador com NAT traduz esses endereços para permitir conexões externas; no CGNAT, esse compartilhamento também acontece na rede do provedor. NAT não substitui uma política de firewall. Em IPv6, também é necessário definir quem pode iniciar conexões e quais serviços estarão expostos.

Um equipamento que só tem IPv4 não se comunica diretamente com um servidor que só tem IPv6. É preciso oferecer as duas famílias de endereços no serviço ou colocar um intermediário capaz de receber em uma família e conectar pela outra.

Por que adotar IPv6 se IPv4 ainda funciona?

IPv6 permite preparar aplicações para redes que já o utilizam e crescer com menor dependência de endereços IPv4 públicos, que podem ser cobrados individualmente. Também pode simplificar partes do endereçamento em ambientes planejados para ele.

A adoção, porém, precisa acompanhar a aplicação. Bibliotecas, monitoramento, VPNs, listas de IP permitidos e ferramentas de administração devem lidar com IPv6. A conectividade final depende do provedor e das rotas disponíveis; habilitá-lo não garante, por si só, menor latência, mais velocidade ou mais segurança.

Para muitos ambientes, o primeiro passo é operar com IPv4 e IPv6 simultaneamente, medir o comportamento e reduzir a dependência de IPv4 aos poucos.

Onde IPv6 pode reduzir custos

O custo mais fácil de identificar é o de IPv4 público. Na tabela de preços da Amazon VPC, consultada em 2 de novembro de 2026, a tarifa padrão publicada para IPv4 público em uso ou ocioso é de US$ 0,005 por endereço por hora. Existem exceções e benefícios que precisam ser verificados para cada conta.

Usando 730 horas como referência mensal:

IPv4 públicos cobrados	Cálculo	Custo mensal de referência
1	1 × 730 × US$ 0,005	US$ 3,65
10	10 × 730 × US$ 0,005	US$ 36,50
50	50 × 730 × US$ 0,005	US$ 182,50

Esses valores cobrem apenas os endereços, antes de eventuais benefícios e tributos. Não representam o custo total do ambiente nem uma tarifa comum a todos os provedores.

Se a empresa substituir dez IPv4 públicos por uma entrada compartilhada com dois IPv4 cobrados, a redução nessa rubrica seria de US$ 29,20 por mês. Esse é um cenário aritmético: a quantidade real de endereços depende do serviço, das zonas e da disponibilidade exigida.

Para decidir, desconte dessa redução o custo adicional do proxy ou balanceador, processamento, transferência e operação. A migração também tem custo inicial. Se uma nova camada custar mais do que os endereços retirados, a conta mensal pode aumentar.

Eliminar o IPv4 público de uma máquina também não elimina automaticamente despesas de NAT Gateway. A saída para destinos IPv4 pode continuar exigindo tradução e gerando cobrança. Compare o caminho efetivo do tráfego antes e depois da mudança.

Três formas de manter os usuários conectados

1. Dual stack: oferecer IPv4 e IPv6 juntos

Em uma implantação dual stack, o serviço aceita as duas famílias. O DNS publica um registro A para IPv4 e um AAAA para IPv6; o suporte de DNS ao IPv6 é definido na RFC 3596.

Clientes compatíveis podem utilizar mecanismos como Happy Eyeballs, que coordena tentativas de conexão para reduzir a espera quando um dos caminhos apresenta problemas. Isso ajuda a experiência, mas não corrige uma rota quebrada nem cria conectividade onde ela não existe.

Dual stack costuma ser uma boa etapa de adoção. Como mantém IPv4, não implica economia com endereços públicos por si só.

2. Entrada dual stack e servidores de origem IPv6

Para sites e APIs, uma alternativa é manter IPv4 e IPv6 na camada que recebe as conexões e usar IPv6 até os servidores da aplicação:

1. Acesso dos usuários: os visitantes se conectam ao domínio normalmente por IPv4 ou IPv6.
2. Entrada dual stack: um proxy ou balanceador recebe a conexão em qualquer uma das duas famílias de endereços.
3. Origem IPv6: o intermediário estabelece uma nova conexão IPv6 com o servidor da aplicação, que pode dispensar IPv4 público.

Uma mesma camada de entrada pode atender várias aplicações, conforme a arquitetura e a capacidade.

Antes de escolher uma CDN, proxy ou balanceador, confirme suporte a IPv6 na conexão com a origem. Aceitar visitantes IPv6 não prova que o produto alcance uma origem exclusivamente IPv6. Confira também portas, TLS, WebSocket, limites de upload, verificações de saúde e tratamento do IP do cliente. Cabeçalhos encaminhados devem ser aceitos apenas de proxies confiáveis.

A camada de entrada precisa da disponibilidade adequada ao negócio. Um proxy único pode transformar uma economia pequena em um ponto de falha. Restrinja também o acesso direto à origem para preservar os controles aplicados na entrada.

3. Manter IPv4 nas dependências que ainda precisam dele

Alguns serviços, protocolos ou integrações podem exigir IPv4. Nesses casos, mantenha um caminho compatível enquanto a dependência existir. Isso pode significar manter dual stack em parte do ambiente ou concentrar conectividade IPv4 em componentes específicos.

Situação	Caminho a avaliar
Site público com clientes de redes diferentes	Entrada dual stack
Várias aplicações web com origens compatíveis com IPv6	Entrada compartilhada com conexão IPv6 às origens
Integração que exige IP de saída IPv4 fixo	Saída IPv4 controlada, com custos e disponibilidade dimensionados
Serviço TCP ou UDP fora do escopo do proxy web	Solução específica para o protocolo ou manutenção de IPv4

Um proxy HTTP não resolve automaticamente email, VPN, jogos ou qualquer outro protocolo.

E quando o servidor IPv6 precisa acessar uma API IPv4?

Esse é um problema de saída, diferente do acesso de visitantes ao site. O NAT64 permite que clientes IPv6 iniciem comunicação com servidores IPv4 por meio de tradução. O DNS64 pode sintetizar registros AAAA a partir de registros A para viabilizar esse caminho.

O par exige infraestrutura e configuração adequadas. Aplicações com IPv4 literal, protocolos que carregam endereços no conteúdo e requisitos de IP de saída precisam de avaliação específica. Pode haver custos de tradução e tráfego.

NAT64/DNS64 não é uma solução automática para um visitante IPv4 acessar uma origem IPv6. Para esse sentido, planeje uma entrada compatível, como o proxy descrito acima.

Como adotar sem interromper a operação

Comece pelo inventário: quem acessa a aplicação, quais serviços ela consulta e como a equipe administra os servidores? Inclua pagamentos, webhooks, email, repositórios de pacotes, backups, VPNs e monitoramento.

Depois, faça uma implantação gradual:

1. Habilite e valide IPv6 na infraestrutura. Confira endereços, rotas, regras de nuvem, firewall do sistema e interfaces em que a aplicação escuta.
2. Verifique a segurança das duas famílias. Evite aplicar restrições apenas no IPv4. Preserve mensagens ICMPv6 necessárias ao funcionamento da rede, conforme as recomendações da IETF para filtragem de ICMPv6.
3. Teste antes de publicar AAAA. Um registro DNS só anuncia o endereço; não configura rede, TLS ou aplicação.
4. Valide acesso e integrações. Teste login, uploads, pagamentos e webhooks por redes IPv4-only, IPv6 e dual stack, incluindo dispositivos móveis.
5. Monitore por família de endereço. Compare erros, tempo de resposta e disponibilidade. Verifique também IPs em logs, alertas e listas de acesso.
6. Prepare reversão. Planeje TTL e mantenha o caminho anterior durante a observação. Alterações de DNS não removem imediatamente entradas em cache.
7. Retire IPv4 apenas onde estiver dispensável. Confirme entrada, saída, administração e recuperação antes de liberar endereços cobrados.

Comandos para um primeiro diagnóstico

Substitua example.com pelo domínio que você administra:

dig +short A example.com
dig +short AAAA example.com
curl -4 --connect-timeout 10 -I https://example.com
curl -6 --connect-timeout 10 -I https://example.com

Os dois primeiros comandos consultam DNS. Os seguintes tentam uma requisição HTTP HEAD usando a família indicada. O teste com curl -6 precisa de conectividade IPv6 na máquina e na rede de origem. Uma falha local, isoladamente, não comprova defeito no servidor. Alguns serviços também não aceitam HEAD; nesse caso, teste um endpoint apropriado.

Esses comandos são uma verificação inicial, não uma validação completa de produção. Se houver proxy, teste separadamente o caminho até ele e a conexão entre ele e a origem.

Perguntas frequentes

Posso usar um servidor somente IPv6 para um site público?

Pode, desde que os usuários sem IPv6 tenham uma entrada compatível que alcance essa origem. Um domínio apontando apenas para uma origem IPv6 não atende diretamente redes exclusivamente IPv4.

Basta adicionar um registro AAAA?

Não. O endereço anunciado precisa ter rota funcional, firewall adequado e serviço disponível. Publique o registro depois de validar essas condições.

IPv6 é sempre mais barato?

Não. A economia depende da cobrança do provedor, dos IPv4 que podem ser retirados e das camadas necessárias para manter o serviço funcionando. Tráfego, computação e operação continuam existindo.

Devo desligar IPv4 agora?

A decisão deve vir dos testes e das dependências. É possível habilitar IPv6 primeiro e manter IPv4 onde ainda for necessário, sem migrar todos os componentes de uma vez.

Como aplicar isso ao seu ambiente

Ao comparar servidores, coloque IP público, entrada de tráfego e saída para integrações na mesma conta. O comparador de VPS e cloud da Fidalgo ajuda a começar pela configuração de CPU e memória; os custos de rede precisam complementar essa análise.

Se sua empresa quer adotar IPv6 ou revisar gastos com IPv4, a Fidalgo pode ajudar a mapear dependências, desenhar a conectividade e validar a migração. Converse conosco sobre seu ambiente.