Lesson 7 of 8 · 11 min
Scaling, Pausing, and Reservations
Real usage has a shape. Weekday mornings are busy, nights are quiet, weekends are quieter, and month-end is different again. A Fabric capacity does not follow that shape on its own. It stays one size, billed every hour it runs, until someone changes it.
This lesson turns the shape into a cost plan with three tools: reservations for the steady part, resizing for predictable peaks, and pausing for the hours nothing needs to run.
Draw the shape first
From the Capacity Metrics app, sketch a typical week in hourly blocks:
- The floor: the lowest sustained utilization, usually overnight background work.
- The working-hours level: where the capacity sits on a normal weekday.
- The peaks: month-end, quarter-end, or known events, with their dates.
- The idle hours: when nothing important runs at all.
Each part of the shape maps to a different lever.
Reservations for the steady baseline
A Fabric reservation commits to a quantity of CUs in a region for one or three years, bought in one-CU increments. Capacity usage that matches the reservation is billed at the reserved rate instead of pay-as-you-go. Reservations cover capacity only, not storage or networking.
Two behaviors decide whether a reservation saves money:
- If the running capacity uses more CUs than you reserved, the difference is billed at pay-as-you-go. A 64-CU reservation with the capacity scaled to F128 pays the reserved rate for 64 CUs and pay-as-you-go for the other 64.
- If the running capacity uses fewer CUs than you reserved, or is paused, the unused reservation is not refunded. Scaling below the reservation does not reduce what you pay for it.
That gives you a simple break-even test. If the reservation discount is D, a reservation beats pay-as-you-go with pausing only when the capacity would run for more than roughly (1 − D) of the hours in the term. The one-year discount has been around 40% on the Fabric pricing page, which puts the break-even near 60% of hours. Check the current discount for your region before deciding.
Illustrative examples:
- A production capacity that runs every hour of the week easily clears the break-even. Reserve it.
- A development capacity that runs 12 hours a day on weekdays runs about 36% of the hours in a week. Pay-as-you-go with pausing is cheaper.
Reserve after you have optimized and measured, not before. A reservation sized on unoptimized demand locks waste into a one- or three-year commitment.
Resizing for predictable peaks
Resizing an F SKU in place changes its size without moving the workspaces assigned to it. Use it for peaks you can predict: scale up for the month-end close, then back down when it is over.
The common pattern is to reserve the working-hours level and pay pay-as-you-go for anything above it during peaks. Peaks then cost what they actually use.
Know the side effects before you schedule it:
- F64 is a licensing line. Below F64, viewers with free licenses cannot read Power BI content in the capacity. Do not scale below F64 during hours when those users work.
- License updates can lag. Scaling a capacity below F64 up to a larger size is nearly immediate for compute, but the license change can take up to a day to apply.
- Resize, do not reassign. Moving workspaces between capacities cancels their running jobs. Resizing in place usually does not.
- Mind the F256 to F512 boundary. Resizing across it, in either direction, puts the capacity through a brief transition that can cancel in-flight operations and running jobs. Do it in a quiet window and rerun anything that was canceled.
Pausing for idle hours
A paused capacity stops billing compute. Its content is unavailable until it resumes, which makes pausing ideal for development, test, training, and demo capacities, and rarely appropriate for production.
When a capacity is paused, any remaining smoothed and burst usage is billed at that moment. A paused capacity also stops throttling immediately, which is why pause and resume is useful as an emergency lever in lesson three.
Automating it
Fabric does not resize capacities based on load by itself. All automation calls the same Azure REST operations: PATCH on the capacity resource to change the SKU, and suspend and resume actions to pause and restart it.
| Approach | Driven by | Effort | Fits |
|---|---|---|---|
| Logic App on a schedule | The clock | Low | Predictable business-hours patterns |
| Azure Automation runbook | The clock | Low | Teams already using Automation |
| Timer-triggered Azure Function | The clock | Low | Scheduled scaling as code |
| Fabric Activator on capacity events | Real load | Medium | Reactive scaling inside Fabric |
Whichever you choose:
- Give the identity a custom role limited to reading, writing, suspending, and resuming the capacity. Do not give it a broad privileged role.
- Make the automation idempotent. A resume call on a running capacity, or a resize to the current size, should succeed quietly.
- Log every change and alert on failures. A scale-down that silently fails is a cost leak. A scale-up that silently fails is an incident.
- For reactive scaling, react to sustained trends in capacity events, not to a single reading. The events arrive roughly every 30 seconds on a best-effort basis.
Exercise: build the cost plan
Using your weekly shape, fill in a plan for each capacity.
| Part of the shape | Hours per week | CUs needed | Lever | Billing |
|---|---|---|---|---|
| Floor | Reserve or pause | |||
| Working hours | Reserve | |||
| Predictable peaks | Scheduled resize | Pay-as-you-go above reservation | ||
| Idle hours | Pause or minimum size |
Then estimate the monthly cost of three options using current pricing for your region: all pay-as-you-go at a fixed size, fully reserved at a fixed size, and your plan. If your plan is not the cheapest, check whether licensing or operational risk explains the difference.
Carry this forward
A cost plan only stays true while someone owns it. The final lesson turns everything in this course into an operating model: chargeback, alerts, reviews, and a runbook.