How Azure Picks a Discount (and Why Your Bill Looks Confusing)

When I wrote Azure Savings Plans, Finally Explained with Math That Actually Makes Sense, I was very focused on solving one specific problem. People were looking at Savings Plans and feeling like they were missing something obvious. They saw the hourly commitment. Then they saw their bill. They did not see a discount. And that disconnect was driving a lot of unnecessary anxiety.

Once that post went live, I started finalizing this post as I knew there would be immediate follow up questions which would circle around the same theme. “This makes sense now, but what happens when we also have Reserved Instances?” Sometimes that question gets asked directly by customers I work with (namely they don't understand the distinction between the two). Other times I've had this question show up as a screenshot of a cost report with a “does this look right to you?”

That is the moment where things can start to feel slippery. Not because Azure is doing anything wrong, but because the system is doing more than one thing at once and the explanation usually stops before it makes sense to many.

So this post is meant to be the next layer. Not a correction, not a gotcha, but a calm walkthrough of how Azure actually applies discounts when you have more than one in play and why the results can look strange even when everything is working exactly as intended.

Let us ground ourselves before we go any further

Before we talk about stacking discounts, it helps to restate the core idea from the first post in plain language.

Savings Plans do not show up as a visible discount. They change how compute is priced.

Azure is not subtracting money from your bill after the fact. It is choosing a cheaper price when it calculates certain compute charges, evaluated hour by hour. The savings exist as avoided cost. You feel them when you compare outcomes over time, not when you scan a single invoice looking for a credit line.

That framing still applies here. We are not replacing it. We are building on it by explaining what happens when Azure has more than one possible way to price the same hour of compute.

Yes, Azure really does consider more than one discount

This is the first thing that tends to surprise people, so it is worth saying clearly.

In a given hour, the same virtual machine can technically qualify for a Reserved Instance and a Savings Plan for compute. Azure does not ignore one just because the other exists. It evaluates eligibility for both.

However, Azure will only apply one discount to a given hour of compute. Discounts do not stack. There is no scenario where you get a reservation benefit and a savings plan benefit applied to the same VM hour.

That means Azure has to make a choice. And the way it makes that choice is very intentional.

The order Azure uses actually tells you a lot

When Azure decides which discount to apply, it does so in a fixed order. Reserved Instances are evaluated first. Savings Plans are evaluated second. Anything that remains uncovered is billed at pay as you go pricing.

This ordering is not random and it is not arbitrary. It reflects how flexible each discount type really is once you are living with it day to day.

Reserved Instances are the most rigid discount construct Azure offers. They are tied to specific VM families, regions, and sometimes sizes. Once you buy them, your ability to move them around if your environment changes is limited. Because of that rigidity, Azure prioritizes using them whenever a matching compute resource exists. If you bought it, Azure wants to make sure it gets consumed.

Savings Plans are intentionally more flexible. They are not pinned to a specific VM configuration and can float across eligible compute. Azure uses them to cover what remains after Reservations have been applied. In other words, Savings Plans are designed to be the safety net for everything that does not neatly line up with a reservation.

When you look at it through that lens, the ordering starts to feel less confusing and more pragmatic.

What this actually looks like in a real environment

Here is where most explanations fall apart, so let us slow down and talk through it like we would at a whiteboard.

During a given hour, Azure first scans your environment for compute that matches existing Reserved Instances. Wherever there is a match, those reservations are applied and those VM hours are considered covered. At that point, those hours are no longer eligible for any other discount. They are done.

Next, Azure looks at everything that is still eligible for compute discounts. This is an important detail. Savings Plans are not applied in a neat one to one mapping that you can easily predict by scanning a list of VMs. They are evaluated globally. Azure looks across the remaining usage and applies the Savings Plan benefit to the compute that yields the greatest savings in that hour.

That might be a different set of VMs from one hour to the next. It might not align with what your intuition tells you should be covered. Azure is not optimizing for visual clarity. It is optimizing for cost impact. Anything left after that process is billed at pay as you go pricing.

Once you understand that this is a global, hourly optimization problem rather than a static assignment, a lot of strange looking reports start to make more sense.

Why cost reports can feel unsettling even when nothing is wrong

This is the point where people often assume they made a mistake:

You open a cost report and you see Reserved Instances that are not fully utilized. You see Savings Plans that are not at one hundred percent utilization. You still see pay as you go charges. It feels like the system should have done better.

In most cases, the system is doing exactly what it should:

Discounts are evaluated hourly. Usage changes throughout the day. Workloads move. Regions shift. VM families change. The most optimal way to apply discounts changes right along with those patterns.

So what you are seeing is not failure. It is the system constantly rebalancing itself to extract the most value from the commitments you already made. The discomfort usually comes from expecting stability in a system that is designed to be adaptive.

The timing detail that quietly trips people up

There is one more nuance that matters, especially for anyone who checks cost reports daily or has alerts tied to utilization metrics. Discount application and cost reconciliation are not always immediately reflected in reporting. It can take up to forty eight hours for cost data to fully settle and accurately show how Reserved Instances and Savings Plans were applied.

That means looking at yesterday’s data, or even today minus twenty four hours, can give you an incomplete or misleading picture. This does not mean discounts were missed. It means the data pipeline has not finished reconciling yet.

This is one of the reasons I always caution teams against reacting too quickly to short term utilization swings. Cost optimization decisions need a little time and a little context to tell the full story.

Bringing it all back together

None of this changes the core guidance from the original Savings Plans post. Savings Plans are still best suited for covering boring, predictable baseline compute. Reserved Instances still make the most sense for very stable, always on workloads (think production VMs). Pay as you go pricing still plays an important role in preserving flexibility and absorbing change.

What this post adds (hopefully) is clarity. It explains why these constructs can coexist without stacking, why Azure applies them in the order it does, and why your reports can look strange even when your strategy is sound.

If cloud cost management ever feels more complicated than it should be, it is usually because the explanation is missing this layer. Once you understand how Azure decides which discount applies, it becomes much easier to trust what you are seeing and stop assuming you broke something when the numbers look odd for a day or two.

That confidence is often the real savings.

Further reading and references

Azure Savings Plan for Compute overview

How Azure Savings Plan discounts are applied

Azure Savings Plans pricing and FAQ

Azure Advisor cost recommendations

Decide between Azure Reservations and Savings Plans

Azure Cost Management and Billing documentation