End-to-End Cost Management in Amazon Bedrock: FinOps Guide

In a post published on the AWS blog, Aswath Ram A Srinivasan presents a five-stage operating model for cost management in Amazon Bedrock. According to the authors, cost management for generative AI is a shared responsibility between the teams that build applications and the teams accountable for cloud spend. Many teams start by comparing per-model token rates and asking to shorten prompts, but those steps do not answer the questions that finance and engineering leaders ask as usage scales: which team spent the amount, on which workload, and was that spend inside an approved budget? Agentic workloads sharpen these questions, because a typical conversational assistant issues one model invocation per user turn, whereas an agentic workflow issues many invocations per task and carries a larger context on each call. Token consumption scales with the degree of autonomy granted to the workflow and the size of the context it carries, rather than with the number of user interactions.

Stage 1: Attribute Every Dollar to an Owner (Attribute)

The foundation of spend management is granular cost attribution in Amazon Bedrock. The service attributes inference costs directly to the AWS Identity and Access Management (IAM) principal that made the call, across all models, with no need to manage dedicated resources. The caller’s ARN is recorded in the line_item_iam_principal column of the Cost and Usage Report (CUR 2.0), and coverage includes IAM users, roles, federated identities, and API keys. Setting up attribution involves four steps:

1. Turn on IAM principal data in the CUR 2.0 data export.
2. Tag IAM principals with business dimensions such as team, application, and cost center. For federated access, configure the identity provider to pass session names and tags through OIDC or SAML claims.
3. Activate these tags as cost allocation tags in AWS Billing.
4. Analyze the tags: they appear in CUR 2.0 with the iamPrincipal/ prefix and are displayed in AWS Cost Explorer under the IAM category within 24 to 48 hours of activation, enabling filtering and grouping by team, application, or cost center.

When a large language model (LLM) gateway calls Amazon Bedrock through a single IAM role, a shared-role problem arises that eliminates per-user visibility. The solution is per-user session management: the gateway assumes the Bedrock invocation role (using sts:AssumeRole) once per user, passes the user's identity as the role session name and their attributes as session tags, and caches credentials for up to one hour (one STS call per user per hour, instead of a call on every request). In addition to this mechanism, two other mechanisms exist: Application inference profiles on the bedrock-runtime endpoint that carry cost tags and suit a small, stable set of applications, and Projects and workspaces on the bedrock-mantle endpoint suitable for OpenAI-compatible workloads.

Stage 2: Make Every Request Observable (Observe)

CUR reports show who spent the budget, but invocation logs explain what actually happened. Amazon Bedrock supports inference logging of request data, response data, and metadata to Amazon CloudWatch Logs, Amazon S3, or both. CloudWatch logs are designed for fast operational queries, and S3 combined with Amazon Athena is designed for long-term data analysis and business intelligence (BI).

Additionally, while CUR data arrives with a lag of roughly 24 hours, combining CloudWatch and OpenTelemetry enables building near-real-time dashboards showing per-developer spend within minutes. To achieve workload-level attribution (which feature, workflow, or tenant generated the tokens), request metadata (requestMetadata) can be attached to each call to the Converse API. These fields include application, workflow, tenant, and agent. Because Bedrock does not enforce this metadata automatically, the authors recommend that the platform team inject standardized metadata centrally through a shared SDK wrapper or gateway. Using CloudWatch Logs Insights, queries can be run to identify the callers that consume the highest number of tokens, or grouped by application and workflow to build a leaderboard.

Stage 3: Enforce Budgets at Three Tiers (Enforce)

Budget enforcement can be implemented across three architectural tiers depending on spend velocity and risk tolerance:

• Tier 1: Monitor and alert (no blocking). Use AWS Budgets to send threshold breach alerts and OpenTelemetry dashboards for ongoing visibility. There are no components to deploy and no added latency on inference calls, but no hard block takes place and spend is discovered after it occurs. Suitable for early adoption phases.
• Tier 2: IAM tag enforcement (deny on breach). An AWS Lambda function calculates token and dollar counters from inference logs in Amazon DynamoDB. When a user exceeds the threshold, the function adds their identity to an IAM deny policy (denying bedrock:*) until a monthly reset or administrator intervention. Enforcement operates asynchronously: the block takes effect seconds to minutes after the breaching call via an IAM policy update, or at the next credential refresh when checking limits during credential issuance.
• Tier 3: Gateway-based enforcement (synchronous block). A gateway positioned in the inference data path enforces budgets in real time by returning an HTTP 429 error code the moment a user or team exceeds the limit. This tier provides sub-second blocking, model allowlists, token rate limits, and centralized routing rules, but requires deployment, security management, and routing requests through the gateway. For Claude Code and Claude Desktop fleets, the Claude apps gateway for AWS runs as a single container backed by PostgreSQL. For mixed models, LiteLLM can be used on Amazon ECS on AWS Fargate.

Choosing between the tiers depends on connectivity (if developers connect directly to Bedrock without a proxy, only Tiers 1 and 2 are viable) and spend velocity.

Stage 4: Optimize Platform Defaults (Optimize)

Most waste does not stem from developer carelessness, but from platform defaults that no one configured. The two primary levers are:

1. Model routing: Routine tasks (such as boilerplate completion, linting suggestions, and small code edits) can run on smaller, cheaper models, while frontier models are reserved for complex reasoning. This is done through Intelligent Prompt Routing or routing rules at the gateway. In agentic coding fleets, an achievable target is directing more than half of calls to cheaper models.
2. Prompt caching: This feature rewards stable, repeated prefixes. As of October 2026, according to published Amazon Bedrock pricing for Anthropic Claude models in the US East (N. Virginia) region, writing to cache is billed at 1.25x the base input rate with a 5-minute TTL (and 2x with a 1-hour TTL). A cache read is billed at 0.1x the input rate on Claude Sonnet 4.6 and Claude Haiku 4.5, and at 0.05x on Claude Sonnet 5.5 and Claude Opus 5.5. At a 5-minute TTL, a single reuse covers the write cost, and ten calls against a stable prefix cost roughly one-fifth of the uncached price. The only losing scenario is a write that is never read again, which adds 25% to the cost at a 5-minute TTL and doubles it at a 1-hour TTL.

Application-level optimization (such as just-in-time retrieval instead of bloated context or conversation compaction) is the responsibility of application teams, and the platform team supports this by exposing consumption metrics and setting token limits.

Stage 5: Operate the Loop and Performance Metrics (Operate)

This stage translates data into ongoing decisions. The platform team runs a dashboard with four signals: model mix (which models are called and how often), failed request rates (errors, throttles, and timeouts, where retries may cause double billing), cache effectiveness (read versus write ratio), and metadata coverage (percentage of production calls carrying complete metadata).

The FinOps team manages anomaly reviews and cost allocation (chargeback) by team and application. For this purpose, a Scorecard was introduced featuring four dimensions with performance thresholds (green, yellow, red):

• Unit economics: Cost per successful outcome – green when less than or equal to budget, yellow between 1x and 1.5x of budget, and red above 1.5x of budget.
• Per-dev cost: Daily spend per developer – green below $100, yellow between $100 and $300, and red above $300.
• Model routing: Percentage of calls to cost-efficient models – green above 50%, yellow between 30% and 50%, and red below 30%.
• Cache efficiency: Cache-read hit ratio – green above 60%, yellow between 30% and 60%, and red below 30%.

The authors emphasize that these thresholds represent a starting point rather than a binding prescription, and must be calibrated according to fleet data and pricing tiers. Additionally, the post emphasizes the distinction between cost per successful outcome and cost per single call, as a workflow can be completely cost-efficient and still not be worth running without measuring the agent compared to the human process it replaced.