FinOps na prática: prever e cortar o custo da infra
Tetos de gasto, alertas e atribuição de custo por squad. Como sair do susto no fim do mês para um número que cabe no DRE.
A fatura do cloud chega e o valor assusta. Não porque a engenharia gastou à toa, mas porque ninguém sabia quanto cada serviço custava enquanto decidia subir aquilo. FinOps não é sobre cortar custos: é sobre dar contexto financeiro às decisões técnicas. Este guia organiza quando e como usar cada prática, sem transformar o engineering em controllers de planilha.
Todo engineering lead já passou por isso: a reunião de review trimestral revela que o custo de cloud cresceu 40% em seis meses e ninguém consegue explicar por quê. Não é má-fé. É ausência de infraestrutura de visibilidade. A solução não está em contratar outro FinOps engineer ou comprar mais uma ferramenta. Está em combinar práticas certas, na ordem certa, com o contexto organizacional correto.
Os três pilares e quando cada um importa
FinOps previsível não é um projeto: é uma stack de práticas que se reforçam. Se você tentar implementar tudo de uma vez, nada funciona. A decisão de por onde começar depende de três variáveis:
- Tamanho da operação: menos de 20 recursos ativos? Tagging manual funciona. Mais de 500? Precisa de automação e conventions enforced.
- Maturidade da engenharia: times que já usam IaC (Terraform, Pulumi) têm meio caminho andado para tagging consistente.
- Cultura de responsabilização: se o VP de engenharia pergunta "quanto custou" depois do deploy, você está no nível reativo. Se pergunta "quanto vai custar" antes, está no proativo.
A árvore abaixo guia o primeiro passo:
Pilar 1: Tagging que funciona em produção, não só na documentação
Tagging é a base de tudo. Sem ele, você tem custo total e nada mais. Com ele, tem custo por time, ambiente, projeto, serviço. Mas tagging que não é enforced vira um caixote de valores inconsistentes.
Quando tagging manual basta
Times pequenos (2 a 5 engenheiros), poucos recursos e convenção verbal funcionam. Crie um documento de referência, use padrão key:value consistente e revise na code review. Exemplo de estrutura:
Name=api-gateway-prod
Environment=production
Team=platform-engineering
CostCenter=platform-001
Application=payment-service
[email protected]
Quando tagging precisa ser automatizado A partir de 50 recursos ou 3+ times, manual falha. Ferramentas como CloudHealth, Spot.io ou o AWS Tag Editor com Rules permitem policy-as-code:
resource "aws_config_rule" "mandatory_tags" {
name = "mandatory-tags-enforcement"
source {
owner = "AWS"
source_identifier = "REQUIRED_TAGS"
}
input_parameters = jsonencode({
tag1Key = "Team"
tag2Key = "Environment"
tag3Key = "CostCenter"
})
}
A armadilha do tagging ornamental O erro mais comum é criar 15 tags e só usar 2. Tag que não alimenta uma decisão (alerta, budget, relatório) é ruído. Liste as perguntas que você precisa responder e defina tags para respondê-las. Menos tags, mais utilidade.
Pilar 2: Budgets que guiam decisões, não que travam deploys
Budget é a tradução financeira de uma meta técnica. "Não ultrapasse R$ 50k/mês em RDS na produção" soa como controle. "Mantenha o custo por transação abaixo de R$ 0.003" soa como engenharia.
Estrutura de budget por contexto
| Tipo | Alcance | Alerta (threshold) | Ação esperada |
|---|---|---|---|
| Budget de time | Todos os recursos do time | 80% do monthly budget | Review de recursos órfãos |
| Budget de serviço | Um serviço específico | 90% do monthly budget | Análise de otimização |
| Budget de experimento | Recursos de P&D | 100% com TTL definido | Cleanup automático |
| Budget de anomalia | Desvio vs baseline | 20% acima da média | Investigação urgente |
Alertas sem ruído Três alertas por budget é o máximo tolerável. Use uma escala progressiva:
# AWS Budgets - configuração de alertas em cascata
budget-alerts:
- threshold: 70 #% do budget
action: notify # canal #finops-ops
urgency: low
- threshold: 90
action: notify + escalation
urgency: medium
- threshold: 100
action: block + notify + PagerDuty
urgency: high
O threshold de 100% com action block deve ser raramente atingido. Se acontece toda semana, seu budget está mal calibrado, não sua engenharia.
O erro de budget zerado Se um time nunca teve budget, qualquer valor é surpresa. Comece com o valor atual (baseline) mais 10-15% de margem. Após dois meses com comportamento estável, refine. Budget existe para surpreender, não para punir.
Pilar 3: Cultura que sustenta sem virar burocracia
Práticas FinOps morrem quando viram formulário. O objetivo é responsabilização orgânica, não aprovação centralizada.
O modelo de FinOps tripartido A Fundação FinOps popularizou o conceito de três fases que coexistem:
- Crawl: visibilidade total. Todos veem todos os custos. Sem julgamento, sem meta. Apenas transparência.
- Walk: otimização orientada. Times começam a agir sobre os dados visíveis. Eliminação de recursos órfãos, rightsizing de instâncias.
- Run: otimização por design. Decisões técnicas já incluem projeção de custo. Engenharia e FinOps falam a mesma língua.
A maioria das empresas está entre Crawl e Walk. Pular para Run é receita de frustração.
Regra de ouro: uma pergunta, uma resposta, uma ação Para cada metric de custo visível, defina:
- Quem recebe a informação (owner do recurso, tech lead, CTO)
- Quando recebe (diário, semanal, mensal)
- O que deve fazer ao receber (uma única ação, não uma lista)
Exemplo:
- Informação: "Uso de EBS não anexado superou R$ 2k este mês"
- Quem: Platform team lead
- Quando: Relatório mensal de infraestrutura
- Ação: Executar script de cleanup até dia 15
Sem essa clareza, o relatório vai para a inbox, ninguém abre, o custo permanece.
Armadilhas comuns que destroem iniciativas FinOps
Tagging walls of shame: criar ranking público de times por custo gera tribalismo, não colaboração. Time A esconde recursos, time B otimiza demais e degradam performance. Shame não escala.
Budgets punitivos: se ultrapassar o budget significa cortes no headcount ou freeze de hiring, times vão manipular dados ou esconder custos. Budget é ferramenta de planejamento, não de punição.
Análise sem ação: relatório de 40 páginas que ninguém lê é inútil. Três métricas com ação clara vencem dashboards complexos.
FinOps como gatekeeper: se o FinOps team precisa aprovar todo deploy acima de R$ 100, você tem bottleneck, não governança. Empoderar times é mais eficaz que controlar centros.
Ignorar dados de vendor: Reserved Instances, Savings Plans e Spot têm lógicas próprias. Se você não os considera no budget, vai parecer que está sempre gastando mais do que deveria quando na verdade está otimizando.
A decisão que importa agora
Você não precisa implementar tudo hoje. Se sua fatura tem mais perguntas do que respostas, comece por duas coisas:
- Liste as três perguntas de custo mais importantes para sua operação (ex.: quanto custa nossa API por request? Quanto gastamos com infraestrutura de batch processing? Qual time está crescendo mais em custo?)
- Escolha uma prática que responda pelo menos uma delas (provavelmente tagging ou um budget com baseline)
Daqui a três meses, avalie. Se estiver funcionando, adicione a próxima camada. Se não estiver, a pergunta não é "qual prática falhou". É "qual organização falhou em consumir a informação". FinOps é 20% técnica e 80% organização. Invista na parte que realmente depende de escala.
Se a sua fatura de cloud cresce sem explicação e ninguém sabe de quem é cada custo, vale uma conversa de 30 minutos. A gente mapeia onde o gasto está escondido e mostra o que dá para recuperar, sem compromisso.