Why your Amazon Bedrock bill has token counts but no owner

This surprises a lot of people, because the bill looks detailed, and it is. You get real token counts for every model. But that alone doesn't tell you where the spending came from, or whether it was worth it.

What the Bedrock bill actually shows

Bedrock is billed in tokens. On your AWS bill, each Bedrock line has a meter that says whether it counts input tokens or output tokens, and a quantity that is the number of tokens. For models from other providers sold through AWS Marketplace, that quantity is in millions of tokens. For AWS's own models, it's in thousands.

So the tokens are there, and they are real counts, not estimates.

For each line you get:

• the AWS account, and its name
• the region
• the model, or the inference profile used to call it
• whether the tokens were input or output
• the number of tokens
• the cost

What you don't get is anything about who sent the request, or what it was for. There's no team, no user, no application and no API key. There are also no cache or reasoning tokens on the bill, only input and output.

Why this becomes a problem

If each team has its own AWS account, the account tells you who spent the money, and you're fine.

Most companies don't work like that. Several teams often share one account, or one application calls Bedrock for many different teams. In both cases, the bill puts everyone together. Three teams using Claude on the same account show up as one line.

That's when someone asks "which team spent this?" and nobody can answer.

Six ways to get the owner back

AWS documents several ways to attribute Bedrock costs. Which one fits depends on two things: what you want to track, and which Bedrock APIs your engineers use.

Bedrock has two endpoints, bedrock-runtime and bedrock-mantle, and some of these options only work on one of them. It's worth asking your engineers which one they use before you choose.

1. One AWS account per team

This is the simplest fix. If every team or service runs in its own AWS account, the account name tells you who spent what, with no extra setup.

It works well if you already organise AWS this way. It's a lot of work to change if you don't.

2. Attribute cost to the IAM identity

This is what AWS recommends first if you want costs by user or team on your bill. Bedrock records which IAM identity made each call, and the costs show up by identity in AWS Cost Explorer and the Cost and Usage Report 2.0. It works with all of Bedrock's main APIs, on both endpoints.

There is one thing to watch. If requests go through a gateway or one shared application, Bedrock sees the gateway's identity, not your teams. You can fix this by setting up the gateway to use a separate session name or session tags for each user or team. It needs some work on the gateway side, but it keeps everything inside AWS billing.

3. Application inference profiles

An application inference profile is a label you put around a Bedrock model. You create one for each team or application, add a cost allocation tag like Team=Payments, and send that team's requests through its own profile. Costs then show up by tag in AWS Cost Explorer.

Four things to know before you rely on it:

• Tags only count from the day you turn them on. They don't apply to anything you spent before.
• Each profile is tied to one model. Five teams and four models means twenty profiles, and every new model version adds more.
• They only work on the bedrock-runtime endpoint, with the InvokeModel and Converse APIs.
• Requests have to go through the profile. If a request is sent straight to the model, it isn't tagged.

4. Projects and Workspaces

On the bedrock-mantle endpoint, where application inference profiles don't work, AWS offers Projects instead. Projects cover the Responses and Chat Completions APIs. Workspaces do the same job for Anthropic's Messages API. Both attribute costs by tag.

5. Tag each request

If you want cost for single prompts or experiments, you can add tags to each request. Bedrock records them in its invocation logs, together with the token counts for that request.

This gives the most detail of any AWS option. But the data lives in logs, not on your bill, so you have to turn the token counts into cost yourself, and invocation logging has to be switched on.

6. Send requests through a gateway

A gateway is a tool your engineers put between their applications and the AI model. LiteLLM, Helicone, OpenRouter, Cloudflare AI Gateway and Bifrost are common examples. Every request goes through the gateway, and the gateway records which API key made it.

If your keys are named after teams or projects, you get the owner for every request. You also get cache and reasoning tokens, which the Bedrock bill doesn't show. And it works the same way whether the model is on Bedrock or with another provider.

How to attribute AI costs to teams when there is no team field →

The catch is that someone has to set up the gateway and make sure requests go through it.

One thing the AWS options have in common

The AWS billing options (accounts, IAM identity, application inference profiles, Projects and Workspaces) show billed cost per day, grouped by identity or tag. They don't show individual requests. For request-level detail, you need invocation logs or a gateway.

Which one to choose

If you already have one AWS account per team, you're mostly done. Use the account.

If you want costs by team on your AWS bill, start with IAM identity attribution. It's what AWS recommends first, and it works on every API.

If you want costs by application and use InvokeModel or Converse, application inference profiles are a good fit.

If you want costs by application and use the bedrock-mantle endpoint, use Projects, or Workspaces for Anthropic's Messages API.

If you want cost per prompt or per experiment, tag each request and use invocation logs.

If you use more than one AI provider, or want cache and reasoning tokens, a gateway is the most complete option.

Whichever you choose, set it up before the spending grows. None of these options can go back and assign an owner to money you've already spent.

How Glassity handles Bedrock

Glassity reads Bedrock usage from your AWS bill, and optionally from CloudWatch for live numbers within minutes. It shows tokens and cost by account, region and model, every hour, next to the rest of your cloud billing data.

We'll be honest about the limit. Glassity doesn't yet show the AWS attribution options above, like IAM identities, application inference profiles or Projects, as separate views. Today, if you want to see Bedrock costs by team in Glassity, the reliable ways are separate AWS accounts, or sending requests through one of the gateways Glassity reads from.

If you connect a gateway, Glassity shows cost for every key, and the gateway's own fields like team, user and tags.

Further reading

• Track usage and costs in Amazon Bedrock, Amazon Bedrock documentation
• Application inference profiles, Amazon Bedrock documentation
• Track generative AI costs with Amazon Bedrock inference profiles, AWS Architecture Blog
• What is AI token economics? →