Amazon Bedrock cost attribution: Track IAM usage and set spending controls
Principal tags, CUR 2.0, and AWS Budgets can help teams trace Amazon Bedrock costs to identities and restrict access when spending passes a threshold. You can set this up without changing application code, but it won’t cap spending instantly. Shared roles also make it hard to control costs for individuals.
- Use tags to link IAM identities or role sessions to teams and cost centers.
- Use Cost Explorer for a quick view, or CUR 2.0 and Athena for detailed billing analysis.
- AWS Budgets can attach a prepared Deny policy when spending reaches a threshold.
- Budget data refreshes up to three times a day, so spending can exceed the threshold before the action runs.
Attribute, report, enforce
The process has three steps: attribute usage to an identity, report the resulting costs, and enforce limits. AWS’s IAM-principal billing data can link Bedrock usage to the IAM user or role behind an inference request. To use that identity for cost allocation, configure the supported reporting options and add tags where needed.
Choose tags that fit your identity setup
Principal tags are attached to an IAM user or role and apply to usage associated with that identity. Session tags are passed when someone assumes a role, allowing you to distinguish users or tenants who share that role. If a session tag and principal tag have the same key, the session tag takes precedence for that session.
The role’s trust policy must allow sts:TagSession for session tags to pass through. Depending on the configuration, you can supply tags through role-assumption flows such as sts:AssumeRole, AssumeRoleWithWebIdentity, or AssumeRoleWithSAML. AWS allows up to 50 tags on an IAM user or role, and up to 50 session tags for an assumed-role session. These are separate limits.
Before tags show up in billing data, activate the relevant IAM principal cost allocation tag keys in the AWS Billing and Cost Management Console. AWS says a key becomes available for activation only after the principal has made at least one Bedrock call. A newly applied key can take up to 24 hours to appear for activation. Billing data may take up to another 24 hours to reflect it. Activation does not apply retroactively by default.
In an AWS Organization, the management account must activate these tags. Member accounts cannot do so independently. Set up your tagging scheme early. Yesterday’s usage won’t automatically pick up today’s labels. For more on the privacy implications of AI and crypto infrastructure, see Amazon Bedrock and Thales’ tokenization approach.
Cost Explorer for a quick view; CUR 2.0 for detail
Cost Explorer is the simpler choice for charts and tables grouped by identity or an activated tag. For more detailed analysis, use Cost and Usage Reports 2.0 (CUR 2.0), which can include IAM principal fields. The legacy CUR format does not include them. AWS explains its billing export options in the AWS Data Exports guide.
To export CUR 2.0 data with IAM-principal details, enable Include caller identity (IAM principal) allocation data, choose Hourly time granularity, and select Amazon Athena integration. The export sends files to Amazon S3 but does not create the query table for you. Run the provided setup script, or use an equivalent Glue crawler or DDL, to create the table in the AWS Glue Data Catalog.
Existing CUR 2.0 exports created before identity attribution was enabled will not gain that data retroactively. In query results, IAM principal tag columns use the iamPrincipal/ prefix, while resource tag columns use resourceTags/. Bedrock charges can appear under more than one product service code, including AmazonBedrock and AmazonBedrockService. Filtering on just one may leave out relevant usage.
CUR provides billing line items at the report’s selected time granularity. It does not create a separate billing record for each inference request. You can group those records by usage type, operation, and pricing or resource attributes. CUR is useful for cost analysis, but it is not a request-by-request audit trail.
Count every token category
Bedrock usage may have separate rates and line items for input tokens, output tokens, cache reads, and cache writes. Add up only input and output tokens, and you may understate spending, especially if your workloads rely heavily on prompt caching. Bedrock’s role in AI micropayments is another emerging use case, explored in Amazon and Coinbase’s AgentCore payments launch.
Prices can also vary by token type, service tier, and whether a request used cross-Region inference. Match prices to individual CUR line items instead of applying one rate to every request for a model. AWS’s sample repository, aws-samples/sample-cur-iam-principal-bedrock-tracking, includes queries for this reporting pattern.
Budgets can restrict access, but not instantly
AWS Budgets can monitor actual or forecasted spending and trigger an action when a threshold is crossed. For this setup, configure the action to attach a prepared IAM policy that explicitly denies selected operations. For example, the policy can deny bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for a specified foundation model, with the model resource scoped in the policy.
Budget actions can target an IAM user, group, or role. They can run automatically or require human approval. A budget can have multiple thresholds and actions. For example, an organization might deny access to a premium model at 80 percent of a budget, then restrict a mid-tier model at 100 percent while keeping a lower-cost model available. Those are examples, not universal settings.
Set up at least one notification to explain access changes to affected users. A sudden denial with no explanation is a good way to create confusion and support tickets.
The main limitation is timing: AWS Budgets data refreshes up to three times a day. Spending can pass the threshold before an action runs, and AWS does not specify a universal overshoot amount. Treat budget actions as a guardrail, not a hard, immediate cap.
Shared roles are the weak link
A budget action applies to the identity it targets. If several people use one IAM role, attaching a Deny policy to that role blocks everyone, not just the person whose usage pushed spending over the limit.
The same attribution problem comes up with an LLM gateway. By default, Bedrock records the gateway’s execution role rather than the individual end user behind it. Session tags can distinguish users or tenants in aggregated billing data, but they are set when the role is assumed and stay the same for that session. They are not written into model invocation logs. AWS’s work with Ripple on AI-driven XRP Ledger monitoring is another example of AI being applied to blockchain operations.
For request-level distinctions, the source recommends a per-user RoleSessionName or request metadata, depending on the implementation. Those identifiers belong to the relevant session or logging setup. They do not make CUR a per-request billing record. If you need individual limits behind a shared gateway, a budget action targeting the gateway role cannot isolate users. You may need a more customized enforcement design.
Key questions and answers
-
Can Bedrock costs be attributed to IAM identities?
Yes. IAM-principal billing data can link usage to an IAM user or role. Tags can add team, user, or cost-center context when identities and sessions are configured accordingly.
-
When should I use CUR 2.0 instead of Cost Explorer?
Use Cost Explorer for a simpler view in the console. CUR 2.0 is better for detailed billing analysis and SQL queries through Athena.
-
Can AWS Budgets stop spending at an exact limit?
No. It can trigger an access restriction after detecting a threshold, but delayed data refresh means spending may exceed the limit first.
-
Does tag activation apply to past usage?
Generally, no. Billing data from before activation, or from a CUR 2.0 export created before identity attribution was enabled, should not be expected to populate retroactively.
-
Will a budget action affect only one person using a shared role?
No. It affects the IAM user, group, or role targeted by the action, so everyone using a shared role is affected.
This setup offers useful cost visibility and policy-based controls without requiring you to build an enforcement loop from scratch. But tags take time to appear, billing records are aggregated, and budget actions can lag. If you need immediate, per-user limits, especially behind shared roles or gateways, design around those constraints. A budget threshold is not a precision kill switch.
