Buy Microsoft Fabric reserved capacity

This is the rare cost lever that does not ask you to give anything up. Advisor has already established that the capacity runs steadily, so a reservation simply re-prices compute the business consumes anyway. Microsoft does not publish a single fixed discount, so confirm the live figure on the Fabric pricing page, but the saving against pay-as-you-go on committed Fabric capacity is material, commonly cited in the region of 40 percent for a one year term and deeper for three years. The benefit applies automatically the moment the reservation is active.

Frame it as a payback calculation, not an approval rubber stamp. The commitment is known up front: quantity of CUs, term, and whether you pay upfront or monthly at the same total cost. Set that against the discounted run rate and the monthly saving is a fixed, forecastable number. Because the discount only ever applies to usage you were already incurring, the reservation begins paying back from hour one rather than needing growth to justify it.

The downside is bounded and quantifiable, which is what makes this an easy yes. If consumption later falls, an unused reservation hour is simply lost for that hour; it does not carry forward, but neither does it cost more than the commitment you already signed. And Azure reservations can be exchanged or returned, with the total cancelled commitment across your billing scope capped at USD 50,000 in any rolling 12 month window. The way to keep the downside near zero is to size to the steady floor of usage, not the peak.

Priya is the finance partner supporting the data platform team. The Advisor recommendation lands with a High impact rating and a projected annual saving on the F64 capacity in UK South. The instinct is not to wave the purchase through on Advisor's headline figure; it is to confirm the number against the team's own consumption. Advisor sizes its recommendation from a look-back window, so the first question is whether the last few months reflect steady state or a temporary spike from a one-off migration.

Priya asks the team to chart the capacity's CU usage across the look-back period. It shows a consistent floor at F64 with no sign of winding down, and a roadmap that keeps the workload on Fabric for at least the next two years. That turns the decision into a clean payback: the committed cost of a one year reservation sized to F64 against the discounted run rate gives a fixed monthly saving that begins immediately, because every reserved hour matches usage that was already being billed at pay-as-you-go. The finance pack reads: 'Advisor projects a saving on compute we already run flat-out; the usage floor confirms it; the only real decision is one versus three year term, and the downside is capped by the exchange and return rules.'

The cost model here is unusually clean. A reservation re-prices compute you already consume, so the saving is not a forecast of future behaviour, it is a discount on a known run rate. That makes the payback calculable to a high degree of confidence: committed cost in, discounted run rate out, fixed monthly saving from the first hour. There is no growth assumption to believe and no efficiency project to deliver before the benefit shows up.

The downside is small and explicitly bounded. If usage falls, an unmatched reserved hour is lost but never costs more than the commitment already made, and Azure reservations can be exchanged or returned, with cancelled commitment across the billing scope capped at USD 50,000 in any rolling 12 month window. Set the modest, capped downside against a saving that recurs for the full term and the asymmetry favours acting. The finance role is to confirm the usage floor, choose the term that best matches the workload's expected life, and treat the recommendation as a payback decision rather than a discretionary spend.

Microsoft Fabric is where a growing share of analytics and BI spend now sits, and a capacity left on pay-as-you-go is paying a premium for steady, predictable compute. Azure Advisor has already identified the workloads where that premium is being paid. Acting on it is one of the highest-certainty savings available on the Azure bill, because the saving lands on consumption that is already happening.

The leadership question is not 'should we use Fabric?' It is 'are we paying the right rate for the Fabric we already run every day?' The defensible position is that any capacity with stable, ongoing usage is on a reservation sized to its steady floor, the genuinely spiky or experimental workloads stay on pay-as-you-go on purpose, and the split is reviewed rather than left to drift.

This is a commitment decision, so it warrants a clear owner and a light governance loop, but the risk profile is benign. The saving is on compute already consumed, the term is fixed and forecastable, and reservations can be exchanged or returned within documented limits. The cost of getting it slightly wrong is small; the cost of never acting is a recurring premium paid quarter after quarter.

At a cost review, the CFO noticed that analytics spend on Azure had grown steadily as the business moved reporting onto Microsoft Fabric, and asked the obvious question: are we getting the best rate for it? The honest answer at the time was that the main capacity had been left on pay-as-you-go since it was first provisioned, because nobody had revisited the commercial footing once the workload settled.

The team's response was to treat Advisor's reservation recommendation as a prompt to make a deliberate decision rather than a notification to dismiss. They confirmed the capacity had run at a stable level for months, bought a one year reservation sized to that floor at a shared scope so the benefit could float across subscriptions, and left a small headroom of usage on pay-as-you-go for genuine spikes. The recurring premium on steady analytics compute disappeared from the bill, with no change to performance and no project to deliver. The next time the CFO asked the question, the answer had moved from 'we are on the default rate' to 'the steady capacity is reserved and the saving is in the run rate, reviewed each renewal.' That shift, from paying on-demand by inertia to paying the committed rate by decision, is the saving this recommendation delivers.

Most cost decisions involve a trade: cheaper but slower, or faster but dearer. This one does not. A Fabric reservation lowers the rate on compute the business already runs without touching performance, capacity or architecture, so the only question is whether the usage is steady enough to commit, and Advisor plus the consumption history answer that.

The risk of acting is small and bounded by the exchange and return rules; the risk of not acting is a premium that recurs every quarter on a growing part of the analytics estate. This is the kind of saving leadership should be quickest to approve, because the certainty is high, the effort is low, and the only thing standing between the business and the lower rate is the decision to make the commitment deliberately.