Como rastrear custos por cliente em uma arquitetura multi-tenant na AWS

O AWS Cost Explorer e qualquer ferramenta baseada em billing mostram o custo por conta, região, serviço e tag. Isso funciona bem em modelos de tenant dedicado, em que cada cliente tem sua própria conta ou namespace. E não funciona para infraestrutura compartilhada.

Um único cluster RDS atendendo 400 clientes não gera 400 itens de custo. Gera um só. Um cluster Kafka atendendo uma dúzia de times de produto continua aparecendo como um único centro de custo compartilhado. Um node pool do EKS rodando workloads variadas é cobrado como computação, e não como "cliente A: US$ 142 mil, cliente B: US$ 89 mil".

A abordagem baseada em tags falha aqui de três formas:

1. Tags não se propagam por recursos compartilhados. Dá para colocar uma tag em uma instância EC2 com um time ou serviço. Não dá para colocar tag em uma query contra um banco de dados compartilhado.
2. Tags exigem esforço contínuo de engenharia. Cada novo recurso, cada novo serviço, cada novo deploy precisa de uma tag. Em empresas que se movem rápido, a cobertura se deteriora depressa.
3. Tags dizem o que o recurso é, não como ele foi usado. Uma instância RDS com tag diz que ela pertence ao serviço de "pagamentos". Mas não diz que 60% da carga dela veio de um único cliente neste mês.

Como funciona: em vez de ler exports de billing ou adicionar instrumentação na aplicação, observe o que realmente acontece no nível de rede e sistema — quais serviços estão chamando quais bancos de dados, quais IDs de cliente aparecem em quais queries, quanta carga cada cliente gera em cada recurso compartilhado.

A distinção importante é que sistemas de billing só enxergam cobranças. Sistemas de runtime enxergam consumo.

Na prática, essa é uma das poucas abordagens capazes de atribuir sistemas compartilhados como RDS, Kafka ou Elasticsearch a clientes individuais sem exigir mudanças na aplicação nem uma higiene perfeita de tags.

Ela também oferece atribuição em tempo real, no lugar de exports do CUR com atraso, e cobre infraestrutura autogerenciada que nunca aparece de forma limpa nos dados de billing da AWS.

O tradeoff: isso exige um componente que observe tráfego de rede e chamadas de sistema. No passado, coletar esse nível de dados de runtime em produção era um pesadelo operacional. O eBPF mudou esse jogo. As mesmas primitivas por trás de ferramentas como Cilium, Falco e Pixie também podem ser usadas para atribuição de custo em runtime. A diferença é que você está extraindo sinais de consumo de recursos em vez de eventos de segurança ou observabilidade.

Como funciona: cada cliente ganha uma conta AWS ou um namespace Kubernetes dedicado, com o billing isolado na mesma proporção.

Onde funciona: verticais de alta conformidade (saúde, finanças), contratos enterprise com exigências contratuais de isolamento e clientes grandes o suficiente para justificar economicamente uma infraestrutura dedicada.

Onde falha: não escala para centenas de clientes SMB. O overhead operacional de gerenciar centenas de contas AWS é enorme. A cobertura de Reserved Instances fica fragmentada. E você ainda tem serviços compartilhados (pipelines de logs, infraestrutura de observabilidade, data planes) que ficam de fora das contas por tenant.

Como funciona: imponha padrões de tagging em todos os recursos. Use tags de customer-id, team, service e environment. Puxe os dados de custo com tag via API do Cost Explorer ou AWS Cost and Usage Reports (CUR). Construa a lógica de agregação por cima disso.

Onde funciona: arquiteturas greenfield em que os padrões de tagging são impostos desde o dia um. Funciona razoavelmente bem para computação dedicada (EC2, node groups do EKS, Lambda), em que o mapeamento entre recurso e cliente é limpo.

Onde falha:

• Desmorona assim que vários clientes passam a compartilhar os mesmos sistemas com estado. Um cluster RDS compartilhado ou um deployment de Kafka tem, no fim das contas, uma única conta e muitos consumidores.
• Na prática, a maioria das empresas maduras nunca sustenta uma cobertura limpa de tagging por muito tempo. Donos mudam, serviços proliferam e as tags decaem.
• Os dados do CUR chegam com atraso de 24 a 48 horas — você está sempre olhando para trás.
• Recursos compartilhados (Kafka autogerenciado, Elasticsearch no EC2) são totalmente invisíveis para os exports de billing.

A maioria dos times que usa essa abordagem convive com pontos cegos significativos que conhece e aceita.

Como funciona: instrumente o código da aplicação para emitir métricas por cliente — queries executadas, bytes lidos/escritos, tempo de computação consumido. Monte um modelo de custo que mapeie essas métricas para o gasto na AWS. Multiplique o consumo pela unidade de custo para chegar a uma estimativa de custo por cliente.

Onde funciona: times com cultura forte de observabilidade, aplicações em que o consumo de recursos é dominado por um pequeno número de operações mensuráveis, e times de pricing de produto que precisam de uma aproximação.

Onde falha:

• A cobertura da instrumentação é, por definição, incompleta. Você mede o que decidiu medir.
• Infraestrutura compartilhada (connection pooling, overhead de cluster, capacidade ociosa) não se atribui a nenhuma operação específica.
• Modelos de custo exigem calibração contínua conforme os preços mudam.
• Infraestrutura autogerenciada (Kafka no EC2, Elasticsearch no EC2) exige instrumentação sob medida para cada tecnologia.
• Essa abordagem mostra o consumo proporcional, não o custo real.

É uma aproximação razoável para visibilidade interna, mas não resolve uma análise real de cost-to-serve.

A atribuição de custo por cliente em arquiteturas multi-tenant na AWS é um problema resolvido para modelos de tenant dedicado — e um problema em aberto por padrão para infraestrutura compartilhada. A toolchain padrão de FinOps (CUR, Cost Explorer, tagging) entrega custo por serviço e por time. Não entrega custo por cliente.

Para chegar lá, é preciso migrar para uma arquitetura menos compartilhada (custo operacional alto), investir em instrumentação na camada de aplicação (incompleta por natureza) ou observar diretamente o comportamento em runtime (cobertura abrangente).

Se você opera um modelo de precificação por consumo ou está tentando identificar contas não lucrativas em escala, as abordagens incompletas não vão te levar até lá. Se você precisa de uma alocação aproximada para relatórios internos, tagging combinado com alguma modelagem já resolve boa parte.

A maioria dos times acaba se contentando com um modelo de alocação que sabe ser útil na direção certa, mas não realmente preciso.

De forma geral, as ferramentas de FinOps são construídas em torno das contas de nuvem, não do comportamento compartilhado em runtime. Isso funciona até você precisar de uma atribuição mais profunda dentro de sistemas altamente compartilhados.

Nesse ponto, o gargalo normalmente não são os dados de billing da AWS. É a visibilidade sobre como a infraestrutura compartilhada está de fato sendo consumida.

O Attribute™ é focado exatamente nessa camada de atribuição em runtime para ambientes multi-tenant.