O Guia Completo de Atribuição de Custos de Nuvem e IA

Situação	O export de billing é suficiente?
Infraestrutura simples e single-tenant	Sim
Time pequeno, uma única conta de nuvem	Sim
Microsserviços em Kubernetes	Geralmente não
Produto SaaS multi-tenant	Não
RDS, Kafka ou Elasticsearch compartilhados	Não
Alocação de inferência de IA por cliente ou feature	Não
Análise de margem por cliente	Não
Infraestrutura autogerenciada (sistemas de dados hospedados em EC2)	Não
Atribuição de NAT gateway e data transfer	Não

Se o seu ambiente se parece com a metade de baixo da tabela, os exports de billing são só um ponto de partida. Não são uma ferramenta de otimização de custos. Para times que rodam features de IA, essa lacuna é ainda mais crítica: o gasto com tokens é só uma parte da superfície de custo da IA. Bancos vetoriais, camadas de orquestração, egress e a infraestrutura autogerenciada ao redor da chamada ao modelo costumam representar de 40 a 60 por cento do gasto total da feature. Ferramentas que leem só a conta de tokens deixam a maior parte passar.

O billing de nuvem foi desenhado para um modelo estático: provisionar um recurso, taguear e ler a tag no fim do mês.

O Kubernetes quebrou todas as premissas desse modelo. Pods são efêmeros. Serviços compartilham infraestrutura entre times e tenants. Uma única requisição do cliente passa por vários serviços antes de a resposta ser enviada. Resultado: nenhuma tag captura quem consumiu o quê, apenas quem é dono do recurso. E ser dono não é a mesma coisa que consumir.

A maioria das ferramentas de monitoramento de custos do Kubernetes reage medindo no nível do cluster: alocação de CPU, requests de memória, horas de pod. É um contexto útil, mas não é atribuição de custo. RDS, Kafka, Snowflake e data transfer costumam ser drivers de custo relevantes e sub-atribuídos ao lado do cluster. Ferramentas que param no nível do node e do pod deixam a maior parte da conta sem atribuição.

Quatro falhas se repetem de forma previsível:

• O tagueamento vira o projeto. Tags capturam propriedade, mas não atribuem o consumo de recursos compartilhados. O projeto leva meses e nunca chega ao fim.
• Custos compartilhados são alocados no chute. Percentuais estáticos e divisões iguais. Defensáveis na planilha. Precisos, não.
• Falta atribuição no nível do cliente. O gasto total é visível. O custo por tenant, não. Contas lucrativas e não lucrativas parecem idênticas.
• Os dados chegam tarde demais. O export de billing fecha só no fim do mês. O desperdício já aconteceu.

A atribuição em runtime parte de uma fonte de dados completamente diferente: o que está acontecendo no sistema neste exato momento.

O Attribute™ implanta um sensor eBPF na infraestrutura de compute: nodes EKS, tasks ECS, instâncias EC2, auto scaling groups. O eBPF (extended Berkeley Packet Filter) é uma tecnologia do kernel Linux que permite observar a atividade do sistema no nível do kernel de forma segura e em sandbox. O sensor inspeciona pacotes de rede em modo somente leitura, sem overhead de performance e sem mudanças no código da aplicação.

O que o sensor observa:

• Cada chamada de rede entre serviços
• Qual microsserviço está chamando qual banco de dados e com que frequência
• Como a infraestrutura compartilhada está sendo de fato consumida
• Quais endpoints de APIs de IA são chamados por qual workload, com que volume de tokens e atribuídos a qual cliente, feature ou agente
• Headers HTTP que carregam identificadores de cliente
• Destinos e volumes de data transfer

A partir dessas observações, o Attribute™ monta um grafo de dependências de serviços em tempo real. Ele sabe quais serviços dependem de quais recursos, em que intensidade e em que proporção. Esse grafo é o modelo de atribuição.

Quando uma instância RDS compartilhada gera custo, o modelo não aplica uma regra estática. Ele olha a distribuição real de queries entre os serviços naquele período e aloca o custo proporcionalmente ao consumo real.

Novos serviços são descobertos automaticamente assim que surgem. As relações se atualizam à medida que os deploys mudam. Sem catálogo de serviços estático. Sem reconfiguração manual.

Case de cliente: Island

O contexto: a Island está construindo a categoria de navegador enterprise, com valuation de US$ 5 bilhões e escalando para centenas de clientes corporativos. O ambiente AWS deles usa EKS, RDS e DynamoDB compartilhados, além de um volume significativo de data transfer entre AZs. Tagueamento não era uma opção — não dá para taguear um cliente numa arquitetura multi-tenant.

Antes: nenhuma visibilidade do custo real por cliente ou por feature. Sem condições de embasar decisões de pricing, modelagem de crescimento ou GTM com dados de custo reais. As ferramentas nativas de nuvem e as plataformas de terceiros mostravam contas e gráficos, mas não conseguiam responder quanto cada cliente de fato custava.

Depois: o Attribute™ entregou custo preciso por cliente e por feature em poucos dias. Sem tagueamento, sem instrumentação, sem pedidos para engenharia.

Mudança operacional: engenharia, produto e GTM passaram a operar a partir de uma fonte de custo comum. As decisões de pricing e modelagem de crescimento passaram a ser tomadas com base em dados reais de consumo, não em estimativas.

"Você não consegue taguear um cliente num ambiente multi-tenant. O Attribute™ finalmente mostra quanto cada cliente custa e o que está por trás desses custos.",

– Omri Cohen, Director of Engineering Platform, Island

Quer ler mais? Clique aqui para ver como uma plataforma líder em Work Management descobriu 360 contas não lucrativas, ou aqui para ver como uma empresa de segurança desfragmentou os relatórios das áreas de Finanças e Engenharia.

Unit economics exigem um modelo de custo que corresponda à unidade real. Numa empresa SaaS, essa unidade normalmente é o cliente.

Essa pergunta não tem resposta nos exports de billing. O billing mostra custos de recursos. Não mostra quais clientes consumiram esses recursos, nem em que proporção.

A camada de atribuição por cliente do Attribute™ mapeia a atividade observada em runtime para identificadores de cliente — vindos de headers HTTP, labels de workload ou convenções de nomenclatura em nomes de banco ou de fila. Uma vez estabelecido esse mapeamento, cada evento de custo no modelo é atribuído ao cliente que o gerou.

Quando conectado aos dados de receita, o resultado é um P&L no nível do cliente: quais contas são lucrativas, quais não são e por quanto.

O que essa visibilidade destrava:

• Identificar contas com margem negativa antes que os prejuízos se acumulem
• Detectar features de IA com custo fora de controle antes que o ciclo de billing feche
• Dar aos times de plataforma números defensáveis para chargeback de infraestrutura compartilhada
• Precificar contratos enterprise a partir do consumo real, não de suposições
• Justificar investimentos em arquitetura com dados reais de custo antes e depois
• Encerrar a discussão mensal entre finanças e engenharia sobre metodologia de alocação

Time to value: o sensor é implantado no Kubernetes via DaemonSet. A descoberta inicial de workloads é concluída em poucas horas. A atribuição de custo relevante fica disponível em poucos dias. Sem projeto de tagueamento.

Overhead de performance: o sensor eBPF é somente leitura e roda em sandbox no nível do kernel. Não intercepta nem modifica tráfego. O overhead de compute é desprezível.

Integrações: o Attribute™ é instalado na infraestrutura de compute (EKS, ECS, EC2) e monitora o tráfego da camada de aplicação para outros recursos de nuvem, incluindo provedores SaaS de terceiros como MongoDB Atlas, Snowflake, OpenAI e outros. Sem instrumentação no nível da aplicação.

Isso substitui o Kubecost ou o CloudHealth? Para empresas SaaS cujas perguntas de custo vão além dos relatórios no nível do cluster, sim. O Attribute™ vai mais longe na atribuição de recursos compartilhados, no cost-to-serve no nível do cliente, na cobertura de infraestrutura autogerenciada e na visibilidade total da superfície de custo da IA — incluindo atribuição de tokens por cliente, feature ou agente, junto com o gasto da infraestrutura ao redor que essas ferramentas não enxergam.

Dados históricos: o histórico de billing de nuvem é ingerido no setup. Para times que precisam de entregáveis de chargeback antes de implantar o sensor, o Attribute™ pode gerar relatórios a partir dos exports de billing fornecidos pelo cliente, mesmo sem o sensor.

Ambientes suportados: AWS, GCP, Azure. Kubernetes (EKS, GKE, AKS), ECS, EC2. Snowflake, MongoDB Atlas, OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Vertex AI. Kafka autogerenciado (com granularidade até o nível de topic), Elasticsearch, RabbitMQ.

Segurança: PII, credenciais, segredos, API keys e cookies são removidos antes que qualquer dado saia do ambiente do cliente. Eventos mínimos transmitidos via OpenTelemetry criptografado, autenticado por JWT e protegido por TLS. Pacotes brutos nunca são transmitidos. Os clientes podem, opcionalmente, rotear a telemetria pelo próprio endpoint OpenTelemetry para ter capacidade completa de auditoria.

As ferramentas baseadas em billing perguntam o que foi cobrado. A atribuição em runtime pergunta o que de fato aconteceu no sistema e quem causou.

Para times de compra que estão avaliando plataformas, cinco perguntas separam as ferramentas que respondem o que importa das que não respondem:

1. Funciona sem tags desde o primeiro dia?
2. Consegue alocar custos de recursos compartilhados com base no consumo observado, e não em regras estáticas?
3. Consegue atribuir custo por cliente num sistema multi-tenant?
4. Enxerga infraestrutura autogerenciada e gastos externos com IA?
5. Consegue mostrar sinais de custo durante o ciclo de billing, e não depois que ele fecha?

Para times com gasto relevante em IA, some uma sexta: consegue atribuir custos de tokens a um cliente, feature ou agente específico, e não apenas a uma API key? As ferramentas baseadas em billing respondem algumas dessas perguntas parcialmente, para alguns ambientes, com investimento significativo em setup. A atribuição em runtime responde todas elas desde o deployment.