Reduzir custos na AWS: 6 estratégias que eu aplico nos clientes

A AWS passou a cobrar IP público, e esse é só um dos pontos da fatura onde dá para cortar. Aqui estão as seis estratégias, já validadas, que eu passo para os meus clientes: tirar o IP público, enxugar as zonas do load balancer, migrar para ARM, desligar o RDS de homologação fora do expediente, sair por CDN com Savings Bundle e ligar o Cost Optimization Hub.

Para cada uma eu explico o que fazer e respondo a objeção que costuma aparecer. Os valores são os que citei em abril de 2024: confira os atuais nas páginas de preços da AWS, como a da Amazon VPC, antes de decidir.

O que mudou: IP público passou a ser cobrado

A partir da fatura de março de 2024, a AWS passou a cobrar 4 dólares por mês por IP público alocado. Entra na conta qualquer recurso com IP público: EC2, load balancer, RDS publicamente acessível. As duas primeiras estratégias atacam essa cobrança.

1Acabar com o IP público

Se você paga IP público, seus recursos provavelmente estão em subnet pública. A saída é movê-los para a subnet privada e deixar só uma porta de entrada pública.

O banco (RDS). Em consultorias, encontrei bancos acessíveis publicamente com o argumento "os devs precisam acessar".

A alternativa é o que eu chamo de porteiro, o modelo de bastion host:

1. Mude o banco para privado.
2. Crie um túnel pelo porteiro até ele. No seu computador, você mapeia uma porta local para o banco: o PostgreSQL está na 5432, então você pode mapear a 5433 em localhost.
3. Se você pensou "o túnel SSH exige IP público no porteiro", use o porteiro com SSM. Com SSM, o porteiro e o banco ficam na subnet privada.
4. Configure a saída para a internet 100% pelo NAT Gateway, ajustando a route table.

As EC2. Aplicação web acessível direto pela EC2 só se justifica em projeto muito pequeno. O cenário adequado é um Application Load Balancer na frente: a EC2 vai para a subnet privada e o ALB é o único publicamente acessível. Você ganha segurança e paga menos IP público.

Quantos IPs públicos você tem? Use o IPAM (VPC IP Address Manager):

1. Abra o IPAM no console da VPC e crie um IPAM.
2. Marque a camada Free Tier: ela informa o uso de IP público da conta sem custo.
3. Depois de criado, abra Public IP Insights. As primeiras métricas levam cerca de 6 a 8 horas para aparecer.
4. Com os dados na tela, veja onde ainda há IP público e acompanhe quantos restam conforme você move os recursos.

2Diminuir as zonas de disponibilidade do ALB

Esta é nova: passei a aplicar nos clientes agora, e você deve conseguir aplicar assim que entrar na conta. Ao criar um load balancer sem muito domínio da AWS, muita gente marca todas as zonas disponíveis, de A a F, "porque a minha aplicação vai ter alta disponibilidade".

O ponto é que cada zona ativa do load balancer aloca um IP público na sua conta. Com duas zonas ativas, cada ALB custa 8 dólares por mês de IP; com seis, são 4 dólares por cada uma, e todas aparecem no relatório do IPAM.

A conta incha só por causa do IP público. Muita gente só percebe quando a parte de VPC explode na fatura, sem saber o motivo.

A objeção é "e a alta disponibilidade?". A chance de cair uma zona já é mínima; a de cair duas ao mesmo tempo é menor ainda. Se uma cair, a outra responde, e a AWS trabalha para recuperar a que caiu. No meu exemplo, tirei a zona A e o ALB ficou só na B e na C.

3Migrar para instâncias ARM

A t3.micro é a instância que a gente costuma usar no começo, antes de escalar para maiores. Com o preço sob demanda por hora multiplicado por 750 horas, você tem o custo mensal: para a t3.micro, aproximadamente 7 dólares e meio.

A t4g.micro usa a arquitetura ARM. Custa em média 20% menos que a t3.micro e é mais poderosa. Existe também a t3a.micro, como terceira opção na mesma tabela.

A objeção é "nunca trabalhei com ARM". Sair de x86 para ARM é tranquilo, basta entender a diferença. Dá para fazer o deploy direto na máquina ou por um pipeline, com a máquina de build preparada para ARM.

Por ser mais performática, a instância ARM faz mais operações com o mesmo processamento. Se você usa 10 instâncias t3.micro, é possível que 8 t4g.micro deem conta. Vale testar.

4Parar o RDS de homologação fora do expediente

Pense num banco de homologação, para o time de desenvolvimento trabalhar e fazer deploy. Você precisa dele ligado full time ou só de segunda a sexta, das 8h às 18h?

A conta que fiz: 8h às 18h, de segunda a sexta, dá em torno de 50 horas por semana. Contando 5 semanas no mês, são 250 horas, de um mês de aproximadamente 750. Você usa só um terço do tempo. Se hoje você paga 20, 50 ou 60 dólares só por esse banco, passa a pagar um terço. O mesmo vale para EC2.

Para automatizar, eu ensino com Lambda: uma função com agendamento nos horários de ligar e de desligar, informando qual banco ela opera. Roda às 8h, roda às 18h.

5Savings Bundle com a saída por CDN

Imagine um ALB na frente de um cluster de EC2. Com a saída de dados direto pelo load balancer, o free tier de transferência é de 100 GB, o que serve a contas pequenas.

Com um CDN na frente da aplicação, o CloudFront, o free tier de saída sobe para 1 TB. E há mais: você pode assumir um compromisso de uso com a AWS, o que ela chama de Savings Bundle.

A conta do exemplo, de volume alto: 30 TB por mês a aproximadamente 10 centavos de dólar por giga dá cerca de 100 dólares por TB. Pelo load balancer, são 3 mil dólares no mês.

Mudando toda a saída para o CDN e assumindo com a AWS o compromisso de 30 TB por mês, o desconto é de aproximadamente 30%, e o custo cai para cerca de 2.100 dólares.

6Ligar o Cost Optimization Hub

E a estratégia de que todo mundo fala, a redução por reserva e por compromisso de poder computacional? Ela entra aqui, num recurso que a AWS lançou no fim de 2023, no re:Invent: o Cost Optimization Hub, na área de Billing.

É gratuito e traz recomendações de economia em EC2, Lambda, volumes EBS e Savings Plans. Basta habilitar: normalmente em 24 horas ele começa a popular com os dados da conta.

As recomendações incluem:

• Redimensionamento: se você colocou uma instância muito poderosa por medo de não dar conta, e já há métrica suficiente, ele sugere uma menor.
• Volume EBS: se o tipo do volume está desatualizado, ele sugere o mais novo.
• Compromisso: com base no uso computacional, ele indica reserva e Savings Plans.

Checklist

• Crie um IPAM na camada Free Tier e liste os recursos com IP público.
• Mova o banco para a subnet privada e acesse por um porteiro com SSM.
• Ponha um Application Load Balancer na frente das EC2 e leve as EC2 para a subnet privada.
• Revise as zonas ativas de cada load balancer e tire as que não precisa.
• Compare a t3.micro com a t4g.micro e teste a sua aplicação em ARM.
• Agende com Lambda o desligamento do RDS e da EC2 de homologação fora do horário de trabalho.
• Coloque a saída de dados por CDN e avalie o compromisso do Savings Bundle.
• Habilite o Cost Optimization Hub e leia as recomendações no dia seguinte.

Para trabalhar com nuvem, não basta entender de cultura DevOps: a cultura de custo, o FinOps, também é muito importante. Se o projeto não for financeiramente viável, ele não se mantém: às vezes é descontinuado, às vezes um profissional é demitido. Cuide da saúde técnica e da financeira.