Cloud Scal3
Every AI dollar. Owned. Attributed. Governed.
Governance isn’t a brake on AI adoption — it’s what lets enterprises scale AI consumption confidently. FinOps Center gives every budget owner a governed path from model approval to spend accountability: an approved model, a scoped IAM role, and a named budget owner before the first token — entirely within your own AWS estate.
AI platforms governed — Bedrock, AWS Marketplace Models, and Claude Platform — under one approval framework
Allocation Gap scenarios detected and actioned — from unattributed spend to unclaimed workloads
Spend Cards per claimed workload — actuals vs estimate, by model, token type, and region
from Business Request to a governed, running AI workload — the governed path is the fast path
AI implementation needs to start with business approval — not with an engineering team enabling a new model and using it.
Ask most enterprise teams these questions — and see how many they can answer:
Amazon Bedrock and Claude Platform bill at the environment level. Five workloads sharing one environment produce one invoice. Without a governed approval process, Finance gets a growing pile of unowned spend — with no model audit trail, no estimates to measure against, and no workload owner to call.
The governance principle is simple: every model must be approved for use in a specific region, for a specific set of actions, with allocation back to the requesting workload. That approval needs to happen before the first API call — not after Finance asks where last month’s bill came from.
FinOps Center gives every AI dollar a name — from the moment a workload is approved through the weekly Spend Card review.
The FinOps Foundation is explicit: the goal of AI governance is not to slow adoption — it is to guide it responsibly, and make the governed path the easiest path. FinOps Center operationalizes exactly that. An approved model, a scoped IAM role, and a named budget owner before the first token. Teams ship faster because the guardrails are already there — not despite them.
Practitioners told the FinOps Foundation they're holding back guardrails to avoid slowing AI down. That's the false choice.
FinOps Center removes it — the governed path is the fast path.
Paraphrased from practitioner findings · Source: State of FinOps 2026, FinOps Foundation
Up from 31% just two years ago — a +35% jump in 2025 alone. AI spend is no longer a special project. It is core FinOps work.
Governance, forecasting, and scope expansion now collectively outweigh optimization as top practitioner priorities — a maturity signal.
Pre-deployment architecture costing and granular AI spend monitoring (tokens, LLM requests) are the top capabilities teams want and don't yet have.
Source: FinOps Foundation, State of FinOps 2026 (data.finops.org) · 6th annual survey · 1,192 respondents · $83B+ in annual cloud spend · Licensed CC BY 4.0
Product Owners set forward estimates before spend begins. The FA Confirmed Estimate — informed by live Bedrock pricing — is the official figure that drives weekly Spend Cards. Estimating is not about blocking projects; it's about enabling them with a budget anchor.
Workload-level IAM attribution via line_item_iam_principal in CUR 2.0. Every AI dollar is attributed to a named consuming workload — not the environment owner. Six Allocation Gap scenarios surface spend that Finance cannot yet attribute.
Every model must be approved for a specific region, a specific set of actions, and a specific workload before the first API call. The Business Request workflow enforces this — governance precedes consumption by design.
Weekly Spend Cards surface actuals vs estimate at the workload level. Portfolio Owners approve the rollup. Finance gets a chargeback-ready record every week — not every quarter.
The Crawl / Walk / Run maturity model aligned to the FinOps Foundation framework. Four dimensions — Workload Attribution, Model Governance, Estimate Coverage, Process Efficiency — each showing current tier and the next advancement move.
FinOps Center runs entirely inside your AWS estate. No cross-account IAM to a vendor. Your CUR data, attribution records, and spend cards stay in accounts you control — consistent with the Foundation's data governance guidance.
Amazon Bedrock and Claude Platform are AI model environments — providers of foundation model access. They bill at the environment level. Without consumer identity, Finance gets one invoice with no names on it — the same problem the API economy spent a decade solving.
Five product teams consuming services through one shared API account produced one invoice. The platform team that set up the integration got the bill. Finance needed to charge each consumer. The answer was metering by API key — the key traveled with the consuming application, not the platform that provisioned it.
Five workloads calling models through one Bedrock environment produce one invoice. The team that owns the environment gets the bill. Finance needs to charge each consuming workload. The answer is the same: meter by consumer identity. The IAM principal travels with the consuming workload — not the environment that provisioned the model access.
The IAM principal is the API key of the AI economy. FinOps Center is the metering and chargeback layer.
When your Customer Support Bot and your Engineering AI Assistant both call the same Bedrock model environment, the environment produces one bill. IAM principal attribution splits it — down to the workload, the model, and the token type — so Finance can charge each consuming team against their own budget.
When the FinOps Lead changes the approved model from Claude 3 Haiku to Nova Lite, the IAM principal stays the same. The Product Owner still sees their workload. Their spend card still works. Governance doesn't break during model transitions — because attribution follows the consumer, not the model.
The line_item_iam_principal field in CUR 2.0 is AWS's answer to workload-level AI attribution — confirmed in the AWS April 2026 Bedrock cost attribution guidance. FinOps Center builds the governance layer that makes this field actionable: approvals, role generation, spend cards, and Allocation Gap detection all anchored to the same principal.
Picks a use case — Coding or Operations — describes the workload, sets a budget estimate, and selects an availability requirement. No platform selection. No model knowledge.
Reviews business context, selects platform, assigns model, account, and region. Writes rationale. One approval generates every downstream task.
Works through a pre-built task queue. CLI commands are written. IAM role names are auto-generated. No policy authoring. No governance judgment calls.
No non-technical person should need to understand CUR data or IAM principals to know if they're on budget. Agent Bill translates AWS AI billing into plain language for every stakeholder — scoped to what they own.
Product Owners onboard AI workloads through a three-step form. They pick a use case type, describe the workload in their own terms, set a budget, and select an availability requirement. The model, the platform, the AWS account, and the region are decided downstream — by the people responsible for those decisions.
The Product Owner answers two business questions. FinOps Center estimates the monthly cost — actual cost depends on model selection made by the FinOps Lead.
Estimated monthly cost is calculated from these inputs. Actual cost depends on model selection made by your FinOps Lead.
The Product Owner describes what the application does, who uses it, how often, and what availability their workload requires.
Single region. Standard Bedrock pricing. Appropriate for internal tools, dev workloads, and non-critical applications.
Cross-region inference profile. Approximately 10% pricing premium. Appropriate for customer-facing or SLA-bound workloads.
The Product Owner's submission flow — use case, workload context, and budget. No AWS access required.
The FinOps Lead receives each Business Request with full business context — team size, AI utilization rate, workload description, availability requirement, and estimated budget. They select the platform, assign the model, account, and region. One approval generates every downstream task automatically.
Full business context from the PO — team size, AI utilization, workload purpose, availability requirement, and estimated monthly cost.
Choose Amazon Bedrock, AWS Marketplace Models, or Claude Platform based on workload type, organizational standards, and billing model.
Assign model, AWS account, region, and IAM role name. For Claude Platform: name the workspace the workload will use. Sets the FA Confirmed Estimate — a dollar or token figure informed by live Bedrock pricing that drives weekly Spend Cards and Estimate Coverage in the Governance Maturity model.
Write the rationale. Approve generates all CE tasks automatically with pre-written CLI commands. Reject returns to the PO with context.
The FinOps Lead review — business context on top, platform selection and configuration below. One approval generates all downstream tasks.
Approving a model in the catalog opens the door. A Business Request is what ensures no workload walks through it without a named budget owner and a confirmed estimate. The FA Confirmed Estimate — set during configuration using live Bedrock pricing for the selected model — is the number that drives weekly Spend Cards and Estimate Coverage in the Governance Maturity model. The Product Owner's budget request is context; the FA Confirmed Estimate is the official figure both parties see in Spaces.
When the FinOps Lead approves a Business Request, FinOps Center generates every Cloud Engineer task — workload name, model ID, account, region, IAM role name, and exact CLI commands pre-populated. The engineer executes what was decided. They never author a policy or make a governance decision.
Engineering Tracking — every approved Business Request generates tasks with type, model, account, region, and step progress pre-populated.
Confirm the model is accessible in the target account and region. AWS CLI command provided.
Role name auto-generated: finops-{workloadName}-{4charId}. The IAM role is the attribution anchor — it is what makes line_item_iam_principal appear in CUR.
Apply the generated policy with bedrock:InvokedModelId condition key scoped to the approved model ARN. Exact CLI command provided.
Task complete. Audit record created. Product Owner can now claim the role in Spaces for spend attribution.
MAP tasks are separate. For workloads eligible for MAP migration credits, a dedicated MAP Tag task creates an Application Inference Profile tagged map-migrated=mig{MPEID} — independent of the Enable Access flow. See AI MAP & Migration Tracking for the full MAP task lifecycle.
Task detail — platform, approval rationale, step progress, and CLI commands pre-written for each step. The engineer executes. They author nothing.
A single code deployment or new prompt template can 10x token consumption overnight. By the time a monthly invoice surfaces the spike, four weeks of unbudgeted spend have already happened. FinOps Center generates a Spend Card for every claimed workload every week — actuals vs estimate, broken down by model, region, and token type.
Compute, storage, and network costs change slowly and predictably. Drift is gradual and visible in trend data. A monthly invoice review is workable.
Token consumption can spike overnight. A new prompt template, a new user cohort, a code change — all can 10x spend before the next monthly review. Weekly Spend Cards catch variance when it's still recoverable.
The Product Owner sets a token or dollar estimate before spend begins. Budget intent is captured before a single API call. The application that invokes the model is the only party that knows how often it calls, with what prompt sizes, and whether caching is in play — so the estimate sits with whoever owns the workload.
Actuals vs estimate every week, broken down by model, token type (input / output / cache-read), and region. Variance is flagged automatically. Overspend draws attention without blocking the workload — the goal is accountability, not a gate.
Product Owner accepts the card if spend matches expectations — or disputes with flagged lines routed back to the FinOps Lead. Portfolio Owner approves the rollup. Finance gets a chargeback-ready record every week, not every quarter.
FinOps Center measures AI governance across four categories, each rated on a Not Started → Crawl → Walk → Run scale. A category that's Crawling isn't failing — it's at an early, often perfectly acceptable, stage. The rating shows where you are and what moves you forward. Each dimension shows what closing its gap is worth in attributed dollars.
The practice isn't established yet for this category. AI spend is happening without the governance step in place.
The basics are forming; coverage is partial. The practice has begun — not yet consistent across your AI estate.
The practice is working for most of your AI spend. You can answer "who owns this?" for the majority of your AI cost.
The practice is the default — it happens automatically. You're optimizing, not chasing.
Maturity tier definitions aligned to the FinOps Foundation framework · Overall maturity is a weighted blend of the four category scores.
AI Governance Maturity — current tier per dimension with the next advancement move. Each gap shows what closing it is worth in attributed dollars.
The percentage of AI spend attributed to a specific workload owner — where FinOps Center can answer "which application, and which budget owner, is responsible for this?" Attribution turns "this account spent $50K on AI" into "the Customer Support Bot spent $30K, the Document Platform spent $20K."
The percentage of active AI models that are approved for use, enabled in the accounts and regions where they're running, and free of governance gaps. Before governance, any developer could call any model in any account with no approval and no accountability. Model Governance is the gate.
The percentage of claimed AI workloads with a budget estimate set — a forward-looking figure for what the workload is expected to cost. An estimate lets a Product Owner course-correct mid-period instead of learning about overspend at quarter-end. A workload with no estimate is spend with no plan.
How quickly governance work moves from Business Request submission through FinOps Lead approval and Cloud Engineer enablement to a claimed, live workload. Governance that's slow becomes governance that gets bypassed — keeping the cycle short is what keeps the whole model credible.
Example action: Closing 14 Allocation Gaps advances Workload Attribution from Crawl to Walk — attributing $620K of unattributed AI spend to named budget owners and enabling Spend Cards for 15 additional workloads.
CUR data, IAM principals, token billing, inference profiles — none of that should land on a Product Owner or Portfolio Owner. Agent Bill absorbs the complexity and returns plain language answers, scoped to each person's role and financial hierarchy. No dashboards. No AWS knowledge required.
“Am I tracking on or over my token estimate this period?”
Your Engineering AI Assistant workload has consumed $198 of your $340 monthly estimate — 58% through the month at 67% of budget. You're tracking well. Cache hit rate is 22%, which is healthy for a coding workload. Daily trend is flat for the last 5 days.
“Which of my Products has the highest AI cost this month?”
The Customer Support Bot is leading at $4,840 this month — up 23% from last month, driven by a 15% increase in invocations and a shift toward Claude Opus 4.7. The Document Platform is second at $2,100. Both have confirmed estimates and claimed roles. No Allocation Gaps on either.
“Are any of my workloads using models that aren't approved?”
Yes — 2 Allocation Gaps this week. Claude Opus 4.7 has 140 invocations from the checkout-service role in Pre-Prod with no approved Business Request: No Budget Allocation. Nova Lite has 8 invocations from an unclaimed finops-ai role in the data-science account: Unclaimed Workload. Both need action in the Allocation Gaps tab.
If a workload is consuming way over budget and needs to stop immediately, the Product Owner types the request into Agent Bill. A single MCP action fans out: the IAM role is tagged, an SCP fires on the next Bedrock call, spend stops within seconds — before CUR has even registered the spike. FinOps Center surfaces the workload as SUSPENDED with a full audit record. The FinOps Lead reviews and resumes when investigation is complete.
When AI spend moves in unexpected ways — a spike in a single hour, a new IAM principal appearing in an account with no Business Request, a model suddenly consuming 10× its baseline — FinOps Center surfaces it as an Investigation. The FinOps Lead reviews the signal, assigns it to an owner, or links it to an existing Allocation Gap. Nothing falls through the cracks between weekly Spend Cards.
Allocation Gaps are not compliance violations. They are attribution gaps that prevent Finance from answering “who owns this spend?” FinOps Center detects six gap scenarios and routes each to the right action — without leaving the governance view.
When two budgets share an AWS account, every Bedrock dollar is split evenly regardless of who made the call. When a workload's IAM role is claimed, that spend exits the shared pool and flows 100% to the right budget. Without workload-level attribution, shared accounts systematically mischarge non-AI budgets for AI spend — and nobody has the data to correct it.
Most enterprise CUR exports were created before line_item_iam_principal existed. This field GA'd in April 2025 and requires opt-in on the CUR 2.0 export settings — existing exports cannot be retroactively updated. Without it, no AI attribution works. Most enterprise CUR exports were created before this feature existed, making it the most common starting point for organizations beginning the governance journey.
FinOps Center validates this at onboarding and surfaces it as a blocking task before anything else proceeds. One new CUR export with Include caller identity selected unlocks workload attribution across your entire AI estate.
The account has not enabled the line_item_iam_principal feature in CUR export settings. Every Bedrock dollar is unattributable at the workload level.
The caller is known — AWSAdministratorAccess or AWSPowerUserAccess — but the workload is not. This is not a security issue. The gap is that spend cannot be routed to a specific budget.
A model is being called in AWS with no corresponding Business Request in FinOps Center. The invocations are real, the cost is real, and no Product Owner has a workload claim.
The model has an approved Business Request, but CUR shows usage in an account or region not included in the original approval.
A finops-ai-* IAM role was created through the CE task workflow and has spend in CUR, but no Product Owner has claimed it in Spaces.
Guardrail rows never emit line_item_iam_principal — the Guardrail ARN is the only attribution anchor. Spend is real but unassigned to any workload.
Every gap has a status lifecycle. When a FinOps Lead actions a gap — approving, assigning, creating a Business Request — the record moves from Active to Actioned to Resolved. If circumstances change, a decision can be Recalled and revisited. The original decision is never deleted.
Every action carries a timestamp, rationale, and the identity of the person who made it. Finance gets an audit trail, not just a snapshot. These are allocation gaps — not compliance violations. The goal is always attribution: connecting every AI dollar to a budget owner.
FinOps Center deploys inside your AWS account via AWS Marketplace. This is not a positioning claim — it is an architectural fact that AWS formally recognizes with the Deployed on AWS Marketplace badge, enabling PPA/EDP spend retirement eligibility for enterprise buyers.
AI attribution data, model approvals, IAM role assignments, and spend cards all live in an account you control. No cross-account IAM to a vendor.
Your billing metadata never lands in a vendor database. No compliance review required. No vendor lock-in on your own billing data.
Deployed on AWS badge means FinOps Center spend counts toward your AWS committed spend — unlike SaaS FinOps tools that don't retire EDP.
| Capability | FinOps Center | Vantage / nOps / Finout |
|---|---|---|
| Deployed in customer AWS account | ✓ | ✗ |
| Workload-level AI attribution | ✓ | ✗ |
| Model approval governance workflow | ✓ | ✗ |
| Business Request → CE Task → PO Claim | ✓ | ✗ |
| Shared account chargeback accuracy | ✓ | ✗ |
| AI Governance Maturity model (Crawl / Walk / Run) | ✓ | ✗ |
| Allocation Gaps detection (6 scenarios) | ✓ | Partial |
| Claude Platform (CCU) support | ✓ | ✗ |
| PPA/EDP spend retirement eligibility | ✓ | ✗ |
The FinOps Lead selects the platform at Business Request review time. The governance model — submission, approval, task generation, and Agent Bill attribution — is identical across all three. The implementation and attribution mechanics differ.
IAM principal attribution via CUR 2.0. FinOps Center auto-generates the IAM role name and CLI commands. Two workload paths: Operations (dedicated role) and Coding (IAM Identity Center + session tags).
Third-party foundation models accessed through AWS Marketplace via Bedrock — including models from Anthropic and other providers. Each provider bills as their own legal entity in CUR, separate from native Bedrock charges. IAM principal attribution applies the same way: the workload's dedicated role appears in line_item_iam_principal for every inference call.
Claude Platform bills in Claude Consumption Units (CCU) via AWS Marketplace. The workspace is the allocation unit — each workspace maps to a portfolio or product team via CUR tags. The FinOps Lead names the workspace at Business Request approval time. The Cloud Engineer creates it via a 3-task chain.
One Athena query against your own CUR. No AWS access required from us. We score your AI Governance Maturity across four dimensions and deliver a clear action plan within 24 hours — so your teams can move fast with every workload governed from day one.
Complimentary · Your data stays in your account · Roadmap within 24 hours