As AI inference grows into a big share of cloud spend, understanding who and what are driving prices is important for chargebacks, value optimization, and monetary planning. At the moment, we’re saying 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 will be an IAM person, a task assumed by an software, 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 optionally available value allocation tags, you possibly can combination prices by crew, venture, or customized dimension in AWS Price Explorer and AWS Price and Utilization Experiences (CUR 2.0).
On this publish, we share how Amazon Bedrock’s granular value attribution works and stroll by means of instance value monitoring situations.
How granular value attribution works
In your CUR 2.0, you possibly can see which AWS Identification and Entry Administration (IAM) principals are calling Amazon Bedrock and what every is spending while 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:person/alice
USE1-Claude4.6Sonnet-input-tokens
$0.069
arn:aws:iam::123456789012:person/alice
USE1-Claude4.6Sonnet-output-tokens
$0.214
arn:aws:iam::123456789012:person/bob
USE1-Claude4.6Opus-input-tokens
$0.198
arn:aws:iam::123456789012:person/bob
USE1-Claude4.6Opus-output-tokens
$0.990
Right here, you possibly can 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 exhibits what the line_item_iam_principal column comprises for every id kind:
The way you name Amazon Bedrock Inference
line_item_iam_principal
AWS IAM Person
…person/alice
Bedrock key (maps to IAM Person)
…person/BedrockAPIKey-234s
AWS IAM Function (e.g. AWS Lambda perform)
…assumed-role/AppRole/session
Federated Person (e.g. from an id supplier)
…assumed-role/Function/person@acme.org
Including tags for aggregation and Price Explorer
To combination prices by crew, venture, or value heart, 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 they usually apply to each request from that principal.
- Session tags are handed dynamically when a person or software assumes an IAM position to acquire non permanent credentials or embedded in id supplier assertions. To study 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
…person/alice
{“iamPrincipal/crew”:”ds”}
AWS IAM Function
…assumed-role/AppRole/session
{“iamPrincipal/venture”:”chatbot”}
Federated Person
…assumed-role/Function/person@acme.org
{“iamPrincipal/crew”:”eng”}
For extra steerage on constructing a price allocation technique, see Greatest Practices for Tagging AWS Assets.
Quickstart by situation
Your setup is dependent upon how your customers and functions 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
How you can add tags for aggregation + Price Explorer
State of affairs
Builders with IAM customers or API keys
Every person’s ARN seems in CUR 2.0
Connect tags to IAM customers
1
Purposes with IAM roles
Every position’s ARN seems in CUR 2.0
Connect tags to IAM roles
2
Customers authenticate by means of an IdP
session identify in ARN identifies customers
Go session identify and tags out of your IdP
3
LLM gateway proxying to Bedrock
Solely exhibits gateway’s position (one id for all customers)
Add per-user AssumeRole with session identify and tags
4
Be aware: For Eventualities 1–3, the line_item_iam_principal column in CUR 2.0 offers you per-caller id attribution. Tags are solely wanted if you wish to combination by customized dimensions (crew, value heart, 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 position.
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 just a few frequent situations.
State of affairs 1: Per-user monitoring with IAM customers and API keys
Use case: Small groups, growth environments, or fast prototyping the place particular person builders use IAM person credentials or Amazon Bedrock API keys.
The way it works:
Every crew member has a devoted IAM person with long-term credentials. When both user-1 or user-2, for instance, calls Amazon Bedrock, Amazon Bedrock routinely captures their IAM person Amazon Useful resource Title (ARN) throughout authentication. Your CUR 2.0 exhibits who’s spending what.
If you wish to roll up prices by crew, value heart, or one other dimension — for instance, to see complete spend throughout information science crew 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 crew’s customers
aws iam tag-user
–user-name user-1
–tags Key=crew,Worth=”BedrockDataScience” Key=cost-center,Worth=”12345″
aws iam tag-user
–user-name user-2
–tags Key=crew,Worth=”BedrockDataScience” Key=cost-center,Worth=”12345″
What seems in CUR 2.0:
The Price and Utilization Report captures each the person person id and their tags, supplying 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:person/user-1
USE1-Claude4.6Sonnet-input-tokens
$0.0693
{“iamPrincipal/crew”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″}
arn:aws:iam::123456789012:person/user-1
USE1-Claude4.6Sonnet-output-tokens
$0.2145
{“iamPrincipal/crew”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″}
arn:aws:iam::123456789012:person/user-2
USE1-Claude4.6Opus-input-tokens
$0.1980
{“iamPrincipal/crew”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″}
arn:aws:iam::123456789012:person/user-2
USE1-Claude4.6Opus-output-tokens
$0.9900
{“iamPrincipal/crew”:”BedrockDataScience”,”iamPrincipal/cost-center”:”12345″}
The line_item_usage_type column encodes the area, mannequin, and token path (enter vs. output), so you possibly can 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 possibly can analyze prices in a number of methods:
- By person: Filter on line_item_iam_principal to 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_type to check per-model spend, for instance, who’s driving Opus prices vs. Sonnet.
- By crew: Group by iamPrincipal/crew to see complete spend throughout information science crew members. That is helpful for departmental chargeback.
This method is good when you may have a manageable variety of customers and wish the only attainable setup. Every person’s credentials instantly 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 much 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 functions can nonetheless monitor prices again to the originating IAM person or position.
State of affairs 2: Per-application monitoring with IAM roles
Use case: Manufacturing workloads the place functions (not people) name Amazon Bedrock, and also you wish to monitor prices by venture or service.
The way it works:
You will have two backend functions, for instance, a doc processing service (app-1) and a chat service (app-2). Every software runs on compute infrastructure (Amazon EC2, AWS Lambda, Amazon Elastic Container Service (Amazon ECS), and so forth.) and assumes a devoted IAM position to name Amazon Bedrock. When both software calls Amazon Bedrock, the assumed-role ARN is routinely captured. This attribution flows to your CUR 2.0 report, supplying you with per-application value visibility.
You possibly can filter by line_item_iam_principal, which comprises the position identify, to see complete spend per software, or by line_item_usage_type to check mannequin utilization throughout providers. Tags are optionally available. In case your software generates distinctive session names per request or batch job, you possibly can monitor prices at an excellent finer degree of element.
If you wish to roll up prices by venture, value heart, or one other dimension — for instance, to check complete spend throughout DocFlow vs. ChatBackend — connect tags to the IAM roles:
# Tag the doc processing position
aws iam tag-role
–role-name Function-1
–tags Key=venture,Worth=”DocFlow” Key=cost-center,Worth=”12345″
# Tag the chat service position
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 position’s tags movement by means of to billing routinely.
What seems in CUR 2.0:
The line_item_iam_principal exhibits the complete assumed-role ARN together with the session identify, 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 position: See complete spend per software utilizing the position identify portion of the ARN.
- Filter by session: Observe prices per request or batch job utilizing the session identify.
- Mixture by venture: Group by iamPrincipal/venture to check prices throughout DocFlow vs. ChatBackend.
- Mixture by value heart: Group by iamPrincipal/cost-center to see complete spend throughout functions owned by the identical crew.
This method is good for microservices architectures the place every service has its personal IAM position, a safety finest 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 position. Per-user attribution comes from two mechanisms: the session identify (person id embedded within the assumed-role ARN) and session tags (crew, value heart, and so forth. handed from the IdP). One IAM position serves the customers, so there are not any per-user IAM sources to handle.
The session identify (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 situations
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 software units –role-session-name to the person’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., person electronic mail) and PrincipalTag:* attributes (crew, value heart) within the assertion. Each session identify and tags are embedded within the signed assertion — the calling software doesn’t set them individually. The IAM position 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/crew”:”data-science”,”iamPrincipal/cost-center”:”12345″}
…assumed-role/Function-1/user-1@acme.org
USE1-Claude4.6Opus-output-tokens
$0.990
{“iamPrincipal/crew”:”data-science”,”iamPrincipal/cost-center”:”12345″}
…assumed-role/Function-1/user-2@acme.org
USE1-Claude4.6Sonnet-input-tokens
$0.165
{“iamPrincipal/crew”:”engineering”,”iamPrincipal/cost-center”:”67890″}
…assumed-role/Function-1/user-2@acme.org
USE1-Claude4.6Sonnet-output-tokens
$0.264
{“iamPrincipal/crew”:”engineering”,”iamPrincipal/cost-center”:”67890″}
On this instance, user-1 is utilizing Opus and user-2 is utilizing Sonnet. Each share the identical IAM position, however every is individually seen. Group by iamPrincipal/crew for departmental chargeback or parse the session identify 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 position hooked up to the gateway’s compute. With out extra 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 position for every person, passing the person’s id as –role-session-name and their attributes (crew, tenant, value heart) as –tags. The ensuing per-user credentials are cached (legitimate as much as 1 hour) and reused for subsequent requests from the identical person. This requires two IAM roles. The primary is a gateway execution position with sts:AssumeRole and sts:TagSession permissions. The second is an Amazon Bedrock invocation position, trusted by the gateway position and scoped to Amazon Bedrock APIs.
Determine 2. Identification movement in LLM Gateway situations
Key implementation issues:
- Cache periods: AssumeRole provides minimal latency. With a 1-hour time to stay (TTL), you name STS as soon as per person per hour, not per request.
- Cache measurement scales with concurrent customers, not complete customers (500 concurrent = ~500 cached periods).
- STS price restrict is 500 AssumeRole calls/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/crew”:”data-science”}
…assumed-role/BedrockRole/gw-user-1
USE1-Claude4.6Sonnet-output-tokens
$0.163
{“iamPrincipal/crew”:”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 position. 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/providers 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 identify + 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 a minimum of one Amazon Bedrock request (enable as much as 24 hours), they seem within the AWS Administration Console below 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 below the IAM class. You possibly can:
- Filter by crew = data-science to see that crew’s complete Amazon Bedrock spend
- Group by tenant to check prices throughout your prospects
- Mix dimensions to reply questions like “How a lot did the engineering crew spend on Claude Sonnet this month?”
Getting began
The brand new value attribution function for Amazon Bedrock is out there now in business areas at no extra value. To get began:
- Establish your entry sample. Are builders calling Amazon Bedrock instantly with IAM customers or API keys (State of affairs 1)? Are functions 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 identify 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 crew, group by venture, or mix dimensions to reply questions like “How a lot did the engineering crew 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 possibly can hint inference requests again to a selected person, software, or tenant utilizing IAM id and tagging mechanisms you may have in place. Whether or not your groups name Amazon Bedrock instantly 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 extra value.
In regards to the authors
Ba’Carri Johnson is a Sr. Technical Product Supervisor on the Amazon Bedrock crew, specializing in value administration and governance for AWS AI. With a background in AI infrastructure, laptop science, and technique, she is captivated with product innovation and serving to organizations scale AI responsibly. In her spare time, she enjoys touring and exploring the nice outdoor.
Vadim Omeltchenko is a Sr. Amazon Bedrock Go-to-Market Options Architect who’s captivated with serving to AWS prospects innovate within the cloud.
Ajit Mahareddy is an skilled Product and Go-To-Market (GTM) chief with over 20 years of expertise in product administration, engineering, and go-to-market. Previous to his present position, Ajit led product administration constructing AI/ML merchandise at main expertise firms, together with Uber, Turing, and eHealth. He’s captivated with advancing generative AI applied sciences and driving real-world impression with generative AI.
Sofian Hamiti is a expertise chief with over 12 years of expertise constructing AI options, and main high-performing groups to maximise buyer outcomes. He’s passionate in empowering various expertise to drive international impression and obtain their profession aspirations.
