Allocation Gaps
Role: FinOps Lead Location: AI Governance → Allocation Gaps
Allocation Gaps shows AI spend detected in CUR that cannot be attributed to a workload or budget owner. Gaps are detected nightly by comparing CUR spend against the set of approved ModelApprovalScopes and claimed IAM roles. Every gap represents spend that Finance cannot route to a specific owner.
This page is for the FinOps Lead. Product Owners do not see Allocation Gaps — if spend attributed to their workload appears here, they are notified via the Unclaimed Workload action flow.
Reading the Gaps Page
Scenario pills — At the top of the page, six pills show the count of Active gaps by scenario. A pill with a count greater than zero appears in red. Click any pill to filter the table to that scenario.
Total unattributed cost — The total estimated monthly cost of all Active gaps is displayed right-aligned above the table as $X,XXX/mo unattributed. This is the total spend that cannot currently be routed to a budget owner.
Status tabs — Filter the table by gap status: Active (default), Actioned, Resolved, Recalled, or All.
The Six Gap Scenarios
Attribution Not Enabled
Bedrock spend is appearing in CUR for this account but line_item_iam_principal is not populated. The account has not enabled the IAM principal feature in CUR export settings. Without this, no workload-level attribution is possible for any spend in this account.
Action: Click Enable Attribution →. This opens the AWS CUR Data Export settings page for the account in a new tab. Enable the line_item_iam_principal field in the export configuration and save. Return to FinOps Center and click Action Gap with a rationale noting the change was made. The gap will resolve on the next nightly CUR refresh after the export setting propagates.
Unattributed Spend
An IAM principal is present in CUR but it is a broad SSO role — for example, AWSAdministratorAccess or AWSPowerUserAccess. The caller is identified but the workload is not. This is not a security issue — the role is authorized to call Bedrock. The gap is that the spend cannot be routed to a specific workload or budget owner.
Action: Click Create Business Request →. This prompts the Product Owner who owns this usage to submit a Business Request in Spaces using a dedicated workload IAM role. Copy the Gap ID shown in the info modal and share it with the Product Owner so they can reference it in the Business Request. Once the Product Owner claims a dedicated role, the spend moves from the broad SSO principal to the workload-specific role and this gap resolves.
No Budget Allocation
The model is being invoked in this account and region but there is no approved Business Request on record for this (account × region) combination. There is no budget owner for this spend.
Action: Click Approve or Block →. This opens the model approval modal pre-filtered to the affected product code. You can approve the model for the account and region — which generates Cloud Engineer tasks and starts the onboarding workflow — or block the model for this account.
Out of Budget Scope
The model is approved and implemented, but CUR shows usage in an account or region that is outside the approved ModelApprovalScope. The usage is not within any approved (account × region) combination.
Action: Click Add Scope →. This opens the model's approval scope modal with the out-of-scope account and region pre-filled. Review whether the usage is legitimate. If it is, add the account and region to the approved scope — this generates a Cloud Engineer task for the new scope. If it is not legitimate, block the model for that account and region and investigate the source of the calls.
Unclaimed Workload
A dedicated finops-ai-* IAM role exists with spend attributed to it in CUR, but no Product Owner has claimed it in Spaces. The role was created by a Cloud Engineer (and is therefore within the governed path) but the workload setup in Spaces is incomplete.
Action: Click Notify Product Owner →. A confirmation modal appears showing the workload ID associated with the role. Confirming calls the gap action with the rationale "Notified PO to claim role." Contact the Product Owner for the workload and direct them to the Workload Setup steps in Spaces to claim the role and set an estimate. The gap resolves once the role is claimed.
Unallocated Guardrail Cost
A Bedrock Guardrail ARN appears in CUR with spend but no workload claims ownership. Guardrail rows do not emit line_item_iam_principal — the Guardrail ARN is the only attribution anchor available.
Action: Click Assign to Workload →. An assignment modal appears. Enter the workload ID that should own this Guardrail cost and a rationale for the assignment. This links the Guardrail ARN to the workload in the allocation model. The gap resolves after the next nightly attribution run.
Taking Action on a Gap
Scenario-specific action buttons
Use the labeled action button on each row (described per scenario above). These are the fastest path to resolution for each gap type.
Action Gap (generic)
Every Active gap also has an Action Gap button. This opens a modal with a single rationale field. Use this when you have taken a remediation step outside FinOps Center — for example, disabling a Bedrock model directly in the AWS console — and want to record that action against the gap. A rationale is required. Submitting moves the gap to Actioned status.
Recalling an Actioned Gap
If you actioned a gap in error, or the remediation step needs to be reversed, click Recall on any Actioned gap. Enter a reason for the recall. The gap status changes to Recalled and a new audit record is created. The original action record is preserved — it is never deleted. A recalled gap can be re-actioned.
Gap Detail Drawer
Click any row to open the Gap Detail Drawer. The drawer shows:
Gap Summary — Gap ID, scenario, account, region, product code, IAM principal (or "Not available for this scenario"), resource ARN, estimated monthly cost, and detection timestamp.
Attribution Note — An explanation specific to this scenario describing exactly why this spend cannot be attributed and what the gap means.
Audit Trail — Every action taken on this gap, in reverse chronological order (newest first), showing the action type, the actor, the timestamp, and any note recorded.
Gap Status Lifecycle
Active
Gap detected by nightly run; no action taken
Actioned
FinOps Lead has recorded a remediation step
Resolved
Nightly run confirms the spend is now attributed; gap closes automatically
Recalled
A previous Actioned decision was reversed
Gaps resolve automatically when the nightly attribution run no longer detects the condition. You do not need to manually resolve a gap — once the underlying CUR data changes (attribution enabled, role claimed, scope added), the gap status will move to Resolved on the next nightly run.
Last updated