Introducing granular value attribution for Amazon Bedrock

As AI inference grows into a major share of cloud spend, understanding who and what are driving prices is important for chargebacks, value optimization, and monetary planning. At present, we’re saying granular value attribution for Amazon Bedrock inference.

Amazon Bedrock now mechanically attributes inference prices to the IAM principal that made the decision. An IAM principal will be an IAM person, a job 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 assets to handle and no modifications to your current workflows. With non-obligatory value allocation tags, you’ll be able to mixture prices by staff, challenge, or customized dimension in AWS Price Explorer and AWS Price and Utilization Stories (CUR 2.0).

On this put up, we share how Amazon Bedrock’s granular value attribution works and stroll by way of instance value monitoring situations.

How granular value attribution works

In your CUR 2.0, you’ll be able to see which AWS Id and Entry Administration (IAM) principals are calling Amazon Bedrock and what every is spending while you allow IAM principal knowledge in your knowledge export configuration, as proven within the following instance:

Right here, you’ll be able to 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:

Including tags for aggregation and Price Explorer

To mixture prices by staff, challenge, or value heart, add tags to your IAM principals. Tags movement to your billing knowledge 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 person or software assumes an IAM position to acquire short-term 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 sorts seem within the tags column of CUR 2.0 with the iamPrincipal/ prefix, as proven within the following instance:

For extra steering on constructing a price allocation technique, see Finest Practices for Tagging AWS Assets.

Quickstart by situation

Your setup depends upon how your customers and functions name Amazon Bedrock. The next desk summarizes the attribution obtainable in CUR 2.0 for every entry sample and what to configure for tag-based aggregation:

Observe: 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 mixture by customized dimensions (staff, 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 way of a number of frequent situations.

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 person credentials or Amazon Bedrock API keys.

The way it works:

Every staff member has a devoted IAM person with long-term credentials. When both user-1 or user-2, for instance, calls Amazon Bedrock, Amazon Bedrock mechanically captures their IAM person Amazon Useful resource Identify (ARN) throughout authentication. Your CUR 2.0 reveals who’s spending what.

If you wish to roll up prices by staff, value heart, or one other dimension — for instance, to see complete spend throughout knowledge science staff members — connect tags to your IAM customers. You’ll be able to 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 info science staff's customers
aws iam tag-user 
  --user-name user-1 
  --tags Key=staff,Worth="BedrockDataScience" Key=cost-center,Worth="12345"

aws iam tag-user 
  --user-name user-2 
  --tags Key=staff,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:

The line_item_usage_type column encodes the area, mannequin, and token path (enter vs. output), so you’ll be able to 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 knowledge, you’ll be able to 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 staff: Group by iamPrincipal/staff to see complete spend throughout knowledge science staff members. That is helpful for departmental chargeback.

This method is good when you have got a manageable variety of customers and need the best doable setup. Every person’s credentials immediately 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 functions can nonetheless observe 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 observe prices by challenge 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 on.) and assumes a devoted IAM position to name Amazon Bedrock. When both software calls Amazon Bedrock, the assumed-role ARN is mechanically captured. This attribution flows to your CUR 2.0 report, supplying you with per-application value visibility.

You’ll be able to filter by line_item_iam_principal, which accommodates the position title, to see complete spend per software, or by line_item_usage_type to check mannequin utilization throughout providers. Tags are non-obligatory. In case your software generates distinctive session names per request or batch job, you’ll be able to observe prices at a good finer stage of element.

If you wish to roll up prices by challenge, 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 Position-1 
  --tags Key=challenge,Worth="DocFlow" Key=cost-center,Worth="12345"

# Tag the chat service position
aws iam tag-role 
  --role-name Position-2 
  --tags Key=challenge,Worth="ChatBackend" Key=cost-center,Worth="12345"

When app-1 assumes Position-1 and calls Amazon Bedrock, the request is attributed to the assumed-role session. The position’s tags movement by way of to billing mechanically.

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:

This provides you a number of evaluation choices:

• Filter by position: See complete spend per software utilizing the position title portion of the ARN.
• Filter by session: Observe prices per request or batch job utilizing the session title.
• Combination by challenge: Group by iamPrincipal/challenge to check prices throughout DocFlow vs. ChatBackend.
• Combination by value heart: Group by iamPrincipal/cost-center to see complete spend throughout functions owned by the identical staff.

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 way 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 way of your id supplier (IdP) and assume a shared IAM position. Per-user attribution comes from two mechanisms: the session title (person id embedded within the assumed-role ARN) and session tags (staff, value heart, and so on. handed from the IdP). One IAM position serves the customers, so there are not any per-user IAM assets 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. Id movement in federated authentication situations

For OIDC federation (Auth0, Cognito, Okta OIDC): Register your IdP as an IAM OIDC supplier, create a job 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) mechanically 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 (staff, value heart) within the assertion. Each session title 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:

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/staff for departmental chargeback or parse the session title for per-user evaluation.

State of affairs 4: Per-user monitoring by way of an LLM gateway

Use case: Organizations working 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 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 position for every person, passing the person’s id as --role-session-name and their attributes (staff, 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. Id 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 fee 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:

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
• Functions/providers on AWS compute with IAM roles → State of affairs 2
• Customers authenticate by way 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

1. Open the AWS Billing console
2. Navigate to Price allocation tags
3. After your tags have appeared in at the very least one Amazon Bedrock request (permit as much as 24 hours), they seem within the AWS Administration Console below the IAM class
4. 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 knowledge 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’ll be able to:

• Filter by staff = data-science to see that staff’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 staff spend on Claude Sonnet this month?”

Getting began

The brand new value attribution characteristic for Amazon Bedrock is accessible now in industrial areas at no further value. To get began:

1. Determine your entry sample. Are builders calling Amazon Bedrock immediately with IAM customers or API keys (State of affairs 1)? Are functions utilizing IAM roles (State of affairs 2)? Do customers authenticate by way of an id supplier (State of affairs 3)? Or does site visitors movement by way of an LLM gateway (State of affairs 4)?
2. Allow IAM principal knowledge in your CUR 2.0. Replace your knowledge export configuration to incorporate IAM principal knowledge.
3. Add tags should you 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.
4. Analyze. Inside 24–48 hours of activation, your tags seem in Price Explorer and CUR 2.0. Filter by staff, group by challenge, or mix dimensions to reply questions like “How a lot did the engineering staff 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’ll be able to hint inference requests again to a selected person, software, or tenant utilizing IAM id and tagging mechanisms you have got in place. Whether or not your groups name Amazon Bedrock immediately with IAM credentials, by way 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.

Concerning the authors