Managing Amazon Bedrock costs end to end: A playbook for FinOps and platform teams

Managing Amazon Bedrock costs is a collaborative effort between teams that develop applications and those responsible for cloud spend. While comparing per-model token rates and asking application teams to shorten prompts helps initially, it doesn't address the larger questions about cost when usage scales. An agentic workflow, such as an AI coding assistant, issues many model invocations per task and carries a larger context on each one, causing token consumption to scale with the autonomy granted and the size of the context.

Therefore, cost management for generative AI is an architectural and operational discipline rather than just a matter of choosing a cheaper model or using shorter prompts.

To effectively manage Amazon Bedrock costs, a repeatable loop must be established. This loop involves five stages: attribute, observe, enforce, optimize, and operate.

In Stage 1 (Attribute), every dollar spent on Amazon Bedrock must be attributed to an owner, identity, and application within the billing pipeline. Amazon Bedrock automatically attributes inference costs to the IAM principal that made the call, but this coverage can be enhanced by tagging IAM principals with business dimensions like team, application, and cost center.

Federated access should also be configured to pass session names and tags through OIDC or SAML claims. This allows for per-user and per-tenant attribution in the AWS Cost and Usage Report (CUR) 2.0, which can then be analyzed in AWS Cost Explorer for filtering and grouping by team, application, or cost center.

Stage 2 (Observe) involves logging every request with sufficient metadata to explain what generated the spend. This can be achieved by using the AWS Cost and Usage Report (CUR) 2.0, which provides granular cost attribution of Amazon Bedrock. The caller's ARN will be present in the line_item_iam_principal column of the CUR 2.0, allowing for easy tracking and analysis.

Stage 3 (Enforce) focuses on controlling spend with budgets and enforcement mechanisms. Any overspend should be alerted to and prevented before it compounds. This stage ensures that the operating model is in place and functioning as intended, keeping costs within approved budgets.

Stage 4 (Optimize) involves optimizing the platform defaults that drive most avoidable spend. By centralizing the optimization of platform defaults, such as model routing, caching, and token limits, waste can be minimized without requiring every team to be careful individually.

Stage 5 (Operate) is a review cadence that turns data into decisions. A small scorecard is established, and the FinOps team leads this stage, collaborating with platform engineering teams to analyze the data and make informed decisions. This final stage ensures that the cost management process is continuously improved and adapted to the evolving needs of the organization.