Preciso revisar meus custos de cloud

Onde mora o desperdício em cloud

Cloud cobra por uso, e uso cresce com tudo que sobe. O desperdício se concentra em padrões previsíveis: instâncias provisionadas para teste e nunca desligadas; ambientes de homologação ou desenvolvimento rodando 24/7 quando bastaria horário comercial; volumes EBS órfãos (sobreviventes a instâncias destruídas); snapshots antigos sem política de retenção; IPs elásticos não associados; instâncias superdimensionadas (CPU média em 5% por meses); load balancer sem tráfego; banco gerenciado em Multi-AZ desnecessariamente; logs e métricas em retenção infinita; tráfego cross-region por configuração incorreta.

Cada um desses padrões é simples de detectar e simples de remediar. O que falha é a disciplina de revisar. Sem ritual mensal, cada padrão se acumula. Em seis meses, a soma vira percentual significativo da fatura — usualmente entre 20% e 35% do total em ambientes sem FinOps maduro.

Análise por dimensão

Toda revisão começa cortando o gasto em três dimensões: por serviço (compute, storage, banco, rede, segurança), por ambiente (produção, homologação, desenvolvimento) e por projeto/área (quando tagging é maduro). Cruzar as três expõe padrão. Banco de homologação custando como banco de produção é sinal claro. Tráfego de rede dominando o gasto sugere arquitetura mal calibrada. Compute em desenvolvimento crescendo mais rápido que produção indica ambiente esquecido.

Reserved, savings plans e on-demand

Para cargas estáveis e previsíveis de produção, commitments (reserved instances, savings plans) trazem economia significativa em relação ao on-demand — geralmente entre 20% e 60%, conforme o termo (1 ou 3 anos) e a modalidade (no upfront, partial, all). O risco é o commitment ficar maior do que a carga real e você pagar por capacidade não usada. Por isso a modelagem importa.

Regra prática: comprometa-se com o piso da carga (o que você sabe que vai consumir), use on-demand para o pico variável, reavalie commitment a cada três a seis meses para ajustar. Em ambientes de desenvolvimento e teste, on-demand quase sempre é melhor — carga muda demais. Para storage, opções como Glacier e arquivamento frio cortam custo de dados que precisam existir mas raramente são acessados.

Governança de provisionamento

FinOps maduro não é só limpar gordura — é evitar que a gordura volte. Política de tagging obrigatório (área, projeto, ambiente, dono) é a base. Sem tag, recurso entra em "limbo" e ninguém reclama quando aparece na lista de candidato a remover. Aprovação para provisionamento acima de certo valor, alerta de budget por projeto, automação para desligar ambientes não produtivos fora de hora, política de retenção para snapshots e logs — cada um desses controles vira economia recorrente.