Toda empresa que olha a fatura de nuvem pela primeira vez encontra a mesma coisa: recursos ligados sem uso, instâncias grandes demais, volumes órfãos, retenção de log medida em anos porque ninguém escolheu um número. A limpeza é rápida, o número cai e a reunião termina bem.

Seis meses depois a conta voltou ao patamar anterior. O problema não estava na planilha, e a planilha por definição não podia resolvê-lo.

O que a planilha vê e o que ela não vê

Uma análise de custo enxerga consumo. Ela mostra qual recurso gastou quanto, em que região, sob qual conta. É informação necessária e insuficiente, porque consumo é consequência: o que determina o gasto é a decisão de arquitetura tomada meses antes de a fatura existir.

Três exemplos que aparecem em quase todo diagnóstico. Um serviço que grava log de depuração em produção porque o time nunca separou nível de log por ambiente — o custo é de armazenamento, a causa é de código. Um banco gerenciado dimensionado para o pico de um evento sazonal e mantido nesse tamanho o ano inteiro porque redimensionar exige janela de manutenção que ninguém quer agendar — o custo é de instância, a causa é de processo. Tráfego entre zonas de disponibilidade cobrado por gigabyte porque a aplicação conversa entre componentes que ficaram em zonas diferentes por acidente de provisionamento — o custo é de rede, a causa é de topologia.

Nenhum dos três se resolve desligando algo. Os três voltam, porque a decisão que os criou continua de pé.

Onde o custo é decidido

Custo de nuvem se decide em quatro momentos, e nenhum deles é a revisão de fatura.

No desenho do serviço. Escolher entre fila e chamada síncrona, entre banco gerenciado e autogerenciado, entre contêiner e função é escolher perfil de custo. A conta do fim do mês é a soma dessas escolhas, não uma variável independente.

No provisionamento. Recurso criado sem etiqueta de dono e finalidade é recurso que ninguém vai desligar, porque desligar exige saber quem depende dele. A etiqueta custa dez segundos na criação e vale a diferença entre desperdício identificável e desperdício invisível.

Na política de dados. Retenção de log, de backup e de snapshot é a linha que cresce sozinha, sempre para cima, e a única que exige conversa com quem precisa do dado. Definir retenção é definir por quanto tempo a empresa consegue investigar um incidente. É decisão de risco, não de armazenamento.

No ciclo de vida. Ambiente de teste sem data de expiração vira ambiente permanente. A regra que resolve é banal: tudo que nasce como temporário nasce com prazo, e o prazo é aplicado por automação, não por lembrete.

Um caso e o que ele mostra

No caso que apresentamos no webinar de FinOps, a redução chegou a 67% sem corte de capacidade contratada. Vale olhar de onde veio o número, porque a distribuição é mais interessante que o total.

A maior fatia não veio de negociação nem de instância reservada. Veio de desligar o que ninguém usava — ambientes de homologação parados, réplicas criadas para uma migração concluída havia meses, endpoints de teste esquecidos. A segunda fatia veio de dimensionar pelo consumo real observado, e não pela estimativa feita no projeto, que sempre embute margem de segurança que ninguém revisita. Só a terceira fatia, a menor, veio de compromisso de uso.

A ordem importa: quem começa por compromisso de longo prazo compra desconto para desperdício, e fica preso a ele por um ou três anos.

O erro de sequência que encarece tudo

Quase todo programa de custo começa errado de propósito, e o motivo é compreensível: compromisso de uso dá desconto imediato, aparece na fatura do mês seguinte e não exige mudar nada no ambiente. É a medida mais fácil de aprovar e a que mais atrapalha depois.

Reserva de capacidade é aposta em previsão de demanda por um ou três anos. Feita antes de dimensionar pelo consumo real, ela congela o tamanho errado: a empresa passa a pagar com desconto por uma instância que devia ter metade do tamanho. E como o compromisso existe, redimensionar deixa de ser economia e passa a ser prejuízo contábil, o que na prática significa que ninguém mais vai mexer.

A ordem que funciona é a inversa e não é intuitiva. Primeiro desligar o que não tem uso. Depois dimensionar pelo observado, com duas ou três semanas de métrica real. Depois arrumar o que gera custo por acidente de topologia — tráfego entre zonas, egresso desnecessário, NAT em caminho que não precisava passar por ali. Só então comprometer o que sobrou, que é a parte estável e previsível do consumo.

Quem faz nessa ordem compra desconto para o ambiente que quer manter. Quem inverte compra desconto para o desperdício.

Quem responde pela conta

Existe um padrão organizacional atrás de quase todo caso de custo fora de controle: a nuvem é paga por uma área e consumida por outra. O financeiro recebe a fatura e não tem autoridade técnica para questionar linha. O time técnico cria recurso e não vê o efeito financeiro da decisão. Ninguém está errado, e é exatamente por isso que o número cresce.

O arranjo que resolve não é comitê. É atribuir orçamento de nuvem por produto ou por squad, com o número visível para quem provisiona, na mesma frequência em que se olha desempenho. Quando o time que cria o recurso vê o custo do que criou na semana seguinte, a conversa muda sozinha, sem política nova.

O que medir depois

Custo absoluto é péssimo indicador, porque sobe quando a empresa cresce e cair pode significar que o negócio encolheu. Três medidas funcionam melhor.

Custo por unidade de negócio: por cliente ativo, por transação processada, por documento emitido. É o número que separa crescimento de desperdício.

Variação percentual mês a mês por conta e por etiqueta, com alerta em desvio. Fatura que sobe 8% em um mês é notícia; fatura alta e estável não é.

Percentual de recursos com dono identificado. Enquanto esse número não estiver perto de 100%, qualquer análise de custo é estimativa, porque o que não tem dono não pode ser questionado.

O que muda para quem opera

A consequência prática é que FinOps deixa de ser tarefa mensal do financeiro e passa a ser critério na revisão de arquitetura. A pergunta “quanto isso vai custar por mês em regime” entra na mesma conversa em que se decide banco, fila e topologia — antes de existir código, quando mudar ainda é barato.

A segunda consequência é sobre expectativa. Não existe otimização automática de custo, com ou sem IA no meio. Ferramenta identifica candidato a corte; decidir se aquele recurso pode ser desligado exige saber o que depende dele e qual cenário de falha a empresa aceita. Isso é conhecimento de quem opera, e nenhum painel substitui.

O próximo passo

Escolha a maior linha da sua fatura do mês passado e responda três perguntas: quem é o dono desse recurso, qual decisão de arquitetura o criou e o que aconteceria se ele fosse reduzido pela metade. Se qualquer resposta exigir levantamento, o levantamento é o trabalho — e é por ele que começamos quando entramos em um ambiente novo.