Como reduzir custo de AWS sem degradar produção

O desperdício raramente está onde procuram

Quando a fatura assusta, o primeiro reflexo é negociar desconto ou trocar instância por uma menor. É a alavanca mais arriscada e quase nunca a maior.

Na prática, o desperdício se concentra em três categorias: recurso que ninguém usa, dado guardado na classe errada e tráfego que ninguém mediu. Nenhuma delas exige reduzir capacidade de produção.

Abaixo, sete frentes ordenadas por risco — as primeiras não tocam em produção.

---

1. Recursos órfãos (risco: nenhum)

É dinheiro parado, e toda conta com mais de um ano tem.

• Volumes EBS desanexados. Instância morreu, o disco ficou — e continua cobrando por GB/mês.
• Snapshots sem política de retenção. Snapshot diário há três anos sem expiração é um dataset inteiro pago do zero.
• IPs elásticos não associados. IP alocado e não usado é cobrado justamente por não estar em uso.
• Load balancers sem target. Ambiente desligado, o ALB continua de pé.
• NAT Gateways esquecidos em VPCs de projetos encerrados. Um NAT ocioso custa mais do que a maioria imagina, porque cobra por hora e por GB processado.

Comece por aqui. É reversível, não afeta ninguém e costuma pagar a auditoria inteira.

---

2. Ambientes de não-produção ligados 24×7 (risco: baixo)

Desenvolvimento, homologação e QA raramente precisam existir de madrugada e no fim de semana.

Um ambiente que roda só em horário comercial — 12h por dia, 5 dias por semana — fica ligado 60 das 168 horas da semana. É uma redução de aproximadamente 64% naquele ambiente, sem discussão técnica alguma.

Agende o desligamento e a religação. O atrito real é cultural: alguém vai reclamar que precisou do ambiente às 22h. Resolve-se com um botão de "ligar agora" — não com manter tudo aceso.

---

3. Classes de armazenamento no S3 (risco: baixo)

Muito bucket guarda tudo em Standard porque foi assim que nasceu.

• Lifecycle policy movendo objetos para classes mais baratas conforme a idade. Log de aplicação com 90 dias não precisa de acesso instantâneo.
• Intelligent-Tiering quando o padrão de acesso é imprevisível — ele move sozinho e cobra uma pequena taxa de monitoramento.
• Expiração de uploads multipart incompletos. Upload que falhou no meio deixa partes cobradas e invisíveis na listagem normal. É um clássico: buckets com dezenas de GB fantasmas.
• Versionamento sem expiração de versões antigas. Cada sobrescrita guarda a versão anterior, para sempre, se ninguém configurar a regra.

Antes de mover para classes de arquivamento, confira o custo de recuperação. Dado que você lê com frequência em classe fria pode sair mais caro que em Standard.

---

4. Transferência de dados (risco: baixo)

É a linha que ninguém entende e todo mundo paga.

• Cross-AZ. Tráfego entre zonas de disponibilidade é cobrado nos dois sentidos. Uma aplicação conversando com o banco em outra AZ paga por cada consulta. Em arquitetura com muita chamada interna, isso vira item principal da fatura.
• NAT Gateway. Todo tráfego de saída de subnet privada passa por ele e é cobrado por GB. Uma boa parte disso costuma ser acesso a serviços da própria AWS — que resolve com VPC Endpoints.
• Saída para internet. Servir arquivo estático direto do S3 ou da aplicação custa mais que servir por CDN.

Antes de otimizar, meça. Sem o relatório de custo detalhado com as tags certas, você vai otimizar a coisa errada.

---

5. Direito de compra: Savings Plans e Reserved (risco: baixo, se dimensionado)

Compromisso de uso reduz preço de forma relevante — e não muda nada tecnicamente.

O erro é comprar antes de arrumar a casa. Se você reservar capacidade e depois descobrir que 30% era desperdício, você comprou desperdício com desconto.

Ordem correta: limpar → medir a linha de base estável → só então comprometer. E comprometa o piso de consumo, não o pico. O que ficar acima roda sob demanda.

---

6. Rightsizing (risco: médio — aqui começa a doer)

Agora sim, ajustar tamanho de instância. E aqui é preciso disciplina.

• Olhe p95 e p99, não a média. Média baixa com picos de 100% significa que a instância está certa e o gráfico está mentindo.
• CPU não é a única dimensão. Memória, IOPS e rede prendem tanto quanto processador.
• Prefira mudar de família antes de mudar de tamanho. Gerações mais novas costumam entregar mais desempenho pelo mesmo preço, e a migração é menos arriscada que reduzir capacidade.
• Uma mudança por vez, com janela de observação. Reduzir dez serviços num sábado e descobrir degradação na segunda é ficar sem saber qual foi.

---

7. Banco de dados (risco: alto — por último)

RDS costuma ser a maior linha isolada da fatura, e por isso vira alvo. É o lugar onde otimização mal feita causa incidente.

O que é relativamente seguro: revisar retenção de backup exagerada, remover réplicas de leitura que ninguém consulta, desligar Multi-AZ em ambiente que não é produção.

O que exige cuidado real: reduzir a instância. Banco reage a pressão de forma não linear — funciona bem até parar de funcionar de uma vez.

E antes de reduzir hardware, olhe as consultas. Uma query sem índice pode ser a razão de você estar pagando por uma instância três tamanhos maior do que a necessária. Otimizar a consulta reduz custo e melhora latência; reduzir a instância só reduz custo.

---

O que fazer para não voltar

Corte é evento. Controle é processo.

• Tags obrigatórias de time, ambiente e centro de custo, aplicadas por política — sem tag, sem provisionamento.
• Budgets com alerta por conta e por tag, disparando antes do fim do mês.
• Revisão mensal de custo por serviço, comparada com o mês anterior. Variação inexplicada vira investigação.
• Custo no pull request. Mudança de infraestrutura que altera gasto deveria mostrar o delta antes do merge, do mesmo jeito que mostra teste.

A conta cresce em silêncio, um recurso por vez. Só um processo contínuo pega isso — auditoria semestral sempre encontra seis meses de desperdício acumulado.