Managing Amazon Bedrock costs with AWS tools

Introduction to managing Amazon Bedrock costs

Amazon Bedrock costs can be attributed to people or applications and restricted through AWS-native billing and identity tools, without writing application code for the common case. The approach combines IAM principal attribution, Cost Explorer or Cost and Usage Reports (CUR) 2.0, and AWS Budgets actions. Its most important limitation is timing: AWS Budgets is not a real-time spending cap, so charges can exceed a threshold before access changes.

In its walkthrough of per-principal Bedrock cost controls, AWS describes three connected tasks: identify who made inference requests, report the associated spending, and apply an access restriction when a budget threshold is crossed. Each task depends on the identity structure behind the application. A separate IAM role for each person or application supports both distinct attribution and a distinct enforcement target. A shared role requires more care.

This makes the design useful for organizations seeking team or user spending visibility and automated guardrails without maintaining a custom enforcement service. It does not remove the need to configure permissions, activate billing tags, or decide which access should change. The practical question is whether billing-based enforcement and the available IAM targets fit the organization’s requirements.

Challenges in attributing generative AI costs

The first challenge is distinguishing the caller from the person responsible for the spending. Bedrock automatically captures the IAM user or role for every inference request, without changes to model inference calls. If each application or person uses a distinct role, that identity may already provide sufficient reporting detail. If several people use a gateway, however, the captured identity is the gateway’s execution role.

Principal tags attach descriptive values to an IAM user or role. Those values apply to requests from that principal, making them useful for identifying a team, cost center, or application. They cannot distinguish people sharing the same role because the principal’s tags are the same for those people.

Session tags provide additional detail when a role is assumed. They can vary between sessions, and a session tag overrides a principal tag with the same key for that session. But their scope matters: their values remain constant for every call made with that session’s credentials. A gateway cannot label requests from different users simply by continuing to reuse one tagged session.

Billing attribution and request-level investigation also have different boundaries. AWS says session tags surface in aggregated billing data and are not written to model invocation logs, which capture the caller’s identity.arn. Its documented options for distinguishing users at the request level include a per-user RoleSessionName or user information in request metadata on each call. Neither changes the fact that CUR records aggregate costs rather than individual requests.

A second challenge is counting the full cost. The AWS walkthrough identifies four token categories: input, output, cache read, and cache write. Each has its own usage type and unit price. Counting only input and output understates costs, particularly for workloads that use prompt caching heavily. Rates also depend on service tier and cross-Region routing, so applying one price to every line item for a model can misrepresent spending.

Overview of AWS-native tools for cost management

AWS divides the workflow into attribution, reporting, and enforcement. These tools serve different purposes; selecting a reporting dimension does not by itself determine whose access a budget action can restrict.

Cost Explorer is the console-only reporting route. Filter to Amazon Bedrock and group by an available identity or tag dimension to inspect spending. AWS describes this route as sufficient for most recurring reporting needs, without query authoring. It is a sensible starting point before adding an export and SQL workflow.

CUR 2.0 supports more detailed analysis through an export to Amazon S3, with Amazon Athena available for queries. Caller identity allocation data must be selected when creating the export. Principal and session tag fields use the iamPrincipal/ prefix, while resource tags use resourceTags/. The legacy CUR format does not contain IAM principal fields, although both formats provide token cost breakdowns.

AWS Budgets supplies enforcement through budget actions. For this workflow, the relevant action applies a custom IAM policy, such as a Deny policy restricting selected models. AWS performs the policy attachment, avoiding custom code for that step. The budget can use realized spending or a forecast as its trigger, and actions can run automatically or require human approval.

The result is an access guardrail whose responsiveness follows billing updates. AWS says budget data refreshes up to three times a day. Its walkthrough contrasts this with an earlier custom approach using IAM Identity Center, Athena over model invocation logs, and Lambda, which it describes as providing near-real-time control while requiring code to operate. The native workflow therefore trades enforcement speed for less custom implementation and maintenance.

Step-by-step guide to implementing cost controls

1. Confirm prerequisites and inspect existing visibility

Start with an AWS account that has Bedrock model access enabled and uses IAM roles or IAM users to access the service. The walkthrough requires permissions to tag principals, activate cost allocation tags, and configure the billing features being used, including budgets and budget actions. It also lists an appropriately configured AWS CLI. Billing Console access is managed separately from most IAM permissions, so confirm that access before configuration.

Open Cost Explorer, filter the service to Amazon Bedrock, and group by an available identity or tag dimension. This initial inspection establishes whether distinct roles already provide the required visibility. An S3 destination and CUR 2.0 export are needed only for detailed export-based reporting; Athena is optional for querying that export.

2. Map identities to the spending units you need

For a role dedicated to one person or application, apply principal tags directly to the role or IAM user. The source’s example tag keys include user, team, Department, CostCenter, and Environment. Choose the dimensions that correspond to the reports and budget filters you intend to use.

For a shared role, pass session tags when assuming it. The role’s trust policy must permit sts:TagSession. AWS documents three paths: sts:AssumeRole with --tags; AssumeRoleWithWebIdentity with tags in the https://aws.amazon.com/tags OIDC claim; and AssumeRoleWithSAML with PrincipalTag:* attributes mapped in the identity provider’s SAML assertion.

Existing SAML claims do not automatically become session tags. For example, capturing saml:sub elsewhere does not make it available to this workflow. The identity provider must separately map the attribute to a PrincipalTag:* statement, and the trust policy must allow session tagging. These details determine whether a proposed attribution dimension actually reaches billing data.

3. Activate cost allocation tags before relying on reports

In the AWS Billing and Cost Management Console, open Cost allocation tags, filter by type IAM principal, select the required keys, and activate them. In an AWS Organization, activation belongs in the management account, or payer account; member accounts cannot activate these tags independently.

A tag key appears in the activation list only after the principal has made at least one Bedrock call. Make a test call if the list is empty. AWS allows up to 24 hours for a newly applied key to appear, followed by up to another 24 hours after activation before it begins populating billing data.

Activation does not apply retroactively by default. Establish the tag configuration before the spending period you need to analyze, and account for the documented delay when checking whether the setup works. An empty tag-based report immediately after activation is not sufficient evidence that the mapping failed.

4. Add CUR 2.0 only if the reporting requirement calls for it

If Cost Explorer provides enough detail, skip the export workflow. Otherwise, create a CUR 2.0 (Standard) export in Data Exports. Select Include caller identity (IAM principal) allocation data, choose Hourly granularity, and select Amazon Athena under report data integration. Set the destination S3 bucket.

The Athena integration sets the file format to Parquet and delivers a setup script alongside the export. Run that script, or the Glue crawler or DDL it defines, to create the Glue Data Catalog table. The console export configuration alone does not create the queryable table. An older export does not gain identity data retroactively; AWS directs users to create a new export with caller identity enabled.

When writing queries, check the actual table name and how the export exposes its billing period. The source’s example uses cur2_view and billing_period, but it explicitly warns that names and period partitioning can differ. Its service filter includes both AmazonBedrock and AmazonBedrockService, illustrating that spend can appear under multiple service codes.

Group costs by the required principal tag and usage type, and include all relevant token categories. Preserve line-item distinctions for service tier and cross-Region routing instead of applying one model-wide rate. This produces a report aligned with the billing distinctions documented in the source.

5. Configure the restriction, permissions, and budget action

Create the Deny policy that AWS Budgets will attach. The supplied example restricts bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for selected higher-cost foundation models, leaving a lower-cost model available. The model identifier must match the environment; the source supplies a placeholder rather than a deployable model choice.

Two permission contexts must be configured separately. The person or role creating the budget needs AWSBudgetsActionsWithAWSResourceControlAccess, which includes budget permissions and the conditioned iam:PassRole permission. The role assumed by AWS Budgets needs a trust policy allowing budgets.amazonaws.com, scoped with aws:SourceArn and aws:SourceAccount conditions, plus the relevant action permissions. For the role-policy workflow, AWS specifies iam:AttachRolePolicy and iam:DetachRolePolicy.

Create a cost budget scoped to Bedrock and filtered to the identity or tag value being monitored. Add an alert threshold using Actual for realized spending or Forecasted to trigger from a forecast. Attach an IAM policy action, select the budget action role, choose the Deny policy, and identify the IAM target. Enable automatic execution if that is the intended behavior; otherwise, actions require approval from the alert details page.

Configure at least one notification explaining the access change. Multiple thresholds and actions can support graduated restrictions. AWS gives the example of denying premium models at 80 percent and mid-tier models at 100 percent while retaining a lower-cost option. Those percentages illustrate a policy design, not a prescribed budget.

Check the target carefully. A budget filtered to one user’s session tag can still attach a Deny policy to a role shared by many users. That action affects everyone using the role. More precise reporting does not create a more precise enforcement target.

Conclusion and best practices

The strongest fit for this workflow is an organization whose people or applications have distinct IAM roles and whose spending controls can tolerate billing-update delays. Cost Explorer offers an initial reporting path; CUR 2.0 and Athena add detail when required. AWS Budgets then connects the spending threshold to a concrete access restriction without custom policy-attachment code.

Three practices follow from the documented limitations: establish identity and tag mappings before collecting the reporting period, verify that billing queries include the full set of applicable charges, and align each enforcement target with the intended scope of restriction. Keep notifications attached to access changes so affected users understand what happened.

The central qualification remains the meaning of a cap. With budget data refreshing up to three times daily, threshold overshoot is possible. Shared roles also limit isolation, even when session tags improve attribution. Treat this design as automated billing-based access control, and evaluate those timing and identity boundaries before relying on it to govern Bedrock spending.