Know what your agents cost — down to the team.
Running Claude through Amazon Bedrock puts AI spend on the AWS bill you already have — and makes it your job to answer the question every finance team eventually asks: who is spending this? Whether the tokens come from an application calling the API, engineers on IAM roles, or Claude Code running as an agent, the tracking machinery is the same. This lesson sets it up.
You pay per token, and the directions aren't equal.
Bedrock charges for on-demand inference by the token: one rate for input (what you send the model) and a higher one — several times higher — for output (what it writes back), with rates set per model. Three consequences follow. Frontier models cost multiples of the smaller tiers, so model choice is a cost decision. Output tokens dominate agent bills, so verbosity is money. And prompt caching changes the math: cached input reads back at roughly a 90% discount, which matters enormously for agents that re-send the same system prompt and project context on every turn.
Exact per-token rates change with every model release — check the Bedrock pricing page rather than trusting any article's table, including this one. What doesn't change is the structure, and the structure is what you build controls around.
Three ways to answer “who spent that?”
A single “Amazon Bedrock” line on the bill is where cost control goes to die. These three mechanisms split it — use the first for teams and products, the second for individual engineers, the third only when you need per-request forensics.
Application inference profiles + cost allocation tags
The recommended path for per-team and per-product visibility. Create one inference profile per team or workload, tag it with your cost dimensions (CostCenter, Project), activate those tags in Billing, and route all invocations through the profile ARN instead of the raw model ID. Cost Explorer then breaks Bedrock spend down by tag — no custom analytics, no log parsing.
IAM principal attribution
The Cost and Usage Report (CUR 2.0) automatically records which IAM identity made every Bedrock call — no Bedrock configuration at all. Tag your IAM roles by department or team and filter the CUR by those tags. This is the zero-setup answer to per-engineer attribution, and it's also why per-person IAM roles beat shared credentials: shared keys make spend anonymous.
Model invocation logging
For per-request forensics — exact token counts, models, and latency for every call — enable model invocation logging and query the logs yourself. Most teams don't need this for cost work; reach for it when the first two approaches leave a question open, like which specific workload inside one team's profile is the heavy hitter.
The inference-profile setup, end to end:
# 1. Create a profile per team or product
aws bedrock create-inference-profile \
--inference-profile-name "platform-team" \
--model-source "copyFrom=arn:aws:bedrock:us-east-1::foundation-model/<model-id>"
# 2. Tag it with your cost dimensions
aws bedrock tag-resource \
--resource-arn <inference-profile-arn> \
--tags key=CostCenter,value=platform key=Project,value=agents
# 3. Activate the tags as cost allocation tags
# (Billing console; ~24h until they appear in Cost Explorer)
# 4. Invoke through the profile ARN instead of the model IDTags aren't retroactive — spend from before activation stays unattributed. Set this up at rollout, not after the first surprising invoice.
Claude Code on Bedrock is just another caller — treat it like one.
Claude Code can route all of its inference through your Bedrock account instead of an Anthropic subscription — one environment variable flips it, the model gets pinned explicitly, and authentication rides the standard AWS credential chain your engineers already use:
# Route Claude Code through your AWS account
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
# Point the primary model at your team's TAGGED
# application inference profile — every session
# lands pre-attributed in Cost Explorer
export ANTHROPIC_MODEL='arn:aws:bedrock:us-east-1:<account-id>:application-inference-profile/<id>'
# Pin background tasks to a cheap tier
export ANTHROPIC_DEFAULT_HAIKU_MODEL='<haiku-class-id>'
# Auth: the standard AWS credential chain
# (SSO profiles and assumed roles both work)The detail that makes this a cost-tracking lesson rather than a setup note: ANTHROPIC_MODEL accepts an application inference profile ARN, not just a model ID. Point each team's Claude Code at that team's tagged profile and the attribution from the previous section applies automatically — no wrapper, no proxy. Engineers on per-person IAM roles additionally show up individually in the CUR. And because agent sessions burn tokens at a very different rate than a chat window — long contexts, many turns, tool results flowing back as input — Claude Code is precisely the traffic you want attributed from day one. One caveat: there are no subscription-style spend caps on this path. The in-session /cost command shows usage, but enforcement is entirely the AWS-side controls below.
Six levers, in the order we pull them.
Set max output tokens explicitly
Output tokens are the expensive direction, and an unset limit defaults to the model's maximum — which also silently reserves far more throughput quota than you use, a common cause of mystery throttling. Cap it per workload.
Turn on prompt caching
Cached input tokens are read back at roughly a 90% discount (writes carry a ~25% surcharge). Agent workloads re-send the same system prompt and context every turn, so cache hit rates are naturally high — verify by checking cache-read counts in the response.
Route work to the right model tier
Not every call needs the frontier model. Background and formatting tasks belong on a Haiku-class model at a fraction of the rate; Claude Code does this split natively via its small/fast model setting.
Fix verbosity at the system prompt
A model that recaps, pads, and restates burns output tokens on every response across every seat. Standing communication rules cut that at the source — that is lesson 01, and on Bedrock it shows up directly on the bill.
Alert before the surprise
An AWS Budget scoped to the Bedrock service with an 80% threshold costs nothing to set up and turns the end-of-month surprise into a mid-month email. Budget actions can go further and apply a restrictive IAM policy when a hard threshold is crossed.
Watch the two metrics that matter
CloudWatch publishes InputTokenCount and OutputTokenCount per model under AWS/Bedrock. A dashboard with those two lines per team answers most cost questions before anyone opens Cost Explorer.
The budget alert takes two minutes and catches most surprises:
aws budgets create-budget --account-id <account-id> \
--budget '{"BudgetName":"bedrock-monthly",
"BudgetLimit":{"Amount":"2000","Unit":"USD"},
"TimeUnit":"MONTHLY","BudgetType":"COST",
"CostFilters":{"Service":["Amazon Bedrock"]}}' \
--notifications-with-subscribers '[{
"Notification":{"NotificationType":"ACTUAL",
"ComparisonOperator":"GREATER_THAN","Threshold":80},
"Subscribers":[{"SubscriptionType":"EMAIL",
"Address":"eng-leads@yourco.com"}]}]'Verbosity control is covered in depth in lesson 01 — system prompts. On a subscription it saves attention; on Bedrock it saves attention and money.
Let the agent that spends the tokens audit them.
Everything in this lesson — Cost Explorer queries, budget creation, tag audits, CloudWatch token metrics — is an AWS API call, and the AWS MCP Server puts those calls in your agent's hands. It's a managed remote MCP server exposing three tools: one that can execute any of 15,000+ AWS API operations under your existing IAM credentials, a pair that search and read current AWS documentation at query time, and a sandboxed server-side Python runner for analysis. Connect it to Claude Code once and the cost questions in this lesson become prompts instead of console sessions.
# Connect Claude Code to the AWS MCP Server
claude mcp add-json aws-mcp --scope user \
'{"command":"uvx","args":["mcp-proxy-for-aws==1.6.0",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata","AWS_REGION=us-west-2"]}'Give the agent its own IAM role — separate from yours, which AWS supports explicitly via IAM and SCPs — and scope it to the job rather than defaulting to read-only. Read-only would defeat half the point: the real payoff is having the agent build the attribution stack from this lesson — create the inference profiles, tag them, activate the tags, stand up the budgets — in one session instead of an afternoon of console work. A cost-management role that can read billing and CloudWatch and write budgets, tags, and inference profiles does all of that while remaining structurally unable to touch production. Every call lands in CloudTrail either way, so the auditor is itself audited. The server is free; you pay only for what it provisions.
- ›What did Bedrock cost last month, grouped by our CostCenter tag?
- ›Which model had the highest output-token count this week?
- ›List our application inference profiles and flag any missing tags
- ›Create a tagged inference profile for the data team and route it through our CostCenter tags
- ›Create a monthly Bedrock budget of $2,000 with an 80% alert
Every one of these runs inside a role scoped to cost management — broad enough to do the work, structurally unable to touch anything else.
Or hand it the whole job.
Everything this lesson sets up, as one prompt. Fill in the bracketed values, run it in a session with the cost-management role, and review the reference-pointed summary it hands back — the D items are yours to decide.
Using the AWS MCP server, set up Bedrock cost tracking
for us end to end:
1. Report Bedrock spend for the last 30 days: total, by
model, and by CostCenter tag. Call out any spend that
is unattributed.
2. List our application inference profiles. Flag any
missing CostCenter or Project tags and tag them —
ask me for values you can't infer.
3. For each team in [TEAMS], create an application
inference profile named "<team>-agents" copied from
[MODEL_ID], tagged CostCenter=<team>.
4. Verify CostCenter and Project are activated as cost
allocation tags; activate them if not.
5. Create a monthly budget scoped to Amazon Bedrock of
$[AMOUNT] with an email alert to [EMAIL] at 80% of
actual spend.
6. Publish a CloudWatch dashboard with InputTokenCount
and OutputTokenCount per model.
Then summarize with reference points: findings (F1...),
actions taken (A1...), and decisions you need from me
(D1...). Do not create or modify anything outside cost
management.Remember the timing caveats: activated tags take about 24 hours to start flowing, and nothing is retroactive — the sooner this runs, the sooner the answers exist. The reference-point summary format comes from lesson 01; if your system prompt already defines it, the last paragraph is redundant in the best way.
Attribution before adoption, not after the invoice.
The pattern in every Bedrock cost story is the same: the rollout worked, usage grew, and three months later nobody can say which teams the bill belongs to. Setting up profiles, tags, per-person roles and budgets on day one is a few hours of work — it's also part of every deployment we run.