Preciso revisar meus custos de cloud
Resposta rápida
Revisar custos de cloud é o ritual mensal de FinOps que mais retorna em economia por hora investida. Estruture em quatro passos: ler o gasto do mês por serviço (compute, storage, banco, rede) e por ambiente (produção, homologação, desenvolvimento); identificar desperdício óbvio (instâncias ligadas sem uso, volumes órfãos, ambientes esquecidos, snapshots antigos); revisar dimensionamento (instâncias superdimensionadas, autoscaling mal configurado); decidir reserved vs on-demand para cargas previsíveis. Defina alerta de budget no provedor para não descobrir o estouro no fechamento. Sem FinOps regular, custo cloud cresce silenciosamente — provedor cobra por uso e o uso cresce com tudo: cada novo projeto, cada ambiente esquecido, cada experimento não desfeito.
Na empresa pequena, o ambiente cloud costuma ser modesto — algumas instâncias, banco gerenciado, storage, alguns serviços SaaS sobre nuvem. A revisão mensal cabe em 30 minutos olhando o relatório do provedor. O desperdício mais comum aqui é ambiente esquecido: máquina de teste ligada há meses, banco de homologação que ninguém usa, snapshot antigo se acumulando. Outra fonte: SaaS pago para mais usuários do que existem ativos. A disciplina mínima é olhar a fatura junto com o uso uma vez por mês e tirar o que não está sendo usado. Reserved instance raramente compensa nesse porte — falta previsibilidade de carga. O importante é tirar gordura visível; sofisticação fica para depois.
Na empresa média, o ambiente cloud já tem volume e múltiplos times provisionando. A revisão mensal vira ritual de uma a duas horas com responsáveis por área. O desperdício se espalha em mais frentes: instâncias superdimensionadas, autoscaling configurado errado (escala mas não desce), workloads de teste em horário comercial 24/7, banco RDS sem leitura crítica em alta disponibilidade desnecessária. Aqui já compensa olhar reserved e savings plans para cargas previsíveis — pode trazer 20% a 40% de economia em compute estável. O risco característico é provisionamento sem governança: cada dev provisiona o que quer, tag não é obrigatório, e no fim do mês ninguém sabe a quem cobrar. Política de tagging obrigatório e alerta de budget por projeto resolvem boa parte.
Na empresa grande, FinOps é função formalizada com time dedicado e ferramenta especializada (CloudHealth, Cloudability, Apptio, ferramenta nativa do provedor ou stack próprio). Múltiplas contas, múltiplos provedores, contratos enterprise com desconto negociado. O risco aqui não é falta de visibilidade — é excesso de complexidade: cada unidade negocia seu próprio commitment, cargas migram entre regiões, e o cálculo de show-back ou charge-back exige modelo de custo unificado. Foco em chargeback maduro (cada área vê e paga pelo que consome) muda comportamento: enquanto cloud era custo de TI, o dev provisionava livremente; quando vira custo da área usuária, a disciplina muda. Reserved e savings plans são geridos como portfólio, com renovação planejada.
- A fatura cloud cresce mês a mês sem explicação clara
- Você não sabe o que cada serviço cloud está custando
- Existem instâncias ligadas que ninguém reclama se desligar
- Snapshots e volumes antigos se acumulam sem alguém limpar
- Você nunca olhou se reserved instance compensaria
- O CFO descobre o estouro de cloud antes de você
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.
- Puxe o relatório consolidado. Custo do mês por serviço, ambiente e tag (quando houver). Compare com o mês anterior e com a média de três meses.
- Investigue desvios maiores que 10%. O que cresceu? Por que cresceu? Foi planejado (projeto novo, sazonal) ou foi descuido (ambiente esquecido, autoscaling ruim)?
- Rode a lista de desperdício óbvio. Instâncias ociosas, volumes órfãos, snapshots antigos, IPs não usados, load balancers sem tráfego. Ferramenta nativa do provedor já marca esses.
- Revise dimensionamento. Instâncias com utilização média abaixo de 20% são candidatas a redução. Autoscaling com piso alto demais é candidato a baixar piso.
- Avalie commitments. Reserved instances ou savings plans para cargas estáveis de produção. Modele economia versus risco de subutilização do commitment.
- Atualize alertas de budget. Limite por conta, por projeto, por serviço. Alerta em 80%, 90% e 100% do limite para agir antes do fechamento.
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.
Cortar sem entender. Desligar instância "porque está cara" sem mapear o que rodava nela é receita para incidente. Investigar antes de cortar, mesmo quando o desperdício parece óbvio.
Reserved demais. Commitment agressivo no início — antes de entender a carga real — gera capacidade não usada. Comprometer com o piso conservador e expandir depois é mais seguro do que o contrário.
FinOps como projeto pontual. Faxina anual de cloud economiza no mês mas o desperdício volta. Sem cadência mensal, a economia evapora em três meses.
Sem tagging consistente. Quando recurso não tem tag, não se sabe a quem cobrar. Sem responsável, ninguém defende o gasto e ninguém corta o desperdício. Tagging obrigatório resolve.
- Desvios acima de 10% têm explicação documentada
- Instâncias ociosas e recursos órfãos foram identificados e tratados
- Instâncias com utilização baixa foram avaliadas para redimensionar
- Commitments existentes têm cobertura adequada para a carga atual
- Alertas de budget estão configurados em 80%, 90% e 100%
- Tagging cobre pelo menos 90% dos recursos com custo
- O número de hoje fecha com o mesmo número no relatório anterior