As AI inference grows into a big share of cloud spend, understanding who and what are driving prices is crucial for chargebacks, value optimization, and monetary planning. Right now, we’re asserting granular value attribution for Amazon Bedrock inference.
Amazon Bedrock now routinely attributes inference prices to the IAM principal that made the decision. An IAM principal could be an IAM consumer, a task assumed by an utility, or a federated id from a supplier like Okta or Entra ID. Attribution flows to your AWS Billing and works throughout fashions, with no sources to handle and no modifications to your present workflows. With non-obligatory value allocation tags, you may combination prices by workforce, venture, or customized dimension in AWS Price Explorer and AWS Price and Utilization Studies (CUR 2.0).
On this put up, we share how Amazon Bedrock’s granular value attribution works and stroll by means of instance value monitoring eventualities.
How granular value attribution works
In your CUR 2.0, you may see which AWS Identification and Entry Administration (IAM) principals are calling Amazon Bedrock and what every is spending once you allow IAM principal information in your information export configuration, as proven within the following instance:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost |
| arn:aws:iam::123456789012:consumer/alice | USE1-Claude4.6Sonnet-input-tokens | $0.069 |
| arn:aws:iam::123456789012:consumer/alice | USE1-Claude4.6Sonnet-output-tokens | $0.214 |
| arn:aws:iam::123456789012:consumer/bob | USE1-Claude4.6Opus-input-tokens | $0.198 |
| arn:aws:iam::123456789012:consumer/bob | USE1-Claude4.6Opus-output-tokens | $0.990 |
Right here, you may see that Alice is utilizing Claude 4.6 Sonnet and Bob is utilizing Claude 4.6 Opus, and what every is spending in enter and output tokens. The next desk reveals what the line_item_iam_principal column accommodates for every id sort:
| The way you name Amazon Bedrock Inference | line_item_iam_principal |
| AWS IAM Person | …consumer/alice |
| Bedrock key (maps to IAM Person) | …consumer/BedrockAPIKey-234s |
| AWS IAM Function (e.g. AWS Lambda operate) | …assumed-role/AppRole/session |
| Federated Person (e.g. from an id supplier) | …assumed-role/Function/consumer@acme.org |
Including tags for aggregation and Price Explorer
To combination prices by workforce, venture, or value middle, add tags to your IAM principals. Tags movement to your billing information in two methods:
- Principal tags are hooked up on to IAM customers or roles. Set them as soon as and so they apply to each request from that principal.
- Session tags are handed dynamically when a consumer or utility assumes an IAM function to acquire short-term credentials or embedded in id supplier assertions. To be taught extra, see Passing session tags in AWS STS.
After activation as value allocation tags in AWS Billing, each tag varieties seem within the tags column of CUR 2.0 with the iamPrincipal/ prefix, as proven within the following instance:
| The way you name Bedrock | line_item_iam_principal | tags |
| AWS IAM Person | …consumer/alice | {“iamPrincipal/workforce”:”ds”} |
| AWS IAM Function | …assumed-role/AppRole/session | {“iamPrincipal/venture”:”chatbot”} |
| Federated Person | …assumed-role/Function/consumer@acme.org | {“iamPrincipal/workforce”:”eng”} |
For extra steering on constructing a price allocation technique, see Greatest Practices for Tagging AWS Sources.
Quickstart by situation
Your setup will depend on how your customers and purposes name Amazon Bedrock. The next desk summarizes the attribution accessible in CUR 2.0 for every entry sample and what to configure for tag-based aggregation:
| Your setup | CUR 2.0 attribution | Tips on how to add tags for aggregation + Price Explorer | State of affairs |
| Builders with IAM customers or API keys | Every consumer’s ARN seems in CUR 2.0 | Connect tags to IAM customers | 1 |
| Purposes with IAM roles | Every function’s ARN seems in CUR 2.0 | Connect tags to IAM roles | 2 |
| Customers authenticate by means of an IdP | session title in ARN identifies customers | Move session title and tags out of your IdP | 3 |
| LLM gateway proxying to Bedrock | Solely reveals gateway’s function (one id for all customers) | Add per-user AssumeRole with session title and tags | 4 |
Word: For Situations 1–3, the line_item_iam_principal column in CUR 2.0 provides you per-caller id attribution. Tags are solely wanted if you wish to combination by customized dimensions (workforce, value middle, tenant) or use Price Explorer for visible evaluation and alerts. For State of affairs 4, per-user session administration is required to get user-level attribution. With out it, site visitors is attributed to the gateway’s single function.
After including tags, activate your value allocation tags within the AWS Billing console or by way of UpdateCostAllocationTagsStatus API. Tags seem in Price Explorer and CUR 2.0 inside 24–48 hours.
The next sections stroll by means of a couple of widespread eventualities.
State of affairs 1: Per-user monitoring with IAM customers and API keys
Use case: Small groups, improvement environments, or speedy prototyping the place particular person builders use IAM consumer credentials or Amazon Bedrock API keys.
The way it works:
Every workforce member has a devoted IAM consumer with long-term credentials. When both user-1 or user-2, for instance, calls Amazon Bedrock, Amazon Bedrock routinely captures their IAM consumer Amazon Useful resource Title (ARN) throughout authentication. Your CUR 2.0 reveals who’s spending what.
If you wish to roll up prices by workforce, value middle, or one other dimension — for instance, to see whole spend throughout information science workforce members — connect tags to your IAM customers. You possibly can add tags within the IAM console, AWS Command Line Interface (AWS CLI), or the AWS API. The next instance makes use of the AWS CLI:
# Tag the information science workforce's customers
aws iam tag-user
--user-name user-1
--tags Key=workforce,Worth="BedrockDataScience" Key=cost-center,Worth="12345"
aws iam tag-user
--user-name user-2
--tags Key=workforce,Worth="BedrockDataScience" Key=cost-center,Worth="12345"What seems in CUR 2.0:
The Price and Utilization Report captures each the person consumer id and their tags, providing you with two dimensions for evaluation as proven within the following instance:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| arn:aws:iam::123456789012:consumer/user-1 | USE1-Claude4.6Sonnet-input-tokens | $0.0693 | {“iamPrincipal/workforce”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:iam::123456789012:consumer/user-1 | USE1-Claude4.6Sonnet-output-tokens | $0.2145 | {“iamPrincipal/workforce”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:iam::123456789012:consumer/user-2 | USE1-Claude4.6Opus-input-tokens | $0.1980 | {“iamPrincipal/workforce”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:iam::123456789012:consumer/user-2 | USE1-Claude4.6Opus-output-tokens | $0.9900 | {“iamPrincipal/workforce”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″} |
The line_item_usage_type column encodes the area, mannequin, and token route (enter vs. output), so you may reply questions like “How a lot did user-1 spend on Sonnet enter tokens vs. output tokens?” or “Who’s utilizing Opus vs. Sonnet?”
From this information, you may analyze prices in a number of methods:
- By consumer: Filter on
line_item_iam_principalto see precisely how a lot every particular person spent. That is helpful for figuring out heavy customers or monitoring particular person experimentation prices. - By mannequin: Filter on
line_item_usage_typeto check per-model spend, for instance, who’s driving Opus prices vs. Sonnet. - By workforce: Group by
iamPrincipal/workforceto see whole spend throughout information science workforce members. That is helpful for departmental chargeback.
This method is good when you will have a manageable variety of customers and wish the only attainable setup. Every consumer’s credentials straight establish them in billing, and tags allow you to roll up prices to higher-level dimensions.
Utilizing Amazon Bedrock API keys: Amazon Bedrock additionally helps API keys for a simplified authentication expertise just like different AI suppliers. API keys are related to IAM principals. Requests made with API keys are attributed to the corresponding IAM identities, so the identical line_item_iam_principal and tag-based attribution applies. This implies organizations distributing API keys to builders or embedding them in purposes can nonetheless monitor prices again to the originating IAM consumer or function.
State of affairs 2: Per-application monitoring with IAM roles
Use case: Manufacturing workloads the place purposes (not people) name Amazon Bedrock, and also you wish to monitor prices by venture or service.
The way it works:
You could have two backend purposes, for instance, a doc processing service (app-1) and a chat service (app-2). Every utility runs on compute infrastructure (Amazon EC2, AWS Lambda, Amazon Elastic Container Service (Amazon ECS), and many others.) and assumes a devoted IAM function to name Amazon Bedrock. When both utility calls Amazon Bedrock, the assumed-role ARN is routinely captured. This attribution flows to your CUR 2.0 report, providing you with per-application value visibility.
You possibly can filter by line_item_iam_principal, which accommodates the function title, to see whole spend per utility, or by line_item_usage_type to check mannequin utilization throughout companies. Tags are non-obligatory. In case your utility generates distinctive session names per request or batch job, you may monitor prices at a fair finer degree of element.
If you wish to roll up prices by venture, value middle, or one other dimension — for instance, to check whole spend throughout DocFlow vs. ChatBackend — connect tags to the IAM roles:
# Tag the doc processing function
aws iam tag-role
--role-name Function-1
--tags Key=venture,Worth="DocFlow" Key=cost-center,Worth="12345"
# Tag the chat service function
aws iam tag-role
--role-name Function-2
--tags Key=venture,Worth="ChatBackend" Key=cost-center,Worth="12345"When app-1 assumes Function-1 and calls Amazon Bedrock, the request is attributed to the assumed-role session. The function’s tags movement by means of to billing routinely.
What seems in CUR 2.0:
The line_item_iam_principal reveals the total assumed-role ARN together with the session title, as proven within the following instance:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| arn:aws:sts::123456789012:assumed-role/Function-1/session-123 | USE1-Claude4.6Sonnet-input-tokens | $0.0330 | {“iamPrincipal/venture”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:sts::123456789012:assumed-role/Function-1/session-123 | USE1-Claude4.6Opus-output-tokens | $0.1650 | {“iamPrincipal/venture”:”DocFlow”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:sts::123456789012:assumed-role/Function-2/session-456 | USE1-NovaLite-input-tokens | $0.0810 | {{“iamPrincipal/venture”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} |
| arn:aws:sts::123456789012:assumed-role/Function-2/session-456 | USE1-NovaLite-output-tokens | $0.0500 | {“iamPrincipal/venture”:”ChatBackend”,”iamPrincipal/cost-center”:”12345″} |
This provides you a number of evaluation choices:
- Filter by function: See whole spend per utility utilizing the function title portion of the ARN.
- Filter by session: Observe prices per request or batch job utilizing the session title.
- Combination by venture: Group by
iamPrincipal/ventureto check prices throughout DocFlow vs. ChatBackend. - Combination by value middle: Group by
iamPrincipal/cost-centerto see whole spend throughout purposes owned by the identical workforce.
This method is good for microservices architectures the place every service has its personal IAM function, a safety greatest follow that now doubles as a price attribution mechanism.
State of affairs 3: Per-user monitoring with federated authentication
Use case: Enterprise environments the place customers authenticate by means of a company id supplier (Auth0, Okta, Azure AD, Amazon Cognito) and entry AWS by way of OpenID Join (OIDC) or Safety Assertion Markup Language (SAML) federation.
The way it works:
Customers authenticate by means of your id supplier (IdP) and assume a shared IAM function. Per-user attribution comes from two mechanisms: the session title (consumer id embedded within the assumed-role ARN) and session tags (workforce, value middle, and many others. handed from the IdP). One IAM function serves the customers, so there aren’t any per-user IAM sources to handle.
The session title (highlighted in inexperienced) is what seems in line_item_iam_principal:
arn:aws:sts::123456789012:assumed-role/BedrockRole/user-1@acme.org
Determine 1. Identification movement in federated authentication eventualities
For OIDC federation (Auth0, Cognito, Okta OIDC): Register your IdP as an IAM OIDC supplier, create a task with a belief coverage permitting sts:AssumeRoleWithWebIdentity and sts:TagSession, and configure your IdP to inject the https://aws.amazon.com/tags declare into the ID token. AWS Safety Token Service (AWS STS) routinely extracts session tags from this declare. The calling utility units –role-session-name to the consumer’s electronic mail (or one other identifier) when calling AssumeRoleWithWebIdentity.
For SAML federation (Okta, Azure AD, Ping, ADFS): Configure SAML attribute mappings in your IdP to move RoleSessionName (e.g., consumer electronic mail) and PrincipalTag:* attributes (workforce, value middle) within the assertion. Each session title and tags are embedded within the signed assertion — the calling utility doesn’t set them individually. The IAM function wants sts:AssumeRoleWithSAML and sts:TagSession.
In each circumstances, tags are cryptographically signed contained in the assertion or token so customers can not tamper with their very own value attribution.
What seems in CUR 2.0:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| …assumed-role/Function-1/user-1@acme.org | USE1-Claude4.6Opus-input-tokens | $0.283 | {“iamPrincipal/workforce”:”data-science”,”iamPrincipal/cost-center”:”12345″} |
| …assumed-role/Function-1/user-1@acme.org | USE1-Claude4.6Opus-output-tokens | $0.990 | {“iamPrincipal/workforce”:”data-science”,”iamPrincipal/cost-center”:”12345″} |
| …assumed-role/Function-1/user-2@acme.org | USE1-Claude4.6Sonnet-input-tokens | $0.165 | {“iamPrincipal/workforce”:”engineering”,”iamPrincipal/cost-center”:”67890″} |
| …assumed-role/Function-1/user-2@acme.org | USE1-Claude4.6Sonnet-output-tokens | $0.264 | {“iamPrincipal/workforce”:”engineering”,”iamPrincipal/cost-center”:”67890″} |
On this instance, user-1 is utilizing Opus and user-2 is utilizing Sonnet. Each share the identical IAM function, however every is individually seen. Group by iamPrincipal/workforce for departmental chargeback or parse the session title for per-user evaluation.
State of affairs 4: Per-user monitoring by means of an LLM gateway
Use case: Organizations operating a big language mannequin (LLM) gateway or proxy (LiteLLM, customized API gateway, Kong, Envoy, or a homegrown service) that sits between customers and Amazon Bedrock.
The issue: Gateways authenticate customers at their very own layer, then name Amazon Bedrock utilizing a single IAM function hooked up to the gateway’s compute. With out further work, each Amazon Bedrock name seems in CUR 2.0 as one id with no per-user or per-tenant visibility.
The answer: Per-user session administration
The gateway calls AssumeRole on an Amazon Bedrock-scoped function for every consumer, passing the consumer’s id as --role-session-name and their attributes (workforce, tenant, value middle) as --tags. The ensuing per-user credentials are cached (legitimate as much as 1 hour) and reused for subsequent requests from the identical consumer. This requires two IAM roles. The primary is a gateway execution function with sts:AssumeRole and sts:TagSession permissions. The second is an Amazon Bedrock invocation function, trusted by the gateway function and scoped to Amazon Bedrock APIs.
Determine 2. Identification movement in LLM Gateway eventualities
Key implementation issues:
- Cache classes:
AssumeRoleprovides minimal latency. With a 1-hour time to dwell (TTL), you name STS as soon as per consumer per hour, not per request. - Cache dimension scales with concurrent customers, not whole customers (500 concurrent = ~500 cached classes).
- STS price restrict is 500
AssumeRolecalls/sec/account by default. Request a rise for high-throughput gateways. - Session tags are immutable per session. Tag modifications take impact on subsequent session creation.
What seems in CUR 2.0:
| line_item_iam_principal | line_item_usage_type | line_item_unblended_cost | tags |
| …assumed-role/BedrockRole/gw-user-1 | USE1-Claude4.6Sonnet-input-tokens | $0.081 | {“iamPrincipal/workforce”:”data-science”} |
| …assumed-role/BedrockRole/gw-user-1 | USE1-Claude4.6Sonnet-output-tokens | $0.163 | {“iamPrincipal/workforce”:”data-science”} |
| …assumed-role/BedrockRole/gw-tenant-acme | USE1-Claude4.6Opus-input-tokens | $0.526 | {“iamPrincipal/tenant”:”acme-corp”} |
| …assumed-role/BedrockRole/gw-tenant-acme | USE1-Claude4.6Opus-output-tokens | $0.925 | {“iamPrincipal/tenant”:”acme-corp”} |
With out per-user session administration, gateway site visitors is attributed to the gateway’s single function. Including session administration is the important thing to unlocking per-user and per-tenant attribution.
Selecting your situation
- Builders with IAM customers or Amazon Bedrock API keys → State of affairs 1
- Purposes/companies on AWS compute with IAM roles → State of affairs 2
- Customers authenticate by means of an IdP (Auth0, Okta, Azure AD) → State of affairs 3
- LLM gateway or proxy sitting in entrance of Amazon Bedrock → State of affairs 4
- Constructing a multi-tenant SaaS → State of affairs 4 with tenant ID as session title + session tags
- Claude Code workloads → State of affairs 3
Activating tags in AWS Billing
- Open the AWS Billing console
- Navigate to Price allocation tags
- After your tags have appeared in no less than one Amazon Bedrock request (permit as much as 24 hours), they seem within the AWS Administration Console underneath the IAM class
- Choose the tags you wish to activate and select Activate
For CUR 2.0, you’ll additionally must allow IAM principal when creating or updating your information export configuration.
Viewing prices in Price Explorer
After you activate them, your IAM tags seem in Price Explorer’s Tags drop-down underneath the IAM class. You possibly can:
- Filter by workforce = data-science to see that workforce’s whole Amazon Bedrock spend
- Group by tenant to check prices throughout your prospects
- Mix dimensions to reply questions like “How a lot did the engineering workforce spend on Claude Sonnet this month?”
Getting began
The brand new value attribution function for Amazon Bedrock is obtainable now in industrial areas at no further value. To get began:
- Determine your entry sample. Are builders calling Amazon Bedrock straight with IAM customers or API keys (State of affairs 1)? Are purposes utilizing IAM roles (State of affairs 2)? Do customers authenticate by means of an id supplier (State of affairs 3)? Or does site visitors movement by means of an LLM gateway (State of affairs 4)?
- Allow IAM principal information in your CUR 2.0. Replace your information export configuration to incorporate IAM principal information.
- Add tags if you happen to want aggregation or wish to filter in Price Explorer. Connect tags to IAM customers or roles, configure your IdP to move session title and tags, or add per-user session administration to your gateway. Then activate your value allocation tags within the AWS Billing console.
- Analyze. Inside 24–48 hours of activation, your tags seem in Price Explorer and CUR 2.0. Filter by workforce, group by venture, or mix dimensions to reply questions like “How a lot did the engineering workforce spend on Claude Sonnet this month?”
Conclusion
Understanding who’s spending what on inference is step one to chargebacks, forecasting, and optimization. With granular value attribution for Amazon Bedrock, you may hint inference requests again to a selected consumer, utility, or tenant utilizing IAM id and tagging mechanisms you will have in place. Whether or not your groups name Amazon Bedrock straight with IAM credentials, by means of federated authentication, or by way of an LLM gateway, AWS CUR 2.0 and AWS Price Explorer provide the visibility you want, at no further value.
In regards to the authors
