Como rastrear e limitar os gastos do Amazon Bedrock por entidade principal do IAM com CUR 2.0 e AWS Budgets

O gasto com IA generativa é difícil de atribuir. Antes de ampliar o acesso à IA, os CFOs e CTOs de uma organização costumam querer três respostas: quanto se gasta por pessoa ou por equipe, se é possível limitar esse gasto e quanto trabalho é necessário para chegar lá.

Em uma publicação anterior, Tokenomics at Scale: How Jamf Built Real-Time Spend Enforcement for Amazon Bedrock, descrevemos um loop de aplicação personalizado construído sobre AWS IAM Identity Center, Amazon Athena executando sobre os logs de invocação de modelos do Amazon Bedrock e AWS Lambda. Essa abordagem oferece controle quase em tempo real, mas exige código que você passa a manter e operar. Esta publicação mostra outro caminho: visibilidade dos custos do Amazon Bedrock por identidade e limites de gasto aplicáveis usando somente recursos nativos da AWS, sem código de aplicação para escrever no caso comum. A abordagem depende de três elementos: a atribuição por entidade principal do IAM, que o Amazon Bedrock registra automaticamente; o AWS Cost and Usage Reports (CUR) 2.0 ou o AWS Cost Explorer para relatórios; e o AWS Budgets com ações de orçamento para aplicação. Ao final, você terá relatórios de custo por identidade e uma barreira automática que restringe o acesso ao Amazon Bedrock quando um limite é ultrapassado.

Visão geral da solução

A solução tem três partes: atribuir, relatar e aplicar.

Atribuir. O Amazon Bedrock captura a identidade da entidade principal do AWS Identity and Access Management (IAM), ou seja, o usuário ou perfil do IAM, em cada solicitação de inferência. Isso acontece automaticamente, sem nenhuma alteração nas chamadas de inferência de modelos do Amazon Bedrock. Se várias pessoas compartilham um mesmo perfil, o detalhamento por usuário é adicionado por meio de tags de sessão passadas no momento da assunção do perfil. Se cada pessoa ou aplicação tem seu próprio perfil, as tags de entidade principal no perfil são suficientes.

Relatar. Ative essas tags como tags de alocação de custos e depois leia os dados no Cost Explorer para uma visualização apenas pelo console, ou em uma exportação de dados do CUR 2.0 para análise detalhada por item de linha e consultas SQL.

Aplicar. Crie um orçamento do AWS Budgets com escopo no Amazon Bedrock e filtrado para uma identidade ou valor de tag e anexe uma ação de orçamento que aplica uma política de negação do IAM quando o limite é ultrapassado.

Pré-requisitos

Para implantar esta solução, você precisa de:

• Uma conta da AWS com acesso a modelos do Amazon Bedrock habilitado.
• Permissões para marcar entidades principais do IAM, ativar tags de alocação de custos, criar exportações de dados e criar orçamentos e ações de orçamento.
• Amazon Bedrock acessado por meio de perfis ou usuários do IAM.
• A AWS Command Line Interface (AWS CLI) configurada com as credenciais apropriadas.
• Uma exportação de dados do CUR 2.0 e um bucket do Amazon Simple Storage Service (Amazon S3) para recebê-la (opcional, para análise detalhada por item de linha).
• Amazon Athena (opcional, para consultar a exportação).

O acesso ao AWS Billing Console é gerenciado separadamente da maioria das permissões do IAM, portanto confirme que você o possui antes de começar.

Passo a passo

Antes de configurar qualquer coisa, verifique o que você já tem. O Amazon Bedrock registra automaticamente a identidade de quem chama em cada solicitação de inferência. Abra o Cost Explorer, filtre Service por Amazon Bedrock e agrupe pela dimensão de identidade ou tag disponível. Em contas onde cada aplicação ou pessoa já usa um perfil do IAM distinto, essa pode ser toda a visibilidade necessária.

Para configurar visibilidade adicional:

• A etapa 1 fornece visibilidade no nível da identidade.
• As etapas 2 a 4 adicionam dimensões de tags e relatórios detalhados.
• A etapa 5 adiciona a aplicação de limites.

Etapa 1: Decida como a identidade se relaciona com seus usuários

A forma de marcar depende de como as entidades principais do IAM estão organizadas.

Um perfil por pessoa ou por aplicação. Anexe tags de entidade principal diretamente a cada perfil ou usuário do IAM. Elas são estáticas e se aplicam a todas as solicitações dessa entidade principal. Use o console do IAM ou a AWS CLI:

aws iam tag-role \
  --role-name BedrockDeveloperRole-alice \
  --tags Key=user,[email protected] Key=team,Value=platform Key=CostCenter,Value=CC-1001

Um perfil compartilhado por várias pessoas, ou um gateway. As tags de entidade principal não conseguem distinguir usuários em um perfil compartilhado, porque todas as sessões carregam as mesmas tags. Use tags de sessão em vez disso, passadas quando o perfil é assumido. As tags de sessão são dinâmicas e podem variar por sessão; se uma tag de sessão e uma tag de entidade principal tiverem a mesma chave, a tag de sessão prevalece naquela sessão.

A política de confiança do perfil deve permitir sts:TagSession. As tags de sessão podem ser passadas de três maneiras:

• sts:AssumeRole com --tags, para um gateway que assume um perfil por usuário ou locatário.
• AssumeRoleWithWebIdentity, com as tags na declaração https://aws.amazon.com/tags do token de ID do OpenID Connect (OIDC) (é um nome de declaração, não uma URL para navegar).
• AssumeRoleWithSAML, mapeando atributos PrincipalTag:* na asserção de Security Assertion Markup Language (SAML) do provedor de identidade.

Se sua organização já captura uma declaração como saml:sub para outros fins, isso por si só não a torna disponível aqui. O provedor de identidade precisa mapear separadamente esse atributo para uma declaração de atributo PrincipalTag:* do SAML, e a política de confiança do perfil precisa permitir sts:TagSession, antes que ele flua como tag de sessão. As duas integrações partem da mesma asserção SAML, mas são configuradas de forma independente. As chaves de tag comuns são user, team, Department, CostCenter e Environment, e é possível aplicar até 50 tags de entidade principal ou de sessão por usuário ou perfil do IAM.

Etapa 2: Ative as tags de alocação de custos

As tags não aparecem nos dados de faturamento até serem ativadas.

1. Abra o console do AWS Billing and Cost Management.
2. Escolha Cost allocation tags.
3. Filtre pelo tipo IAM principal.
4. Selecione suas chaves de tag e escolha Activate.

Em uma AWS Organization, ative as tags de alocação de custos de entidade principal do IAM na conta de gerenciamento (pagadora); as contas-membro não podem ativá-las de forma independente.

Duas coisas a esperar:

• Uma chave de tag só aparece nessa lista depois que a entidade principal faz pelo menos uma chamada ao Amazon Bedrock, portanto faça primeiro uma chamada de teste se a lista estiver vazia.
• Uma chave de tag recém-aplicada pode levar até 24 horas para aparecer para ativação e, depois, até mais 24 horas após a ativação antes de começar a preencher os dados de faturamento.

A ativação não é retroativa por padrão, portanto ative as tags antes de precisar dos dados.

Etapa 3: Crie uma exportação de dados do CUR 2.0 que inclua a identidade de quem chama

Pule esta etapa se o Cost Explorer for suficiente para seus relatórios.

1. No console do Billing and Cost Management, escolha Data Exports.
2. Escolha Create e crie uma exportação CUR 2.0 (Standard).
3. Em Additional export content, selecione Include caller identity (IAM principal) allocation data.
4. Em Time granularity, selecione Hourly.
5. Em Report data integration, selecione Amazon Athena. Isso define o formato de arquivo como Parquet e, o que é importante, entrega um script de configuração no seu bucket do S3 junto com os dados da exportação.
6. Escolha o bucket do Amazon S3 de destino.
7. Execute uma vez o script de configuração entregue (ou o crawler do Glue/DDL que ele define). É isso que realmente cria a tabela do Glue Data Catalog que você consultará na etapa 4; o fluxo de console anterior não a cria automaticamente.

Se você já tem uma exportação do CUR 2.0 criada antes de habilitar a atribuição de identidade, ela não incluirá dados de identidade retroativamente, portanto crie uma nova exportação com a opção de identidade de quem chama selecionada. Na exportação, as tags de entidade principal e de sessão aparecem como colunas com o prefixo iamPrincipal/, e as tags de recurso como resourceTags/. Uma chave de tag team, por exemplo, aparece como iamPrincipal/team. A AWS publica um conjunto de consultas prontas para esse padrão em aws-samples/sample-cur-iam-principal-bedrock-tracking.

Etapa 4: Leia os dados

Há duas maneiras de ler os dados: um caminho apenas pelo console via Cost Explorer e um caminho SQL sobre a exportação do CUR 2.0 com o Amazon Athena.

Caminho do console, sem código personalizado. O Cost Explorer filtrado pelo Amazon Bedrock e agrupado pela sua chave de tag mostra o gasto por equipe ou por usuário em gráfico e tabela. Isso cobre a maioria das necessidades recorrentes de relatório e não exige a criação de consultas.

Caminho SQL, com pouco código. Aponte o Amazon Athena para a exportação do CUR 2.0 para agrupar o gasto por iamPrincipal/team e tipo de uso:

SELECT
    tags['iamPrincipal/team'] AS team,
    line_item_usage_type,
    SUM(line_item_unblended_cost) AS cost
FROM cur2_view
WHERE product_servicecode IN ('AmazonBedrock', 'AmazonBedrockService')
AND billing_period = '2026-09'
GROUP BY 1, 2
ORDER BY 3 DESC

Pontos a observar:

• Código de serviço: o gasto do Amazon Bedrock pode ser registrado sob mais de um valor de product_servicecode, por exemplo AmazonBedrock e AmazonBedrockService.
• Nome da tabela: o nome da tabela (cur2_view) é o que o script de configuração da etapa 3 deu à tabela do Glue ao criá-la. Verifique o script ou seu catálogo do Glue se for diferente. Os nomes das colunas seguem o esquema Parquet do CUR 2.0 independentemente do nome da tabela.
• Coluna do período de faturamento: confirme como sua exportação expõe o período. Algumas exportações usam billing_period (YYYY-MM); outras particionam por uma coluna de data de início ou de ano/mês.

Duas observações valem para qualquer consulta que você escrever:

• Conte todos os tipos de token: o Amazon Bedrock cobra quatro tipos de token, cada um a uma taxa diferente: entrada, saída, leitura de cache e gravação de cache. Cada um é um item de linha separado, com seu próprio tipo de uso e preço unitário, portanto somar apenas entrada e saída subestima o gasto. A diferença é maior em cargas de trabalho que usam intensamente o cache de prompts. Consulte o documento da AWS Understanding Amazon Bedrock pricing in CUR para as informações mais recentes.
• Associe a taxa ao item de linha, não ao modelo: o preço do Amazon Bedrock no CUR é determinado por três fatores: o tipo de token, o nível de serviço e se a solicitação foi roteada por inferência entre regiões. Solicitações dentro da região e entre regiões têm preços diferentes, e o nível de serviço também aparece no tipo de uso. O tipo de uso carrega um sufixo que indica o roteamento entre regiões e o nível de serviço, portanto, se suas cargas de trabalho misturam esses casos, associe a taxa a cada item de linha em vez de aplicar uma única taxa por modelo. Consulte os exemplos de tipos de uso do CUR.

Etapa 5: Adicione aplicação com AWS Budgets e ações de orçamento

O AWS Budgets realiza o anexo, portanto não há código personalizado nesse fluxo de trabalho. As ações de orçamento são anexadas a um usuário, grupo ou perfil específico do IAM, o que isola o acesso de uma pessoa somente se ela já tiver seu próprio perfil. Se o tráfego do Amazon Bedrock passa por um perfil compartilhado por muitas pessoas, uma ação de negação anexada a esse perfil bloqueia todos que o usam, não apenas quem ultrapassou o limite.

O AWS Budgets pode executar uma ação quando um limite é ultrapassado. As ações disponíveis incluem aplicar uma política do IAM personalizada, aplicar uma service control policy (SCP) e atingir instâncias do Amazon Elastic Compute Cloud (Amazon EC2) ou do Amazon Relational Database Service (Amazon RDS). Para este caso de uso, a ação relevante é a de política do IAM.

Primeiro, crie a política de negação que a ação anexará. Este exemplo nega os modelos de maior custo mantendo disponível um modelo de menor custo, para que o usuário possa continuar trabalhando:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/[HIGHER-COST-MODEL-ID]"
      ]
    }
  ]
}

Substitua [HIGHER-COST-MODEL-ID] pelo ID do modelo que você deseja negar no seu ambiente.

Depois configure as permissões e o próprio orçamento. Há dois perfis distintos aqui, e a política gerenciada da AWS cobre apenas um deles:

• Seu próprio usuário ou perfil (o que configura o orçamento) precisa da política gerenciada da AWS AWSBudgetsActionsWithAWSResourceControlAccess. Ela concede permissões de orçamento mais o iam:PassRole condicionado necessário para entregar seu perfil de ação de orçamento ao AWS Budgets.
• O perfil do IAM que o AWS Budgets assume para executar a ação não é coberto por uma única política gerenciada nomeada para este caso de uso. Crie-o com uma política de confiança que permita à entidade principal budgets.amazonaws.com assumi-lo, delimitada pelas condições aws:SourceArn e aws:SourceAccount, e uma política de permissões que conceda iam:AttachRolePolicy e iam:DetachRolePolicy (e organizations:AttachPolicy e organizations:DetachPolicy se você também usar SCPs). Consulte Setting up a role for AWS Budgets to run budget actions para ver as permissões que podem ser concedidas.

Etapas de configuração:

1. Crie o perfil de ação de orçamento descrito acima.
2. Crie um orçamento de custos com escopo no Amazon Bedrock, filtrado para a identidade ou o valor de tag que você quer limitar.
3. Em Configure alerts, adicione um limite de alerta. Escolha Actual para o gasto já realizado ou Forecasted para agir antes que o gasto aconteça.
4. Em Attach actions, escolha Add Action, selecione o perfil de ações de orçamento e escolha a ação de política do IAM. Selecione a política de negação e o usuário, grupo ou perfil do IAM ao qual anexá-la.
5. Para aplicação automática, escolha Yes para executar a ação automaticamente; escolha No para exigir que uma pessoa aprove cada ação na página Alert details.
6. Configure pelo menos uma notificação para que o usuário afetado saiba por que o acesso mudou.

Você pode anexar várias ações a um mesmo limite e vários limites a um mesmo orçamento. É assim que se constroem níveis: por exemplo, negar o modelo premium a 80 por cento e o modelo intermediário a 100 por cento, sem nunca negar o modelo de baixo custo.

Somente a conta de gerenciamento pode aplicar SCPs e, a partir da conta de gerenciamento, é possível aplicar uma SCP a outra conta.

Considerações

• O AWS Budgets não é quase em tempo real: os dados de orçamento são atualizados até três vezes ao dia, portanto o gasto pode ultrapassar um limite antes que a ação seja executada.
• As tags de alocação de custos não são retroativas: espere até 24 horas para que uma chave de tag recém-aplicada apareça e até mais 24 horas após a ativação antes de ela começar a preencher os dados de faturamento.
• O CUR não contém itens de linha por solicitação: tanto o CUR clássico quanto o CUR 2.0 agregam o custo do Amazon Bedrock por tipo de uso, operação e atributos de preço ou recurso ao longo de uma hora ou de um dia.
• Os campos de entidade principal do IAM exigem o CUR 2.0: o formato CUR herdado não os inclui. Os detalhamentos de custo por token estão disponíveis nos dois formatos.
• As tags de sessão são fixadas no momento do AssumeRole, não por solicitação: seus valores são constantes para todas as chamadas feitas com as credenciais daquela sessão e aparecem apenas como dados de faturamento agregados. As tags de sessão não são gravadas nos logs de invocação de modelos; os logs capturam o identity.arn de quem chama. Para distinguir usuários em uma sessão compartilhada no nível da solicitação, use um RoleSessionName por usuário ou defina o usuário nos metadados da solicitação em cada chamada.
• As ações de orçamento são anexadas a usuários, grupos e perfis do IAM: se seus usuários são federados e não têm uma identidade permanente do IAM, a ação precisa de um perfil como alvo. É por isso que o padrão funciona melhor quando cada pessoa ou aplicação tem seu próprio perfil. Se seus usuários compartilham um perfil ou são federados sem perfil próprio, veja a publicação anterior para uma abordagem de aplicação por usuário.
• Um perfil de gateway compartilhado colapsa a atribuição por padrão: com um gateway de large language model (LLM), a identidade capturada é o perfil de execução do gateway.
• Modelos novos exigem atenção: os tipos de uso são específicos de cada modelo. Ao habilitar um modelo novo, confirme que ele aparece como esperado nas suas consultas e filtros de orçamento, em vez de presumir que está coberto.

Estrutura de decisão

Limpeza

Para evitar cobranças contínuas, exclua todos os recursos que você criou.

Conclusão

Este passo a passo mostrou como obter visibilidade dos custos do Amazon Bedrock por identidade e limites de gasto aplicáveis usando somente recursos nativos da AWS, sem código de aplicação para escrever no caso comum, e como essas peças respondem às três perguntas por trás do problema da tokenomia: quanto se gasta por pessoa ou por equipe, se é possível limitar e quanto trabalho é necessário para chegar lá.