AWS Builder Center

Builder Center

Cost Control and User Attribution for Claude Code on Amazon Bedrock: The Wargaming Experience

Cost Control and User Attribution for Claude Code on Amazon Bedrock: The Wargaming Experience

Wargaming engineers started using Claude Code on Amazon Bedrock faster than the usual governance could follow. Finance couldn't tell who was spending what. Security didn't want long-lived API keys on laptops. The team closed both gaps in a week, using corporate SSO, one AWS account per cost center, and a Bedrock feature that makes every inference call traceable to the person who made it.

Mikhail Ishenin

Mikhail Ishenin , Solutions Architect, AWS — with Renat Lasitsa , Team Lead, Capacity & Operations Services, Wargaming.net
The agentic coding revolution is well underway, and every engineering organization is now wrestling with the same question: how do you get AI coding agents into your developers' hands without creating a mess? New tools appear almost weekly. AWS has its own contenders like Kiro, yet the tool that truly captured the industry's imagination has been Claude Code — and Wargaming's developers wanted it just as much as everyone else.
Buying it directly from Anthropic was an option, but for a company of Wargaming's size that path runs through procurement, a new vendor relationship, and yet another bill to reconcile — far more friction than it sounds. The thing is, they were already running Amazon Bedrock, with those very same Claude models sitting right inside it. Opening up access to infrastructure you already operate is a great deal simpler than standing up something new, so the choice made itself. The one loose end was visibility: Bedrock reported spend per model, not per person, and before anyone could decide who deserved a flat subscription and who was perfectly happy on pay-as-you-go, the team needed to know who was actually spending what. They came to us asking whether AWS had a clean way to tie usage back to individual people. As it happened, a new Bedrock feature was just around the corner. They put it into production, and the result proved more interesting than anyone expected.

Who spent how much?

Leadership at Wargaming didn't fight the adoption of Claude Code. They asked a sharper question: who is spending how much, and how do we keep it safe?
Total Bedrock spend was visible at the account level, but it didn't map to people or teams. The usual shortcut — handing out long-lived API keys — solves neither problem: keys sit on laptops, onboarding and offboarding stay manual, and one forgotten key quietly runs up a bill.
The answer leaned on three things Wargaming already had — one AWS account per cost center, corporate SSO, and a least-privilege permission set — joined by one new ingredient: IAM Principal Attribution , the Bedrock feature that shipped in April 2026. No new code, no key inventory to maintain.
The team went from "Bedrock is a shared cost on an account" to "we know who, when, and how much."
  • Finance sees who spends what. The team can tell who runs $100/day and who runs $1/week, and decide who belongs on pay-as-you-go versus a flat subscription.
  • Security uses the existing process. When a person leaves, the corporate Identity Provider revokes their access — Bedrock access goes with it. No separate key inventory.
  • Onboarding takes minutes. A new developer requests the role through the internal portal, runs aws configure sso once, and is ready.
  • Developers notice nothing. Open a terminal, run claude. Sessions refresh in place while the terminal is active.
"You know exactly what got charged. Who spent more than a hundred dollars in a day — you can make decisions. Someone who uses it rarely, a dollar a week — great, access is still under control." — Renat Lasitsa
Total build time, from the first conversation to a working rollout, was about a week.

How it works

The four building blocks

A dedicated AWS account per cost center. Wargaming runs a separate account per product or cost center — maintenance has its own, game titles have theirs. Spend separation happens at the account boundary, which is the cleanest split AWS provides. Mandatory account-level tags (cost center, product, team) flow into Cost and Usage Reports, so aggregation across accounts is straightforward.
IAM Identity Center wired to the corporate IdP. The federation was already in place for other AWS accounts, so there's no parallel identity system to operate. People leave through normal HR, and Bedrock access disappears with their IdP account.
A permission set with Bedrock-only privileges. Each target account inherits a role with a BedrockDeveloper policy. It allows inference actions (bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream) plus the inference profile lookups Claude Code needs (bedrock:ListInferenceProfiles, bedrock:GetInferenceProfile) and nothing else. The account is purpose-built for Bedrock, so a developer who signs in can't accidentally spin up EC2 or read S3.
IAM Principal Attribution in Bedrock. This feature, released in April 2026, makes Bedrock record the IAM identity of the caller on every inference request. Combined with session tags propagated from the IdP (email, team, cost center), the Cost and Usage Report can be sliced by person with no application-level instrumentation.

No friction, by design

Daily friction is how secure systems get bypassed.
One-time setup: request the role through the internal portal, run aws configure sso.
Every day: open a terminal, run claude. Claude Code picks up session credentials from the AWS profile and automatically refreshes them when the session expires (details in Step 7 below). No token copying, no password-manager detours. The Claude Code VS Code plugin behaves the same way; the team tested both.
"You don't have to do anything extra. You open Claude Code, it logs in by itself. Sessions refresh automatically — I have an open session in my terminal, they keep working fine." — Renat Lasitsa

What they tried first: API keys with tags

Before the SSO design, the team ran the simpler option: IAM users with programmatic access keys, each user tagged with their corporate email. It makes per-user spend visible in Cost Explorer and sets up in an afternoon.
It also ages badly. Those keys live on laptops as a permanent secret, and every new hire or departure turns into manual AWS-side work — creating users, deleting them, rotating a key the moment a laptop goes missing. At five or ten people you can absorb that overhead; across a whole organization you can't. The SSO design makes both headaches disappear at once.

Where this pattern goes next

The architecture isn't specific to Claude Code. Anything that calls Bedrock — custom applications, agent frameworks, background automations acting on behalf of a user — inherits the same attribution for free. The team already pulls CUR data into its own database and joins it with other providers to get a single multi-provider spend view.
"Out of the eight tags we currently use, you can extend them to other services and get a new view of the data. The tag system is universal — that's what this format shows." — Renat Lasitsa
Worth exploring from here:
  • AWS Budgets with tag-based filters for spend alerts per user or cost center.
  • Broader tag taxonomy — the same session tags can attribute any service, not just Bedrock.
  • Cross-provider FinOps — Bedrock alongside Anthropic API, OpenAI, and internal model hosting in one dashboard.

Build it yourself

Here's the implementation, step by step. Everything below uses standard AWS components — no custom code.

Step 1: Create a dedicated AWS account

Create a separate account in your AWS Organization per cost center. Apply mandatory account tags (cost center, product, team) at creation — they'll flow into Cost and Usage Reports.
Reference: Creating an AWS account in your organization 

Step 2: Configure IAM Identity Center with your IdP

Connect your corporate Identity Provider (Okta, Entra ID, Ping, JumpCloud, or other) to IAM Identity Center. If you already federate for other accounts, this step is done.
Reference: Connect to an external identity provider 

Step 3: Create a permission set with minimal Bedrock privileges

Create a Permission Set (for example, BedrockDeveloper) with an inline policy scoped to Bedrock inference and the inference profile lookups Claude Code needs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:ListInferenceProfiles",
"bedrock:GetInferenceProfile"
],
"Resource": [
"arn:aws:bedrock:*:*:inference-profile/*",
"arn:aws:bedrock:*:*:application-inference-profile/*",
"arn:aws:bedrock:*:*:foundation-model/*"
]
}
]
}
The inference-profile permissions are required because Claude Code resolves models through cross-region inference profile IDs (e.g., us.anthropic.claude-sonnet-4-5-...). Omitting them will make invocations fail even though InvokeModel is allowed. You can tighten further with conditions on specific model IDs or regions. Assign the permission set to the relevant groups in each target account.
Reference: Create a permission set 
Reference: Claude Code on Amazon Bedrock — IAM policy 

Step 4: Forward session tags from the IdP

Configure your IdP to pass user attributes as session tags during federation. At minimum you need one identifying attribute (email or username).
In SAML, map the attribute to:
1
https://aws.amazon.com/SAML/Attributes/PrincipalTag:User
Make sure the role's trust policy allows sts:TagSession.
Reference: Pass session tags in AWS STS 
Reference: Access control with IAM Identity Center session tags 

Step 5: Activate cost allocation tags

This must be done in the management account of your AWS Organization — member accounts can't activate it. In the AWS Billing and Cost Management console:
  1. Open Cost allocation tags
  2. Filter by type IAM principal
  3. Select the tags you need and click Activate
The tags show up in Cost Explorer and CUR 2.0 after the first Bedrock call (up to 24 hours to propagate).
Reference: IAM principal attribution — Amazon Bedrock 

Step 6 (optional): Create a CUR 2.0 data export

For line-item analytics, create a new CUR 2.0 data export with Additional export content → Include caller identity (IAM principal) allocation data enabled. Existing exports aren't retroactively augmented — if you already have one, you need a new export to get identity data. The output lands in S3 and loads into any BI stack.
Reference: Creating Data Exports 

Step 7: Hand developers a one-page runbook

The developer-facing setup is short:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# One-time: configure the SSO profile
aws configure sso
# SSO session name: bedrock
# SSO start URL: https://your-company.awsapps.com/start
# SSO region: eu-west-1
# SSO registration scopes: sso:account:access
# (browser opens; pick account and role)
# Default client Region: us-east-1
# CLI default output format: json
# Profile name: bedrock

# Daily: use Claude Code through Bedrock
export AWS_PROFILE=bedrock
export AWS_REGION=us-east-1 # required by Claude Code
export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_MODEL='us.anthropic.claude-sonnet-4-5-20250929-v1:0'
claude
After the first aws sso login --profile bedrock, Claude Code picks up session credentials from the profile. Add "awsAuthRefresh": "aws sso login --profile bedrock" to the Claude Code settings file so the CLI re-runs aws sso login automatically when the session expires.

Closing

The pattern works because it reuses mechanisms the enterprise already has — federated SSO, multi-account organization, cost allocation tags — and adds one new one to close the gap between spend and identity. If you already run AWS at scale, the incremental build is small. If you don't, the SSO and account-per-cost-center investments pay off well beyond Bedrock.
The end state is quiet in the best way. Developers open a terminal and work. Finance sees who spent what. Security sees access flowing through one existing system. Nobody runs a key rotation script at 3 a.m.

References

AWS Documentation

Tools

This article is part of a series on how enterprise companies organize access to AI tools on AWS.
# anthropic-claude# claude-code# claude-cowork# amazon-bedrock# cost-allocation
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article