Amazon Bedrock Cost Allocation: How to Break Down Spend by Model, Token Type, and Team

Open Cost Explorer, group by service, and Amazon Bedrock is one row. That row might be a few Claude calls in one account or a dozen models spread across teams and regions. The questions finance and engineering actually ask are narrower: which model, which token type, which account and region, and which team or tag?

The answers are in your AWS Cost and Usage Report (CUR). Bedrock charges arrive as line items whose usage type encodes the model, the token type, the service tier and the routing. This guide to Amazon Bedrock cost allocation shows how to read them, which columns matter, how to attribute the spend to teams with AWS’s own mechanisms, and what no billing report can tell you. It is based on AWS’s Amazon Bedrock documentation as checked on November 2, 2026. AWS changes this area often, so the primary pages are linked at the end.

Why doesn’t my Bedrock bill match a token estimate?

A simple estimate multiplies tokens by a published price per model. The bill is more granular. AWS’s CUR documentation says Bedrock pricing in the CUR is determined by three factors: the token type, the service tier, and whether the request was routed through cross-region inference. Each combination shows up as its own usage type with its own unit price.

• ◦Model. Each model has its own rates, and a model’s input and output tokens are priced differently.
• ◦Token type. AWS lists four: input, output, cache read and cache write. Each has a different unit price. Cache reads are described as significantly cheaper than input, and cache writes as more expensive than input.
• ◦Service tier. Standard, priority and flex are reflected in the usage type, and AWS says to apply the unit price for the tier on each line item.
• ◦Routing. In-region and cross-region inference have different unit prices, so a workload that uses both needs both rates.

AWS names the most common mistake directly: if you only sum input and output tokens, your totals will not match your bill. That is most visible in workloads that lean on prompt caching. Prices change often, so this article does not quote any; use AWS’s Bedrock pricing page for current rates.

Two more things sit outside a token estimate. AWS’s FAQ notes that a cost computed from model invocation logs does not reflect discounts, commitments, batch pricing, the free tier or provisioned throughput unless you model them. And AWS’s Cost Anomaly Detection guide states that third-party foundation models on Bedrock appear in Cost Explorer and on your bill under the AWS Marketplace billing entity, so check the billing entity as well as the service when you reconcile.

Where does the Bedrock detail live in the CUR?

AWS calls CUR 2.0, delivered through AWS Data Exports, its recommended way to receive detailed cost and usage data. Per-token breakdowns for Bedrock exist in both the legacy CUR and CUR 2.0, but some attribution features need CUR 2.0, as covered below. The detail sits in a handful of columns.

How do you decode a Bedrock usage type?

The line_item_usage_type field is where the model, token type, service tier and routing are packed together. AWS documents four patterns:

• ◦{region}-{model}-{token-type} for bedrock-runtime standard-tier requests
• ◦{region}-{model}-{token-type}-{tier} for bedrock-runtime priority or flex requests
• ◦{region}-{model}-mantle-{token-type}-standard for bedrock-mantle requests
• ◦{region}-{model}-{token-type}-cross-region-global for cross-region requests

The token-type part is one of -input-tokens, -output-tokens, -cache-read-input-token-count or -cache-write-input-token-count. Note that the two cache suffixes end in token-count, not tokens. A filter that looks for the word tokens alone will miss them.

The prefix (USE1 in these examples) is the usage-type region code, not part of the model name. Model segments can contain dots, digits and hyphens, so splitting on hyphens does not work. Strip the known suffixes from the right instead. The Athena SQL below does that for the documented patterns.

SELECT
  regexp_extract(line_item_usage_type, '^([A-Z0-9]+)-', 1) AS region_prefix,
  regexp_extract(line_item_usage_type,
    '^[A-Z0-9]+-(.+?)(?:-mantle)?-(?:cache-read-input-token-count|cache-write-input-token-count|input-tokens|output-tokens)', 1) AS model,
  regexp_extract(line_item_usage_type,
    '(cache-read-input-token-count|cache-write-input-token-count|input-tokens|output-tokens)', 1) AS token_type,
  COALESCE(regexp_extract(line_item_usage_type,
    '(?:tokens|token-count)-(priority|flex)', 1), 'standard') AS service_tier,
  line_item_usage_type LIKE '%cross-region-global%' AS cross_region_global,
  SUM(line_item_usage_amount) AS usage_amount,
  SUM(line_item_unblended_cost) AS unblended_cost
FROM your_cur_table
WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = '2026-10'
GROUP BY 1, 2, 3, 4, 5
ORDER BY unblended_cost DESC

We checked these patterns against the six usage types AWS documents above, plus the cache-write suffix, and they decode as expected. Treat the query as a starting point, not a drop-in. Run SELECT DISTINCT line_item_usage_type on your own export first, because AWS adds models and suffix shapes over time. Non-token charges use other usage types and come back with a NULL model and token type. Keep those rows in the totals instead of filtering them out, or the sum will not tie to the bill.

How do you do Amazon Bedrock cost allocation by team?

Amazon Bedrock cost allocation starts with what AWS already gives you. AWS documents several attribution mechanisms for Bedrock, and which one you can use depends on the API you call.

The first three deliver billed dollars. AWS says the finest grain they produce is per usage type per day, attributed by identity or tag, and none of them produces a per-request row. Per-request metadata is for per-prompt analysis in your own logs and does not appear in Cost Explorer or the CUR.

Account boundaries come first. If teams already run in separate linked accounts, line_item_usage_account_id splits the spend with no tagging at all, and the region prefix on the usage type splits it by region.

Tags are the second lever, and AWS spells out their rules. A tag must be activated as a cost allocation tag in the Billing console before it appears in the CUR or Cost Explorer. AWS’s Bedrock documentation says to allow up to 24 hours after activation, and its general billing guide describes up to 24 hours for a new tag key to appear for activation and up to 24 more to activate. AWS’s Bedrock pages say cost allocation tags are not retroactive: only costs incurred after activation are tagged. AWS’s billing guide separately documents a tag backfill, which the management account can request for up to twelve months and which only works where the tag was historically assigned to the resource, so check whether it covers your history before you assume it is lost. You activate tags from the management (payer) account, or from a standalone account. Member accounts cannot.

Each mechanism has its own catches. An application inference profile is tied to a single model, so you need a separate profile for each combination of model, team and tag set, and AWS recommends Projects for flexibility where you can use them. Responses and Chat Completions requests that name an inference profile are rejected with a 400 error. IAM principal attribution captures the caller identity automatically, but to see it in the CUR you need a CUR 2.0 export created with the caller-identity option, and AWS warns that existing exports do not retroactively gain that data.

Behind a gateway or proxy, Bedrock records the gateway’s role as the caller. AWS’s documented fix is to assume the role per user or tenant and pass session tags, caching the credentials instead of calling STS on every request. Once tags are active, you can group by them in SQL. AWS’s Bedrock docs name these keys with a resourceTags/ prefix, and AWS’s Athena example reads tags from a tags map. The key string below is an example, so list the keys in your own export before you rely on it.

SELECT
  tags['resourceTags/Team'] AS team,
  line_item_usage_type,
  SUM(line_item_unblended_cost) AS unblended_cost
FROM your_cur_table
WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = '2026-10'
GROUP BY 1, 2
ORDER BY unblended_cost DESC

Rows with no value for the tag are your unallocated Bedrock spend. That number is the one to watch, and the allocation and chargeback guides linked below cover what to do with it.

What can’t the bill tell you?

AWS is explicit. Both the legacy CUR and CUR 2.0 aggregate Bedrock cost by usage type, operation and pricing or resource over an hour or a day, and neither carries a per-request identifier. There is no per-prompt cost on your bill and no way to trace a single request in the CUR.

Per-user billing is a different thing, and it is available. With IAM principal attribution and a CUR 2.0 export created with the caller-identity option, you can get aggregated dollars per IAM user or role, as granular as your IAM design separates people. The finest grain is still per usage type per day. That is per-user or per-role billing, not per-request or per-prompt billing: no row in the CUR represents a single request.

Per-user, per-feature or per-customer economics need a second source: your model invocation logs, with request metadata set on each call. AWS’s guidance is to join logs to the CUR at the model and usage-type grain for reconciliation, and to treat any cost computed from log token counts as an estimate. AWS also notes that Bedrock cannot require request metadata on every call. It does not reject calls that omit it, so enforcement belongs in a shared client or gateway, while IAM principal attribution captures the caller identity automatically.

Do budgets and alerts stop Bedrock spend?

No. An alert notifies. AWS Budgets can also run budget actions, either automatically or after manual approval, but the actions AWS documents are applying an IAM policy or a service control policy and targeting specific EC2 or RDS instances. Those are controls you design and test yourself, not a Bedrock spend cap.

Anomaly alerts are secondary to allocation, but one AWS change matters here. AWS announced on August 19, 2026 that Cost Anomaly Detection monitors third-party foundation models on Bedrock with no setup, and its current user guide agrees. For other AWS Marketplace charges the guide points to AWS Budgets with the Billing entity filter. Detection works from Cost Explorer data that can lag by up to 24 hours, and AWS has been changing this area this year, so check the guide before you rely on it.

How does CloudQuell handle Bedrock?

CloudQuell has no separate Bedrock connector. It reads supported Bedrock spend through the AWS integration and the CUR data that integration already ingests. The AI Spend view is a read-only lens over those same rows. Bedrock stays inside your AWS totals and is counted once. The All AI figure that combines Bedrock with direct OpenAI and Anthropic spend is an analytical total and is never added to cloud spend.

In that view you can break Bedrock down by model, token type (input, output, cache read and cache write, where the CUR exposes them), service tier, routing, linked account, region and any cost-allocation tag key you choose. Tagged spend can be routed into cost centers with allocation rules, and budgets can be scoped to the Bedrock service or a tag, the same way as the rest of your AWS cost. Cost centers, budgets and alerts are on paid plans. AI Spend itself is on every plan.

The limits mirror the CUR’s. CloudQuell does not attribute Bedrock cost per user, per API key or per request. It does not cap spend, because its alerts notify. It does not generate Bedrock-specific savings recommendations. Model and token detail comes from the CUR going forward, and older history is Bedrock dollars by account. Tag-based splits still depend on you activating the tags in AWS first.

An Amazon Bedrock cost allocation and reconciliation checklist

• ◦Pick one CUR 2.0 export and one cost basis, and use them for every number.
• ◦List the distinct product codes and usage types in the export, and confirm which Bedrock product codes and billing entities appear.
• ◦Decode usage types into model, token type, tier and routing. Send anything that does not match to an other bucket instead of dropping it.
• ◦Reconcile all four token types before you blame pricing. Then check tiers, then in-region against cross-region.
• ◦Check how third-party models appear: which billing entity and product code their rows carry.
• ◦Activate cost allocation tags from the payer account and wait for activation. AWS’s Bedrock pages say they are not retroactive, so ask whether a billing-side tag backfill covers your history.
• ◦If you need user-level dollars, create a CUR 2.0 export with the caller-identity option. It will not backfill older months.
• ◦Split by linked account and region first, then by tag, and track the untagged remainder.
• ◦Use invocation logs only for per-prompt questions, and treat anything computed from them as an estimate.
• ◦Compare the sum of your decoded rows with the Bedrock total in Cost Explorer for the same period and cost basis.