IT Admin Business Leader Data Architect Platform Owner — This page covers Fabric capacity reservations in depth: how to purchase and manage them, SKU exchange rules, overage and throttling mechanics, real-world scenarios, and cost optimization strategies.
All pricing, discount percentages, reservation policies, exchange rules, overage rates, and refund limits referenced on this page are approximate and subject to change. Microsoft may update pricing, terms, and policies at any time. Actual costs vary by region, currency, enterprise agreement, and negotiated terms. This guide is for informational and planning purposes only — always verify current pricing and policies on the official Microsoft Fabric pricing page and consult your Microsoft account representative before making financial commitments.
Understanding Fabric Reservations
Commit to capacity for predictable pricing and significant savings over pay-as-you-go rates.
A Microsoft Fabric capacity reservation is a commitment to a fixed number of Capacity Units (CUs) for either 1 or 3 years in exchange for a substantial discount versus pay-as-you-go pricing. Reservations cover compute only — you purchase a specific F SKU (F2 through F2048), each of which maps to a defined number of CUs, and all Fabric workloads consume from that single CU pool.
This is one of Fabric's most powerful cost features: every workload — Spark notebooks, SQL analytics, Power BI reports, Data Factory pipelines, Real-Time Intelligence streams — draws from the same pool of CUs. There is no separate billing meter per engine. A reservation secures a block of CUs at a fixed rate, and any workload running on that capacity benefits from the discounted compute.
Why Reserve?
- ~41% savings with a 1-year or 3-year commitment vs. pay-as-you-go
- Predictable monthly billing — no surprises from variable compute usage
- Budget certainty — finance teams can forecast Fabric spend accurately
F64 and above include Power BI viewer access without requiring per-user Pro or PPU licenses. This can represent significant additional savings for organizations with many report consumers. Below F64, each viewer still needs a Pro license or PPU license.*
*Per-user license pricing varies by region and agreement. Check the Power BI pricing page for current rates.
Pricing Models Compared
💳 Pay-As-You-Go
Billed per-second for actual CU consumption. No commitment required. Full flexibility to pause, scale, or delete capacity at any time. Best for variable workloads, dev/test environments, or when you're still sizing your needs.
When to use: Unpredictable usage, short-term projects, non-production workloads, or initial evaluation period.
📅 1-Year Reserved
Commit to a specific F SKU for 12 months. Pay upfront or monthly at a ~41% discount vs. PAYG. Can exchange for a different SKU size at any time (new term starts). Auto-renewal available.
When to use: Established production workloads with predictable consumption. Good balance between savings and flexibility.
📆 3-Year Reserved
Commit to a specific F SKU for 36 months. Same ~41% discount as 1-year — currently there is no additional discount for the longer term. Same exchange flexibility as 1-year. The benefit is locking in today's price for 3 years, protecting against future price increases.
When to use: Mature, stable production environments where you want long-term price certainty and are confident capacity needs won't decrease significantly.
A reservation covers Capacity Units (compute) only — OneLake storage and networking (egress) are always billed separately at pay-as-you-go rates, regardless of your reservation status. Factor storage costs into your total Fabric budget.
How Reservations Work
Purchasing, scoping, billing mechanics, and lifecycle management for Fabric capacity reservations.
Purchasing a Reservation
Fabric capacity reservations are purchased through the Azure Portal, not through the Fabric admin portal or Microsoft 365 admin center. The process is straightforward:
- Navigate to Azure Portal → Reservations → Add → Microsoft Fabric
- Select the Azure region where your Fabric capacity will run (must match your capacity's region)
- Choose the F SKU size (F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048)
- Select the term: 1 year or 3 years
- Choose billing frequency: pay the full amount upfront or spread it monthly (same total cost either way)
- Configure the scope (see below) and complete the purchase
Scoping Options
The reservation scope determines which Fabric capacities can receive the reservation discount. Choose carefully based on your organizational structure:
🎯 Single Resource Group
The reservation discount applies only to Fabric capacities in the specified resource group. Use when you have strict resource isolation per team or project and want to prevent cross-charging.
📋 Single Subscription
The discount applies to any Fabric capacity within the selected Azure subscription. The most common choice for organizations with one subscription per environment (prod, dev, etc.).
🌐 Shared Scope
The discount applies across all subscriptions within the billing context (EA enrollment or billing account). Maximizes utilization — if one subscription's capacity is paused, the unused CU credits automatically apply to another subscription's capacity. Recommended for multi-subscription enterprises.
🏢 Management Group
Scopes the discount to all subscriptions under a specific Azure management group. Useful for large organizations that use management groups to organize subscriptions by division or geography.
Billing Mechanics
Reservation charges are deducted from your EA Azure Prepayment (formerly called Monetary Commitment) balance if you have an Enterprise Agreement. For MCA (Microsoft Customer Agreement) or CSP subscriptions, charges are billed to the subscription's payment method. The reservation discount is applied automatically — any matching Fabric capacity in the configured scope receives the discounted rate without manual intervention.
Auto-Renewal
You can enable automatic renewal on any reservation. When enabled, Azure automatically purchases a replacement reservation at expiry with the same attributes (SKU, region, scope). You can modify the renewal configuration at any time to change the billing frequency, term length, or quantity. This prevents accidental gaps in coverage that would revert to pay-as-you-go rates.
When a reservation expires without auto-renewal, your Fabric capacity continues running without interruption — workloads are not stopped or paused. However, billing immediately reverts to full pay-as-you-go rates, losing your ~41% reservation discount. Set a calendar reminder 2-3 months before expiry to review and renew or exchange.
Check Your Current Reservations
az reservations reservation-order list \ --query "[?contains(displayName,'Fabric')]" \ --output table
az consumption reservation summary list \ --reservation-order-id <order-id> \ --grain daily \ --start-date 2024-01-01 \ --end-date 2024-01-31 \ --output table
SKU Exchange Rules
Everything you need to know about exchanging Fabric capacity reservations — upgrades, downgrades, financial impact, and constraints.
Yes! Microsoft supports exchanging Fabric capacity reservations for different SKU sizes at any time during your reservation term. You can upgrade (F64 → F128), downgrade (F128 → F64), or migrate from legacy P SKUs (P1 → F64). The exchange process is handled through the Azure Portal with prorated financial adjustments.
Exchange Rules in Detail
1. Full Reservation Exchange Only
You cannot split a reservation. The entire reservation is exchanged as a single unit. For example, you cannot exchange one F128 reservation into two F64 reservations. If you need multiple smaller capacities, you would need to cancel (subject to refund limits) and purchase new reservations separately.
2. New Term Starts
Every exchange creates a brand-new 1-year or 3-year commitment at the then-current pricing for the target SKU. This is true for both upgrades and downgrades. Even exchanging an F64 for a smaller F32 resets the clock — you're committing to a full new term.
3. Prorated Credit
The unused portion of your current reservation is calculated on a daily prorated basis and credited toward the new reservation. If you're upgrading, you pay the difference. If you're downgrading, the excess credit is applied to the new reservation (effectively pre-paying some of the new term).
4. Repeatable
There is no limit on the number of exchanges. If you exchange from F64 to F128 and later realize F256 is needed, you can exchange again. Each exchange starts a new term with fresh prorated calculations.
5. No Direct Refunds Without Exchange
Reservations generally cannot be cancelled for a cash refund. Microsoft enforces a $50,000 USD rolling 12-month refund cap across all reservation types. The exchange mechanism is the primary way to adjust your reservation — it doesn't count against the refund cap because you're swapping, not cancelling.
6. P-SKU Migration
Legacy Power BI Premium SKUs (P1, P2, P3, P4, P5) can be exchanged for equivalent Fabric F SKUs using the same process. P1 → F64, P2 → F128, P3 → F256, P4 → F512, P5 → F1024. Prorated credit applies identically.
Exchange Scenarios at a Glance
| Scenario | Allowed? | Effect on Term | Financial Impact |
|---|---|---|---|
| F64 → F128 (Upgrade) | ✅ Yes | New 1/3-year term | Prorated unused value credited |
| F128 → F64 (Downgrade) | ✅ Yes | New 1/3-year term | Prorated unused value credited |
| F64 → 2×F32 (Split) | ❌ No | N/A | Must exchange entire reservation |
| Cancel for refund | ⚠️ Limited | N/A | $50K/12-month rolling cap |
| P1 → F64 (Migration) | ✅ Yes | New term | Prorated value credited |
Suppose you purchased a 1-year F64 reservation at ~$5,003/month ($60,036/year):
- After 6 months, you've consumed $30,018 of value
- Remaining unused value: ~$30,018 (prorated daily)
- New F128 reservation costs ~$10,005/month ($120,060 for a new 1-year term)
- The $30,018 credit is applied to the new F128 reservation
- Net amount owed: ~$90,042 for the full new 1-year F128 term
The credit reduces your effective cost, but you are committing to a full new year at the F128 rate.
*All dollar amounts are illustrative, based on approximate US East region pricing at time of writing. Actual figures vary by region, currency, and enterprise agreement. Verify on the official pricing page.
An exchange always starts a NEW term. If you exchange an F64 for an F128 at month 6, you're committing to a full new 1-year (or 3-year) term for F128 — not just the remaining 6 months of your original reservation. Plan exchanges carefully and factor in the full financial commitment of the new term.
Overage & Throttling Mechanics
What happens when your workloads exceed reserved capacity — smoothing, bursting, throttling stages, and the overage billing option.
A common question: "What happens if I have an F64 reserved and my workloads need more compute?" The answer involves a multi-stage system designed to absorb short spikes gracefully while protecting capacity from sustained overload.
Step 1: Smoothing
Fabric does not enforce CU limits on a per-second basis. Instead, it smooths consumption over rolling time windows, allowing bursts of activity without immediate penalty:
- Interactive operations (Power BI queries, ad-hoc SQL, on-demand previews): smoothed over a 5 to 64-minute window, depending on the operation type
- Background operations (scheduled refreshes, Spark notebook jobs, Data Factory pipelines): smoothed over a 24-hour rolling window
This means a Spark job that briefly spikes to 3× your reserved CUs for 10 minutes will be averaged against periods of lower usage. If your average consumption over the smoothing window stays within your reserved CUs, no throttling occurs.
Step 2: Bursting
If your smoothed consumption temporarily exceeds your reserved CUs, Fabric allows bursting — your workloads continue running at full speed with no additional charges. Bursting is designed to handle legitimate short-term spikes (e.g., a large Power BI report rendering, a complex query, or a batch of concurrent refreshes) without penalizing users. There is no explicit "burst limit" — the smoothing algorithm naturally handles this.
Step 3: Throttling Stages
When sustained consumption exceeds your reserved CUs beyond what smoothing can absorb, Fabric progressively throttles operations through four stages:
Step 4: Capacity Overage
As an alternative to throttling, Fabric offers an opt-in overage billing model. When enabled, workloads that exceed your reserved CUs are allowed to continue running, and the excess consumption is billed at a premium rate.
- How it works: Fabric lets operations continue beyond reserved CUs and charges the excess at a premium overage rate
- Admin-controlled cap: The capacity admin sets a maximum overage limit (in CUs or dollars) to prevent runaway costs
- Only excess billed: Only CUs consumed above the reservation are billed at the overage rate — your reserved CUs remain at the committed rate
- Fallback to throttling: If workloads exceed both the reserved capacity AND the overage limit, throttling resumes as described above
Overage billing is significantly more expensive than standard pay-as-you-go rates. It is designed as a safety net for occasional spikes, not a permanent scaling strategy. Exact overage pricing is subject to change — always check the official Fabric pricing page for current rates. If you're consistently using overage, it's more cost-effective to exchange your reservation for a larger SKU.
The Payback Effect
An important and often surprising concept: after a period of heavy CU overuse, throttling may persist even after you stop all workloads. This is the "payback effect."
Here's why: the overconsumed CUs accumulated during the spike are still being counted in the smoothing window. Even with zero active workloads, the historical overconsumption needs time to "burn down" before the capacity returns to a healthy state. For background operations with a 24-hour smoothing window, payback can last up to 24 hours.
If you see throttling persisting after stopping heavy jobs, this is the payback effect. Wait for the smoothing window to clear — up to 24 hours for background operations or approximately 1 hour for interactive operations. During this period, reduce or defer non-critical workloads to help the capacity recover faster.
Real-World Scenarios
Practical decision-making guidance for common reservation and capacity challenges.
Scenario 1: "I have F64 reserved and need more compute for a big project"
Situation: Your team is starting a major data migration project that will run for 3 months and requires F128-level capacity. You currently have an F64 reservation with 6 months remaining on a 1-year term.
🎯 Options
- Exchange F64 → F128 reservation: Commits to a new 1-year term at F128 pricing, but you get ~41% savings over PAYG. The prorated unused F64 value is credited. Best if you expect sustained need for F128 beyond the 3-month project.
- Keep F64 reserved + add a separate F64 PAYG capacity: More flexible — you can delete the PAYG capacity after the project ends. No new commitment, but the additional CUs are at full PAYG rates. Assign migration workloads to the PAYG capacity specifically.
- Enable capacity overage on F64: Simplest to configure, but the ~3× PAYG overage rate makes this expensive for sustained use over 3 months. Only viable if the overage is modest and intermittent.
✅ Recommendation
If the need is sustained (months), exchange to F128 for the reservation discount. If temporary (days/weeks) and unpredictable, add a PAYG capacity alongside your reservation. Avoid overage for sustained heavy use — the 3× premium adds up fast.
Scenario 2: "Seasonal spike — Black Friday / end-of-quarter reporting"
Situation: Your organization experiences predictable 2-week spikes every quarter — end-of-quarter financial reporting, Black Friday analytics, or year-end data processing — where CU consumption roughly doubles.
🎯 Options
- Enable overage with a cap: Simple to configure. Set a CU or dollar cap. But the ~3× premium rate for 2 weeks of doubled usage is expensive.
- Spin up a temporary PAYG capacity: Create a second Fabric capacity at F64 PAYG, assign spike workloads to it, then pause or delete it when the spike ends. Standard PAYG rate (1× rate) is much cheaper than overage (3× rate).
✅ Recommendation
For known, predictable spikes, a temporary PAYG capacity is almost always cheaper than overage billing. Pre-create the capacity and pre-assign workspaces before the spike begins. Automate creation/deletion with Azure CLI or IaC if this is a recurring pattern.
Scenario 3: "Migrating from Power BI Premium P1 to Fabric F64"
Situation: Power BI Premium P SKUs are being retired. You have a P1 reservation and need to migrate to a Fabric F SKU.
📋 Migration Process
- Go to Azure Portal → Reservations and locate your P1 reservation
- Select Exchange and choose F64 as the target (P1 = F64 in CU equivalence)
- Review the prorated credit and new term commitment
- Complete the exchange — your P1 reservation is replaced with an F64 reservation
🔑 Key Differences
P1 and F64 are equivalent in CU capacity, but Fabric F64 unlocks the full Fabric workload spectrum — Spark, Data Factory, Real-Time Intelligence, Data Warehouse, and more — in addition to Power BI. The compute pool is shared across all engines, so existing Power BI workloads may experience different performance characteristics if other Fabric workloads are introduced on the same capacity.
⚠️ Important
Test before exchanging. Use a Fabric trial capacity or a short-term PAYG capacity to validate that your existing Power BI reports, dataflows, and datasets perform acceptably on Fabric before committing to the exchange. Pay special attention to semantic model refresh times and query performance under concurrent load.
Scenario 4: "Heavy overnight ETL causing morning dashboard slowdowns"
Situation: Large Spark notebook jobs and Data Factory pipelines run overnight, consuming massive amounts of CUs. When morning users open Power BI dashboards, they experience slow load times, delays, or even "Interactive Delay" throttling messages.
🔍 Root Cause
Background operations (ETL jobs) are smoothed over a 24-hour rolling window. If overnight jobs consumed a large portion of the daily CU budget, the carryforward from that consumption reduces the effective CUs available for interactive operations in the morning. The smoothing algorithm doesn't "reset" at midnight — it's a continuous rolling window.
🎯 Solutions
- Stagger ETL jobs: Instead of running all pipelines at 2 AM, spread them across the night (11 PM through 6 AM) to flatten CU consumption peaks
- Optimize Spark settings: Tune executor count, memory allocation, and parallelism to reduce per-job CU consumption. Smaller, more efficient jobs mean less carryforward
- Separate capacities: Place ETL workloads on a dedicated PAYG capacity and BI workloads on the reserved capacity. This provides complete isolation but increases cost
- Upgrade SKU: If the total CU demand (ETL + BI) consistently exceeds the current SKU, exchange up to a larger reservation
💡 Tip
Use the Capacity Metrics App to identify exactly which items (notebooks, pipelines, datasets) are consuming the most CUs overnight. Often, a single poorly optimized Spark job accounts for the majority of background CU consumption. Fixing that one job can resolve morning throttling without needing a SKU upgrade.
Scenario 5: "Multi-team capacity — one large or multiple small reservations?"
Situation: Three teams (Data Engineering, BI Analytics, Data Science) each need approximately F32-equivalent capacity. Should you provision one shared capacity or separate ones?
🎯 Options
Option A: Single F128 Shared
Pros: Better overall utilization (teams rarely spike simultaneously), cost efficient (one reservation discount), simpler management.
Cons: "Noisy neighbor" risk — one team's heavy job can throttle another team's interactive queries. Requires governance via workspace-level surge protection.
Option B: Three Separate F32
Pros: Complete workload isolation, independent throttling domains, clear cost attribution per team.
Cons: More expensive total (3× F32 > 1× F128 after reservation discount), each team has less burst headroom, and F32 is below the F64 threshold for Power BI viewer access.
Option C: F64 Reserved + F32 PAYG
Pros: Compromise — reservation discount on primary capacity, flexibility for overflow. Meets F64 Power BI threshold on main capacity.
Cons: F32 PAYG portion is at full rate. Still requires workspace assignment decisions.
✅ Recommendation
Start shared with a single larger capacity. Use Fabric's workspace-level surge protection settings to prevent any single workspace from consuming more than its fair share. Monitor for 4-6 weeks using the Capacity Metrics App. Only split into separate capacities if you observe persistent SLA conflicts between teams that governance controls cannot resolve.
Cost Optimization
PAYG vs. reserved break-even analysis and practical strategies to minimize Fabric spend.
PAYG vs. Reserved Break-Even Analysis
The key question: at what utilization level does a reservation save money? The rule of thumb is straightforward: if your capacity runs more than ~60% of the time (or ~60% of CU utilization consistently), a 1-year reservation is cheaper than pay-as-you-go. Below that, PAYG with pausing is more cost-effective.
| Usage Pattern | PAYG Monthly | 1-Year Reserved | 3-Year Reserved | Best Option |
|---|---|---|---|---|
| Always-on (100%) | $8,410 | $5,003 | $5,003 | Reserved (1 or 3-Year) |
| Business hours (60%) | $5,046 | $5,003 | $5,003 | Reserved (1 or 3-Year) |
| Variable (40%) | $3,364 | $5,003 | $5,003 | PAYG |
| Dev/Test (20%) | $1,682 | $5,003 | $5,003 | PAYG + Pause |
*F64 SKU, approximate USD (US East region). PAYG amounts assume capacity is paused when not in use. Prices vary by region, currency, and enterprise agreement — verify on the official pricing page before making decisions.
Key Cost Optimization Strategies
📊 Right-Size Before Reserving
Run PAYG for 1-2 months to understand your actual CU consumption patterns before committing to a reservation. Use the Capacity Metrics App to identify peak usage, average utilization, and throttling frequency. It's much easier (and cheaper) to right-size before committing than to exchange later.
⏸️ Pause Non-Production Capacities
Dev/test/sandbox capacities should be paused outside business hours and weekends. PAYG billing stops when a capacity is paused (you only pay for the minutes it runs). Reservations, however, keep billing whether paused or running — so never reserve dev/test capacity unless it runs 24/7.
🌐 Use Shared Scope
If you have multiple Fabric capacities across Azure subscriptions, configure reservations with "shared scope" so unused CU credits automatically apply across subscriptions within your billing context. This maximizes reservation utilization and prevents waste from idle capacities.
📈 Monitor Utilization Continuously
Use the Capacity Metrics App to track actual vs. reserved CU consumption weekly. If utilization is consistently below 50%, consider exchanging down to a smaller SKU. If consistently above 80% with throttling events, exchange up before performance impacts accumulate.
🔀 Separate Hot and Cold Workloads
Put always-on production workloads on reserved capacity for the discount. Use PAYG for variable dev/test environments and burst/overflow workloads. This "hot/cold" split maximizes reservation value while maintaining flexibility for unpredictable usage.
🔄 Configure Auto-Renewal
Set up auto-renewal on all production reservations to avoid accidental gaps in coverage. When a reservation expires without renewal, billing immediately reverts to full PAYG rates, losing the ~41% reservation discount. Review renewal settings 2-3 months before expiry to right-size if needed.
Monitoring & Management
Tools and practices for tracking CU consumption, identifying throttling, and managing reservation lifecycle.
Capacity Metrics App
The Microsoft Fabric Capacity Metrics App is the essential tool for understanding how your capacity is being consumed. It provides granular visibility into CU utilization by workspace, item type, user, and time period — critical for validating your reservation sizing and identifying optimization opportunities.
Key metrics to monitor:
- CU utilization % — overall consumption relative to your reserved/provisioned CUs
- Throttling events — frequency and severity of Interactive Delay, Interactive Rejection, and Background Delay events
- Top consumers — which workspaces, items, and users are driving the most CU consumption
- Background vs. interactive split — ratio of scheduled/background CU usage vs. interactive queries
- Overages — periods where consumption exceeded reserved CUs and the duration of each spike
1. Open Power BI → Apps → Get apps 2. Search "Microsoft Fabric Capacity Metrics" 3. Install and connect to your capacity 4. Configure the capacity ID and date range 5. Review the Overview, Throttling, and Top Items tabs
Azure Portal Reservation Management
All reservation lifecycle operations are managed through the Azure Portal:
- View all reservations: Azure Portal → Reservations → filter by "Microsoft Fabric"
- Check utilization: Select a reservation → Utilization tab shows daily and cumulative usage vs. committed CUs
- Exchange: Select a reservation → Exchange → choose new SKU → review prorated credit → confirm
- Configure auto-renewal: Select a reservation → Renewal → toggle on and configure new term attributes
- Change scope: Select a reservation → Configuration → modify scope (single subscription, shared, management group)
When to Exchange Up
Warning signs that your current reservation is undersized and you should consider exchanging to a larger SKU:
🟡 Consistent Throttling Events
If the Capacity Metrics App shows Interactive Delay or Interactive Rejection events occurring during business hours on a regular basis (multiple times per week), your capacity is undersized for the interactive workload.
📊 CU Utilization >80%
Peak-hour CU utilization consistently above 80% after smoothing leaves minimal headroom for spikes. Any concurrent heavy query or refresh will push into throttling territory.
🐌 Slow Dashboard Load Times
Users reporting degraded Power BI performance — slow report rendering, delayed visual interactions, or timeout errors — especially during morning hours after overnight ETL jobs.
⏰ Background Jobs Missing Windows
Scheduled refreshes, notebook jobs, or pipeline runs failing to complete within their scheduled windows due to throttling or queuing. Jobs that used to finish by 6 AM now run past 9 AM.
Don't exchange immediately after the first throttle event. Analyze whether the spike was temporary (a one-off large report render, a poorly optimized query, or a failed-and-retried pipeline) or a sustained pattern. Collect at least 2 weeks of Capacity Metrics data before deciding to exchange. One bad week doesn't justify a new multi-year commitment.
Best Practices
Proven strategies for getting the most value from Fabric capacity reservations.
📊 Start PAYG, Then Reserve
Run pay-as-you-go for 1-2 months to understand your real CU consumption patterns before committing to a reservation. This initial investment in PAYG rates pays for itself by ensuring you reserve the right SKU size — avoiding either overpaying for unused capacity or under-provisioning and facing throttling.
🏭 Reserve Production, PAYG Everything Else
Only reserve always-on production capacities that run 24/7 and justify the commitment. Use pay-as-you-go with aggressive pausing for dev, test, staging, and sandbox environments. A dev capacity running 8 hours/day, 5 days/week (24% utilization) costs 75% less on PAYG than a reservation.
📈 Monitor Before Exchanging
Collect at least 2 weeks of Capacity Metrics data before deciding to exchange up or down. Look for sustained patterns, not one-off spikes. Analyze peak vs. average CU utilization, throttling frequency, and top consumers. One bad week — perhaps caused by a runaway Spark job or a surge in ad-hoc queries — doesn't justify a new multi-year commitment.
🛡️ Enable Overage as a Safety Net
Configure capacity overage with a reasonable cost cap as insurance against unexpected spikes. Even if you rarely hit the cap, it prevents critical business operations from being throttled during unforeseen demand surges. It's cheaper than permanently over-provisioning a larger SKU year-round to handle occasional peaks.
🕐 Schedule Heavy Jobs Strategically
Spread ETL, data pipeline, and background refresh jobs across off-peak hours to flatten CU consumption curves. Avoid clustering all jobs at the same time (e.g., midnight). Staggering reduces peak smoothed consumption and avoids triggering throttling during morning business hours when interactive queries compete for CUs.
📅 Review Annually
Reservations are multi-year commitments. Set calendar reminders to review utilization 2-3 months before renewal or auto-renewal triggers. Analyze whether your consumption has grown (exchange up), decreased (exchange down), or shifted (consider restructuring capacities). Don't let renewals auto-process without deliberate review.
🌐 Use Shared Scope for Multi-Subscription
If your organization has multiple Azure subscriptions with Fabric capacities, configure reservations with shared scope to maximize coverage. Unused CU credits from a paused or lightly loaded capacity in one subscription automatically apply to active capacities in another. This prevents waste from idle reservation time.
📝 Document Your Exchange History
Track all reservation exchanges with the business rationale, CU utilization data before and after, financial impact, and outcome. This institutional knowledge helps with future sizing decisions and prevents repeated mistakes. A simple spreadsheet with date, old SKU, new SKU, reason, and post-exchange utilization is sufficient.