Track and Optimize Generative AI Spend for Applications, Developers, and Agents on AWS
An overview of the cost attribution options available for Amazon Bedrock workloads, from IAM principal tagging to per-request metadata and LiteLLM, with a comparison of visibility latency, granularity, and setup effort.
Introduction
As organizations scale their generative AI workloads on Amazon Bedrock , a common challenge emerges: who is spending what, and where? Whether you're running multi-tenant applications, enabling developers with Claude Code , or deploying autonomous agents with Amazon Bedrock AgentCore , you need visibility into how your AI budget is being consumed.
Amazon Bedrock offers multiple cost attribution mechanisms that work at different levels of granularity. Choosing the right one (or combining several) depends on what you're optimizing for: billing accuracy, real-time visibility, or per-prompt detail.
This post introduces the available mechanisms and helps you decide which combination fits your workload.
The Challenge
Generative AI spend is uniquely difficult to track:
- Token-based pricing makes costs unpredictable compared to fixed-resource services
- Shared infrastructure (one account, many teams) obscures who is driving costs
- Agentic workloads (Claude Code, AgentCore) make many inference calls per task, with no built-in association between the business context and the API call
- Multi-provider environments add another layer when teams use Bedrock alongside other model providers
Without proper attribution, you're left with a single monthly bill and no way to answer: "Which team, application, or agent is responsible for this spike?"
Where Cost Data Lands: Cost Explorer and CUR 2.0
Most of the mechanisms described in this post deliver cost data to two AWS billing tools. AWS Cost Explorer is an interactive console that lets you visualize, filter, and group your AWS spending over time. You can slice costs by tag, service, account, or any activated cost allocation dimension without writing queries or building pipelines.
For deeper analysis, AWS Cost and Usage Reports 2.0 (CUR 2.0) provides line-item billing data exported to Amazon S3. Each row represents a usage record with fields like service, resource, tags, and the IAM principal that made the call. You can query CUR 2.0 with Amazon Athena, join it with other datasets, and build custom dashboards in Amazon QuickSight. CUR 2.0 is the most granular billing data source AWS provides, and it is where IAM principal attribution and resource tags appear at the line-item level.
Cost Attribution Options for Amazon Bedrock Workloads
IAM Principal Attribution
Amazon Bedrock automatically captures the calling principal ARN (IAM user or role) for every inference request on the
bedrock-runtime and bedrock-mantle endpoints. If calls are made via assumed roles, the RoleSessionName or session tags identify the individual caller. You can tag your IAM principals with attributes like team, project, or cost center, activate them as cost allocation tags, and get per-identity spend in Cost Explorer and CUR 2.0 with no code changes.Best for: Per-developer visibility (including Claude Code users, whose sessions map to IAM roles).
Application Inference Profiles
Create inference profiles that wrap on-demand models with custom resource tags. Route application traffic through a profile, and the tags flow directly to your billing tools.
Best for: Per-application or per-team cost isolation on
bedrock-runtime workloads.Projects (bedrock-mantle)
For workloads using the OpenAI-compatible API (Chat Completions, Responses) on the
bedrock-mantle endpoint, projects provide resource-level tagging that flows to Cost Explorer and CUR 2.0.Best for: Teams using OpenAI SDK through the bedrock-mantle endpoint.
Workspaces (Anthropic Messages API)
Workspaces provide cost attribution for the Anthropic-compatible Messages API on the
bedrock-mantle endpoint. Set the anthropic-workspace HTTP header on each request, and tags applied to the workspace appear in your billing tools.Best for: Anthropic SDK-based applications that need per-app cost segmentation.
Per-Request Metadata Tagging
Tag each individual inference call with custom key-value pairs (tenant, experiment, task ID) on the
bedrock-runtime endpoint. Metadata appears in model invocation logs and gives you token counts per request. Note that this provides token usage, not dollar costs. You convert tokens to cost using the published pricing for each model. Logs can be queried with Athena or visualized in QuickSight.Best for: Per-prompt, per-tenant, and per-experiment tracking on
bedrock-runtime. Ideal for multi-tenant applications and AgentCore agent step-level attribution. Not available on the bedrock-mantle endpoint.IAM Identity Log Attribution
When model invocation logging is enabled, Amazon Bedrock records the calling IAM identity (user or role ARN) in every log entry alongside the token usage. You can query these logs with CloudWatch Log Insights to get per-identity token consumption in near real-time, without any code changes to your application. Unlike Per-Request Metadata Tagging, you do not need to add metadata fields to your API calls. You simply use or assume a specific IAM identity, and the invocation logs capture who made each call and how many tokens were consumed.
While tagging IAM roles is not strictly required for this method, it is good practice if you also want per-identity visibility in Cost Explorer. The key advantage here is zero code changes: enable invocation logging, query by identity ARN, and get token-level attribution immediately.
Best for: Per-identity token tracking with zero code changes on
bedrock-runtime. Ideal when you want near real-time visibility without modifying application code, and when per-identity (rather than per-request) granularity is sufficient.LiteLLM (Third-Party Gateway)
LiteLLM is an open-source LLM proxy that sits between your applications and model providers. It provides a unified API layer that routes requests to over 100 LLM providers, including Amazon Bedrock, OpenAI, Azure OpenAI, Anthropic, and others. LiteLLM automatically tracks spend for every request in real time, with built-in dashboards for cost per user, team, API key, and model. It also supports budget enforcement, rate limiting, and alerting.
Unlike the AWS-native mechanisms that deliver billing data with up to 24-hour delay, LiteLLM gives you immediate cost visibility as requests flow through the proxy. This makes it particularly useful for organizations that need real-time budget guardrails or are using multiple AI providers and want a single pane of glass for cost tracking.
Important caveat: Placing any proxy (including LiteLLM) in front of Amazon Bedrock collapses the IAM identity. All calls appear under the proxy's IAM role unless the proxy assumes a per-user role or forwards request metadata. Additionally, LiteLLM's cost figures are estimates based on published pricing. Always reconcile against your AWS bill for invoice-accurate numbers.
Best for: Real-time cost visibility, multi-provider environments, budget enforcement, and organizations that need immediate spend alerts rather than next-day billing data.
Comparison
| Mechanism | Endpoint | Cost Visibility Latency | Where You See Metrics | Output | Granularity | Setup Effort | Multi-Provider |
|---|---|---|---|---|---|---|---|
| IAM Principal Attribution | bedrock-runtime, bedrock-mantle | Up to 24h | Cost Explorer, CUR 2.0 | Billed dollars | Per identity, per day | Low: tag IAM roles, activate cost allocation tags | Bedrock only |
| Application Inference Profiles | bedrock-runtime | Up to 24h | Cost Explorer, CUR 2.0 | Billed dollars | Per profile, per day | Medium: create profiles, tag, route traffic through them | Bedrock only |
| Projects | bedrock-mantle | Up to 24h | Cost Explorer, CUR 2.0 | Billed dollars | Per project, per day | Low: create a project, tag it | Bedrock only |
| Workspaces | bedrock-mantle | Up to 24h | Cost Explorer, CUR 2.0 | Billed dollars | Per workspace, per day | Low: create workspace, add HTTP header to requests | Bedrock only |
| Per-Request Metadata Tagging | bedrock-runtime | Near real-time (in logs) | Invocation Logs, Athena, QuickSight | Token counts (convert to cost) | Per request | Medium: enable logging, add metadata to each call, build analytics pipeline | Bedrock only |
| IAM Identity Log Attribution | bedrock-runtime | Near real-time (in logs) | CloudWatch Log Insights, Athena | Token counts (convert to cost) | Per identity | Low: enable invocation logging, query by identity ARN | Bedrock only |
| LiteLLM (third-party) | Proxy layer | Real-time | LiteLLM Dashboard | Estimated cost | Per request | Medium: deploy and configure the proxy, set up routing and tagging | Multi-provider |
Combining Mechanisms
These mechanisms are not mutually exclusive. A common pattern is:
- IAM Principal Attribution for invoice-level per-user dollars
- Per-Request Metadata Tagging for per-prompt, per-task detail in logs
- LiteLLM as a gateway when you need real-time visibility or multi-provider support
For AgentCore workloads, combine IAM attribution (which agent role) with request metadata (which task, session, or customer) for end-to-end traceability.
For Claude Code, the endpoint depends on your configuration. By default, Claude Code uses the
bedrock-runtime endpoint (InvokeModel API), so IAM principal attribution and application inference profiles apply. If you enable the Mantle endpoint (CLAUDE_CODE_USE_MANTLE=1), requests route to bedrock-mantle via the Anthropic Messages API, where Workspaces apply. Pick the endpoint that matches the attribution dimension you care about most.Getting Started
- Start simple: Activate IAM principal attribution by tagging your IAM roles and enabling cost allocation tags. This gives you per-user visibility with zero code changes.
- Add structure: Create application inference profiles or projects to segment costs by application or workload.
- Go deeper: Enable model invocation logging and add request metadata for per-prompt analytics.
- Build dashboards: Use Cost Explorer for billing-level views and QuickSight (fed by Glue-transformed invocation logs) for operational insights.
- Optimize: Once you have visibility, act on it. We will cover cost optimization strategies (budgets, provisioned throughput, model right-sizing, and batch inference) in the next posts in this series.
Conclusion
Generative AI cost management on AWS is no longer a single-tool problem. By combining Amazon Bedrock's native attribution mechanisms with operational tooling, you can build a cost visibility stack that scales from a single developer using Claude Code to thousands of autonomous agents running on AgentCore.
The key is matching the mechanism to the question you're trying to answer: "How much did team X spend?" (IAM/Profiles) vs. "What did this specific agent task cost?" (request metadata) vs. "How do costs compare across providers?" (LiteLLM).
Want to Try It Hands-On?
Explore the sample code that demonstrates how to implement each attribution method covered in this post.
A workshop where you can run all of these methods yourself is coming in late July. You'll get hands-on experience implementing each attribution mechanism, combining them for real-world scenarios, and building cost dashboards. Stay tuned!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article