AWS explains per-identity Amazon Bedrock cost reporting and spend limits

AWS published a post on its Machine Learning Blog on 12 November 2026 describing how to see Amazon Bedrock costs per IAM user or role and restrict access when a threshold is crossed. The method uses AWS-native features (CUR 2.0, Cost Explorer and AWS Budgets) and needs no application code in the common case.

What happened

In a post on the AWS Machine Learning Blog, six named authors offer a lower-effort alternative to the custom enforcement loop in their earlier post about Jamf. That earlier design combined IAM Identity Center, Amazon Athena over Bedrock model invocation logs, and AWS Lambda. The authors say it gives near-real-time control but leaves you with code to own and operate.

The new approach has three parts: attribute, report and enforce.

• Attribute: Bedrock records the calling IAM user or role for every inference request automatically, with no change to your model calls.
• Report: you activate your tags for cost allocation, then read the results in Cost Explorer (console only) or in a CUR 2.0 data export queried with SQL.
• Enforce: you define a budget limited to the Bedrock service and filtered to one identity or tag value, then attach a budget action that applies a Deny IAM policy when the threshold is crossed.

Key details

Prerequisites

• An AWS account with Bedrock model access enabled, using IAM roles or IAM users.
• Permissions to tag IAM principals, activate cost allocation tags, create data exports, and create budgets and budget actions.
• AWS CLI configured with credentials.
• Optional, for line-item analysis: a CUR 2.0 export, an S3 bucket to receive it, and Amazon Athena.
• Billing console access, which the post notes is managed separately from most IAM permissions.

The post suggests checking what you already have first: open Cost Explorer, filter to Amazon Bedrock and group by the available identity or tag dimension. If each person or app already has its own role, that may be enough.

Choosing how to tag

• One role per person or application: put principal tags directly on the role or user. They are static and apply to every request from that principal.
• Shared role or gateway: principal tags cannot tell users apart, so use session tags passed when the role is assumed. If a session tag and a principal tag share a key, the session tag wins for that session.
• Session tags require the role's trust policy to allow sts:TagSession. They can be passed via sts:AssumeRole with --tags, via AssumeRoleWithWebIdentity using the https://aws.amazon.com/tags claim in an OIDC ID token, or via AssumeRoleWithSAML by mapping PrincipalTag:* attributes in the SAML assertion.
• A claim such as saml:sub captured for other purposes is not automatically a session tag. The identity provider must map it separately.
• You can apply up to 50 principal or session tags per IAM user or role.

Activating tags

• Tags do not show up in billing data until activated in the Billing and Cost Management console, under Cost allocation tags, filtered by type IAM principal.
• In an AWS Organization, activation must happen in the management (payer) account.
• A tag key only appears after the principal has made at least one Bedrock call, so make a test call if the list is empty.
• A new tag key can take up to 24 hours to become available for activation, then up to another 24 hours before it populates billing data. Activation is not retroactive by default.

Setting up the CUR 2.0 export

Skip this if Cost Explorer covers your reporting. Otherwise:

1. In Data Exports, create a CUR 2.0 (Standard) export.
2. Under Additional export content, select the option to include caller identity (IAM principal) allocation data.
3. Set time granularity to Hourly.
4. Under Report data integration, choose Amazon Athena. This sets the format to Parquet and delivers a setup script to your S3 bucket.
5. Choose the destination S3 bucket.
6. Run the delivered setup script (or the Glue crawler/DDL it defines) once. This creates the Glue Data Catalog table you will query; the console flow does not create it.

An export created before you enabled identity attribution will not include identity data retroactively, so create a new one. Principal and session tags appear as columns prefixed iamPrincipal/, so a team tag becomes iamPrincipal/team. The post points to a ready-made query set in the aws-samples/sample-cur-iam-principal-bedrock-tracking repository.

Querying the data

The post's Athena example sums line_item_unblended_cost, grouped by the iamPrincipal/team tag and line_item_usage_type, for one billing period, ordered by cost. Three caveats:

• Bedrock spend can be recorded under more than one product_servicecode, such as AmazonBedrock and AmazonBedrockService, so filter on both.
• The example table name, cur2_view, is whatever your setup script assigned.
• Check how your export exposes the billing period; some use a billing_period column in YYYY-MM form.

Try it

For the one-role-per-person case, the post tags a role with the AWS CLI. This version uses a plain username instead of the post's example email address:

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

Why it matters

For developers, the practical gain is a route to per-person or per-team Bedrock cost data and a spending guardrail that lives in billing configuration rather than in a service you maintain. The tradeoff is timing: tag activation can take up to two days to reach billing data, and the authors describe their earlier custom loop, not this one, as the near-real-time option.

Plan tagging before rollout, and decide early whether you need principal tags or session tags. A shared role or gateway will need session tags, which means trust-policy and identity-provider changes.