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

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 application teams to shorten prompts. Those steps help, but they don’t answer the questions that finance and engineering leaders ask as usage scales: which team spent this, on which workload, and was that spend inside an approved budget? Agentic workloads make those questions more pressing. A conversational assistant typically issues one model invocation per user turn. An agentic workflow, such as an AI coding assistant that plans a change, reads files, calls tools, and iterates, issues many invocations per task and carries a larger context on each one. Token consumption therefore scales with the degree of autonomy you grant the workflow and the size of the context it carries, rather than with the number of user interactions. Because consumption is a function of how a workload is designed and operated, cost management for generative AI is an architectural and operational discipline. Published averages are a poor substitute for your own numbers: use the AWS Pricing Calculator and the Amazon Bedrock pricing page to model rates, and use Step 2 of this post to measure what your workloads actually consume. The fix isn’t a cheaper model or a smaller prompt. It’s an operating model: a repeatable loop that attributes every dollar to an owner, makes every request observable, alerts on and enforces budgets before overspend compounds, optimizes the platform defaults that drive most waste, and reviews the whole system on a cadence. In this post, you learn how to manage Amazon Bedrock cost in five steps. You attribute every dollar to an owner, make every request observable, control spend with budgets and enforcement, optimize the platform defaults that drive most avoidable spend, and operate a review cadence that turns data into decisions. This approach is built from AWS building blocks, and you can customize it and apply it to your own environment. The post is written for two audiences: FinOps practitioners who own attribution, chargeback, budgets, and anomaly review, and platform engineering teams who own logging, request metadata, enforcement, and routing defaults. The operating model in one view Five stages, run as a loop. Attribute: every Amazon Bedrock dollar lands on an identity, team, and application in the billing pipeline. Observe: every request is logged with enough metadata to explain what generated the spend. Enforce: budgets have teeth, with alerts at minimum and hard blocks where the risk demands them. Optimize: the platform defaults (model routing, caching, token limits) remove waste centrally instead of asking every team to be careful. Operate: a small scorecard and a review cadence turn the data into decisions. FinOps leads stages one and five. Platform engineering leads two through four. The review is joint. The stages are sequenced deliberately. Each one depends on the ones before it, and teams that jump straight to optimization without attribution and observability are guessing. Figure 1: The five-stage operating model, run as a continuous loop Stage 1: Attribute every dollar You can’t manage what you can’t attribute, and everything downstream (chargeback, budgets, enforcement, anomaly detection) depends on this stage. The foundation is the granular cost attribution of Amazon Bedrock (see Introducing granular cost attribution for Amazon Bedrock ): Amazon Bedrock automatically attributes inference costs to the AWS Identity and Access Management (IAM) principal that made the call, across all models, with no resources to manage. The caller’s ARN lands in the line_item_iam_principal column of the AWS Cost and Usage Report (CUR) 2.0 , and coverage spans IAM users, roles, federated identities, and API keys. Setup is four steps: Turn on IAM principal data in your CUR 2.0 data export. Tag your IAM principals with business dimensions such as team, application, and cost center. For federated access, configure your identity provider to pass session names and tags through OIDC or SAML claims. Activate those tags as cost allocation tags in AWS Billing (console or the UpdateCostAllocationTagsStatus API). Analyze the tags: they surface in CUR 2.0 with an iamPrincipal/ prefix (for example, iamPrincipal/team ) and appear in AWS Cost Explorer under the IAM category within 24–48 hours of activation, ready for filtering and grouping by team, application, or cost center. This is invoice-grade, per-identity attribution with no custom infrastructure. The shared-role problem The pattern that deserves the most attention is the shared-role problem, because it is where most platforms silently lose attribution. A large language model (LLM) gateway that calls Amazon Bedrock through a single IAM role attributes every dollar to that one role, eliminating per-user visibility entirely. The fix is per-user session management. The gateway assumes the Amazon Bedrock invocation role once per user, passing the user’s identity as the role session name and their attributes as session tags, then caches those credentials for up to an hour (one AWS Security Token Service (AWS STS) call per user per hour, not per request). This needs two roles: a gateway execution role holding sts:AssumeRole and sts:TagSession permissions, and the Amazon Bedrock invocation role it assumes. The result is line_item_iam_principal entries like assumed-role/BedrockRuntimeRole/gw-alex , each carrying its user’s tags: per-user and per-tenant attribution restored behind a shared gateway. import boto3 sts = boto3.client("sts") # One call per user; cache the returned credentials up to 1 hour response = sts.assume_role( RoleArn="arn:aws:iam::123456789012:role/BedrockRuntimeRole", RoleSessionName="gw-alex", # the user, not the gateway Tags=[ {"Key": "team", "Value": "sales-ai"}, {"Key": "application", "Value": "renewal-agent"}, {"Key": "costCenter", "Value": "CC-2041"} ] ) A note on application inference profiles and Projects Amazon Bedrock offers two more attribution mechanisms, each suited to a different pattern. Application inference profiles are pre-created, per-application resources on the bedrock-runtime endpoint that carry cost allocation tags. You create one profile per application per model per AWS Region, and callers reference the profile ARN, which fits teams with a small and stable set of applications and models. Projects and workspaces serve the bedrock-mantle endpoint (Responses API, Chat Completions API). A project isn’t tied to a specific model, so a single project ID spans many models, which fits teams whose model usage changes frequently. You pass the project ID at client initialization, and its tags flow to CUR 2.0 and Cost Explorer (see Manage AI costs with Amazon Bedrock Projects ). Projects are the attribution path for OpenAI-compatible workloads on Amazon Bedrock. For bedrock-runtime workloads, we recommend IAM principal attribution through session tags as the primary mechanism. It scales with your identity system, requires no pre-created resources, and covers every model and API operation. Application inference profiles work well when a small, stable set of business units needs invoice-grade billing separation without changes to identity design. Use projects for bedrock-mantle workloads that use the Responses API or Chat Completions API. Stage 2: Make every request observable CUR tells you who spent. Invocation logs tell you what happened. Amazon Bedrock supports model invocation logging of request data, response data, and metadata to Amazon CloudWatch Logs, Amazon Simple Storage Service (Amazon S3), or both. Use Amazon CloudWatch for fast operational queries and S3 plus Amazon Athena for long-term business intelligence (BI) access. Treat logging as infrastructure, not a manual toggle: provision the log group or bucket through code, define retention and encryption policies, and valid