Claude on Bedrock is billed on-demand, per input and output token consumed. That is easy to reason about in aggregate and hard to attribute in detail: token charges accrue against the account, and unless you set up attribution deliberately, Cost Explorer will show you that you spent money on Bedrock but not who spent it. This article covers the tagging strategy and the supporting mechanisms that turn one line into a per-team, per-application, per-environment breakdown.
How cost allocation tags work, briefly
A cost allocation tag is an ordinary AWS resource tag (a key-value pair like team=payments) that you additionally activate in the AWS Billing console. Once activated, AWS starts including that tag key as a dimension in Cost Explorer and in the Cost and Usage Report, so you can group and filter spend by it. Two caveats every FinOps team learns the hard way: activation is not retroactive (costs incurred before you activate a tag are not broken down by it), and tags only attribute costs that accrue to a taggable resource.
That second caveat is the crux for Bedrock. On-demand token consumption is metered against API calls, not against a long-lived resource you created. Which Bedrock resource types accept tags — and which charges those tags actually flow through to — is something you should confirm in the current Bedrock and AWS Billing documentation before designing your reporting around it.
A workable tagging strategy
Keep the tag schema small and boring. Three keys cover most enterprises:
| Tag key | Example values | Question it answers |
|---|---|---|
team | payments, support-eng | Which budget does this hit? |
app | claims-triage, kb-assistant | Which product is driving spend? |
env | prod, staging, dev | Is this revenue-serving or experimentation? |
Apply these keys consistently to every taggable resource in your Bedrock setup — including resources with fixed, resource-shaped costs. Provisioned Throughput, for example, bills hourly per Model Unit with no-commitment, 1-month, or 6-month terms; those hourly charges are exactly the kind of resource-attached cost that tags attribute cleanly.
Where tags fall short — and what fills the gap
Account separation is the bluntest, most reliable instrument. If two business units must never argue about a shared bill, put their Claude workloads in separate AWS accounts under one Organization. Every token they consume is then attributed by construction, with no tagging discipline required.
Model invocation logging gives per-call attribution data. Bedrock's invocation logging (disabled by default) writes a record per call containing modelId, the caller's identity.arn, input.inputTokenCount, output.outputTokenCount, and — most usefully here — optional caller-supplied requestMetadata. Have each application stamp its calls with its own metadata, and you can compute tokens-per-team from the logs and multiply by list prices to build a showback report that is more granular than anything tags alone produce. Note this covers the bedrock-runtime endpoint only, not the newer bedrock-mantle endpoint.
Mind the pricing modifiers when you convert tokens to dollars. On-demand list prices are per million tokens (Claude Sonnet 5, for instance, has promotional pricing of $2 input / $10 output per million through August 31, 2026). Regional endpoints carry a 10% premium over global endpoints for Claude Sonnet 4.5 and later models; AWS's S3-based batch inference runs at a 50% discount versus on-demand; and prompt caching bills separate cache-write and cache-read rates. A showback model that ignores these will misstate team costs.
Where to go next
See CloudWatch alarms and metric filters for turning the same logs into spend alerts, and FinOps for LLMs for the broader cost-management picture. Cost estimation helps you sanity-check the showback math.