Manage Amazon Bedrock costs by assigning usage to the people and workloads that generate it, tracking operational activity separately from billing reports, and choosing a budget control that fits how requests reach Bedrock. AWS’s cost-management framework gives FinOps and platform teams shared roles across those tasks, plus optimization and regular review.
AWS published its five-stage framework on October 30, 2026. Its sequence is attribute, observe, enforce, optimize, and operate. The practical starting points are your attribution needs, how quickly you need a usage signal, and whether you need to stop requests at a spending limit.
Attribute spend to people and workloads
First decide which identity or workload should appear against each charge. AWS says teams can enable IAM-principal details in Cost and Usage Report (CUR) 2.0, then activate business tags for cost allocation. The principal appears in the line_item_iam_principal field; the related cost-allocation tags use the iamPrincipal/ prefix. AWS says activated tags can take 24 to 48 hours to appear in Cost Explorer.
A shared gateway needs extra care. If every Bedrock call uses one shared IAM role, AWS attributes the spend to that role. AWS’s proposed pattern assumes a Bedrock invocation role for each user, puts the user identity in the role-session name, and passes business dimensions such as team or application in session tags.
For stable application and model groupings, AWS describes application inference profiles, with a profile for each application, model, and AWS Region. Callers use the profile ARN. AWS describes Projects for eligible bedrock-mantle workloads using the Responses API or Chat Completions API; one Project can cover multiple models.
AWS’s console walkthrough demonstrates setting up application inference profiles, activating cost-allocation tags, and viewing filtered Bedrock usage in Cost Explorer.
Monitor usage before billing attribution arrives
Billing attribution and operational monitoring answer different questions. AWS describes CUR attribution as lagging by roughly 24 hours. For a faster operational view, its CloudWatch and OpenTelemetry example shows per-developer spend within minutes. That timing belongs to the described dashboard example, not every Bedrock monitoring setup.
AWS says invocation logs can send request data, response data, and metadata to CloudWatch Logs, Amazon S3, or both. It recommends CloudWatch for operational queries and S3 with Athena for longer-term business intelligence. Request metadata can identify an application, workflow, tenant, or agent, but Bedrock does not enforce a consistent metadata schema. Teams need to agree on those fields if they want to compare workloads reliably.
Choose a control that matches the request path
AWS describes three ways to respond when spending reaches a budget. Their key difference is whether they merely alert or can block a request, and how the calls reach Bedrock.
| Control | What happens at the budget limit | Time to take effect | Operational requirement |
| AWS Budgets alerts | Sends an alert; calls are not blocked. | No hard stop. | Suitable when a person can review the alert and respond. |
| IAM enforcement | A policy update or withheld credentials can deny later calls. | Policy updates may take seconds to minutes; withheld credentials take effect at the next credential refresh. | Works for direct callers without adding a gateway to the inference path. |
| Gateway enforcement | The gateway can block a request at the limit and return HTTP 429. | Synchronous; AWS describes enforcement as sub-second. | Clients must send requests through the gateway, which must be deployed, scaled, and security-reviewed. |
If the priority is a synchronous stop, the gateway is the option AWS describes for blocking a request at the threshold. That control only covers calls routed through it. IAM enforcement can fit direct callers, but it is asynchronous; alerts alone provide notice rather than a hard limit.
Optimize models and estimate prompt-cache costs
AWS recommends evaluating whether a cheaper model meets the workload’s quality needs before routing tasks to it. A lower input rate by itself does not establish that a model is suitable for the task.
AWS’s October 2026 article reports these Claude prompt-cache multipliers for US East (N. Virginia):
- Cache writes cost 1.25× the base input rate with a five-minute time to live (TTL), or 2× with a one-hour TTL.
- Cache reads cost 0.1× the base input rate for Claude Sonnet 4.6 and Claude Haiku 4.5.
- Cache reads cost 0.05× the base input rate for Claude Sonnet 5.5 and Claude Opus 5.5.
The ten-call estimate assumes the same input prefix is used ten times, with one five-minute-TTL cache write followed by nine equal-volume reads. At a 0.1× read rate, the input-prefix charges are (1.25 + 9 × 0.1) ÷ 10 = 21.5% of the cost of ten uncached inputs. At a 0.05× read rate, they are (1.25 + 9 × 0.05) ÷ 10 = 17%. These calculations cover the cached input prefix only; they exclude output tokens and other charges. A write that is not reused does not receive the offset from later reads.
Review the operating metrics regularly
AWS suggests reviewing cost and usage jointly across FinOps and platform teams. Its scorecard covers daily spend per developer, the share of work routed to cost-efficient models, cache-read hit ratio, and cost per successful outcome. AWS calls its scorecard thresholds starting points to calibrate against a workload, rather than universal targets.
AWS suggests a weekly review for high-velocity fleets and a biweekly review otherwise.
