# IP público cobrado na AWS: como achar e reduzir os IPv4 da conta

> A AWS anunciou a cobrança de todo IPv4 público. Como contar os IPs da conta, cortar os que não precisam existir e mover as instâncias para subnet privada.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos, Rede
- URL: https://pages.formacaoaws.com.br/blog/ip-publico-ipv4-cobrado-na-aws/
- Aula de origem: "IP público vai ser cobrado na AWS. E agora, o que fazer?" (https://www.youtube.com/watch?v=DIJ3ySPXD_8)

A AWS anunciou que todo IPv4 público passa a ser cobrado, até o IP público de instância em uso, que antes não custava nada. Aqui você vai contar quantos IPs públicos a sua conta tem e tirar das instâncias os que não precisam existir, com o plano que eu estava aplicando num cliente.

## O que mudou: todo IPv4 público passa a ser cobrado

Antes da mudança, a AWS cobrava IP elástico que não estava em uso, ou o IP elástico secundário que você coloca numa máquina. O IP público de uma instância em uso não custava nada.

A AWS anunciou que, a partir de 1º de fevereiro de 2024, passaria a cobrar todos: IP público em uso, IP elástico em uso e IP elástico ocioso. A tabela do anúncio mostra US$ 0,005 por hora para o IP público em uso, valor que eu resumi na aula como "mais ou menos 4 dólares por mês" por IP.

![A tabela do anúncio da AWS: IP público em uso sem cobrança até então e US$ 0,005 por hora a partir de 1º de fevereiro de 2024](https://pages.formacaoaws.com.br/blog/assets/posts/ip-publico-ipv4-cobrado-na-aws/tabela-preco-ipv4.webp)

> **Importante:** esses são os valores e a data do anúncio, como eu os citei na aula em outubro de 2023. Confira o preço atual na [página de preços da Amazon VPC](https://aws.amazon.com/vpc/pricing/) antes de fazer qualquer conta.

Quantas instâncias você tem? 50, 100, 200? Se não fizer nada, cada uma com IP público entra na fatura.

## Passo 1: descobrir quantos IPs públicos você tem

No console da EC2, toda instância mostra dois endereços: o `Public IPv4 address` e o privado. O público é o problema, é ele que passa a ser cobrado.

Para ter a conta inteira, em vez de abrir máquina por máquina, pesquise **IPAM** no console e abra o **Amazon VPC IP Address Manager**. Lá existe o **Public IP Insights**, que mostra quantos IPs públicos você tem. A meta, provavelmente, é zerar esse número.

![O Public IP Insights de uma conta em produção: 31 IPs públicos e 3 IPs elásticos sem associação](https://pages.formacaoaws.com.br/blog/assets/posts/ip-publico-ipv4-cobrado-na-aws/ipam-public-ip-insights.webp)

Esse print é da conta de produção do cliente que eu estava migrando. Já tínhamos tirado cerca de 50 IPs e ainda sobravam 31. Nem todos vão ser migrados, mas a conta mostra o tamanho da coisa:

- 81 IPs a 4 dólares por mês dão 320 dólares mensais, se nada fosse feito.
- Com 50 já fora e 31 restando, a conta fica em aproximadamente 120 dólares por mês.
- Isso dá perto de 1.500 dólares por ano.

São números da aula, arredondados, para dar a ordem de grandeza. A conta da sua infraestrutura sai do seu IPAM.

## Passo 2: perguntar por que cada máquina tem IP público

Com a lista na mão, faça a pergunta para cada instância: eu preciso que essa máquina tenha IP público? Se a resposta é sim, avalie por que ela precisa. Se é não, faça a migração.

O meu exemplo era uma instância que criei para trabalhar: conecto o VS Code nela e uso o Docker, como um ambiente de dev. O IP público estava lá por um único motivo, a conexão por SSH.

## Passo 3: trocar o SSH por acesso em IP privado

É a hora de refletir por que a gente ainda se conecta por SSH em IP público. Existem formas mais modernas, usando IP privado:

- **EC2 Instance Connect Endpoint.** A AWS liberou em 2023. Você continua conectando por SSH, só que em cima de IP privado.
- **SSM.** É a que eu prefiro. Também funciona em IP privado, e a instância nem precisa de chave `.pem`.

É um jeito mais avançado e mais seguro, porque você deixa de liberar regra de entrada para o seu IP.

## Passo 4: tirar os recursos da subnet pública

O segundo ponto é onde a instância está rodando. Abra a sua VPC no console e passe o mouse no internet gateway. Se todas as subnets acenderem, tudo na VPC é subnet pública. Foi o que eu vi na VPC padrão da conta.

![O mapa de recursos da VPC padrão com o mouse no internet gateway: as seis subnets acendem, todas ligadas a ele](https://pages.formacaoaws.com.br/blog/assets/posts/ip-publico-ipv4-cobrado-na-aws/vpc-subnets-publicas.webp)

Isso é problema de custo e de segurança. A saída é criar subnets privadas e migrar os recursos para elas. Como migrar depende de como o recurso foi lançado.

**EC2 lançada à mão.** Se ninguém a associou a um serviço de gerenciamento de aplicação (Elastic Beanstalk, ECS ou EKS), a migração também é manual:

1. Na instância, gere uma imagem (`Create image`), dê um nome e escolha se reinicia ou não no processo.
2. Quando a imagem aparecer em AMIs, selecione-a e lance uma instância a partir dessa AMI.
3. Na hora de lançar, escolha uma subnet privada.

Você vai precisar saber se conectar à nova instância por EC2 Instance Connect Endpoint ou por SSM, que é o Passo 3.

**Elastic Beanstalk.** É mais simples. Escolha o ambiente, edite as opções de rede, desmarque o IP público e troque as subnets públicas pelas privadas. O Beanstalk tira as instâncias com IP público e coloca as novas com IP privado.

> **Importante:** antes disso, as subnets privadas precisam existir e você precisa ter definido como elas vão se comunicar com o Beanstalk: por NAT Gateway ou por VPC endpoint, já que elas não operam mais pelo internet gateway.

## Passo 5: montar o desenho final

O que eu recomendo, num desenho: dentro da VPC, na subnet pública, ficam o Application Load Balancer e o NAT Gateway, com uma rota que dá saída para a internet. As instâncias EC2 ficam nas subnets privadas.

**Fluxo:** Application Load Balancer (na subnet pública) → Amazon EC2 (na subnet privada, sem IP público) → NAT Gateway (rota de saída para a internet)

Com a saída pelo NAT, as instâncias privadas conseguem alcançar a internet, falar com o Beanstalk, com outros serviços da AWS e com APIs de terceiros.

> **Importante:** o NAT Gateway público também usa um IPv4 público, o Elastic IP que você associa a ele na criação, e esse endereço é cobrado como qualquer outro. Tirar o IP das instâncias não zera os IPv4 públicos da conta. Veja a [documentação do NAT Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) e a [página de preços da Amazon VPC](https://aws.amazon.com/vpc/pricing/).

![Dentro da VPC: ALB e NAT Gateway na subnet pública, as instâncias EC2 (riscadas na pública) agora na privada, o NAT Gateway com saída para a internet, e o bastion host (BH) com SSM para o acesso do usuário](https://pages.formacaoaws.com.br/blog/assets/posts/ip-publico-ipv4-cobrado-na-aws/desenho-subnet-privada.svg)

Se sobrar algum recurso que precisa ser acessado de fora, como o servidor de build do meu projeto, use um bastion host. Pode ser uma instância com SSM, na subnet privada, com redirecionamento de porta para o usuário se comunicar com ela de forma local.

## Checklist

- Abra o IPAM, vá em Public IP Insights e anote quantos IPs públicos a conta tem.
- Para cada instância, responda: ela precisa de IP público? Se não, migre.
- Troque o acesso por SSH em IP público por EC2 Instance Connect Endpoint ou SSM.
- Passe o mouse no internet gateway da VPC: se todas as subnets acendem, está tudo público.
- Crie subnets privadas e mova as instâncias: por AMI na EC2 avulsa, pela configuração de rede no Beanstalk.
- Antes de migrar, defina a saída das subnets privadas: NAT Gateway ou VPC endpoint.
- Deixe só o load balancer e o NAT na subnet pública. O NAT Gateway público também usa um IPv4 público (Elastic IP), que é cobrado.
- Confira o preço atual do IPv4 público na página oficial de preços da Amazon VPC.

Fazer esse plano antes da cobrança chegar poupa o cliente da surpresa na fatura, e foi o que eu estava fazendo com o meu.