A Token Without a Name: Bedrock Cost Attribution
How we trace every Amazon Bedrock token to a user, team and feature with CUR 2.0 IAM principal data, invocation logs and Amazon Managed Grafana.
The question nobody could answer
Every month our AWS invoice had one line that grew faster than all the others: Amazon Bedrock. Every month someone asked the same question about it: who spent this?
For a long time our honest answer was "the gateway". All our assistants, copilots and AI agents reached Bedrock through one shared service, so the bill saw one caller. That is not an answer a finance team accepts twice.
We are not alone. The FinOps Foundation's State of FinOps survey shows how fast this became everyone's problem: in 2024, 31% of practitioners managed AI spend; in 2025, 63%; in 2026, 98% [1][2].
The same research lists the top challenges in applying FinOps to AI. Visibility comes first, allocating costs to business units second, and proving ROI third [3]. You cannot prove value for something you cannot even assign to an owner.
Why AI spend breaks the tagging we already know
Classic cloud FinOps is built on resources. An EC2 instance or an S3 bucket exists, it has an owner tag, and its cost follows that tag into Cost Explorer. If tagging is good, allocation is mostly solved.
Generative AI does not work like that. You do not rent a model; you pay per token, and a token is created by a request, not by a resource. Thousands of requests from hundreds of people can hit the same model through the same role in the same minute.
Worse, the expensive decisions are made per request, inside code. The chart below takes one ordinary request, a question with some retrieved documents, and prices it on five models available in Bedrock, using public on-demand list prices [9].
A developer who changes one line of configuration can multiply a team's AI bill by two orders of magnitude, and no resource tag will notice. Notice also the orange part of each bar: output tokens are priced several times higher than input tokens, so verbose answers are a cost decision too.
There is a second, quieter effect. A chat conversation re-sends its history on every turn. Using simple, stated assumptions, the 30th message of a conversation costs more than five times as much as the first.
This is why "cost per user" alone is a misleading number. Two colleagues with the same number of requests can differ by a factor of five simply because one of them never starts a new chat. Prompt caching changes this slope, which is exactly why we want to see it in our own data rather than in a spreadsheet model.
What changed in 2026
In April 2026, AWS added cost allocation by IAM principal to Amazon Bedrock. The caller's IAM user or role now appears in CUR 2.0 and Cost Explorer, and the tags on that user or role (team, project, cost center) can be activated as cost allocation tags [4]. In August 2026, the same capability was extended to the newer bedrock-mantle endpoint [5].
In CUR 2.0 this shows up as a new column,
line_item_iam_principal, plus principal tags prefixed with iamPrincipal/, once you enable "Include caller identity (IAM principal) allocation data" in the export [8]. For the first time, the bill itself knows who made the call.But there is a catch, and it is the reason for this article. Bedrock records the identity of whoever signs the request. Behind a shared LLM gateway, that is the gateway's role [6]. The new feature solves attribution only if every user actually reaches Bedrock under their own name.
A real-world use case
Our scenario is common: an internal AI assistant for employees, a few internal applications and several AI agents, all running against Amazon Bedrock in eu-west-1. Finance wants AI cost per team on the monthly report. Team leads want to know which features drive their spend. Engineers want to see which prompts are expensive.
Here is how a single request travels from left to right. An employee asks the assistant a question; their single sign-on session tells the gateway who they are and which team they belong to. The gateway, running on Amazon ECS on Fargate, assumes a Bedrock role for that specific user through AWS STS, with the user as the session name and the team and cost center as session tags. It then calls Bedrock's Converse API and stamps request metadata on the call: which feature and which tenant it belongs to.
Bedrock then does two things for us. It writes one invocation log entry per request to CloudWatch Logs, with token counts, model ID, caller identity and our metadata. And it records the caller's IAM principal on the billing line items that land, through a daily CUR 2.0 export, in Amazon S3. Amazon Athena joins both datasets every day, and Amazon Managed Grafana turns them into dashboards, budgets and alerts for the FinOps lead and team leads.
The decision: two sources of truth, never mixed
The most important design choice we made is easy to say and surprisingly easy to get wrong. We keep two numbers, and we never pretend one is the other.
The first is the money truth. IAM principal attribution in CUR 2.0 gives invoice-accurate dollars per user and per team. It needs no code on each call, because Bedrock captures the caller automatically. Its limit is granularity: CUR aggregates by usage type per hour or per day and never contains a per-request row [6].
The second is the behaviour truth. Model invocation logs with request metadata show every single prompt: which feature, which model, how many tokens in and out. Its limit is that request metadata never appears on the bill [6]. A cost calculated from logs is tokens multiplied by a rate card, an estimate that ignores discounts, batch pricing and commitments unless you model them.
AWS's own guidance describes the same pattern: many teams run IAM principal attribution for dollars and request metadata for per-prompt detail, and reconcile them periodically at the model and usage-type grain [7]. In our dashboards, both numbers sit side by side, and the gap between them is a metric of its own. When the gap grows, either our rate card is outdated or someone found a way around the gateway.
The solution: the gateway as our naming authority
The gateway is deployed with Terraform as a small containerised service on Fargate, and it is the only way to reach Bedrock. A service control policy denies Bedrock access to every other role, so there is no side door where tokens can arrive without a name [7]. That one policy does more for cost attribution than any amount of tagging guidelines.
Identity is handled once per session, not once per request. The gateway assumes a role per user, caches the credentials for the session lifetime and reuses them, because calling STS on every request can hit its rate quotas [7]. Session tags carry only stable, low-cardinality values such as team and cost center, and users are identified by a hashed internal ID rather than an email address, because tag values end up in logs and billing data [7].
Everything else is data. CUR 2.0 and the invocation logs land in S3, the Glue Data Catalog describes them, Athena joins them at the model, usage-type and day grain, and Amazon Managed Grafana shows each team its own spend, its top features and its most expensive conversations. A token without a name is a cost without an owner, and an owner is the only person who can make it cheaper.
The rules we follow
A few rules turned out to matter more than the architecture itself.
Activate cost allocation tags on day one. Activation is not retroactive, so every week you wait is a week of spend that will never be attributed [7].
Keep two kinds of labels apart. Stable keys like team, environment and feature go into principal or session tags; high-cardinality values like session or trace IDs go only into request metadata. Mixing them bloats your billing data and fragments your reports [7].
Enforce at the gateway, not in people. Bedrock does not reject a call that carries no metadata [6]. If tagging depends on every developer remembering it, it will have gaps; if it happens in one shared layer, it cannot.
The question we are still arguing about
We built showback first: every team sees its AI spend, but nobody is invoiced for it yet. Some argue that AI costs should be charged back to teams immediately, because people only optimise what they pay for. Others argue that charging back too early kills experimentation before anyone knows which AI features create value.
We chose visibility before accountability. Would you charge your teams for their tokens today, or wait until you can measure what those tokens earn?
Whatever you decide, start with names. A token without a name is a cost without an owner.
Sources
- FinOps Foundation – State of FinOps 2026: https://data.finops.org/
- SD Times – "Report: FinOps priorities are shifting left and expanding" (State of FinOps 2026 figures): https://sdtimes.com/softwaredev/report-finops-priorities-are-shifting-left-and-expanding/
- Virtasant – Key findings from the State of FinOps 2026 report: https://virtasant.com/blog/state-of-finops-2026
- AWS What's New – Amazon Bedrock now supports cost allocation by IAM user and role (April 2026): https://aws.amazon.com/about-aws/whats-new/2026/04/bedrock-iam-cost-allocation
- AWS What's New – Amazon Bedrock expands IAM principal cost allocation to the bedrock-mantle endpoint (August 2026): https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-expands-iam-principal-cost-allocation-bedrock-mantle/
- Amazon Bedrock User Guide – Cost attribution FAQ: https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-faq.html
- Amazon Bedrock User Guide – Best practices for cost attribution: https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-best-practices.html
- AWS Machine Learning Blog – Part 2: Amazon Bedrock cost attribution with Amazon Athena and CUDOS: https://aws.amazon.com/blogs/machine-learning/part-2-amazon-bedrock-cost-attribution-with-amazon-athena-and-cudos/
- Amazon Bedrock pricing: https://aws.amazon.com/bedrock/pricing/
Read next: Knowing who spent the tokens is step one. Step two is knowing whether it was worth it → Price the Answer, Not the Token: AI Unit Economics
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article