Track and Cap Amazon Bedrock Spend Per IAM Principal With CUR 2.0 and AWS Budgets

AWS says you can attribute Amazon Bedrock spend to each IAM user or role, and cap it, using only AWS-native features and no application code. The walkthrough is Tokenomics at scale, published November 12, 2026 by Arun Chandapillai, Aditya Mettu, Andre Bernardo, Andrew Dunham, Levi McCormick and Cami Persson. It is rated Advanced (300). The page we could read was truncated partway through the enforcement step, so we note below where our coverage stops.

The motivation is simple. Before leadership widens AI access, they usually ask what each person or team spends, whether it can be capped, and how much work that takes. This post answers the last question with "configuration, not code."

TL;DR

Where it fits

AWS says its earlier post described a custom enforcement loop built on IAM Identity Center, Amazon Athena over Bedrock model invocation logs and AWS Lambda. That design gives near-real-time control but needs code the customer owns and operates. The new post targets the same outcome with native features. The trade-off is time: billing data lags, so a cap may fire later than a code-based loop would. For a look at the invocation-log approach, see our post on the Bedrock tokenomics data lake.

The three parts

1. Attribute. Bedrock automatically records the IAM principal, a user or role, for each inference request, with no change to your calls.
2. Report. Activate the tags as cost allocation tags, then view data in Cost Explorer or in a CUR 2.0 export queried through Athena.
3. Enforce. Create an AWS Budget scoped to Bedrock and filtered to an identity or tag value. A budget action then attaches a Deny IAM policy when the threshold is crossed.

Prerequisites

You need an AWS account with Bedrock model access, permission to tag principals, activate cost allocation tags, create data exports and create budgets and budget actions, and Bedrock access through IAM roles or users. The AWS CLI should be configured. A CUR 2.0 export with an S3 bucket and Athena are optional. Billing console access is managed separately from most IAM permissions, so check it early.

Walkthrough

Step 0: check what you already have. Open Cost Explorer, filter to Bedrock and group by the identity dimensions that are available. If each user or app already has its own role, this may be enough.

Step 1: map identity to tags.

• One role per person or app: put static principal tags on the role, for example user, team and CostCenter, in the console or with aws iam tag-role.
• Shared role or gateway: use session tags passed when the role is assumed. The trust policy must allow sts:TagSession. Tags can pass through sts:AssumeRole --tags, AssumeRoleWithWebIdentity with an OIDC token claim, or AssumeRoleWithSAML with SAML PrincipalTag:* attributes. A session tag overrides a principal tag with the same key, and each principal supports up to 50 tags.

Step 2: activate the tags. In the Billing console, filter cost allocation tags by the IAM principal type and activate them. In an AWS Organization, activation must happen from the management account. A tag key appears only after the principal has made at least one Bedrock call. Propagation can take up to about 24 hours to show the key, plus up to another 24 hours after activation before billing data populates. Activation is not retroactive.

Step 3: create the CUR 2.0 export. Create a Standard export with "Include caller identity (IAM principal) allocation data," hourly granularity, Athena integration in Parquet format and an S3 destination. Run the delivered setup script to create the Glue table, because the console does not do it automatically. Existing exports do not gain identity data retroactively. Tag columns use prefixes such as iamPrincipal/ and resourceTags/. AWS points to sample queries in the aws-samples/sample-cur-iam-principal-bedrock-tracking repository.

Step 4: read the data. In the console, filter Cost Explorer to Bedrock and group by a tag key. In SQL, an Athena query groups line_item_unblended_cost by iamPrincipal/team and line_item_usage_type, filtered on the Bedrock service codes AmazonBedrock and AmazonBedrockService and on a billing period. The table name comes from the setup script, and the billing-period column may differ between exports.

Step 5: enforce. AWS Budgets with budget actions attaches a Deny policy to a specific IAM user, group or role, which isolates an individual's access when the threshold is crossed. The rest of this step was cut off in the source we read, so follow the full AWS post for details such as how and when access is restored.

The token-counting mistake

AWS's most practical caution concerns totals. Count all four token types: input, output, cache read and cache write. Each is a separate line item, and omitting cache tokens undercounts spend, especially with prompt caching. Pricing varies by token type, service tier and whether cross-Region inference was used, so match rates to line items, not only to model names. This echoes the point in AWS's companion post on cost per task, not per token.

How the three AWS posts fit together

This is the first of three Bedrock posts AWS published the same day. This one answers "who spent what, and can we stop them." The second, on cost per task and agent ROI, answers "why is this workflow expensive and is it worth it." The third, on a self-service gateway with LiteLLM, shows one way to hand developers keys with budgets attached. Read in that order, they move from attribution to value to developer experience.

A small example shows the tag approach in use. A company gives each of three product teams its own role and tags each role with team and CostCenter. After the delay, Cost Explorer shows Bedrock cost by team. Finance then creates one budget per team, filtered to that team's tag, with an action that attaches a Deny policy at 100 percent. The company adds a lower alert threshold first so the team lead hears about a problem before access stops. That example is ours, built from the steps above, not an AWS case study.

Pitfalls to plan for

• Delay. With up to about 24 hours for the key and up to 24 more for billing data, a tag you activate today will not drive a budget tomorrow morning. Activate early.
• No back-fill. Neither tags nor existing exports gain identity data retroactively. Spend before activation stays unattributed.
• Shared roles. Without session tags set in your identity provider and trust policy, a shared role shows as one spender.
• Management account. In an AWS Organization, activation must happen there, which may need a request to another team.
• Blunt enforcement. A Deny policy blocks the principal. Decide in advance who is told, who can lift it, and whether a team lead should get a warning at a lower threshold first.

Gateway or tags?

Two AWS patterns now cover the same need from different sides. This tag-and-budget approach uses billing data and IAM. The LiteLLM gateway pattern puts a proxy in front of Bedrock and enforces per-key budgets as requests arrive, returning an HTTP 429 when a key goes over. The gateway reacts in real time but is another service to run. The tag approach is serverless and native but reacts on billing time. A large organization may use both: tags for accountability and finance, and a gateway for developer experience.

If you run agents on AWS, the same attribution question applies to them. Our posts on the agent registry with CloudTrail and EventBridge and the Trovata treasury agents show agent workloads that would need the same principal tagging.

Checklist

1. Check Cost Explorer first; per-role attribution may already be enough.
2. Decide whether you need one role per person or session tags on a shared role.
3. Activate cost allocation tags now, from the management account if you use Organizations.
4. Create a CUR 2.0 export with caller identity data and run the setup script.
5. Sum all four token types and match rates to usage-type line items.
6. Create a Bedrock-scoped budget with a Deny action, and write down who can lift it.
7. Test with a low threshold on a test principal before you apply it to people.

Caveats

This is vendor guidance, and we read it only up to the enforcement step. We have not run the setup, and we saw no data on how quickly a budget action fires in practice. Check current AWS documentation for the exact tag and export options in your account and Region.

Related reading

• AWS Part 2: Bedrock cost per task, not per token
• Four Bedrock inference knobs that move token bills (Nov 12)
• Self-service LLM gateway on Bedrock with LiteLLM
• Amazon Bedrock tokenomics data lake
• AWS agent registry with CloudTrail and EventBridge
• Trovata treasury agents on Bedrock AgentCore
• Claude Code token efficiency and prompt cache guide

This post reflects the AWS article available on November 12, 2026.