Cost attribution and controls for AI developer and productivity tools on Amazon Bedrock

Amazon Bedrock provides built-in, zero-instrumentation cost attribution that traces every inference call back to the IAM principal that made it. The identity flows along with organizational tags, into AWS Cost and Usage Reports (CUR 2.0) and AWS Cost Explorer while keeping data inside the AWS security boundary. This post shows you how to use these capabilities to answer three questions that every FinOps and AI Platform leader asks as AI tool adoption scales: What is the real per-user cost? Which teams generate the most spend, and does that spend correlate with the value they deliver? How should next year’s budget scale with headcount and adoption? The approach works identically regardless of which AI coding or productivity tool makes the call. Claude Code, Claude Desktop, OpenAI Codex, ChatGPT Work, and OpenCode all invoke Amazon Bedrock through one of two inference endpoints: bedrock-runtime or bedrock-mantle , and Bedrock’s attribution mechanism operates at the endpoint layer, beneath any tool-specific logic. You configure identity propagation once, and every tool that routes inference through Bedrock inherits per-user cost visibility automatically. By the end of this post, you will have AWS IAM Identity Center configured with your external identity provider for per-user attribution, session tags (team, cost center) flowing into CUR 2.0, Amazon Athena queries and dashboard options for ongoing cost visibility, and a clear understanding of Bedrock-native usage controls to enforce spending limits. How Amazon Bedrock attribution works Amazon Bedrock records the IAM identity of every inference caller with no changes required to your API calls. When a user invokes a model through either the bedrock-runtime or bedrock-mantle endpoint, Bedrock captures the caller’s full IAM ARN, including the session name for federated users and publishes it to CUR 2.0 in the line_item_iam_principal column. In billing data, usage is aggregated per principal and per usage type for each export interval: one hour in an hourly export, one day in a daily export. CUR does not contain per-request cost. For per-prompt detail, use model invocation logs or request metadata tagging. Optionally, you can attach tags to IAM principals or pass session tags during federation to add organizational dimensions. These tags appear in CUR 2.0 with the iamPrincipal/ prefix and in Cost Explorer as filterable dimensions. The mechanism supports four access patterns: IAM users, per-application roles, federated identities, and large language model (LLM) gateways proxying to Bedrock. For a comparison of all four, see Introducing granular cost attribution for Amazon Bedrock . This post follows the federated identity pattern, which is the natural fit for AI coding and productivity tools where each developer or knowledge worker authenticates individually. Amazon Bedrock offers additional attribution mechanisms beyond IAM principal tracking that organizations can layer depending on their needs (see Appendix A for a comparison). With Application Inference Profiles, you can tag spend by workload on the bedrock-runtime endpoint. With Projects and Workspaces, you can isolate and tag spend on the bedrock-mantle endpoint. Per-request metadata tagging provides per-prompt token-level detail in model invocation logs for workloads that need granularity finer than finer than CUR 2.0’s per-usage-type aggregation per export interval. You can combine these, for example, IAM principal attribution for per-user dollars on your invoice alongside per-request metadata tags for per-prompt detail in logs. The choice depends on your goal (see Track usage and costs in Amazon Bedrock ). The attribution problem The developer and productivity tools run on each user’s machine and call Amazon Bedrock directly, or through an LLM gateway. Users authenticate by assuming a shared IAM role, so every API call appears as assumed-role/ / in billing. If every user assumes the role with the same fixed session name, or calls go through a gateway’s own role, CUR aggregates spend to a single principal. With IAM Identity Center, the session name is the user’s sign-in name, so each user gets their own principal. You can further enrich it with session tags (team, cost center, project). These fields flow into CUR 2.0’s line_item_iam_principal column and cost allocation tags with the iamPrincipal/ prefix, making per-user spend queryable alongside the dollars, with zero changes to your Bedrock API calls. Claude Platform on AWS and Claude for Enterprise route inference through Anthropic-managed infrastructure. For Claude Platform on AWS, usage is visible by workspace and API key in Anthropic’s admin console, and workspace tags flow to AWS billing. For Claude for Enterprise, per-user usage is visible in Anthropic’s admin console and Usage and Cost API. Spend limits are enforced natively by Anthropic. Prerequisites Before starting, make sure you have: An AWS account with IAM permissions to access Bedrock models you intend to use. AWS IAM Identity Center enabled in your management account. An external identity provider (Okta, Microsoft Entra ID, or Ping Identity) with SCIM provisioning capability. AWS CLI v2 configured on developer machines. AWS Cost and Usage Report (CUR 2.0) enabled with IAM principal data and delivered to an S3 bucket. Cost allocation tags activated from the management (payer) account. An Athena table configured to query CUR 2.0 data (see the GitHub sample to get started). Step 1: Configure IAM Identity Center with your external IdP Configure your external identity provider as the identity source in AWS IAM Identity Center. Navigate to IAM Identity Center → Settings → Identity source → Change identity source. Select “External identity provider” and configure SAML 2.0 or SCIM connectivity with your IdP. Enable SCIM provisioning to automatically synchronize users and groups, including organizational attributes like team and department. Configure attribute mapping for session tags by navigating to Settings → Attributes for access control. Map your IdP’s organizational attributes to session tags that will flow into CUR 2.0. These attributes propagate as session tags ( aws:PrincipalTag/Team , aws:PrincipalTag/CostCenter ) on every API call the user makes, including every Bedrock invocation through both the bedrock-runtime and bedrock-mantle endpoints. Step 2: Create a permission set for Bedrock access Create a permission set in Identity Center that grants Bedrock invocation access. Each user gets their own session within this permission set. This is the foundation of per-user attribution. The specific IAM actions depend on which Bedrock endpoint the tool calls. Tools that call the bedrock-mantle endpoint (such as Codex and ChatGPT Work) require bedrock-mantle:CreateInference and related actions scoped to a Project resource. Tools that call the bedrock-runtime endpoint (such as Claude Code and Claude Desktop) require bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream scoped to the relevant foundation model or inference profile ARNs. You can combine both in a single permission set if your organization uses tools across both endpoints. { "Statement": [ { "Sid": "BedrockMantleAccess", "Effect": "Allow", "Action": [ "bedrock-mantle:CreateInference", "bedrock-mantle:CountTokens" ], "Resource": “arn:aws:bedrock-mantle:::project/” }, { "Sid": "BedrockModelAccess", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:ListInferenceProfiles", "bedrock:GetInferenceProfile" ], “Resource”: [ “arn:aws:bedrock:::inference-profile/“, “arn:aws:bedrock:::application-inference-profile/“, “arn:aws:bedrock:::foundation-model/” ] } ] } Note: These resource patterns are a starting point. Narrow them to the specific inference profiles and Projects that you approve. Assign this permission set to the relevant groups synchronized from your IdP. Policy changes are instant and universal, audit is centralized