Onde a conta da AWS vaza: sete alavancas que encontramos em contas reais

Em diagnósticos de custo em contas de produção de médio porte, a maior economia raramente está em reserva de instância. Está em configuração: mídia servida direto do S3 sem CDN, banco serverless respondendo a carga constante, ambientes de homologação ligados 24 horas sem ninguém usar.

A ordem que usamos para priorizar é sempre a mesma: primeiro o que economiza sem risco e sem compromisso (cache, desligar o que está órfão, apagar snapshot antigo), depois o que exige uma janela (redimensionar, migrar tipo de instância), por último o que amarra dinheiro por um ano (Reserved Instances e Savings Plans).

Um exemplo recorrente: uma plataforma de conteúdo pagava cerca de US$ 1.400 por mês de tráfego de saída porque o CDN estava na frente do site, mas não na frente do bucket de mídia. Uma regra de cache com TTL de 30 dias resolveu. Só depois disso fazia sentido comprar reserva para o banco, porque a projeção de uso ficou estável.

Aurora Serverless v2 é excelente para carga irregular. Em carga constante, uma instância provisionada com reserva de um ano costuma custar menos, e a migração pode ser feita com failover de segundos. O erro comum é decidir por reserva antes de estabilizar o consumo.

As sete alavancas, em ordem de frequência: egress sem CDN, serverless em carga constante, ambientes sem agendamento, EIPs e volumes órfãos, snapshots sem política de retenção, instâncias superdimensionadas, e ausência de reserva depois que tudo acima está resolvido.

Regra que vale para qualquer conta: toda ação destrutiva ou irreversível passa pelo dono do recurso. O diagnóstico é somente leitura e a economia é estimada por ação, com premissas explícitas, para que a decisão seja de quem paga a fatura.

Como validar cada alavanca antes de agir

Cada alavanca tem um jeito de ser confirmada com dado, sem alterar nada, e é assim que um diagnóstico somente leitura chega a uma economia anualizada por ação. Egress: no Cost Explorer, filtre por tipo de uso DataTransfer-Out e cruze com os buckets e instâncias de origem; se a mídia sai direto do S3, o número está lá. Banco: compare CPU e conexões médias dos últimos 30 dias no CloudWatch com o porte contratado; um banco a 12% de CPU o mês inteiro está pagando por um pico que não existe. Ambientes de não produção: agrupe por tag de ambiente e olhe o consumo por hora ao longo da semana; se a curva é reta no fim de semana, ninguém desliga. Órfãos: volumes EBS sem instância anexada, IPs elásticos sem associação, load balancers sem destino saudável e snapshots com mais de 90 dias aparecem em consultas simples no Config ou no Trusted Advisor. Armazenamento: métricas de acesso do S3 mostram objetos que ninguém lê há meses em classe Standard. Compute: o relatório de cobertura de Savings Plans mostra o que roda sob demanda há mais de 90 dias sem reserva.

Reservas: o erro de comprar antes de limpar

A alavanca mais vendida é a que mais se erra. Savings Plans e instâncias reservadas devolvem parte relevante do valor em troca de um compromisso de um ou três anos, e por isso a tentação é comprar logo. Só que reserva comprada para um ambiente inchado é compromisso com o desperdício: a empresa paga por um porte que ia encolher depois de redimensionar o banco, desligar homologação à noite e mover cargas para ARM. A ordem correta é limpar, estabilizar o consumo por algumas semanas e só então dimensionar a reserva sobre o baseline novo, calculando o payback de cada compromisso antes de assinar. É comum a economia com reserva cair pela metade em valor absoluto depois da limpeza e, mesmo assim, ser a melhor decisão, porque o total é menor.

O que fazer quando a arquitetura é o problema

Há contas em que as sete alavancas resolvem uma parte e a outra parte é estrutural: um monólito que exige a maior instância disponível para atender um pico de duas horas por dia, um processamento em lote que roda em servidores ligados o tempo todo, um banco relacional usado como fila. Nesses casos, a economia vem de projeto, não de ajuste: filas e funções serverless para o pico, agendamento para o lote, cache distribuído na frente do banco. Esses itens entram no plano com custo e prazo próprios, e a decisão de fazê-los é do negócio, comparando o investimento com a economia mensal que devolvem. O erro é misturar os dois tipos de ação no mesmo cronograma e atrasar a economia fácil esperando a difícil.

Governança para a conta não voltar

Uma conta otimizada volta a crescer em seis meses se nada mudar na forma de operar. O que segura: um dono por conta e por ambiente, com meta mensal e alerta antes de estourar; tags obrigatórias por área, produto e ambiente, aplicadas por política, para que o relatório fale a língua do negócio; política de ciclo de vida para snapshots, logs e objetos, como código; estimativa de custo obrigatória para toda carga nova antes de ir para produção; e uma revisão mensal de trinta minutos entre engenharia e finanças sobre o mesmo relatório. Não é burocracia: é o que faz o CFO responder com fatura na mão quanto a tecnologia custa e o que devolve.

Contexto: o que o mercado mede

As alavancas acima aparecem em quase todo diagnóstico porque o desperdício é estrutural, não acidental. A Flexera, no State of the Cloud 2025, estima que 27% do gasto em nuvem é desperdiçado e que 84% das organizações têm dificuldade para gerir esse gasto; os orçamentos são estourados em 17%, em média. A FinOps Foundation, no State of FinOps 2025, coloca otimização de workload e redução de desperdício como a prioridade número um dos praticantes. O framework da fundação organiza o trabalho em Inform, Optimize e Operate: visibilidade primeiro, otimização depois, governança para não voltar ao ponto de partida. As sete alavancas deste artigo são a fase Optimize; sem a fase Operate, elas voltam em seis meses.