Who (and What) Is Spending Your GenAI Budget: Tokenomics Tuesday #7
When you look at your generative AI bill, it is tempting to treat it as one number. But that number is the sum of very different kinds of caller, and each one tells a different cost story. Some of your spend comes from applications: a Lambda function or an Amazon EKS pod calling Amazon Bedrock on a schedule. Some comes from people: a developer using Claude Code, or a named user running queries. And some comes from tools that do not bill in tokens at all, like Kiro and Amazon Quick.
Pillar: Visibility & Attribution
Series: Tokenomics Tuesdays
Series: Tokenomics Tuesdays
Why is this important?
When you look at your generative AI bill, it is tempting to treat it as one number. But that number is the sum of very different kinds of caller, and each one tells a different cost story. Some of your spend comes from applications: a Lambda function or an Amazon EKS pod calling Amazon Bedrock on a schedule. Some comes from people: a developer using Claude Code, or a named user running queries. And some comes from tools that do not bill in tokens at all, like Kiro and Amazon Quick.
If you cannot tell these apart, you cannot act. You might chase a developer about their spend when the real cost is an application looping overnight. Or you might optimize a model when the actual waste is a pile of idle Kiro licences. To put it very simply, visibility is not one lens. It is several, and you need to know which one you are looking through.
The good news is that most of this is already in your data. You just need to know where each kind of caller shows up.
What resources are relevant?
- Using IAM principal for cost allocation to see who called Amazon Bedrock in CUR 2.0
- Understanding your Bedrock CUR data for the line-item detail
- Kiro User Activity Dashboard for Kiro credit and licence usage
- Amazon Quick usage tracking via Mission Control and the Admin Index Dashboard
- Amazon Athena for querying your CUR data
How to implement
The three kinds of caller in CUR
When you turn on IAM Principal cost allocation in CUR 2.0, the
line_item_iam_principal column records who or what made each Amazon Bedrock call. Those callers fall into three recognisable shapes.1. Application roles (your solutions). When a workload calls Bedrock, the principal is the IAM role it assumed. A Lambda execution role or an EKS pod identity (IRSA) role. This is your application spend: chatbots, RAG pipelines, agents running on a schedule. It scales with traffic, not headcount, and it is often the largest and most predictable slice.
2. Role with a session name (your developers). When a person works through an assumed role, the principal carries a session name, and in most enterprise setups that session name is the user's identity. This is how Claude Code usage through Bedrock shows up. It is your per-developer spend, and it scales with how many people are building and how hard.
3. User ARNs (named identities). A plain IAM user ARN calling Bedrock directly. Less common in large organizations, but when you see it, it is a specific named identity you can attribute immediately.
Bucketing them with Athena
You can classify each line into these buckets in a single query, so you see the distribution at a glance:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SELECT
CASE
WHEN line_item_iam_principal LIKE '%:assumed-role/%' AND line_item_iam_principal LIKE '%/%'
THEN 'Role with session (developer)'
WHEN line_item_iam_principal LIKE '%:role/%'
THEN 'Application role (service)'
WHEN line_item_iam_principal LIKE '%:user/%'
THEN 'User ARN (named identity)'
ELSE 'Other / untagged'
END AS caller_type,
SUM(line_item_unblended_cost) AS total_cost
FROM cur_2_0
WHERE line_item_product_code = 'AmazonBedrock'
AND line_item_usage_start_date >= DATE_ADD('day', -30, CURRENT_DATE)
GROUP BY 1
ORDER BY total_cost DESCNow you have a distribution: how much of your Bedrock spend is applications versus developers versus named users. That single breakdown changes the conversation with your teams.
The callers that are not in Bedrock CUR
Here is the part people miss. Not every AI coding tool bills through the Bedrock line items.
Kiro bills in credits, not tokens. Its usage lives in the Kiro User Activity Dashboard, a Cloud Intelligence Dashboard that combines the Kiro user activity report (per user, per day) with your CUR subscription data. That is where you see credit consumption, model choice, and the idle licences nobody is using.
Amazon Quick usage is tracked under Mission Control on the Activity page for individual users, and in the Admin Index Dashboard for administrators, measured in agent hours and index usage rather than tokens.
So the full picture is: CUR tells you about your Bedrock callers (applications, developers, named users), and Kiro and Quick sit alongside in their own dashboards. Fold all three together and you finally see your whole generative AI estate, not just one slice of it.
Summary
Your generative AI bill is not one number, it is a distribution of callers. Use the
line_item_iam_principal column in CUR 2.0 to split Bedrock spend into application roles, developer sessions, and named users, then bring in the Kiro and Quick dashboards for the tools that bill outside Bedrock. Once you can see who and what is spending, you can finally point each optimization at the right place.Join the Tokenomics space for weekly content. Follow on LinkedIn .
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article