Traditional AWS spend is provisioned — you allocate infrastructure and measure it. AI spend is behavioral — every model invocation is a consumption decision made by a developer, an application, or an agent, often invisible to the people who own the budget.
FinOps Center already governs your full AWS cost allocation — hierarchy, workload estimates, budget approval cycles, and Cloud Engineer task queues. AI workloads run on that same foundation. Bedrock adds three requirements that traditional cloud workloads don't have.
Effective AI governance requires a clear separation between the people who make governance decisions and the people who implement them. FinOps Center enforces this by design.
Approvers govern consumption. They don't need console access — they need visibility into their scope, the ability to approve or reject, and a record that the decision was made.
Engineers implement what was approved — not what they think was intended. FinOps Center generates the exact command. No policy interpretation. No governance judgment calls.
When a FinOps Lead approves a model with a specific action scope, FinOps Center generates the Cloud Engineer task and the exact IAM policy CLI command. The engineer executes what was decided. If the scope changes later, a new approval is required and a new task is generated. The decision and the implementation are permanently linked — neither can happen without the other.
AWS CUR 2.0 captures the IAM role behind every Bedrock invocation. FinOps Center maps that role to the Product Owner who claimed it, flowing spend through your financial hierarchy automatically — no tagging required, no engineering effort per workload.
Every model approval defines state (Approved / Restricted / Blocked), scope (which accounts and regions — approvals don't carry across environments), and action scope (Inference Only by default — agentic access requires its own approval).
Every AI role ships with an explicit IAM Deny on aws:ViaAWSMCPService. Agentic access requires a separate FinOps Lead approval. The Cloud Engineer receives the exact CLI command — no judgment call on what the policy should be.
Every step has a defined owner, a defined decision, and a defined implementation task.
Every Bedrock model is automatically discovered daily via bedrock:ListFoundationModels. The FinOps Lead assigns each model a state — Approved, Restricted, or Blocked — with written rationale. Every approval defines three dimensions: model state, account and region scope (an approval in us-east-1 does not extend to eu-west-1 or other accounts), and action scope (Inference Only by default — agentic AWS access is a separate, explicit approval). Once the decision is made, FinOps Center generates a Cloud Engineer task with the exact CLI commands to implement it.
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 the teams invoking Claude Opus are even authorized to use it.
Unlike infrastructure — which is provisioned and relatively predictable — AI inference is entirely consumption-driven. Every prompt is a cost event. Every model version change can shift spending dramatically. Non-engineering teams like product, marketing, and data science are now directly driving Bedrock spend with no visibility into what they're consuming or whether it's within budget.
FinOps Center uses AWS CUR 2.0 IAM Principal Cost Allocation — a native AWS feature — to put the names back on the bill. And a model approval catalog to ensure the teams consuming those models were authorized to do so in the first place.
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 spend through your financial hierarchy automatically.
This records which application called Bedrock — not just which account. One dedicated IAM role per application is what makes workload-level attribution possible without tagging.
One role per app — named, dedicated
line_item_iam_principal captured automatically
Product Owner claims role to workload
BU → Dept → Portfolio → Product
Role-scoped conversational governance
Once IAM principal is claimed and CUR data has landed, governance is conversational — every answer scoped to the authenticated user's role and financial responsibility.
"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 spend — Product Owners need to claim them.
"Are we using any Bedrock models we haven't approved?"
Yes — two unapproved models have drift this month. Claude Opus 4.7 has 140 invocations from the checkout-service role (owned by Maria's team, Pre-Prod account), totaling $2,400. Llama 3 70B has 8 invocations from an unclaimed role in the data-science account, totaling $45. Neither is in your approved catalog.
When a model operates through an MCP server, it can take actions in your AWS environment. Agentic access requires the same approval and implementation separation as model access — but the stakes are higher.
Every AI role generated by FinOps Center ships with an explicit IAM Deny on aws:ViaAWSMCPService: true. IAM Deny always wins — no other policy can override it. Agentic access is off by default.
Approving a model for inference does not grant it agent access. Agentic capability is a distinct FinOps Lead approval — scoped to the action set the agent needs, never automatically inherited across accounts or regions.
Once a FinOps Lead approves an action scope, FinOps Center generates the exact aws iam put-role-policy CLI command. Copy and execute. No policy authoring.
aws iam put-role-policy \
--role-name <ai-workload-role> \
--policy-name FinOpsCenter-Bedrock-<model-id> \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": "arn:aws:bedrock:<region>::foundation-model/<model-id>",
"Condition": {
"StringEquals": {
"bedrock:InvokedModelId": "<model-id>"
}
}
},
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": { "aws:ViaAWSMCPService": "true" }
}
}
]
}'Built on AWS-native services. Deployed inside your account. Every stakeholder accountable for their scope.
IAM principal-based allocation. Every Bedrock invocation attributed to the Product Owner who claimed the application — not just the account. Spend flows through your existing CFM hierarchy automatically.
FinOps Leads approve each model with three dimensions: model state, account and region scope, and action scope. Product Owners see only approved models. Unapproved invocations flag immediately.
Product Owners commit to a monthly cost or token estimate before a workload goes live. Estimates are tied to the budget they draw from, giving Finance visibility before the first Bedrock call is made.
Nightly rollup flags every CUR row where an unapproved model was invoked by a claimed IAM principal. Who invoked it, which model, which workload, and what it cost — all in one governance view.
Role-scoped conversational governance across attribution, approval, and drift. Each persona sees their scope — Product Owner sees their workload, Portfolio Manager sees their portfolio, FinOps Lead sees everything.
Default-deny agentic access on every AI role. Action scope requires a separate FinOps Lead approval. Cloud Engineers receive the exact CLI command to implement what was approved.
CloudFormation-deployed inside your AWS account. Your CUR, your hierarchy, your workload claims — stored in infrastructure you control. No cross-account IAM to a vendor. No data egress.
Check: (1) Has the CUR export landed in S3 with the line_item_iam_principal column? (2) Has the Glue crawler been triggered 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. Make a test Bedrock invocation using the new role, 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 allocates spend that occurred after the claim date was set.
FinOps Center deploys in minutes from the AWS Marketplace. IAM attribution, model approval, consumption estimates, and default-deny agentic governance all start on the first CUR landing.