Every enterprise running AI on AWS faces the same problem: Bedrock shows up as one line item with no visibility into which team consumed it. FinOps Center fixes that with IAM principal attribution, Application Inference Profile tracking, token governance, and MAP AI compliance — all conversational through Agent Bill.
Amazon Bedrock shows up on the AWS bill as a single line item — “Amazon Bedrock: $42,000” — with no visibility into which team, application, or project consumed it.
Finance can't chargeback. Product Owners can't govern their consumption. FinOps teams can't enforce budgets. And nobody knows whether MAP AI credits are at risk because nobody knows which workloads are eligible.
FinOps Center uses AWS CUR 2.0 IAM Principal Cost Allocation — a native AWS feature — to put the names back on the bill. And Application Inference Profiles to unlock MAP AI credit eligibility at the same time.
AWS CUR 2.0 captures the IAM role used for every Bedrock invocation. FinOps Center maps that role to the Product Owner who claimed it, flowing the spend through your financial hierarchy automatically.
line_item_iam_principal = arn:aws:iam::736008242383:role/finopscenter-demo-app-bedrock-roleThis records which application called Bedrock — not just which account. One dedicated IAM role per application is what makes workload-level attribution possible. Shared roles cannot be attributed to a single owner.
Application Inference Profile (recommended): When your application routes Bedrock calls through an Application Inference Profile, it surfaces as a distinct resource in CUR and unlocks MAP AI credit eligibility via the map-migrated tag. Attribution priority: inference profile takes precedence over IAM principal when both are present, preventing double-counting.
Four phases, eight steps. From Bedrock setup to Agent Bill answering natural language AI cost questions — scoped to your role and hierarchy.
Navigate to Amazon Bedrock in the AWS Console in the account where your application will run. Select Model access from the left navigation.
Click Manage model access and request access to the models your application will use. Access is typically granted within minutes for on-demand models.
Go to Billing and Cost Management → Data Exports in your payer account. Select your existing CUR 2.0 export and click Edit (or create a new one if you do not have CUR 2.0 yet).
Under “Data table content”, check the option: Include caller identity (IAM principal) allocation data
Save the export. The updated export will begin landing in S3 within 24 hours. Once the first file lands, manually trigger the Glue crawler to pick up the new column.
This adds line_item_iam_principal to every CUR row where a Bedrock call was made by an assumed IAM role — the attribution anchor for all AI workload allocation.
SELECT line_item_iam_principal,
COUNT(*) AS invocations,
SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table
WHERE line_item_product_code = 'AmazonBedrock'
AND line_item_iam_principal IS NOT NULL
GROUP BY line_item_iam_principal
LIMIT 20;Verify: Run the Athena query above once data lands to confirm line_item_iam_principal is populated with your application role ARNs before proceeding.
The CUR export must be recreated (not just edited) if it was originally created without IAM Principal support. Confirm with your FinOps Center administrator that the Glue crawler has been run and the new column is visible in Athena.
Use a descriptive, application-specific name. This name will appear in CUR and in FinOps Center exactly as you type it — make it recognisable to the Product Owner who will claim it.
Best practice: one role per application or workload. Shared roles cannot be attributed to a single owner.
Set the trust policy to allow your application's compute (Lambda, ECS task, EC2, etc.) to assume the role, and attach permissions to invoke Bedrock models.
// Trust policy — allow your compute to assume the role
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "lambda.amazonaws.com" },
"Action": "sts:AssumeRole"
}]
}
// Permissions — allow Bedrock invocations
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*"
}]
}Verify: Copy the Role ARN after creation. Example: arn:aws:iam::736008242383:role/finopscenter-demo-app-bedrock-role — you will need it in Phase 3.
An Application Inference Profile wraps a foundation model and routes all Bedrock calls for a specific application through a named, taggable ARN. This enables:
Configure with: Name finopscenter-demo-app-profile, select your foundation model, and add tag map-migrated if MAP-eligible.
// Before (direct model invocation) modelId: "us.anthropic.claude-3-5-sonnet-20241022-v2:0" // After (via Application Inference Profile — recommended) modelId: "arn:aws:bedrock:us-east-1:736008242383:application-inference-profile/finopscenter-demo-app-profile"
Attribution priority: inference profile ARN takes precedence over IAM principal when both are present on the same CUR row. A claimed inference profile prevents the same cost being double-counted if the IAM role is also claimed.
Navigate to Spaces and open the Workload record for your application. Select the AI Roles tab (visible to Product Owners and Cloud Engineers).
Click Claim IAM Role and paste the IAM Role ARN from Step 3. If using an Application Inference Profile (Step 4), also paste the profile ARN.
FinOps Center will attempt to validate the ARN is present in your CUR data. If validation fails: confirm the CUR export has landed at least one Bedrock row for this role.
Set the Workload Type to AI Workload and click Confirm Claim. The claim date is recorded — allocation starts from this date only.
Verify: The AI Roles tab should show the claimed ARN with status "Active" and the claim date. The allocation engine will attribute Bedrock spend from this role to this workload on the next nightly run.
In the Estimates tab, set the monthly AI budget for your workload. Choose your estimate type:
Enter a monthly $ amount — FinOps Center back-calculates expected token volumes.
Enter expected monthly input tokens, output tokens, and cache read tokens separately.
The consuming application team sets the estimate because they know their usage patterns — request volume, prompt length, caching strategy. This becomes the baseline Agent Bill compares actual spend against.
In the Allocation tab, assign the workload to its correct position in the element hierarchy:
Click Save Allocation.
Verify: After the next nightly rollup, this workload's AI spend will appear in the Spending Management view, in the Agent Bill Cost Management Topic (scoped to each user's RLS permissions), and in the FinOps Report Card.
Open FinOps Center and navigate to the Agent Bill chat interface. Log in with your Cognito credentials — your role determines what data you can see (RLS enforced at the QuickSight dataset level).
Agent Bill routes AI spend questions to the Cost Management QuickSight Topic automatically based on question type. No configuration needed.
Once IAM principal is claimed and CUR data has landed with the new column, these queries are all supported by the Cost Management Topic.
“Am I within my AI estimate this month?”
Your output tokens are 2× your estimate — on track to exceed budget by $200 this month. Your cache hit rate is 18% — below the healthy threshold. Tightening your prompt cache could recover most of the overage.
“Which of my products is spending the most on Bedrock?”
HR Portal leads at $14,200 this month, followed by Customer Insights at $9,400. Three of your products have unclaimed IAM roles totaling $3,800 in unattributed Bedrock spend — Product Owners need to claim them.
“Are we on track for MAP AI credits this quarter?”
You have $34,200 in qualifying MAP AI spend. $8,600 is at-risk — 4 workloads need Application Inference Profiles created. I have queued the compliance tasks for your Cloud Engineers.
| Sample Question | Persona | What Agent Bill Returns |
|---|---|---|
| "What is my total AI spend this month?" | All roles | Total Bedrock cost across all claimed IAM principals in your hierarchy |
| "Show me AI spend by application" | FinOps Leader | Breakdown of Bedrock spend per claimed IAM role / workload |
| "What is my cache hit rate?" | Product Owner | Ratio of cache_read tokens vs total input tokens — shows prompt caching efficiency |
| "Which workload is spending the most on AI?" | FinOps Leader | Ranked list of AI spend by claimed workload across the portfolio |
| "Show me my AI spend by model" | Cloud Engineer | Bedrock spend split by foundation model (Claude 3.5 Sonnet, Nova, Titan, etc.) |
| "What are my input vs output token costs?" | Product Owner | Token type breakdown — input, output, cache_read, cache_write |
| "Am I over my AI budget this month?" | Product Owner | Compares actual AI_Cost against the estimate set in Spaces (MCP + Q Topic combined) |
| "Show me AI spend by region" | Cloud Engineer | Bedrock cost by AI_Region_Type — cross-region inference vs same-region |
Built on AWS-native services. Deployed inside your account. Operated by the people who own the spending.
IAM principal-based chargeback. Bedrock spend rolls up to the Product Owner who claimed the application — not just the account.
Set token estimates per workload. Track input, output, and cache-read tokens separately. Get alerted when actuals diverge from estimates mid-cycle.
Application Inference Profile tracking. Compliance task queue surfaces exactly which workloads need profiles created — before credits are at risk.
Detect unapproved model usage by workload. Know which teams are using which Bedrock models, with policy enforcement from the same interface.
Conversational layer across all dimensions. Product Owners, Portfolio Managers, FinOps Leaders all ask the questions their role needs — get role-scoped answers.
CloudFormation-deployed inside your AWS account. Data never leaves your environment. Zero data egress. Full control over your CUR, your hierarchy, your governance.
Check: (1) Has the CUR export landed in S3 with the line_item_iam_principal column? Run the Athena validation query from Step 2. (2) Has the Glue crawler been triggered manually after the first file landed? (3) Has the nightly rollup run since the claim was created in Spaces?
The role ARN will only validate if there is at least one CUR 2.0 row where line_item_iam_principal matches that ARN. If your application has not yet invoked Bedrock using the new role, make a test invocation first, then wait for the next CUR delivery (up to 24 hours) before claiming.
Confirm the claim date in Spaces is on or before the usage dates you are checking. FinOps Center only attributes spend from the claim date forward — historical spend before the claim date is not retroactively allocated.
This is the double-count scenario. Check: does the CUR row have both an inference profile ARN (line_item_resource_id) AND an IAM principal ARN (line_item_iam_principal)? If both are claimed, the allocation engine applies the priority rule — inference profile wins. Verify only one claim type is active per spend row.
IAM principal attribution requires CUR 2.0 with that feature enabled, joined to a financial hierarchy that maps roles to business owners. Other tools don't have the hierarchy. They don't have the claiming model. They certainly can't do it from inside your account.
| Capability | Vantage / nOps / Finout / CloudZero | FinOps Center |
|---|---|---|
| Bedrock spend visibility | Account level only | Application → Workload → Budget |
| Team-level chargeback | ||
| Token-level breakdown | Basic | Input / Output / Cache per workload |
| Estimate vs actual tracking | ||
| Cache hit rate per workload | ||
| Application Inference Profile tracking | ||
| MAP AI credit compliance | ||
| Conversational governance | ||
| In-account data residency | Cross-account role required | Data never leaves your AWS |
| Unapproved model detection |
FinOps Center deploys in minutes from AWS Marketplace. IAM principal attribution starts on the first CUR landing after you enable the column.