Cost governance across workloads

Why Fabric cost drifts

A Fabric capacity is a shared, largely fixed cost (you pay for the SKU whether it's busy or idle), consumed by many teams and workloads at once. Without governance the result is predictable: one big bill nobody can attribute, a capacity oversized 'to be safe', and per-user Pro licences bought alongside a capacity that could have covered them for free.

The levers

• Capacity-per-team / chargeback — assign separate capacities (or use the metrics app's per-item attribution) so each department's CU consumption is visible and can be charged back. Attribution is what changes behaviour.
• Pausing — pay-as-you-go capacities for dev/test paused outside working hours stop billing entirely.
• Reservations — reserved (one-year) capacity is materially cheaper than pay-as-you-go for steady-state production; the trade is flexibility.
• Right-sizing from metrics — resize on evidence from the Capacity Metrics app, not on fear (the monitoring concept).

The F64-vs-Pro ROI decision

The recurring cost question: for a given content set and audience, is it cheaper to buy everyone Pro or to host the content on F64+ where free users view for nothing? The break-even is F64 capacity cost vs (viewer count × Pro cost). Large read audiences flip to F64+; small ones stay Pro-per-viewer. The failure is never actually doing this maths — paying for both, or the wrong one, for years.

Failure modes

• Oversizing as insurance — permanent spend on idle CU because nobody checked the metrics.
• Pro + capacity double-pay — buying Pro for viewers who already sit on F64+ (they don't need it), or hosting a tiny audience on F64 that Pro would have covered cheaper.
• No chargeback — one shared capacity with no attribution, so no team has any incentive to tune their heavy workloads.
• Paused-when-needed / never-paused — dev capacities billing 24/7, or production paused by mistake going dark.
• Reserved on a shrinking workload — a year's commitment to capacity you've since outgrown the need for.

What to watch (proofs)

• Capacity spend map: Get-PowerBICapacity / admin/capacities for every SKU, its size and state — the fixed-cost inventory.
• Attribution: the Capacity Metrics app's per-item/per-workspace CU, reconciled via Get-PowerBIWorkspace -Scope Organization to owning teams — the chargeback table.
• The F64 maths on one page: Get-MgUserLicenseDetail viewer/Pro counts per content set vs the F64 capacity cost — the reallocation decision, quantified.
• Utilisation vs SKU: idle headroom (downsizing candidates) or chronic overload (upsizing/tuning candidates) from the metrics app.
• Idle and mis-paused capacities: pay-as-you-go capacities running near-idle, or paused capacities still assigned to production workspaces.