As companies move from simple chatbots to autonomous AI agents, cloud bills for generative AI are becoming harder to predict and explain. A new AWS blog post lays out a five-stage 'operating model' for managing costs on Amazon Bedrock, AWS's managed service for calling foundation models such as Anthropic's Claude family. The piece is a practitioner playbook rather than a product announcement, but it documents several Bedrock features and reference patterns that practitioners may not know about, and it is useful background for anyone trying to understand why AI spending governance is becoming its own discipline.

Why this matters now

A conversational assistant usually makes one model call per user message, so its cost roughly tracks how many people use it. An agentic workflow is different: a coding assistant that plans a change, reads files, calls tools and iterates can issue many model calls for a single task, each carrying a large chunk of context. That means token consumption scales with how much autonomy and context a workflow is given, not with how many people are using it. The post's central argument is that this makes cost control an architectural and operational problem, not something you fix by picking a cheaper model or trimming a prompt.

What is new: a five-stage loop

The playbook describes five stages, run continuously rather than as a one-off project. FinOps teams own attribution and the final review; platform engineering teams own logging, enforcement and routing defaults.

  • Attribute: every Bedrock dollar is tied to an identity, team and application via AWS billing data.
  • Observe: every model request is logged with enough metadata to explain what generated the cost.
  • Enforce: budgets carry real consequences, from alerts to hard blocks.
  • Optimize: platform-level defaults like model routing and prompt caching remove waste centrally.
  • Operate: a small scorecard and a regular review cadence turn the data into policy decisions.

How attribution actually works

Bedrock automatically records which IAM identity (a user, role, federated identity or API key) made each call, and that identity appears in AWS's Cost and Usage Report. Teams tag identities with business labels such as team or cost centre, activate those as cost allocation tags, and the tagged data shows up in AWS Cost Explorer within one to two days, filterable by team or application. The trickiest case is a shared 'LLM gateway' that calls Bedrock using a single IAM role on behalf of many users, which would otherwise dump every user's spend into one bucket. The fix described is per-user session management: the gateway briefly assumes a Bedrock role for each user, stamping that user's identity and attributes onto the session, and caches the resulting credentials for up to an hour so it isn't making a new authentication call on every single request. This restores per-user and per-tenant visibility behind a shared gateway. Two other mechanisms exist for specific cases: 'application inference profiles' are pre-created, per-application, per-model resources suited to organizations with a small, stable set of apps and models; 'Projects' serve Bedrock's OpenAI-compatible endpoints and can span many models under one ID, useful where model choice changes often.

Making requests observable

Billing data alone tells you who spent money, not what they were doing when they spent it. Bedrock can log full request and response data to CloudWatch Logs or S3. The post recommends treating this logging as permanent infrastructure, not a manual switch, because gaps in one environment or region undermine the whole cost programme as usage grows. It also notes a timing gap: billing attribution lags about 24 hours, while CloudWatch combined with OpenTelemetry can produce near-real-time, per-developer spend dashboards within minutes. To get workload-level detail, not just per-user detail, applications can attach custom metadata to each call, like the name of the application, workflow, tenant or agent involved. Bedrock stores this in its logs for later querying. Because Bedrock does not enforce any particular schema for this metadata, the post recommends that platform teams inject it centrally through a shared code wrapper so every application tags its calls consistently.

Enforcing budgets: three tiers

The playbook lays out three levels of enforcement, each a trade-off between simplicity and speed of response.

  • Tier 1 - monitor and alert: AWS Budgets issues threshold alerts with no blocking; nothing to deploy, but overspend is caught only after it happens.
  • Tier 2 - IAM deny on breach: a background process tallies usage and automatically denies Bedrock access to an identity that crosses its limit, until a reset or override; enforcement lags by seconds to minutes.
  • Tier 3 - gateway enforcement: a gateway sitting in the request path blocks calls instantly (returning an HTTP 429 error) when a limit is hit, and can also apply per-user model allowlists and rate limits, at the cost of running and securing an extra component.

Which tier fits depends mainly on whether client applications can be routed through a proxy at all, and on how fast spending is growing. The advice is to phase in: start with alerts, and add stronger enforcement as the numbers demand it.

Where the money actually gets wasted

The post argues most waste comes from platform defaults nobody set, rather than careless individual use, and highlights two levers. The first is model routing: not every task needs a top-tier model, and routine work like boilerplate code or small edits can run on cheaper models, with routing rules or intelligent prompt routing deciding automatically; for agentic coding workloads, routing more than half of calls to cheaper models is described as an achievable target. The second is prompt caching, which reduces the cost of reusing a stable block of context across multiple calls. As of October 2026 Bedrock pricing for Anthropic Claude models in US East (N. Virginia), writing to the cache costs 1.25 times the normal input rate with a 5-minute cache lifetime (2 times with a 1-hour lifetime), while reading from the cache costs only a tenth of the input rate on Claude Sonnet 4.6 and Haiku 4.5, or a twentieth on Claude Sonnet 5.5 and Opus 5.5. These multipliers vary by model and region and can change. Under the 5-minute option, a single reuse already offsets the cost of writing the cache, and ten reuses against a stable prompt bring costs down to roughly a fifth of the uncached price. The only scenario that loses money is writing a cache entry that is never read again.

Turning data into decisions

The final stage is a recurring review built around a small set of signals: the mix of models being called, the rate of failed or retried requests (which can be billed twice), the ratio of cache reads to writes, and the percentage of calls carrying complete metadata. The post includes an illustrative scorecard with 'green/yellow/red' thresholds for metrics such as cost per successful outcome, daily spend per developer, share of calls routed to cost-efficient models, and cache hit ratio, explicitly presented as a starting point for teams to calibrate against their own data rather than a fixed standard.

Limits and open questions

The post is explicit that this framework measures efficiency, not value: a workload can be fully optimized under this model and still not be worth running, because judging whether an agent is worth its cost means comparing it against the human process it replaces, which the authors describe as a separate product and analytics question. It also flags practical caveats: field names in the example log queries are illustrative and need to be checked against an organization's actual log schema, pricing multipliers for caching can change and vary by model and region, and enforcement at Tiers 2 and 3 is asynchronous, meaning a block takes effect with some delay rather than instantly stopping an over-budget call already in flight.

How to try it

AWS points readers toward its published reference architectures as a starting point: the 'Guidance for Claude Code with Amazon Bedrock' in the AWS Solutions Library for stages covering attribution, observability and enforcement, plus AWS's cost attribution documentation for setting up a tagging strategy. For mixed-model workloads spanning multiple providers, the post points to general-purpose gateway options such as LiteLLM on AWS Fargate.

Sources