AWS's Bedrock cost playbook: attribute first, then enforce budgets

AWS published a playbook on 30 October 2026, written by four AWS authors, for teams that need to answer a finance question about Amazon Bedrock: which team spent this, on which workload, and was it inside budget. It frames cost control as an operating loop of five stages: attribute, observe, enforce, optimise, operate. It argues the stages must run in that order, and says teams that jump to optimisation without attribution are guessing.

Attribution comes first, and a shared role breaks it

Bedrock records the calling IAM principal on each inference charge, and that identity appears in the AWS Cost and Usage Report 2.0. The post says to tag principals with team, application and cost centre, then activate those tags as cost allocation tags. They show up in Cost Explorer 24 to 48 hours after activation.

The failure case AWS stresses is the shared role. An LLM gateway that calls Bedrock through a single role attributes everything to that role. AWS's fix is for the gateway to assume the invocation role once per user, passing the user's name as the session name and their attributes as session tags, and to cache those credentials for up to an hour.

Three ways to enforce a budget

• Alert only: AWS Budgets on top of attributed spend. Nothing to deploy and no added latency, but nothing can stop spend; the report lags about 24 hours.
• IAM deny on breach: a Lambda function tallies per-user tokens in DynamoDB from invocation logs and adds the user to a deny policy. The post says the block lands seconds to minutes after the breaching call.
• Gateway: a proxy in the request path returns HTTP 429 as soon as a limit is hit. It adds a component to deploy, scale and security-review, and clients must be pointed at it.

AWS's advice is to phase it. Start with alerts, and build enforcement now only if spend is already in the millions per month. If developers call Bedrock directly with no proxy, only the first two tiers are available.

Caching arithmetic, as AWS states it

For Claude models in US East (N. Virginia), AWS says a 5-minute cache write bills at 1.25x the base input rate, and a 1-hour write at 2x. Reads bill at 0.1x on Claude Sonnet 4.6 and Haiku 4.5, and 0.05x on Claude Sonnet 5.5 and Opus 5.5. On that basis AWS calculates ten calls against a stable prefix cost about 22% of uncached input at 0.1x and about 17% at 0.05x. A low read-to-write ratio, it says, usually means a timestamp or session ID sits before the cache point.

What the post does not give you

It reports no customer result, benchmark or measured saving. Its one numeric target, more than half of calls on cheaper models for coding-agent fleets, is described as achievable, not demonstrated. It also says its log query field paths are illustrative and may differ by model and configuration, and that Bedrock does not enforce request metadata, so the platform team must inject it centrally.

It is an AWS document for AWS customers, so it does not compare gateways or other clouds. Its tier-2 and tier-3 designs are patterns, not products you can switch on.