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

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.

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

1Descobrir 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.

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.

2Perguntar 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.

3Trocar 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.

4Tirar 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.

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.

5Montar 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.

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.

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.