Sua conta de nuvem não é um problema de infraestrutura

A conversa sobre custo de nuvem quase sempre começa no lugar errado: qual instância desligar. É a pergunta que resolve o mês corrente e garante que o problema volte no trimestre seguinte, porque a causa não estava na instância.

O gasto é consequência da arquitetura

• Consulta sem índice adequado gera necessidade de um banco maior — o custo aparece em computação, a causa está no modelo de dados.
• Ausência de cache multiplica chamadas a serviços cobrados por requisição.
• Transferência entre zonas de disponibilidade custa caro e some no relatório agregado.
• Log em nível debug em produção gera terabytes de ingestão que ninguém consulta.
• Ambientes de homologação dimensionados como produção rodam 24 horas para serem usados 6.

Sem marcação, não há diagnóstico

A primeira medida não é economizar, é enxergar. Marcação obrigatória por centro de custo, produto, ambiente e time — aplicada por política, não por convenção. Recurso sem marcação não deveria ser provisionado.

Quando o gasto passa a ser atribuído a um produto, a conversa muda de natureza: deixa de ser "a nuvem está cara" e passa a ser "este produto custa 3% da receita que gera". A segunda pergunta é acionável.

A sequência que funciona

1. Visibilidade: marcação, painel por produto e time, alerta de variação anômala.
2. Desperdício óbvio: discos órfãos, IPs reservados sem uso, snapshots antigos, ambientes ociosos fora do horário útil.
3. Dimensionamento: ajuste a partir de métrica real de uso, não do que foi provisionado "por segurança" há dois anos.
4. Compromissos: reservas e savings plans sobre a linha de base estável, nunca sobre o pico.
5. Arquitetura: só então ataque as decisões estruturais que geram o gasto — e é onde está o ganho duradouro.

Os quatro primeiros passos entregam a economia rápida. O quinto é o que impede o custo de voltar a crescer.

FinOps é prática de engenharia

Colocar FinOps sob responsabilidade exclusiva de finanças não funciona, porque quem gera o custo é quem escreve o código. Funciona quando o time de engenharia vê o custo do próprio serviço no mesmo painel em que vê latência e taxa de erro — e quando eficiência entra na definição de pronto.

Em ambientes que nunca passaram por essa prática, reduções de 25% a 40% são comuns sem qualquer impacto em performance. O que raramente é comum é essa redução se sustentar sem mudar quem enxerga o número.