Por que rastreamento de custos de inferência importa
À medida que modelos de linguagem grande e ferramentas de IA generativa se tornam parte essencial da infraestrutura corporativa, os gastos com inferência passaram a ocupar uma fatia significativa dos orçamentos de nuvem. Para organizações que desejam implementar modelos de chargeback entre equipes, otimizar despesas ou fazer planejamento financeiro preciso, é fundamental saber quem está usando os modelos de IA e quanto cada usuário, aplicação ou projeto está gastando.
A AWS respondeu a essa demanda anunciando um recurso de atribuição granular de custos para o Amazon Bedrock. Agora é possível rastrear automaticamente cada chamada de inferência até o principal da IAM que a originou — seja um usuário individual, uma aplicação com função de acesso, ou uma identidade federada de um provedor externo como Okta ou Entra ID.
Como funciona a atribuição de custos
O recurso funciona de forma transparente, sem necessidade de gerenciar recursos adicionais ou alterar workflows existentes. Os custos de inferência são automaticamente atribuídos através da integração com o AWS Billing e aparecem no CUR 2.0 (Relatório de Custo e Uso versão 2.0).
Ao ativar dados de principal IAM na exportação de dados do CUR 2.0, você verá um novo campo line_item_iam_principal contendo a identidade de quem fez cada chamada, além dos campos de tipo de uso (que indicam qual modelo e se foi processamento de tokens de entrada ou saída) e o custo não faturado. Essa combinação permite responder perguntas como:
- Quanto cada desenvolvedor gastou em tokens de entrada vs. saída?
- Qual modelo (Claude, Llama, Nova) gerou mais custos?
- Quanto a equipe de data science gastou no total?
- Como se distribui o gasto entre diferentes projetos?
Tags para agregação e análise de custos
Além da atribuição automática por identidade IAM, você pode usar tags para agregar custos por dimensões personalizadas como equipe, projeto, centro de custo ou tenant. As tags podem ser aplicadas de duas formas:
- Tags de principal: Anexadas diretamente a usuários ou funções IAM. Uma vez definidas, aplicam-se automaticamente a todas as requisições daquele principal.
- Tags de sessão: Passadas dinamicamente quando um usuário ou aplicação assume uma função IAM para obter credenciais temporárias, ou incorporadas em asserções de provedores de identidade. Para saber mais, consulte a documentação sobre passagem de tags de sessão no AWS STS.
Após ativar essas tags como tags de alocação de custos no AWS Billing, elas aparecem no CUR 2.0 com o prefixo iamPrincipal/ e permitem filtrar e agrupar despesas no AWS Cost Explorer e em relatórios personalizados.
Quatro cenários de implementação
A forma de configurar o rastreamento depende da arquitetura e dos padrões de acesso da sua organização. A AWS detalha quatro cenários principais:
Cenário 1: Rastreamento por usuário com credenciais IAM
Ideal para equipes pequenas, ambientes de desenvolvimento ou prototipagem rápida onde desenvolvedores individuais usam credenciais de usuário IAM ou chaves de API do Amazon Bedrock. Cada membro da equipe tem um usuário IAM dedicado com credenciais de longo prazo. Quando uma chamada ao Amazon Bedrock é feita, a plataforma captura automaticamente a Amazon Resource Name (ARN) do usuário durante a autenticação.
Para agregar custos por equipe ou centro de custo, você anexa tags aos usuários IAM:
aws iam tag-user \
--user-name user-1 \
--tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345"
aws iam tag-user \
--user-name user-2 \
--tags Key=team,Value="BedrockDataScience" Key=cost-center,Value="12345"No CUR 2.0, você verá a identidade individual do usuário, o modelo utilizado, os tokens processados e as tags associadas. Isso permite filtrar por usuário específico, comparar modelos, agrupar por equipe ou cruzar dimensões para análises como “quanto a equipe de data science gastou em tokens de entrada do Claude Sonnet este mês?”
Cenário 2: Rastreamento por aplicação com funções IAM
Adequado para cargas de trabalho em produção onde aplicações (não humanos) chamam o Amazon Bedrock, e você deseja rastrear custos por projeto ou serviço. Duas aplicações backend — um serviço de processamento de documentos e um serviço de chat — rodam em infraestrutura de computação (Amazon EC2, AWS Lambda, Amazon ECS) e cada uma assume uma função IAM dedicada.
Quando cada aplicação chama o Amazon Bedrock, a ARN da função assumida é capturada automaticamente e flui para o CUR 2.0. Você pode filtrar por função para ver o gasto total por aplicação ou por tipo de uso para comparar modelo utilizado entre serviços. Tags opcionais permitem agregar por projeto, centro de custo ou outra dimensão:
aws iam tag-role \
--role-name Role-1 \
--tags Key=project,Value="DocFlow" Key=cost-center,Value="12345"
aws iam tag-role \
--role-name Role-2 \
--tags Key=project,Value="ChatBackend" Key=cost-center,Value="12345"Essa abordagem é ideal para arquiteturas de microsserviços onde cada serviço tem sua própria função IAM — uma prática de segurança recomendada que agora também funciona como mecanismo de atribuição de custos.
Cenário 3: Rastreamento de usuários com autenticação federada
Aplicável em ambientes corporativos onde usuários autenticam através de um provedor de identidade corporativo (Auth0, Okta, Azure AD, Amazon Cognito) e acessam AWS via OpenID Connect (OIDC) ou SAML (Segurança em Linguagem de Asserção de Marcação).
Nesse modelo, usuários autenticam no provedor de identidade e assumem uma função IAM compartilhada. A atribuição por usuário vem de dois mecanismos: o nome da sessão (identidade do usuário incorporada na ARN de função assumida) e tags de sessão (equipe, centro de custo, etc. passadas pelo provedor de identidade). Uma única função IAM serve múltiplos usuários, portanto não há necessidade de gerenciar recursos IAM por usuário.
Para federação OIDC (Auth0, Cognito, Okta OIDC): registre o provedor como provedor OIDC na IAM, crie uma função com política de confiança permitindo sts:AssumeRoleWithWebIdentity e sts:TagSession, e configure o provedor para injetar a declaração https://aws.amazon.com/tags no token de ID. O AWS STS extrai automaticamente as tags de sessão dessa declaração. A aplicação define --role-session-name com o email ou outro identificador do usuário ao chamar AssumeRoleWithWebIdentity.
Para federação SAML (Okta, Azure AD, Ping, ADFS): configure mapeamentos de atributo SAML no provedor para passar RoleSessionName (como email do usuário) e atributos PrincipalTag:* (equipe, centro de custo) na asserção. Ambos ficam criptograficamente assinados dentro da asserção, impedindo que usuários tamperem com sua própria atribuição de custos.
Cenário 4: Rastreamento de usuários através de gateway LLM
Para organizações que rodam um gateway ou proxy de linguagem grande (LiteLLM, gateway de API customizado, Kong, Envoy ou serviço próprio) entre usuários e o Amazon Bedrock. O problema: gateways autenticam usuários em sua própria camada e depois chamam o Amazon Bedrock usando uma única função IAM anexada ao gateway. Sem trabalho adicional, toda chamada ao Bedrock aparece no CUR 2.0 com uma única identidade, sem visibilidade por usuário ou tenant.
A solução é implementar gerenciamento de sessão por usuário. O gateway chama AssumeRole em uma função Bedrock-scoped para cada usuário, passando a identidade do usuário como --role-session-name e seus atributos (equipe, tenant, centro de custo) como --tags. As credenciais resultantes por usuário são cacheadas (válidas até 1 hora) e reutilizadas em requisições subsequentes do mesmo usuário.
Essa abordagem requer duas funções IAM: uma função de execução do gateway com permissões sts:AssumeRole e sts:TagSession, e uma função de invocação do Bedrock confiada pela função do gateway e restrita a APIs do Bedrock.
Considerações práticas de implementação:
- Cache de sessões:
AssumeRoleadiciona latência mínima. Com TTL de 1 hora, você chama STS uma vez por usuário por hora, não por requisição. O tamanho do cache cresce com usuários concorrentes, não usuários totais (500 concorrentes = ~500 sessões em cache). - Limites: O limite padrão de STS é 500 chamadas
AssumeRolepor segundo por conta. Para gateways de alto throughput, você pode solicitar aumento. - Tags imutáveis: Tags de sessão são imutáveis durante a sessão. Mudanças de tag têm efeito na próxima criação de sessão.
Começando: passo a passo
Independentemente do cenário, o fluxo de ativação é similar:
1. Identifique seu padrão de acesso: Desenvolvedores chamam o Bedrock diretamente com usuários IAM ou chaves de API (Cenário 1)? Aplicações usam funções IAM (Cenário 2)? Usuários autenticam através de provedor de identidade (Cenário 3)? Ou tráfego flui através de um gateway LLM (Cenário 4)?
2. Ative dados de principal IAM no CUR 2.0: Atualize sua configuração de exportação de dados para incluir dados de principal IAM.
3. Adicione tags (opcional): Anexe tags a usuários IAM, funções ou configure seu provedor de identidade para passar nome de sessão e tags. Depois, ative suas tags de alocação de custos no console AWS Billing ou via API UpdateCostAllocationTagsStatus. As tags aparecem no Cost Explorer e CUR 2.0 em 24–48 horas.
4. Analise: Filtre por equipe, agrupe por projeto ou combine dimensões para responder perguntas como “Quanto a equipe de engenharia gastou em Claude Sonnet este mês?” dentro de 24–48 horas após ativação.
Para mais orientação sobre estratégia de tags, consulte Melhores Práticas para Tagging de Recursos AWS.
Ativando tags no AWS Billing
Após aplicar tags, ative-as como tags de alocação de custos. Acesse o console AWS Billing, navegue até “Cost allocation tags” e ative suas tags de alocação de custos selecionando as tags desejadas. As tags aparecem em Cost Explorer dentro de 24–48 horas.
Disponibilidade e custos
O novo recurso de atribuição de custos para Amazon Bedrock está disponível agora em regiões comerciais sem custo adicional. O rastreamento funciona para chaves de API do Bedrock e em todos os modelos disponíveis através da plataforma.
Conclusão
Com os gastos em inferência de IA crescendo rapidamente, entender quem está gastando o quê é essencial para implementar modelos de cobrança interna, otimizar custos e planejar orçamentos com precisão. A atribuição granular de custos do Amazon Bedrock oferece visibilidade completa sem exigir recursos adicionais ou mudanças em workflows existentes, integrando-se perfeitamente ao AWS Billing, AWS Cost Explorer e relatórios de custo e uso. Seja você gerenciando equipes pequenas com usuários IAM individuais ou operando gateways LLM com centenas de usuários, a solução se adapta a cada arquitetura e oferece a granularidade necessária para decisões financeiras informadas.
Fonte
Introducing granular cost attribution for Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/introducing-granular-cost-attribution-for-amazon-bedrock/)
Leave a Reply