Cloud Intelligence™
Relatórios em que o financeiro confia de verdade
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
About Devorah Klartag
Marketing director. 15+ years turning marketing vision into infrastructure that actually scales - GTM, demand gen, ops, and the AI-powered systems that keep the whole thing moving. At Attribute, I built the marketing function from the ground up and hit top-3 AI search rankings on competitive FinOps queries in ChatGPT, Perplexity, and Claude.
Previously: senior growth and marketing ops at D-ID (led the self-service studio launch that hit #1 Product of the Day on Product Hunt and landed coverage in TechCrunch, Fast Company, and Forbes), digital marketing at CyberProof, and $7M campaigns at McCann Tech for NICE and Amdocs. Earlier, hospitality marketing across NYC restaurants and cruise lines.
Ex-New Yorker in Tel Aviv. Still misses the bagels most.
My personal pageVocê passou meses construindo relatórios e dashboards. Custo por time, custo por workload, chargeback por unidade de negócio. Tudo parece certo para os engenheiros. O financeiro entra na revisão e pergunta: "Vocês conseguem comprovar esses números?"
É complicado. Suas ferramentas destrincham exportações de faturamento, mecanismos de regras e uma cobertura de tags que chega a 70%. Isso não é concreto o suficiente para decisões de negócio, previsões e projeções.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Por que os números não se sustentam
As ferramentas de FinOps foram criadas para ler o arquivo de faturamento gerado pelo seu provedor de nuvem, fatiá-lo com regras e tags e apresentar o resultado em um dashboard.
O financeiro e a liderança do negócio fazem perguntas por outro ângulo. Quanto custa atender o Cliente X? Qual dos nossos produtos tem margem positiva? A maioria das ferramentas de FinOps dá uma resposta. Pouquíssimas dão uma resposta auditável.
O que "lixo" realmente significa
Quando um stakeholder chama um relatório de custos de "lixo", ele está reagindo a números que não batem com o que ele sabe ser verdade, ou não consegue entender como os números foram calculados.
Na prática, isso costuma se resumir a três coisas:
Regras que faziam sentido, mas envelheceram.
Suas regras de alocação foram configuradas há 18 meses. Três migrações e dois rebrandings de produto depois, as regras ainda apontam para serviços e labels que já não significam o que significavam. Os números parecem consistentes no dashboard porque as regras rodam de forma consistente. Ninguém verificou se as regras ainda estavam corretas. Todo mundo achava que a limpeza era responsabilidade de outra pessoa.
Tags que nunca chegaram à cobertura total.
A atribuição baseada em tags só cobre recursos com tags. Os 30% que a engenharia nunca marcou são descartados ou distribuídos por um rateio sintético. Quando o financeiro pergunta "o que está no bucket não alocado", a resposta honesta é: uma parcela significativa do gasto real. A inferência de IA piora isso — a maioria dos times ainda nem descobriu como aplicar tags em chamadas de modelo, muito menos por feature ou por cliente.
Dados obsoletos no modelo. Contas antigas, serviços desativados, contratos encerrados, mas os dados históricos continuam no modelo.
O problema do P&L por produto
O problema de confiança se agrava quando os times de FinOps tentam responder à pergunta real do financeiro: não "quanto custa este workload", mas "quanto custa este produto, por região, por tier de cliente?"
Essa pergunta exige mais do que dados de custo. Um cliente que roda três produtos em cinco regiões não quer saber qual namespace do Kubernetes é dono do gasto. Ele quer saber se o cliente é lucrativo. É preciso saber qual workload atende qual produto, quais clientes consomem quais workloads e como a infraestrutura compartilhada se divide entre tudo isso. Ferramentas padrão de FinOps conseguem chegar perto disso com tags e regras suficientes. Mas aproximações não sobrevivem a um VP pedindo a metodologia por trás dos números.
O que o financeiro quer de verdade é o cost-to-serve no nível de cliente e de produto, incluindo componentes fixos e variáveis, incluindo gastos com SaaS de terceiros como Snowflake ou Twilio, em um formato que possa ser defendido diante do conselho. Times de pricing precisam disso para definir margens. O financeiro precisa para reportar o COGS. Líderes de produto precisam para saber quais features estão puxando a margem para baixo.
A maioria das ferramentas de custo de nuvem é muito boa em responder "por que nossa fatura da AWS subiu?". Elas nunca foram projetadas para responder "este produto dá dinheiro?".
O mesmo problema agora chega mais rápido pelo gasto com IA. Custos de inferência de LLM não se comportam como EC2. São baseados em requisições, variam por cliente e se acumulam rapidamente. Uma exportação de faturamento diz o que o Bedrock ou a OpenAI cobraram de você no mês passado. Ela não diz qual feature do produto gerou esse custo, qual tier de cliente o consumiu, nem se os unit economics se sustentam em escala. Volume de tokens, escolha de modelo, tamanho do prompt — nada disso aparece em uma linha de faturamento. O financeiro está começando a perguntar sobre o COGS de IA da mesma forma que pergunta sobre o COGS de nuvem. A lacuna de dados é idêntica. O que está em jogo é maior porque os custos mudam mais rápido.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
O problema de reconstruir a realidade
Toda ferramenta baseada em exportações de faturamento tem a mesma limitação estrutural. O arquivo de faturamento diz o que cobraram de você. Ele não diz por quê, quais clientes geraram o custo, nem como recursos compartilhados realmente se dividem entre os consumidores.
O Attribute lê o sistema em produção em vez do arquivo de faturamento. Um sensor eBPF ultraleve, implantado na sua infraestrutura de computação, observa quais workloads se comunicam com quais bancos de dados e serviços usando dados de runtime, na camada de rede. A atribuição de custos segue o comportamento real, não regras sobre o comportamento esperado.
A diferença importa mais quando um stakeholder pergunta como você chegou a um número. Com a atribuição baseada em faturamento, você refaz o caminho por uma cadeia de regras e suposições. Com a atribuição em runtime, você rastreia até a atividade de rede observada.
Como isso funciona na prática
Veja o caso da visibilidade de custo por time, uma das demandas mais comuns de FinOps. Com uma ferramenta baseada em tags, você só enxerga o custo do time tão bem quanto sua cobertura de tags e a higiene dos labels permitem. Namespaces compartilhados são um problema. Serviços que a engenharia implantou na semana passada e ainda não receberam tags ficam invisíveis.
O sensor do Attribute detecta novos workloads automaticamente, porque os observa se comunicando na infraestrutura em vez de esperar que alguém os rotule. Quando seu time precisa mostrar o " custo cobrável por times", a abordagem em runtime produz um número que você pode defender, porque reflete o que está realmente rodando.
O mesmo princípio se aplica no nível do cliente. Se você precisa saber quanto custa de fato atender um cliente específico, incluindo infraestrutura fixa, computação variável e ferramentas SaaS, não dá para chegar lá a partir de uma exportação de faturamento sem um mapeamento manual significativo. O Attribute constrói esse mapeamento a partir do que observa: quais workloads de cliente acessam quais serviços, em qual volume, a qual custo. Quando os clientes pedem o custo do produto por região ou a lucratividade do produto em diferentes tipos de serviço, essa pergunta tem uma resposta real, e não uma estimativa.
O mesmo vale para os custos de IA. O sensor do Attribute lê as chamadas na camada de rede: qual serviço fez a chamada, qual workload de cliente a disparou e quanto custou. Esse é o número que um time de pricing pode usar para decidir se absorve o custo de inferência ou o repassa.
O Attribute ajuda times de FinOps e financeiro a entender o que o gasto com nuvem e SaaS está pagando de fato, usando atribuição em runtime em vez de tags manuais e exportações de faturamento.
Por que relatórios de custo de nuvem reprovam nas revisões do financeiro?
A maioria das ferramentas de FinOps constrói relatórios a partir de exportações de faturamento, regras de alocação e tags. Regras envelhecem. A cobertura de tags raramente é completa. Quando o financeiro pergunta como um número foi calculado, a resposta honesta remonta a uma cadeia de suposições, não a dados observados. Essa é a lacuna.
O que é atribuição de custos em runtime?
Atribuição em runtime significa que os custos seguem o comportamento real do sistema, e não regras sobre o comportamento esperado. O Attribute implanta um sensor eBPF que observa quais workloads se comunicam com quais serviços no nível de runtime. Cada custo é rastreado até a atividade de rede observada, não até uma decisão de tagging tomada há 18 meses.
Como o gasto sem tags é tratado?
Com ferramentas baseadas em tags, recursos sem tags são descartados ou distribuídos por um rateio sintético. O sensor do Attribute detecta workloads independentemente de terem recebido labels, porque os observa se comunicando na infraestrutura. Serviços novos implantados na semana passada ficam visíveis imediatamente.
O Attribute consegue mostrar o cost-to-serve por cliente?
Sim. O Attribute mapeia os gastos de nuvem e SaaS para clientes finais individuais, observando quais workloads de cliente acessam quais serviços, em qual volume, a qual custo. Isso produz o cost-to-serve real, incluindo infraestrutura fixa, computação variável e ferramentas de terceiros como Snowflake ou Twilio.
E os custos de IA e inferência de LLM?
Custos de inferência não aparecem nas exportações de faturamento com detalhe suficiente para serem úteis. O sensor do Attribute lê as chamadas de modelo na camada de rede, atribuindo cada requisição ao serviço, ao cliente e à feature que a disparou. Esse é o número que os times de pricing precisam para definir margens em features de IA.
Qual a diferença em relação ao CloudZero ou ao Apptio?
Essas ferramentas trabalham a partir de exportações de faturamento e exigem tagging antes de mostrar dados relevantes. O Attribute lê o sistema em produção. Sem necessidade de tagging, sem manutenção de regras, e a metodologia se sustenta quando um stakeholder pergunta como você chegou a um número.
