Resumo: A maioria dos times de FinOps acompanha métricas demais e age sobre poucas. As métricas que importam se dividem em quatro categorias: financeiras (variação orçamentária, precisão da previsão), operacionais (utilização, cobertura de commitments, potencial de right-sizing), desperdício (recursos ociosos, armazenamento órfão, gastos não alocados) e de negócio (unit economics, custo como percentual da receita). Quais priorizar depende do seu estágio de maturidade. Um time em estágio inicial (crawl) precisa de métricas de visibilidade. Um time em estágio maduro (run) precisa de unit economics. E, independentemente do estágio, uma métrica sem uma camada de ação por trás não passa de dashboard.
Falta de dados sobre custos em nuvem não é problema para os times de FinOps. AWS Cost Explorer, Google Cloud Billing, Azure Cost Management, plataformas de terceiros. Os dados existem. Difícil mesmo é achar sinal em meio ao ruído — os números específicos que mostram onde o desperdício está se acumulando, se o seu trabalho de otimização está surtindo efeito e se o gasto em nuvem cresce mais rápido ou mais devagar do que o negócio que ele sustenta.
É nesse abismo entre dado e sinal que a maioria dos frameworks de métricas desmorona. Os times montam dashboards com 40 KPIs, fazem revisões mensais que viram arqueologia de custos e patinam para explicar às lideranças de engenharia qual número elas realmente deveriam acompanhar nesta sprint. Segundo o Gartner, apenas 43% das organizações acompanham custos em nuvem no nível unitário, ou seja, a maioria dos times não consegue conectar a fatura da nuvem aos produtos e clientes que a geram.
Este artigo não é uma lista exaustiva de todas as métricas de custo em nuvem. É um framework para decidir quais delas merecem sua atenção em cada estágio de maturidade FinOps, quais ações cada uma deve disparar e onde os erros mais comuns de acompanhamento levam os times para o caminho errado.
O que são métricas de otimização de custos em nuvem e por que times de FinOps precisam de um framework?
Métricas de otimização de custos em nuvem são sinais quantitativos que conectam o comportamento de gastos em nuvem a resultados de negócio. Elas ajudam os times de FinOps a identificar desperdício, validar se o trabalho de otimização está gerando economia real e prever gastos futuros com precisão suficiente para embasar decisões de planejamento.
A definição é simples. A aplicação, nem tanto. O desafio é escolher as métricas certas para a pergunta que o seu negócio está realmente fazendo agora.
Acompanhar métricas demais dá no mesmo que não acompanhar nenhuma. Quando todo número tem o mesmo peso, nada é priorizado. As revisões viram retrospectiva, não ação. Os engenheiros desligam porque a relação sinal-ruído é baixa demais para justificar o esforço.
Uma abordagem em camadas resolve isso. Em vez de uma lista chapada com 30 KPIs, um framework em camadas organiza as métricas por categoria e estágio de maturidade. Cada camada responde a uma pergunta diferente: estamos enxergando nossos gastos com clareza? Estamos usando os recursos de forma eficiente? Estamos eliminando desperdício? Nosso gasto em nuvem cresce na mesma proporção do valor que ele gera?
O modelo crawl/walk/run da FinOps Foundation se encaixa naturalmente nessa estrutura. Times em estágio inicial precisam de métricas de visibilidade, times em estágio intermediário precisam de métricas de otimização e times maduros precisam de métricas de eficiência e valor de negócio. Pular etapas não acelera resultados; só cria complexidade de relatório sem a qualidade de dado por baixo para sustentá-la.
Que categorias de métricas de otimização de custos em nuvem impulsionam resultados em FinOps?
Quatro categorias de métricas cobrem toda a gama de decisões em FinOps: métricas financeiras, que acompanham a saúde do orçamento e das previsões; métricas operacionais, que medem a eficiência com que os recursos rodam; métricas de desperdício, que evidenciam gastos ociosos e órfãos; e métricas de negócio, que conectam o custo em nuvem ao valor que o negócio produz. Cada categoria responde a uma pergunta diferente e deve disparar ações diferentes.
Métricas financeiras: variação orçamentária e precisão da previsão
A variação orçamentária mede a diferença entre o gasto em nuvem planejado e o realizado, expressa em percentual. É a métrica financeira mais comum na gestão de custos em nuvem — e também a mais mal interpretada.
Uma variação negativa (gastar menos do que o orçado) parece saudável no dashboard, mas pode mascarar subutilização ou projetos atrasados. Uma variação positiva (gastar acima do orçado) só vale investigar se você conseguir separar crescimento orgânico de desperdício de verdade. Times que tratam qualquer variação positiva como problema acabam orçando de forma conservadora demais e travando os times de engenharia que deveriam apoiar.
A precisão da previsão mede o quanto o gasto previsto se aproxima do realizado ao fim de um período de faturamento. Benchmarks do setor consideram uma variação de 10 a 15% aceitável para a maioria das organizações, embora times com estratégias maduras de commitments e workloads estáveis frequentemente cheguem a 5% ou menos. A métrica importa porque previsões imprecisas geram problemas em cadeia: os times financeiros criam colchão nos orçamentos de tecnologia, os times de engenharia recebem alertas de gasto no meio da sprint e a liderança perde a confiança no FinOps como função de planejamento.
As duas métricas melhoram com o mesmo investimento por baixo: alocação de custo limpa, tagging obrigatório e visibilidade em nível de conta que torna as anomalias detectáveis antes de virarem variação.
Métricas operacionais: utilização, cobertura de commitments e potencial de right-sizing
As métricas de utilização medem quanto de um recurso provisionado seus workloads de fato consomem. A utilização de CPU e memória em instâncias de computação são os exemplos mais conhecidos, e o limite padrão para candidatos a right-sizing varia conforme o tipo de workload. A maioria dos times marca para revisão as instâncias com utilização média de CPU abaixo de 20 a 30%, embora workloads sensíveis a latência possam justificar um provisionamento maior por questão de folga.
A utilização, sozinha, é um sinal incompleto. Um cluster rodando a 15% de utilização de CPU pode estar superprovisionado, ou pode estar corretamente dimensionado para um workload que sobe para 90% no pico. As métricas de utilização só apontam onde olhar. Elas não dizem se o recurso está corretamente dimensionado até você analisar pico, média e percentis em conjunto.
A cobertura de commitments acompanha o percentual de workloads elegíveis cobertos por reserved instances, Savings Plans ou committed use discounts. Para a maioria das organizações rodando AWS, Google Cloud ou Azure em escala, o gasto on-demand não coberto sobre workloads estáveis é uma das maiores lacunas de eficiência de custo a fechar. Um time com 40% de cobertura de commitments em workloads que rodam 24/7 está deixando muita economia na mesa.
O potencial de right-sizing é a estimativa agregada de economia disponível ao reduzir ou modificar recursos superprovisionados em todo o ambiente. Ele é mais acionável do que o percentual de utilização sozinho porque expressa a oportunidade em valor financeiro — a unidade a que tanto líderes de engenharia quanto de finanças respondem.
Métricas de desperdício: recursos ociosos, armazenamento órfão e gastos não alocados
As métricas de desperdício identificam gasto em nuvem que não gera valor para o negócio. São os alvos de otimização de maior prioridade porque a economia é praticamente livre de risco. Não há trade-off de performance para analisar, nenhum stakeholder para convencer e nenhuma mudança arquitetural exigida.
Recursos ociosos incluem instâncias paradas que ainda geram cobrança, load balancers atrelados a serviços descomissionados e ambientes de desenvolvimento rodando em fins de semana e feriados. O custo unitário de cada recurso ocioso raramente é alto. O agregado, em uma organização de engenharia de porte médio, quase sempre é.
O armazenamento órfão se acumula quando os recursos de computação são encerrados, mas seus volumes, snapshots e backups atrelados não. Buckets de object storage de projetos descontinuados, snapshots de bancos de dados de ambientes que não existem mais e arquivos de log que ultrapassaram a janela de retenção — tudo isso entra nessa categoria. Armazenamento órfão é particularmente comum em organizações que provisionam infraestrutura com agilidade, mas não têm a mesma disciplina para descomissionar.
O gasto não alocado se refere a cobranças em nuvem que não podem ser atribuídas a um time, produto ou centro de custo por causa de tags ausentes ou inconsistentes. É uma métrica de desperdício de outro tipo. Não representa recursos que não entregam valor; representa recursos que entregam valor desconhecido. Você não consegue otimizar o que não consegue atribuir, e o gasto não alocado é o principal indicador de uma lacuna de governança de custos que só vai ficar mais difícil de fechar conforme o ambiente escalar.
Métricas de negócio: unit economics e custo como percentual da receita
As métricas de negócio marcam a transição do FinOps de função de redução de custos para função estratégica. As unit economics, expressas como custo por cliente, custo por transação, custo por chamada de API ou custo por usuário ativo, respondem à pergunta que as métricas financeiras não conseguem: este gasto em nuvem é eficiente em relação ao valor de negócio que ele gera?
Uma empresa que gasta US$ 2 milhões por mês em infraestrutura em nuvem e cresce a receita a 40% ao ano está em uma posição muito diferente da que tem a mesma fatura e crescimento zero. O gasto total, como métrica, trata as duas situações de forma idêntica. O custo como percentual da receita, ou o custo por unidade de resultado de negócio, as diferencia.
As unit economics também mudam a conversa com os times de engenharia. Dizer a um time que o serviço dele custa US$ 180.000 por mês raramente gera ação. Dizer que o serviço custa US$ 0,23 por usuário ativo, e que o líder de mercado está em US$ 0,11, gera uma conversa de design. A métrica conecta o custo em nuvem à performance do produto em uma linguagem que os engenheiros consideram acionável.
Construir unit economics exige conectar dados de billing em nuvem a dados de negócio — especificamente a camada de aplicação que mapeia os custos de infraestrutura para os produtos e a atividade dos clientes que eles sustentam. Isso é tecnicamente mais difícil do que acompanhar utilização ou variação orçamentária, e por isso é uma métrica de estágio maduro. Mas também é onde vivem as decisões de otimização de maior alavancagem.
Como escolher as métricas certas para o seu estágio de maturidade em FinOps?
O framework crawl/walk/run da FinOps Foundation oferece um mapa útil para priorização de métricas. As métricas certas não são as mais sofisticadas disponíveis. São as que se encaixam nas perguntas que o seu negócio consegue de fato responder agora, com a qualidade de dado e o tooling que você tem no lugar.
Estágio inicial: métricas de visibilidade
No estágio crawl, o problema principal é que os custos não são visíveis nem atribuíveis. Você vê uma fatura total. Não vê quais times, serviços ou produtos estão gerando essa conta. As métricas que importam aqui são fundacionais: taxa de cobertura de tagging, custo por conta e serviço e variação orçamentária por unidade de negócio.
A cobertura de tagging é uma métrica de entrada, não de saída: ela mede quanto do seu gasto em nuvem carrega os metadados de atribuição que tornam todo o resto possível. Times que pulam essa etapa e vão direto para métricas de otimização acabam otimizando as partes da infraestrutura que enxergam e ignorando as que não enxergam.
A meta no estágio crawl não é otimização perfeita. É estabelecer a base que torna a otimização possível.
Estágio intermediário: métricas de otimização
No estágio walk, a visibilidade já está no lugar e o time está pronto para agir. As métricas que importam agora são as que identificam oportunidades de otimização e validam que as intervenções geram economia real: cobertura de commitments, potencial de right-sizing, desperdício como percentual do gasto total e precisão da previsão.
A cobertura de commitments merece atenção especial nesse estágio. É uma das alavancas de otimização de maior retorno disponíveis e exige overhead operacional relativamente baixo depois que uma disciplina de compra está estabelecida. Times que definem metas de cobertura de commitments e criam um processo de revisão e ajuste trimestral costumam ver economias sustentadas que se acumulam com o tempo.
A precisão da previsão também ganha importância nesse estágio porque o time passa a conversar com regularidade com finanças e liderança sobre o gasto em nuvem. Previsões que erram consistentemente em 20% ou mais minam a credibilidade do time de FinOps como função de planejamento, por mais desperdício que ele já tenha eliminado.
Estágio maduro: métricas de eficiência e valor de negócio
No estágio run, o time tem visibilidade estável, programas ativos de otimização e previsões confiáveis. As métricas que importam agora são as que conectam a performance da nuvem à performance do negócio: unit economics, custo como percentual da receita e razões de eficiência por workload ou produto.
Esse também é o estágio em que a detecção de anomalias vira uma ferramenta estratégica, e não reativa. Times maduros usam alertas de anomalia de custo não só para pegar gastos descontrolados, mas para captar o sinal precoce de ineficiências arquiteturais — como um novo serviço consumindo três vezes mais computação que o antecessor, um job em batch escaneando mais dados do que o esperado ou uma feature gerando uma fatia desproporcional de cobranças de egress.
O recurso DataHub da DoiT conecta dados de billing em nuvem diretamente a métricas de negócio, tornando as unit economics viáveis sem exigir trabalho customizado de pipeline de dados. Para times que já estabeleceram disciplinas de visibilidade e otimização, mas ainda não construíram a camada de dados que torna as unit economics mensuráveis, é a ponte entre relatórios de estágio walk e run.
Quais são as armadilhas mais comuns ao acompanhar métricas de otimização de custos em nuvem?
Várias métricas amplamente usadas parecem úteis, mas consistentemente desviam os times de FinOps do caminho. Saber onde estão as armadilhas evita o custo em tempo e credibilidade de cair nelas.
Pensar só em utilização é o erro mais comum. Utilização alta parece eficiência. Em muitos casos, é. Mas um cluster Kubernetes com 90% de utilização de CPU pode estar batendo em restrições de performance que desaceleram o tempo de resposta da aplicação. Um banco de dados com 85% de utilização de memória pode estar afogando queries. Utilização sem contexto de performance confunde pressão sobre o recurso com eficiência do recurso. Acompanhe utilização junto com métricas de performance, não no lugar delas.
Acompanhar gasto total de um jeito que penaliza crescimento cria os incentivos errados. Se o KPI principal do time de FinOps for redução do gasto total em nuvem, ele vai otimizar por redução de gasto — às vezes em detrimento da velocidade de engenharia ou das capacidades de produto que motivaram a adoção da nuvem em primeiro lugar. O gasto total é um insumo útil para a conversa, não uma métrica de sucesso. Custo como percentual da receita, ou custo por unidade de resultado de negócio, é um proxy melhor para saber se o gasto em nuvem está saudável.
Análise cega à intenção aplica benchmarks genéricos a workloads com propósitos específicos. Um job de treinamento de machine learning rodando a 40% de utilização de GPU durante o pré-processamento de dados não está superprovisionado. Ele está rodando a fase de pré-processamento de um pipeline que vai subir para 95% durante o treinamento. Um ambiente de disaster recovery ocioso na maior parte do tempo não é gasto desperdiçado. É seguro. Recomendações de right-sizing que ignoram a intenção do workload produzem mudanças que cortam custos e degradam a confiabilidade ao mesmo tempo.
O acúmulo de métricas de vaidade — acompanhar mais métricas porque mais parece rigor — gera sobrecarga de relatório sem profundidade analítica. Se uma métrica não se conecta a uma decisão ou ação, ela está consumindo atenção que poderia ir para as que se conectam.
Como construir uma prática de métricas que realmente reduz o custo em nuvem?
Métrica sem camada de ação por trás é dashboard. Um número que é revisado, discutido e arquivado não otimiza nada. Um número que dispara uma resposta definida — como uma recomendação de right-sizing enviada a um time de engenharia específico, uma lacuna de cobertura de commitments que abre uma revisão de compra ou uma variação de previsão que ativa uma investigação de anomalia — gera resultado.
A diferença entre times que usam métricas de forma eficaz e os que não usam costuma se resumir a três práticas. Eles definem os limites de resposta antes de precisarem deles: se a cobertura de commitments cair abaixo de X%, a revisão de compra é acionada. Eles atribuem responsabilidade pelas métricas: alguém responde pela precisão da previsão da mesma forma que alguém responde pelo uptime. E eles fecham o ciclo entre métrica e resultado: quando uma recomendação de right-sizing é implementada, a economia é medida e reportada de volta ao time que a implementou.
Automação amplifica as três práticas. Revisões manuais de métrica não escalam conforme a infraestrutura cresce. Times que automatizam detecção de anomalias, compliance de tags e identificação rotineira de desperdício liberam a atenção da engenharia para o trabalho de otimização que exige julgamento — decisões de arquitetura, estratégia de commitments e design de workload.
O relatório 2025 State of FinOps, da FinOps Foundation, apontou que otimização de workloads e redução de desperdício seguem como a prioridade máxima para mais de 50% dos praticantes de FinOps, e os times que avançam mais rápido em ambas não estão acompanhando mais métricas. Estão agindo sobre menos, e melhores, com mais velocidade.
A plataforma de FinOps da DoiT dá aos times o analytics, a detecção de anomalias e o mapeamento de métricas de negócio via DataHub para sair do acompanhamento e partir para a ação. Se a sua prática de métricas já superou o seu tooling, fale com o nosso time para ver como a DoiT transforma dados de custo em nuvem em ação automatizada.
Perguntas frequentes
Quais são as métricas de otimização de custos em nuvem mais importantes para um time de FinOps iniciante?
Um time de FinOps iniciante deve começar por três métricas: taxa de cobertura de tagging, custo por conta e serviço e variação orçamentária por unidade de negócio. Essas métricas da camada de visibilidade estabelecem a base de atribuição que torna todo o resto possível. Métricas de utilização e desperdício ficam mais difíceis de acionar quando os custos ainda não são atribuíveis a times ou workloads específicos. Construa a base primeiro, depois adicione métricas de otimização assim que o gasto estiver visível e alocado. Tentar otimizar antes de enxergar com clareza gera correções pontuais que não se somam.
Como as unit economics se diferenciam das métricas de utilização?
As métricas de utilização medem quanto de um recurso provisionado um workload consome. As unit economics medem quanto custa entregar uma unidade de valor de negócio: um cliente atendido, uma transação processada, uma chamada de API concluída. A utilização diz se um recurso está sendo usado. As unit economics dizem se usá-lo é eficiente em relação ao que o negócio recebe em troca. Um cluster altamente utilizado rodando um workload de baixo valor parece saudável em um dashboard de utilização e ruim em um relatório de unit economics. As duas métricas respondem a perguntas diferentes, e uma prática madura de FinOps precisa das duas.
Qual é uma boa meta de precisão para previsão de custos em nuvem?
A maioria das organizações trata uma variação de 10 a 15% entre previsão e realizado como aceitável. Times com estratégias maduras de commitments, workloads estáveis e alocação de custo limpa conseguem chegar a 5% ou menos. Um enquadramento mais útil é o da precisão direcional: uma previsão que erra consistentemente 12% para baixo é um problema de calibração que dá para corrigir. Uma previsão que ora erra 5% para cima e ora 25% para baixo sinaliza um problema de qualidade de dados ou de atribuição que nenhum modelo de previsão vai resolver. Melhore a cobertura de tagging e a visibilidade em nível de conta primeiro, depois foque em estreitar a faixa de variação.