Tem um número que deveria tirar o sono de qualquer time de engenharia: 32% do orçamento de cloud é desperdiçado. Não em empresas pequenas sem governança. Em empresas que gastam milhões por ano. Recursos ociosos, instâncias superdimensionadas, snapshots órfãos que ninguém lembra que existem. Segundo um relatório da Harness, o desperdício projetado em infraestrutura cloud chegou a US$ 44,5 bilhões em 2025.

Durante anos, otimização de custos na nuvem foi tratado como problema do financeiro. O time de engenharia subia os recursos, o financeiro recebia a fatura e tentava entender. Esse modelo quebrou. Em 2026, a prática conhecida como FinOps (junção de "Finance" e "DevOps") se tornou obrigatória para quem trabalha com infraestrutura. E cada vez mais, para quem escreve código também.

O buraco de 32% que ninguém vê

O desperdício em cloud não é um problema novo, mas a escala mudou. Dados da Finout mostram que 72% das empresas gastam mais de US$ 1,2 milhão por ano com nuvem. Dessas, 36% ultrapassam US$ 12 milhões anuais. E apenas 30% das organizações conseguem dizer com clareza para onde esse dinheiro vai.

O desperdício se distribui de forma previsível:

  • Instâncias ociosas ou paradas representam 10-15% da fatura mensal em muitos ambientes
  • Compute superdimensionado (vCPU e RAM que ninguém usa de fato) adiciona outros 10-12%
  • Artefatos de storage órfãos (discos, snapshots, backups esquecidos) somam 3-6%

Organizações sem programa formal de FinOps reportam desperdício entre 35-40% do total gasto. Quem tem um programa estruturado reduz isso para 20-25%. A diferença entre ter e não ter processo é, literalmente, jogar fora um terço do orçamento.

O problema é que a maioria dos engenheiros nunca vê esses números. A fatura chega no financeiro, os alertas de billing vão para o gestor, e quem fez o deploy segue para o próximo sprint. Esse descolamento entre quem provisiona e quem paga é o que o FinOps tenta resolver.

O que é FinOps e por que saiu do financeiro

FinOps é a prática de unir engenharia, financeiro e negócio para gerenciar custos de cloud de forma colaborativa. A FinOps Foundation, que hoje tem mais de 95 mil membros e 34 mil empresas participantes (incluindo 93 das Fortune 100), define três princípios centrais: visibilidade, otimização e operação contínua.

Mas o que mudou em 2026 é o escopo. O State of FinOps 2026 mostra que 98% dos respondentes agora gerenciam custos de IA, um salto absurdo considerando que em 2024 esse número era 31%. Além de cloud pura, 90% dos times de FinOps já cobrem SaaS, 64% incluem licenciamento de software, e 57% gerenciam private cloud.

A estrutura organizacional também evoluiu. 78% dos times de FinOps reportam para o CTO ou CIO (18 pontos percentuais acima de 2023). 60% operam num modelo de enablement centralizado: um time core que define padrões e ferramentas, enquanto os squads de engenharia aplicam no dia a dia.

Para quem desenvolve, isso significa duas coisas. Primeira: custo virou métrica de engenharia, no mesmo nível que latência e uptime. Segunda: ferramentas de FinOps estão cada vez mais integradas no workflow de desenvolvimento, e não confinadas a dashboards que só o financeiro acessa.

De "quanto gastei" para "quanto custa servir um cliente"

A mudança mais significativa no FinOps recente é conceitual. A pergunta deixou de ser "quanto gastamos com cloud este mês" e passou a ser "quanto custa servir mais um cliente" ou "qual o custo marginal dessa feature".

Esse conceito se chama unit economics aplicado a cloud. Em vez de medir economia percentual na infraestrutura ("cortamos 15% do bill"), mede-se custo por outcome:

  • Custo por cliente ativo
  • Custo por feature específica
  • Custo por request de API
  • Custo por inferência de IA

A diferença é enorme na prática. Cortar 15% do bill pode significar degradar performance para todos os clientes. Mas saber que o cliente tipo A custa US$ 0,12/mês para servir enquanto o tipo B custa US$ 4,80 permite decisões de negócio: pricing diferenciado, limites de uso, otimização direcionada.

Para viabilizar unit economics, o pré-requisito é tagging consistente. Todo recurso de cloud precisa ter tags que conectem o custo ao produto, ao time e à feature que o consome. Sem tags, o bill é só um número grande. Com tags, vira informação acionável.

A especificação FOCUS 1.3 (FinOps Open Cost and Usage Specification) surgiu para padronizar esses dados entre providers. Se você trabalha com multi-cloud (AWS, GCP, Azure), o FOCUS normaliza os campos de custo num schema único, eliminando a reconciliação manual que consumia dias todo mês.

Na prática: medindo custo por feature

Medir custo por feature exige conectar três camadas: infraestrutura, aplicação e negócio. Não é trivial, mas também não exige uma revolução.

O primeiro passo é resource tagging. Na AWS, por exemplo, todo recurso pode receber tags de custo:

aws ec2 create-tags \
  --resources i-0abc123def456 \
  --tags Key=team,Value=checkout Key=feature,Value=payment-processing Key=env,Value=production

O segundo passo é configurar Cost Allocation Tags no console de billing para que essas tags apareçam no Cost Explorer e nos relatórios de custo.

O terceiro passo — e o que mais importa — é criar métricas compostas. Se o time de checkout processa 2 milhões de transações por mês e os recursos tagueados como feature=payment-processing custam US$ 3.400, o custo por transação é US$ 0,0017. Se esse número sobe sem que o volume de transações acompanhe, algo mudou: talvez um novo deploy com consumo maior, talvez uma instância que não escalou para baixo.

Ferramentas como CloudZero, Kubecost e o próprio AWS Cost Explorer com tags permitem automatizar esse cálculo. O ponto não é ter precisão de centavos. É ter visibilidade suficiente para perguntar "por que essa feature ficou 40% mais cara esse mês?" e ter dados para responder.

Uma prática que funciona bem é incluir custo estimado no PR review. Algumas empresas já exigem que mudanças de infraestrutura (Terraform, Pulumi, CloudFormation) passem por uma estimativa de custo antes do merge. Ferramentas como Infracost fazem isso automaticamente:

infracost diff --path=./terraform

O output mostra quanto o custo mensal vai subir ou descer com aquela mudança. Não substitui análise humana, mas traz custo para a conversa antes do deploy, não depois.

O caso especial dos workloads de IA

Se cloud já tinha um problema de custo, IA transformou num problema de escala diferente. GPUs industriais custam entre US$ 10.000 e US$ 30.000 cada. Treinar um modelo de linguagem grande pode custar milhões por execução. E data centers já consomem 2,6% da eletricidade global, com crescimento projetado de 15% ao ano segundo a IEA, pressionando os custos operacionais.

O State of FinOps 2026 não deixa dúvida sobre a urgência: gerenciamento de custos de IA é a habilidade mais procurada que times de FinOps planejam adicionar nos próximos 12 meses. Workloads de IA se tornaram a categoria de custo que mais cresce em infraestrutura cloud.

O desafio com IA é que os custos são menos previsíveis. Um endpoint de inferência pode ter custo estável por semanas e explodir quando o tráfego muda ou quando um prompt mal otimizado aumenta o consumo de tokens. Sem caching ou batching, o custo de inferência escala linearmente, e às vezes exponencialmente, com o número de requests.

Unit economics se torna ainda mais importante aqui. "Quanto custa cada chamada ao nosso modelo de recomendação?" e "Quanto mais caro fica servir esse feature de IA para cada novo usuário?" são perguntas que precisam de resposta antes de escalar, não depois.

Segundo dados da própria CloudZero, mais de US$ 20 bilhões em gastos anômalos de cloud foram detectados e corrigidos antes de chegarem à fatura em sua base de clientes, usando loops de controle em tempo real. Isso reforça algo que revisões mensais e thresholds estáticos de orçamento não conseguem acompanhar: em ambientes onde uso muda por hora e sistemas automatizados escalam em segundos, o controle de custo precisa operar na mesma velocidade.

Conclusão

FinOps deixou de ser uma disciplina de nicho. Com 93 das Fortune 100 participando da FinOps Foundation e 98% dos praticantes já gerenciando custos de IA, o recado é direto: custo de cloud é responsabilidade de engenharia tanto quanto disponibilidade e segurança.

Para quem desenvolve, o ponto de entrada mais acessível é tagging. Comece tagueando recursos por time e feature. Depois, conecte esses dados ao volume de uso (transações, requests, usuários ativos). Com essas duas camadas, unit economics deixa de ser conceito abstrato e vira dashboard.

A próxima vez que subir uma instância ou configurar um auto-scaling, vale se perguntar: eu sei quanto isso vai custar por cliente? Se a resposta for não, o problema não é de infraestrutura. É de visibilidade.

Referências pesquisadas nesta publicação