Azure Savings Plans, finally explained with math that actually makes sense
- Shannon
- Jan 23
- 7 min read
Math IS hard and mathing isn't my strong suit. I am writing this blog because I STILL get tripped up at times with Savings Plans. You guessed it...this becomes a cheat sheet for ME in the future, too!
Azure Savings Plans are one of those topics that routinely make smart people feel like they missed a prerequisite class. I see it in customer meetings, I see it in internal chats, and I definitely see it in the way people react to Azure Advisor recommendations.
The issue is not you. The issue is that Savings Plans do not behave like the discount patterns we are used to. There is no coupon. There is no simple “percent off” that shows up as a credit. Azure is doing something subtler and honestly more powerful: it is changing how part of your compute is priced every hour.
This post is meant to make that feel normal. We will keep the explanation workload-agnostic until the one point where it matters to get concrete, which is the math section where I will use an Azure Virtual Desktop monthly example.
The one mental shift that unlocks everything
Here is the sentence I wish Microsoft would tattoo or etch in stone on the first page of every Savings Plan doc:
A Savings Plan does not subtract money from your bill. A Savings Plan replaces part of your variable compute charges with a fixed hourly commitment that is priced more favorably than pay as you go.
That is why people struggle. Most of us expect savings to show up as a visible line item, like a discount applied or a credit issued. With Savings Plans, the savings often show up as avoided cost. You do not see the expensive version of the charge anymore because Azure uses the Savings Plan benefit first each hour, up to your commitment.
One more detail that matters more than people realize: Savings Plans are an hourly benefit window. Each hour stands alone. If you do not use the commitment in a given hour, it does not roll forward to the next hour.
What you are actually buying with a Savings Plan
When you buy a Savings Plan, you are not reserving a specific VM size or pinning yourself to a single host pool design. You are committing to an hourly spend amount for eligible compute services for a one-year or three-year term.
That commitment has two big implications that are worth calling out in plain language:
First, the benefit applies automatically to eligible compute in scope. You do not have to assign it to a VM the way people think about Reserved Instances. Azure applies the benefit for you.
Second, the flexibility is typically higher than reservations because the benefit can apply across participating compute services, up to the hourly commitment, while reservations are tied to a specific service and region combination.
This is why Savings Plans are often the first thing I reach for when an environment is changing over time, and why reservations tend to shine most in very stable, always-on scenarios.
What “cheaper pricing” actually means in practice
This is the exact point where explanations usually fall apart, so I am going to be painfully direct.
Cheaper means: the compute you run would have cost more under pay as you go pricing, but when it is covered by the Savings Plan benefit, Azure prices it using Savings Plan rates instead.
Azure processes this hour by hour. In each hour, eligible compute usage is discounted until you reach your hourly commitment amount. After you hit the commitment, additional usage in that hour is priced at pay as you go rates.
If you are looking for a place to see evidence of this in reporting, Cost Management usage details include fields like EffectivePrice that behave differently when a Savings Plan discount applies, and there are benefit identifiers to reconcile which plan applied.
Also, if you have ever seen the weird scenario where you get both on-demand charges and less than 100 percent utilization in the same day, that is usually because utilization is evaluated per hour. Some hours underutilize the plan and other hours exceed it.
A per-hour example that makes the savings obvious
Let’s use the example that makes most people’s brains finally relax.
Imagine a chunk of compute that costs about $20 per hour at pay as you go rates. You purchase a Savings Plan with pricing that effectively makes that same compute cost about $14 per hour when covered by the plan.
Before Savings Plans, you pay $20 per hour for that usage.
After Savings Plans, for the portion covered by the plan, Azure prices it closer to $14 per hour.
Nothing is refunded. The “savings” is the $6 per hour you avoided paying because Azure never charged you the $20 version for the covered portion.
If usage spikes above what your commitment can cover in a given hour, that overage is simply priced pay as you go for that hour. This is exactly how the discount-application mechanics are documented.
This is also why sizing matters so much. An hourly commitment only helps if there is eligible usage to apply it to in that hour.
Why invoices still feel confusing
Most billing systems show savings as a separate line item. Savings Plans do not always present that way. Azure shows the charges that happened, not the alternate reality where you paid more.
So if a customer says, “I see the commitment, but I do not see the discount,” I usually respond with: you are looking for a credit. Savings Plans are pricing substitution.
Now zoom out: demystifying the math with an AVD monthly example
Ok, here is the one place where we go workload-specific.
Assume an Azure Virtual Desktop environment with an average monthly compute cost of $100,000, and for the sake of a clean example, assume that compute is steady and running 24x7x365.
A month is roughly 730 hours, so the average pay as you go hourly spend is:
$100,000 ÷ 730 ≈ $137 per hour
Now assume Savings Plan pricing is effectively 30 percent cheaper for the eligible compute mix you are running.
The Savings Plan priced equivalent of that same baseline is:
$137 × 0.70 ≈ $96 per hour
This is the part that surprises people: to cover a $137 per hour pay as you go baseline, your commitment is closer to the discounted equivalent, around $96 per hour, because the covered usage is priced more favorably under the Savings Plan.
If you covered that baseline fully with a Savings Plan commitment at about $96 per hour:
$96 × 730 ≈ $70,000 per month
So the avoided cost is roughly:
$100,000 − $70,000 ≈ $30,000 per month
That is the simplest “steady-state” view of why customers can save real money without ever seeing a coupon-like discount line. It is just different pricing applied to the same usage, hour by hour.
One practical note for AVD specifically: AVD costs are not only compute. There are licensing and consumption components depending on how the deployment is designed, plus monitoring if you enable Insights. Always make sure you understand what portion is actually compute and eligible for Savings Plans versus everything else.
What if you only want partial coverage
Most environments should start with partial coverage, not because you cannot do the math (even though it IS tricky), but because reality is messy and baselines take time to prove themselves. Partial coverage simply means you pick a smaller hourly commitment that you are confident will be consumed most hours. The “rest” remains pay as you go, which is perfectly fine. In fact, it is often healthy because it preserves elasticity for bursts and change.
If you are shutting down hosts after hours, this is where you want to be conservative. Remember, unused hourly commitment does not roll over.
What happens when the environment grows
This is one of the best parts of Savings Plans. They are additive.
If your environment grows and you can clearly see a new baseline has stabilized, you do not rip and replace the original plan. You layer in another plan sized to the incremental baseline.
Microsoft’s own recommendation tooling is built around this idea. Savings plan recommendations are generated using your actual on-demand usage and costs, and Advisor can provide commitment guidance based on your eligible on-demand usage and applicable rates.
So operationally, “adding more later” looks like this:
You watch usage long enough to trust the new baseline, you validate that the existing plan is being utilized in the hours you expected, and then you purchase an additional plan to cover the incremental baseline.
What good actually looks like
Good is not 100 percent coverage. Good is a commitment sized to the boring, predictable portion of compute so you stop paying the most expensive way for usage they already know is there.
In a healthy setup, you will see:
A steady baseline covered by Savings Plans most hours, and then on-demand charges that correspond to real variability. When that variability becomes steady, you add another plan.
That is the cycle. It is not dramatic. It is intentionally boring.
A comprehensive link roundup
Core Savings Plan concepts:
How discounts apply and why “hourly” matters:
Recommendations and how Advisor comes up with the number:
Savings Plans vs reservations:
Partner and CSP billing and reconciliation:
Cost Management context for finance and FinOps folks:
Comments