Por que controlar custos de IA generativa é diferente
Comparar preços por token entre modelos e pedir para os times encurtarem prompts são os primeiros passos que quase todo mundo dá. Mas essas ações não respondem às perguntas que realmente importam quando o uso escala: qual time gerou esse gasto, em qual workload, e esse valor estava dentro do orçamento aprovado?
Workloads agênticos tornam essa questão ainda mais urgente. Um assistente conversacional típico faz uma invocação de modelo por turno de usuário. Já um fluxo agêntico — como um assistente de codificação que planeja uma mudança, lê arquivos, chama ferramentas e itera — pode gerar dezenas de invocações por tarefa, cada uma carregando um contexto maior. O consumo de tokens cresce com o grau de autonomia do workflow, não com o número de interações do usuário.
Por isso, a AWS estruturou um modelo operacional em cinco estágios para gerenciar custos do Amazon Bedrock. Use a Calculadora de Preços da AWS e a página de preços do Amazon Bedrock para modelar as taxas — mas meça o que seus workloads realmente consomem antes de tomar qualquer decisão.
O modelo operacional em cinco estágios
Os cinco estágios formam um loop contínuo. Cada um depende dos anteriores — times que pulam direto para otimização sem ter atribuição e observabilidade estão apenas chutando.
- Atribuir: todo gasto no Amazon Bedrock é associado a uma identidade, time e aplicação no pipeline de faturamento. Responsabilidade do time de FinOps.
- Observar: toda requisição é registrada com metadados suficientes para explicar o que gerou o gasto. Responsabilidade da engenharia de plataforma.
- Enforçar: orçamentos têm dentes — alertas no mínimo, bloqueios onde o risco exige. Responsabilidade da engenharia de plataforma.
- Otimizar: os padrões da plataforma (roteamento de modelo, cache, limites de tokens) eliminam desperdício de forma centralizada. Responsabilidade da engenharia de plataforma.
- Operar: um scorecard e uma cadência de revisão transformam dados em decisões. Responsabilidade conjunta de FinOps e plataforma.
Estágio 1: Atribuir cada gasto a um responsável
Tudo o que vem depois — chargeback, orçamentos, enforcement, detecção de anomalias — depende deste estágio. A base é a atribuição granular de custos do Amazon Bedrock: o serviço atribui automaticamente os custos de inferência ao principal do Gerenciamento de Identidade e Acesso da AWS (IAM) que fez a chamada, sem nenhum recurso adicional para gerenciar. O ARN do chamador aparece na coluna line_item_iam_principal do Relatório de Custo e Uso da AWS (CUR) 2.0.
A configuração envolve quatro passos: ativar dados de principal IAM na exportação CUR 2.0; marcar os principais IAM com dimensões de negócio como time, aplicação e centro de custo; para acesso federado, configurar o provedor de identidade para passar session names e tags via claims OIDC ou SAML; e ativar essas tags como tags de alocação de custo no AWS Billing. As tags aparecem no AWS Cost Explorer dentro de 24 a 48 horas após a ativação.
O problema do role compartilhado
O padrão mais crítico de se resolver é o shared-role problem: um gateway de LLM que chama o Amazon Bedrock por meio de uma única role IAM atribui todos os gastos àquela role, eliminando completamente a visibilidade por usuário.
A solução é o gerenciamento de sessão por usuário. O gateway assume a role de invocação do Bedrock uma vez por usuário, passando a identidade do usuário como o nome da sessão e seus atributos como session tags, e armazena essas credenciais em cache por até uma hora (uma chamada ao Serviço de Token de Segurança da AWS (STS) por usuário por hora, não por requisição). O resultado são entradas line_item_iam_principal como assumed-role/BedrockRuntimeRole/gw-alex, cada uma carregando as tags do usuário correspondente.
import boto3
sts = boto3.client("sts")
# One call per user; cache the returned credentials up to 1 hour
response = sts.assume_role(
RoleArn="arn:aws:iam::123456789012:role/BedrockRuntimeRole",
RoleSessionName="gw-alex", # the user, not the gateway
Tags=[
{"Key": "team", "Value": "sales-ai"},
{"Key": "application", "Value": "renewal-agent"},
{"Key": "costCenter", "Value": "CC-2041"}
]
)Outros mecanismos de atribuição
O Amazon Bedrock oferece dois mecanismos adicionais. Perfis de inferência de aplicação são recursos pré-criados por aplicação no endpoint bedrock-runtime que carregam tags de alocação de custo — ideais para times com um conjunto pequeno e estável de aplicações e modelos. Projetos e workspaces atendem ao endpoint bedrock-mantle (Responses API, Chat Completions API) e são indicados para workloads OpenAI-compatíveis; saiba mais em como gerenciar custos de IA com Amazon Bedrock Projects.
Para workloads no bedrock-runtime, a recomendação principal é a atribuição via principal IAM com session tags: ela escala com o sistema de identidade existente, não exige recursos pré-criados e cobre todos os modelos e operações de API.
Estágio 2: Tornar cada requisição observável
O CUR diz quem gastou. Os logs de invocação dizem o que aconteceu. O Amazon Bedrock suporta logging de invocação de modelo de dados de requisição, resposta e metadados para o Amazon CloudWatch Logs, Amazon Simple Storage Service (S3) ou ambos. Use o CloudWatch para consultas operacionais rápidas e S3 com Amazon Athena para acesso de longo prazo em Inteligência de Negócios (BI).
Trate o logging como infraestrutura, não como um toggle manual: provisione o grupo de logs ou bucket via código, defina políticas de retenção e criptografia, e valide a entrega durante o setup do ambiente. O logging também fecha a lacuna de latência: a atribuição via CUR tem um atraso de cerca de 24 horas, mas CloudWatch com OpenTelemetry pode alimentar dashboards quase em tempo real mostrando gasto por desenvolvedor em minutos — o post Analisando uso do Claude Code com CloudWatch e OpenTelemetry demonstra isso de ponta a ponta.
Metadados de requisição para atribuição por workload
Logs brutos respondem perguntas de nível de identidade. Para responder perguntas de nível de workload (qual feature, workflow ou tenant gerou os tokens), é preciso carimbar metadados de requisição em cada chamada. O Amazon Bedrock captura esses metadados nos logs de invocação para análise posterior:
response = client.converse(
modelId="us.anthropic.claude-sonnet-5-5",
messages=[...],
requestMetadata={
"application": "renewal-copilot",
"workflow": "renewal-risk-summary",
"tenant": "enterprise-sales",
"agent": "renewal-agent"
}
)O Amazon Bedrock não impõe metadados de requisição, e os times tendem a usar schemas inconsistentes rapidamente quando cada aplicação faz do seu jeito. O time de plataforma deve injetar metadados obrigatórios de forma centralizada em um wrapper de SDK compartilhado ou gateway, normalizar o conjunto de chaves e tratar a cobertura de metadados como uma métrica de saúde da plataforma.
Com logs e metadados configurados, o CloudWatch Logs Insights responde às perguntas recorrentes. Para identificar quem consome mais tokens, a consulta abaixo agrupa por chamador e modelo:
fields @timestamp, identity.arn as caller, modelId,
input.inputTokenCount as inTokens,
output.outputTokenCount as outTokens
| stats sum(inTokens + outTokens) as totalTokens,
count(*) as calls
by caller, modelId
| sort totalTokens desc
| limit 25A mesma consulta agrupada por requestMetadata.application e requestMetadata.workflow em vez de caller produz o leaderboard por workload — a visão que os times de produto e engenharia vão pedir ao FinOps assim que as conversas de chargeback começarem.
Estágio 3: Enforçar orçamentos
Com atribuição e observabilidade estabelecidas, o enforcement vira uma escolha arquitetural. Existem três tiers viáveis, e a escolha certa depende da velocidade de gasto, da tolerância a risco de overspend e de como as ferramentas se conectam ao Amazon Bedrock.
Tier 1: Monitorar e alertar (sem bloqueio)
O Amazon Bedrock escreve a identidade do principal automaticamente no pipeline de faturamento. O AWS Budgets fica por cima para alertas de threshold, com os dashboards do OpenTelemetry do Estágio 2 fechando a lacuna de 24 horas do CUR. Nada para implantar, sem latência adicional nas chamadas de inferência. Nada pode bloquear o gasto em tempo real — o problema é visto depois que acontece. Indicado para adoção inicial. Dois guias práticos cobrem essa abordagem: Limitando o uso do Bedrock e controlando custos e Deep dive sobre gerenciamento do Bedrock no Claude Code com AWS Budgets e Tags.
Tier 2: Enforcement via tag IAM (bloqueio por violação)
Uma função AWS Lambda agrega contadores de tokens e gastos por usuário no Amazon DynamoDB a partir dos dados do log de invocação. Quando um usuário ultrapassa o threshold, a função adiciona a identidade a uma política de negação IAM (negando bedrock:*) até um reset mensal ou override de administrador. O enforcement é assíncrono — um bloqueio entra em vigor segundos a minutos após a chamada violadora. O Guidance for Claude Code with Amazon Bedrock na AWS Solutions Library oferece uma variante implantável. Indicado para times que precisam de enforcement real, tolerando essa latência, e querem manter software de terceiros fora do caminho de dados.
Tier 3: Enforcement via gateway (bloqueio síncrono)
Um gateway no caminho de dados de inferência enforça orçamentos de forma síncrona, retornando HTTP 429 no momento em que um usuário ou time ultrapassa o limite. Oferece bloqueio em sub-segundo, allowlists de modelos por usuário, limites de taxa de tokens e regras de roteamento enforçadas centralmente. O trade-off: um componente no caminho de dados que precisa ser implantado, escalado e revisado do ponto de vista de segurança.
Para frotas de Claude Code e Claude Desktop, o Claude apps gateway for AWS é a recomendação oficial. Ele roda como um contêiner stateless único com PostgreSQL como backend, oferecendo identidade OIDC, política gerenciada centralmente, telemetria OpenTelemetry, roteamento multi-Region no Amazon Bedrock e limites de gasto por usuário, grupo e organização. Para workloads com múltiplos modelos e múltiplos provedores, gateways de propósito geral são a escolha certa: LiteLLM via arquitetura de referência no Amazon ECS com AWS Fargate, ou a alternativa serverless descrita em Build a proactive AI cost management system for Amazon Bedrock, Part 2.
A maioria das organizações deve adotar os tiers de forma progressiva: comece observando no Tier 1, depois avance. O Well-Architected Agentic AI Lens já codifica a governança de custos de agentes como uma preocupação arquitetural de primeira classe.
Estágio 4: Otimizar os padrões da plataforma
A maior parte do desperdício no Amazon Bedrock não é descuido individual — são padrões de plataforma que ninguém configurou. As duas alavancas de maior impacto são ambas controladas pela plataforma.
Roteamento de modelos
Nem toda tarefa precisa de um modelo frontier. Completions rotineiras (boilerplate, sugestões de linting, pequenos refactors) podem rodar em modelos menores e mais baratos, com qualidade reservada para raciocínio complexo — usando roteamento inteligente de prompts dentro de uma família de modelos ou regras de roteamento no gateway. Veja o walkthrough completo em Reduza custos e latência com Amazon Bedrock Intelligent Prompt Routing e prompt caching. Para frotas de codificação agêntica, onde boilerplate domina o volume de chamadas, mais da metade das chamadas indo para modelos mais baratos é uma meta alcançável.
Cache de prompts
O cache de prompts recompensa prefixos estáveis e repetidos. Conforme a precificação do Amazon Bedrock publicada em outubro de 2026 para modelos Anthropic Claude na região US East (N. Virginia): um cache write é cobrado a 1,25x a taxa base de entrada com o TTL de 5 minutos (2x com o TTL de 1 hora). Um cache read é cobrado a 0,1x a taxa base no Claude Sonnet 4.6 e Claude Haiku 4.5, e a 0,05x no Claude Sonnet 5.5 e Claude Opus 5.5. Verifique a página de preços para seu modelo e região, pois esses multiplicadores variam.
A matemática de break-even é mais favorável do que os times costumam imaginar. Com o TTL de 5 minutos, uma única reutilização já paga pelo write, e dez chamadas contra um prefixo estável custam cerca de um quinto do preço sem cache. O único caso perdedor é writes que nunca são relidos. Por isso, o dashboard da plataforma deve rastrear o volume de cache reads contra cache writes por workflow. Uma taxa de read baixa significa que o prefixo não é realmente estável — geralmente há um timestamp ou session ID embutido antes do ponto de cache.
Candidatos para cache surgem diretamente dos logs de invocação com uma consulta que filtra workflows com mais de 50 chamadas e média de tokens de entrada acima de 2.000:
fields requestMetadata.workflow as workflow, modelId,
input.inputTokenCount as inTokens
| stats count(*) as calls,
avg(inTokens) as avgInputTokens,
sum(inTokens) as totalInputTokens
by workflow, modelId
| filter calls > 50 and avgInputTokens > 2000
| sort totalInputTokens desc
| limit 25Estágio 5: Operar o loop
Os quatro estágios anteriores produzem dados. Este os transforma em decisões. O time de plataforma mantém um dashboard de saúde com quatro sinais:
- Mix de modelos: quais modelos são chamados e com que frequência — medida direta da disciplina de roteamento.
- Taxa de requisições com falha: erros, throttles e timeouts. Cada retry adiciona latência, e um timeout no lado cliente de uma requisição que ainda completa no serviço pode ser cobrado duas vezes.
- Efetividade do cache: a proporção reads versus writes do Estágio 4.
- Cobertura de metadados: o percentual de chamadas em produção com metadados completos. Cada chamada sem cobertura é um ponto cego de atribuição que degrada silenciosamente todos os outros números.
Quando um sinal deriva, a remediação é uma mudança de política (regras de roteamento, limites de tokens, enforcement de metadados) — não um e-mail pedindo para os times serem mais cuidadosos.
O scorecard de FinOps
Os thresholds abaixo são pontos de partida, não prescrições. Calibre-os com os dados da sua frota antes de adotá-los como política:
- Custo unitário por resultado bem-sucedido: Verde = dentro do orçamento; Amarelo = 1–1,5x o orçamento; Vermelho = acima de 1,5x.
- Custo diário por desenvolvedor: Verde = abaixo de US$ 100; Amarelo = US$ 100–300; Vermelho = acima de US$ 300.
- % de chamadas em modelos de menor custo: Verde = acima de 50%; Amarelo = 30–50%; Vermelho = abaixo de 30%.
- Taxa de hit de cache read: Verde = acima de 60%; Amarelo = 30–60%; Vermelho = abaixo de 30%.
Revise esse scorecard em cadência regular — semanal para frotas de alta velocidade, quinzenal para as demais — e trate-o como a superfície de decisão conjunta entre FinOps e plataforma.
Conclusão
O modelo operacional em cinco estágios leva o gasto com Amazon Bedrock de descontrolado a totalmente governado: atribuir cada gasto a um responsável via tags de principal IAM e session tags no CUR 2.0; observar cada requisição via logging de invocação de modelo e metadados carimbados; enforçar orçamentos no tier que corresponde ao seu risco; otimizar os padrões da plataforma com roteamento inteligente de prompts e cache; e operar um scorecard e cadência de revisão que transformam telemetria em decisões de política.
Vale notar a primeira linha do scorecard: custo por resultado bem-sucedido, não custo por chamada. Tudo aqui torna o gasto com Amazon Bedrock visível, atribuível, limitado e eficiente — mas um workflow pode ser perfeitamente eficiente e ainda assim não valer a pena rodar. Decidir isso exige medir o agente contra o processo humano que ele substituiu, o que é uma disciplina de produto e analytics, não de FinOps.
Para começar, implante a arquitetura de referência Guidance for Claude Code with Amazon Bedrock para os Estágios 1 a 3, e depois use a documentação de melhores práticas de atribuição de custos para configurar sua estratégia de tagging.
Fonte
Managing Amazon Bedrock costs end to end: A playbook for FinOps and platform teams (https://aws.amazon.com/blogs/machine-learning/managing-amazon-bedrock-costs-end-to-end-a-playbook-for-finops-and-platform-teams/)
Leave a Reply