Bedrock IAM principal cost allocation reached bedrock-mantle on 11 August 2026, at daily grain

Summary. On 11 August 2026 AWS extended Amazon Bedrock's IAM principal cost allocation to the bedrock-mantle endpoint, which serves the OpenAI Responses API, the OpenAI Chat Completions API and the Anthropic Messages API. The What's New post says this helps "attribute inference costs across users, teams, projects, and applications". The Bedrock User Guide sets the ceiling: "The finest grain is per usage type per day, attributed by identity or tag, it does not produce per-request cost." Three more limits sit only in the documentation. Cost allocation tags are not retroactive, they can take 24 hours to appear, and a CUR 2.0 export created before you enabled this must be rebuilt from scratch. You can attach up to 50 principal or session tags per IAM user or role, and Claude Opus 4.7 is the only model with published bedrock-mantle quotas: 20,000,000 input tokens per minute and 4,000,000 output tokens per minute.

What changed on 11 August 2026

Bedrock has captured caller identity for bedrock-runtime inference for some time. The 11 August 2026 announcement extends the same capture to bedrock-mantle, the newer endpoint at bedrock-mantle.<region>.api.aws.

The two endpoints are not interchangeable. According to the bedrock-mantle quotas page, bedrock-mantle serves the OpenAI Responses API, the OpenAI Chat Completions API and the Anthropic Messages API, and "inference traffic to this endpoint is governed by a separate set of quotas from the bedrock-runtime endpoint". Until 11 August, a team that had moved to the OpenAI-compatible surface lost the identity attribution it had on the older endpoint. That gap is closed.

What is not closed is the gap between the phrase "attribute inference costs" and what actually lands in your billing data.

The grain problem

The IAM principal attribution page carries this note: "IAM principal attribution delivers aggregated cost to AWS Cost Explorer and CUR 2.0. The finest grain is per usage type per day, attributed by identity or tag, it does not produce per-request cost."

That single sentence rules out the two questions FinOps teams most often bring to this feature. You cannot answer "what did that one agent run cost" and you cannot answer "which prompt blew the budget on Tuesday afternoon". You can answer "what did the growth team spend on Claude input tokens on Tuesday".

There is a second, subtler constraint for anyone running a gateway. AWS states that "identity and session tags are bound at AWS STS AssumeRole time and are recorded against the session, not the individual request. Their values are constant across every call made with that session's credentials." A gateway that assumes one role and serves fifty tenants through it produces one identity in billing, not fifty, unless it assumes per user and passes session tags.

The documented workaround has its own cost. AWS advises assuming the role "once per user and cache the credentials for the session lifetime", warning that "calling sts:AssumeRole on every request can exceed AWS STS request rate quotas". So per-user attribution through a shared gateway means per-user credential caching, which is a real change to gateway architecture, not a billing console toggle.

Question you want answered	IAM principal attribution	Where the answer actually lives
What did team X spend yesterday?	Yes, per usage type per day	Cost Explorer, grouped by principal tag
What did user [e-mail] spend?	Yes, if session tags or a per-user role	CUR 2.0, iamPrincipal/ prefixed columns
What did a single request cost?	No	Per-request metadata tagging
Which prompt caused the spike?	No	Model invocation logging to CloudWatch Logs or S3
Which application spent the most?	Not the recommended path	Projects on bedrock-mantle, or application inference profiles on bedrock-runtime
Cost split across both endpoints?	Yes, both are supported	Cost Explorer, but quotas are planned per endpoint

Three setup traps that are documentation-only

Tags are not retroactive. The user guide is direct: "Cost allocation tags are not retroactive, only costs incurred after activation are tagged. Tags can take up to 24 hours to appear after activation." A team that turns this on at the end of a quarter to explain that quarter's Bedrock bill will get nothing. Turn it on before the spend you want to explain.

Tags do not appear until the principal calls Bedrock. Also from the guide: "Tags only appear in AWS Billing after the IAM principal makes at least one Amazon Bedrock API call." You cannot pre-stage the cost allocation tag list from your IAM inventory. The tag key shows up in the Billing console only after traffic exists, which makes a big-bang activation across dozens of teams a staggered exercise.

Existing CUR 2.0 exports are dead weight. This is the one most likely to cost a week. AWS: "If you created a CUR 2.0 data export before enabling IAM principal attribution, you must create a new export and select the caller identity option. Existing exports do not retroactively include identity data." If your FinOps pipeline reads one long-standing CUR export into a data warehouse, that export will never carry identity columns. You need a second export, a second S3 prefix, and a change to whatever ingests it.

Layer the 24-hour cost data lag on top and the realistic timeline from "we decided to do this" to "the dashboard is trustworthy" is several days, not an afternoon.

Where the tags come from

Principal tags attach directly to an IAM user or role through aws iam tag-role, aws iam tag-user, or the TagRole and TagUser APIs. They are static and apply to every request from that principal.

Session tags are passed at sts:AssumeRole time and are the only way to distinguish users who share a role. AWS documents three delivery paths: --tags on AssumeRole, the https://aws.amazon.com/tags claim in an OIDC ID token for AssumeRoleWithWebIdentity, and PrincipalTag:* attributes in a SAML assertion for AssumeRoleWithSAML. In all three cases the role's trust policy must allow sts:TagSession.

Both kinds appear in CUR 2.0 with the iamPrincipal/ prefix, and where a session tag and a principal tag share a key, AWS says "the session tag value overrides the principal tag value for that session". The documented ceiling is 50 principal or session tags per IAM user or role.

Mechanism	Set where	Varies per	Requires
Principal tag	IAM console, CLI, or TagRole/TagUser	Never; static per principal	Tag activation in Billing
Session tag via AssumeRole	--tags on the STS call	Session	sts:TagSession in trust policy
Session tag via OIDC	https://aws.amazon.com/tags claim	Session	IdP claim mapping
Session tag via SAML	PrincipalTag:* assertion attributes	Session	IdP attribute mapping
RoleSessionName	STS call	Session	Nothing; appears in invocation logs

That last row matters. Session tags are billing data only. AWS notes that "session tags are not written to your model invocation logs; logs capture the caller's identity.arn instead". If you want the same user visible in both billing and logs, set a per-user RoleSessionName as well as session tags, because the session name is what shows up in identity.arn.

Projects, profiles and which one to use

AWS gives a recommendation rather than leaving the choice open: "We recommend using Projects for application-level attribution and IAM principal attribution for user-level attribution within the same account." They stack, and the split is not symmetric across endpoints.

Projects work on bedrock-mantle and not on bedrock-runtime. Application inference profiles work on bedrock-runtime and not on bedrock-mantle. IAM principal attribution is the only one of the three that works on both. A team running both endpoints therefore has one consistent attribution dimension and two endpoint-specific ones, which is worth settling before the dashboards get built rather than after.

Capacity planning is now per endpoint

The quotas page is worth reading alongside the cost change, because attribution without capacity planning tends to produce the wrong conclusion about a spike.

bedrock-mantle applies separate input-tokens-per-minute and output-tokens-per-minute quotas per model per Region, while bedrock-runtime "count[s] input and output tokens together against a single per-model quota". AWS is explicit: "If you run workloads on both endpoints, plan capacity for each endpoint independently."

Two behaviours in the admission logic change how throttling looks in your metrics. Input tokens plus max_tokens (or the model maximum, when max_tokens is unset) are checked against the input quota up front, and exceeding it returns HTTP 429. If the output quota is reached mid-generation, "generation stops and the response is returned with a finish reason indicating the cutoff", which is a truncated answer rather than an error. Unused reservation is replenished after the response completes, and cached input tokens read through prompt caching do not count against the input quota.

The endpoint also "does not enforce requests-per-minute (RPM) quotas", so a high-volume, small-prompt workload is throttled purely on tokens. AWS adds that "the endpoint may apply additional internal rate limiting that is not exposed in Service Quotas", so exponential backoff is not optional.

Published default quotas are thin: the only model listed in the guide's table on 22 August 2026 is Anthropic Claude Opus 4.7, at 20,000,000 input tokens per minute and 4,000,000 output tokens per minute, with the note that "new AWS accounts might receive reduced quotas, and quotas can vary by Region."

India-specific considerations

Indian teams running a shared LLM gateway for several product lines are the exact case where the session-tag requirement bites hardest, because the common pattern here is one gateway role, one VPC, and per-tenant routing in application code. Under this feature that architecture reports one identity to Cost Explorer no matter how many tenants sit behind it.

If tenant-level chargeback is a commercial commitment rather than an internal nicety, the per-user AssumeRole and credential caching work has to be scheduled, and it interacts with Digital Personal Data Protection Act 2023 practice: passing an end-user email address as a session tag puts personal data into billing records that finance teams retain for years. Tagging by tenant identifier or cost centre rather than by email keeps the attribution and drops the personal data. That trade costs nothing and is easier to make before the gateway ships than after.

What is still unknown

The announcement says the feature is "available in all AWS Regions where the bedrock-mantle endpoint is available", and no Region list for bedrock-mantle appears in either the announcement or the quotas page. The quotas table lists a single model. AWS documents no additional charge for IAM principal attribution and no charge is implied by the CUR 2.0 export path, but the guide does not state one either way, and a second CUR 2.0 export carries the usual S3 storage cost for the data it writes. Treat the Region question and the model coverage as things to check in your own account before committing to a rollout date.

FAQ

Does IAM principal attribution give per-request Bedrock cost?

No. The Bedrock User Guide states that the finest grain is per usage type per day, attributed by identity or tag, and that it does not produce per-request cost. For per-prompt detail AWS points to per-request metadata tagging and to model invocation logging into CloudWatch Logs or Amazon S3 instead.

Why does my LLM gateway show only one identity?

Because identity and session tags are bound at AssumeRole time and recorded against the session, not the request. A gateway that assumes one shared role produces one identity. To split users, assume the role per user with session tags, and cache the credentials for the session lifetime to avoid STS rate quotas.

Do I have to rebuild my CUR 2.0 export?

Yes, if it predates enabling this. AWS says existing exports do not retroactively include identity data, so you must create a new CUR 2.0 export and select the option to include the caller identity ARN. Cost allocation tags must also be activated separately for tags to appear in that export.

How long before the data is usable?

Cost allocation tags are not retroactive and can take up to 24 hours to appear after activation, and cost data can take up to 24 hours to reach Cost Explorer and CUR 2.0 after a request. Tags also only appear once the principal has made at least one Bedrock API call.

How many tags can I attach?

Up to 50 principal or session tags per IAM user or role, according to the Bedrock User Guide. Both principal tags and session tags appear in CUR 2.0 with the iamPrincipal/ prefix, and where a session tag and a principal tag share the same key, the session tag value wins for that session.

Which endpoint does bedrock-mantle serve?

The bedrock-mantle endpoint, addressed per Region under api.aws, serves the OpenAI Responses API, the OpenAI Chat Completions API and the Anthropic Messages API. Inference traffic there is governed by a separate quota set from bedrock-runtime, so capacity must be planned independently for each endpoint you use.

Do Projects and IAM principal attribution overlap?

They stack rather than overlap. AWS recommends Projects for application-level attribution and IAM principal attribution for user-level attribution in the same account. Projects work on bedrock-mantle only, application inference profiles work on bedrock-runtime only, and IAM principal attribution works on both endpoints.

What are the default bedrock-mantle quotas?

The user guide's default table lists only Anthropic Claude Opus 4.7 as of 22 August 2026, at 20,000,000 input tokens per minute and 4,000,000 output tokens per minute per Region. AWS notes new accounts may receive reduced quotas, quotas vary by Region, and additional internal rate limiting is not exposed in Service Quotas.

How eCorpIT can help

eCorpIT is a CMMI Level 5 and ISO 27001:2022 certified engineering organisation in Gurugram that builds cost attribution into AI platforms rather than bolting it on afterwards. Our senior engineering teams design gateway credential flows that carry tenant identity into CUR 2.0 without putting personal data in billing records, and connect the result to the FinOps reporting finance actually reads. This sits alongside our work on AI agent unit economics and our wider cloud and DevOps practice. To review your Bedrock attribution model, contact us at /contact-us/.

References

1. Amazon Bedrock expands IAM principal cost allocation to the bedrock-mantle endpoint, AWS What's New, 11 August 2026
2. IAM principal attribution, Amazon Bedrock User Guide
3. Track usage and costs, Amazon Bedrock User Guide
4. Quotas for the bedrock-mantle endpoint, Amazon Bedrock User Guide
5. Monitor the bedrock-mantle endpoint, Amazon Bedrock User Guide
6. Per-request metadata tagging, Amazon Bedrock User Guide
7. Pass session tags in AWS STS, AWS IAM User Guide
8. Tags for IAM resources, AWS IAM User Guide
9. IAM principal element reference, AWS IAM User Guide
10. Creating Cost and Usage Reports, AWS Cost and Usage Reports User Guide
11. IAM roles, AWS IAM User Guide
12. Requesting a quota increase, Service Quotas User Guide

Last updated: 22 August 2026.