Como rastrear custos do Amazon Bedrock por usuário usando Athena e CUDOS

Como rastrear custos do Amazon Bedrock por usuário usando Athena e CUDOS

Se a sua empresa usa o Amazon Bedrock para servir modelos como Claude ou Nova, você provavelmente já se deparou com uma pergunta incômoda: quem está gastando o quê? Até pouco tempo atrás, a fatura de inferência chegava como um bloco único, sem distinção entre times, aplicações ou usuários. Em 2026 isso mudou — e este guia mostra como transformar a fatura do Bedrock em visibilidade granular, por usuário e por projeto.

Esta é a segunda parte de uma série sobre atribuição de custos no Bedrock. A primeira parte mostrou como a coluna line_item_iam_principal rastreia automaticamente cada requisição de inferência até o principal IAM que a originou. Aqui, vamos além: montar o relatório de custos, consultar os dados com Amazon Athena e visualizar tudo nos dashboards CUDOS.

Por que isso importa agora

Com ferramentas de agentes de código como Claude Code e Codex disparando milhares de chamadas ao Bedrock por dia, a falta de atribuição de custo deixou de ser um incômodo e virou um risco financeiro real. Uma equipe pode estar gastando centenas de dólares por dia em tokens sem que ninguém saiba. O rastreamento por principal IAM resolve exatamente isso — e funciona tanto para ferramentas de terceiros quanto para aplicações próprias.

Prós e contras desta abordagem

✅ O que você ganha

• Visibilidade de custo por usuário, aplicação, equipe e projeto
• Base para chargeback interno (cobrar cada time pelo que consome)
• Integração com qualquer ferramenta de BI via Athena
• Dashboards prontos com o CUDOS (sem precisar construir visualização do zero)
• Detecção de gastos anômalos e oportunidades de troca de modelo

⚠️ O que você não ganha

• Não é instantâneo: o primeiro relatório CUR 2.0 pode levar até 24 horas para ser entregue
• Dados de principal aumentam o tamanho dos arquivos (uma linha vira várias, uma por principal)
• Tags por projeto só funcionam se os principals IAM estiverem de fato tagueados
• Exige familiaridade básica com SQL e com o console da AWS

Requisitos

Passo 1: criar o relatório CUR 2.0 com dados de principal IAM

O Cost and Usage Report (CUR) 2.0 é a fonte de verdade dos seus custos. Ao configurar a exportação, há uma opção que faz toda a diferença:

• Em Additional export content, marque Include caller identity (IAM principal) allocation data — é isso que popula a coluna line_item_iam_principal e expõe as tags com prefixo iamPrincipal/.
• Em Time granularity, selecione Hourly para o máximo de detalhe.
• Em File versioning, escolha Overwrite existing report para evitar dados duplicados.

⚠️ Atenção: habilitar dados de principal aumenta o tamanho dos arquivos, porque um uso que antes era uma linha única passa a ser expandido em várias — uma para cada principal que contribuiu. Para cargas de alto volume, planeje o armazenamento do S3 e considere políticas de ciclo de vida para arquivos antigos.

Passo 2: conectar o CUR 2.0 ao Amazon Athena

O Athena permite consultar o CUR com SQL padrão, sem gerenciar infraestrutura. Para agilizar, a AWS disponibiliza um repositório de skill agent.md que automatiza a conexão usando assistentes de IA:

git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking
# Entre no diretório e inicie o Claude Code ou o Kiro CLI
# Prompt: "Read agent.md and follow its workflow to set up Cost and
# Usage Report tracking and run the Bedrock-by-principal query."

Se preferir o caminho manual, siga os passos oficiais de configuração. Quem pretende usar o dashboard CUDOS pode implantá-lo via CloudFormation, que também provisiona o banco de dados do Athena no processo.

Para confirmar que tudo funcionou, rode esta consulta de teste no Athena Query Editor:

SELECT line_item_iam_principal, line_item_usage_type, line_item_unblended_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
  AND line_item_iam_principal IS NOT NULL
LIMIT 10;

Se retornar linhas com ARNs de principal e tipos de uso do Bedrock, a configuração está completa. Troque your_cur_table_name pelo nome real da sua tabela (ex: cid_data_export.cur2).

Passo 3: três consultas que respondem as perguntas mais comuns

Consulta 1 — custo por principal e tipo de uso

Responde à pergunta: “quem está chamando quais modelos e quanto está gastando?”

SELECT
  line_item_iam_principal,
  line_item_usage_type,
  SUM(line_item_usage_amount) AS total_tokens,
  SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
  AND line_item_iam_principal IS NOT NULL
  -- AND line_item_usage_type LIKE '%Sonnet%output%'
GROUP BY line_item_iam_principal, line_item_usage_type
ORDER BY total_cost DESC;

Dica de análise: use padrões LIKE como %Sonnet%output% ou %nova% para filtrar modelos específicos. A coluna line_item_iam_principal contém o ARN completo; para roles assumidas, o nome após a última barra identifica a sessão ou o usuário.

Consulta 2 — custo por tags de principal (projeto ou equipe)

Se você tagueou os principals IAM com dimensões como team, project ou costcenter (e ativou essas tags como tags de alocação de custo), elas aparecem no CUR com o prefixo iamPrincipal/. Esta consulta agrupa por essas tags:

SELECT
  tags['iamPrincipal/project'] AS project,
  line_item_usage_type,
  SUM(line_item_usage_amount) AS total_tokens,
  SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
  AND line_item_iam_principal IS NOT NULL
GROUP BY tags['iamPrincipal/project'], line_item_usage_type
ORDER BY total_cost DESC;

Ela responde perguntas como “quanto o time de engenharia gastou no Bedrock este mês?” ou “qual o custo total do projeto do chatbot?”.

Consulta 3 — descoberta dinâmica de tags com UNNEST

Em organizações grandes, você pode não saber de antemão quais tags foram aplicadas. Times diferentes usam chaves diferentes, e novas tags surgem com o tempo. A função UNNEST do Athena resolve isso, descobrindo todas as tags usadas e alocando custo por cada par chave-valor:

WITH iam_principal_costs AS (
  SELECT
    t.key AS tag_name,
    t.value AS tag_value,
    line_item_usage_type,
    line_item_unblended_cost
  FROM your_cur_table_name
  CROSS JOIN UNNEST(tags) AS t(key, value)
  WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
    AND line_item_iam_principal IS NOT NULL
    AND line_item_iam_principal != ''
    AND t.key LIKE 'iamPrincipal/%'
)
SELECT
  tag_name || ': ' || tag_value AS tags,
  line_item_usage_type,
  SUM(line_item_unblended_cost) AS total_cost
FROM iam_principal_costs
GROUP BY tag_name, tag_value, line_item_usage_type
ORDER BY total_cost DESC;

Caso de uso real: comparar serviços em uma mesma plataforma

Imagine uma equipe de plataforma rodando um pipeline de sumarização de documentos (DocProcessor) e um chatbot de atendimento (ChatApp), cada um com sua própria role IAM. Com os padrões acima, a equipe consegue isolar a evolução de gasto de cada serviço:

SELECT
  line_item_iam_principal,
  line_item_usage_type,
  SUM(line_item_usage_amount) AS total_usage,
  SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
  AND line_item_iam_principal IS NOT NULL
  AND (line_item_iam_principal LIKE '%DocProcessor%'
       OR line_item_iam_principal LIKE '%ChatApp%')
GROUP BY line_item_iam_principal, line_item_usage_type
ORDER BY total_cost DESC;

No exemplo da AWS, o ChatApp responde por mais de US$ 80 usando Claude 4.6 Sonnet, enquanto o DocProcessor custa menos de US$ 5 usando Nova Lite. Isso gera decisões concretas: o DocProcessor já usa um modelo leve (adequado para sumarização), mas o time pode avaliar se o ChatApp conseguiria lidar com parte das interações com um modelo mais barato para reduzir o custo de US$ 72 em tokens de saída.

Quanto custam as consultas do Athena

Você paga apenas pelas consultas que executar, com base na quantidade de dados varridos. O Athena cobra US$ 5 por TB lido, com um mínimo de 10 MB por consulta. Como a tabela usa projeção de partição por billing_period, consultas restritas a um único mês varrem apenas os arquivos daquele mês — normalmente bem abaixo de 10 MB, custando cerca de US$ 0,00005 por consulta.

Para manter o custo baixo, inclua sempre o filtro WHERE billing_period = ... e selecione apenas as colunas necessárias, em vez de SELECT *.

Dashboards CUDOS: visualização pronta

O CUDOS faz parte do framework open source Cloud Intelligence Dashboards (CID), implantável via templates de infraestrutura como código. A versão 5.8 traz uma seção dedicada ao Amazon Bedrock na aba AI/ML, com suporte completo a atribuição de custo por principal IAM. Os destaques:

• Agrupamento flexível: por principal IAM, tags (projeto ou equipe), modelo, região ou qualquer campo de taxonomia configurado.
• Custo por milhão de tokens: uma linha de tendência sobre o gráfico de gastos mostra como o custo por milhão de tokens evolui ao longo do tempo — útil para medir o impacto de trocas de modelo ou de otimização de prompts, como o uso de cache.

Troubleshooting

• ❌ A consulta retorna vazio → O CUR 2.0 ainda não foi entregue. A primeira entrega pode levar até 24 horas; aguarde e confira o bucket S3.
• ❌ Nenhuma linha com principal → A opção Include caller identity (IAM principal) allocation data não foi marcada na exportação. Reconfigure o CUR.
• ❌ Consulta 2 não retorna tags de projeto → Os principals IAM não foram tagueados, ou as tags não foram ativadas como tags de alocação de custo.
• ❌ Arquivos CUR ocupando muito espaço no S3 → Dados de principal expandem as linhas. Crie políticas de Lifecycle para arquivos antigos.
• ❌ Custo alto de Athena → Você provavelmente está varrendo muitos dados. Adicione o filtro de billing_period e evite SELECT *.
• ❌ Erro de tabela não encontrada → Confirme o nome da tabela (ex: cid_data_export.cur2) e que o banco do Athena foi implantado (o CloudFormation do CUDOS faz isso automaticamente).

FAQ

• Funciona com ferramentas de terceiros? Sim. Ferramentas como Claude Code e Codex, que chamam o Bedrock, também são rastreadas pelo principal IAM que as executa.
• Preciso usar o CUDOS obrigatoriamente? Não. O Athena sozinho já responde a maioria das perguntas de atribuição; o CUDOS adiciona visualização pronta e comparação de custo por milhão de tokens.
• Qual a granularidade mínima? Com granularidade horária e dados de principal, você consegue chegar ao nível de sessão de usuário.
• Há custo adicional por habilitar dados de principal? Não diretamente, mas os arquivos CUR ficam maiores, o que pode aumentar o custo de armazenamento no S3.
• Posso usar outra ferramenta de BI? Sim. Como os dados ficam em tabelas do Athena, qualquer ferramenta compatível com Athena pode se conectar.

O que vem a seguir

A direção do mercado é clara: conforme agentes de IA ganham autonomia para executar código e disparar inferências, a governança financeira da IA deixa de ser opcional. Espere ver, nos próximos ciclos, ainda mais integração entre relatórios de custo e observabilidade de agentes — inclusive com alertas automáticos de gasto por principal. Quem montar essa base agora estará à frente quando a escala chegar.