Azure Reservations and Savings Plans - Simply Explained

0:00 Azure advertises up to seventy two percent off your cloud bill, but that number hides a catch. Reservations and savings plans are how Microsoft sells that price cut, and both ask you to pay before you use anything. Commit to more than you use, and the savings turn into money you already spent. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. By the end, you'll know which one fits your workload and the number that decides if it's worth it. Why pay before you use it? Normally, the cloud builds you after the fact. You start a virtual machine. It runs for a month and the bill arrives based on what you used. That model is called pay as you go, and it's the default for almost everything in Azure. It's flexible and you pay only for what you actually consume.

0:43 A commitment discount flips that order around. You agree to spend ahead of time, and in exchange, Microsoft drops the rate you pay. The resources themselves don't change at all because this is a billing arrangement and nothing more. Microsoft describes these as billing offers that don't affect the runtime state of your resources, which is a formal way of saying your machines keep running exactly as they did before. Microsoft hands out that discount because a promise carries value on their side. When you commit to spending a set amount over one year or three. They can plan capacity with more confidence and count on that revenue. You give up some flexibility, they give you a lower rate, and that trade sits behind both products. You're about to meet. This next point trips people up. So it's worth naming. Clearly a commitment discount isn't a separate product you deploy or a setting you switch on inside a virtual machine.

1:25 It's a purchase you make on the billing side of Azure, and from there, it changes the rate on the usage that matches. Azure offers two versions of the trade. Reservations are the stricter one and savings plans are the looser one will take them one at a time in plain words, and then work out how to choose between them. Hold on to one thing before we go further. This discount is not free money, and it's a bet on your own future usage that you can lose if you promise to spend. And then don't use the resources you've still paid. So the real question is never just how big the discount is. It's how much of it you'll actually use. And the number that settles that question is coming up later, and it isn't the discount percentage, as your reservations simply explained. A reservation is a promise to use one specific thing in one specific place for one year or three.

2:05 You pick the resource type, the size, and the Azure region, and Microsoft gives you a lower rate on any usage that matches those choices. Reserve a particular virtual machine size in a particular region, and every hour that machine runs gets the discount automatically, with no manual work on your part. Microsoft advertises a saving of up to seventy two percent against pay as you go prices. That figure is a ceiling across every product and every term Microsoft offers, so it's the best case rather than the typical case. And your own discount depends on what you reserve and how long you commit for. Now, the part most people miss. A reservation covers the compute cost of the resource, and not a lot else. For a virtual machine, the discount lands on the machine itself, while windows licensing, networking, and storage stay on the bill at their normal rates.

2:48 The same pattern shows up elsewhere because a SQL reservation covers compute and leaves the software license, the network, and the storage alone. If you already own Windows Server or SQL server licenses, you can cover those licensing costs separately with something called Azure Hybrid Benefit, which lets you bring licenses you've already paid for into the cloud. The rigidity has a softer side, too. You're not locked to one exact machine size because a feature called Instance Size Flexibility lets a single reservation stretch across several sizes inside the same family. Reserve one standard DS3 size and the discount can also land on a smaller DS one or DS two, or on a larger Ds4, as long as they sit in the same flexibility group. What you can't do is jump to a different family or a different region, because the reservation stays tied to those two practical notes.

3:32 Before we move on, reservations apply hour by hour, so you buy against your steady, always on usage rather than your busiest day. And you can pay up front or spread the cost monthly with the total coming out the same either way. Azure savings plans The looser option a savings plan asks for a different kind of promise. Instead of naming a specific resource, you commit to spending a fixed dollar amount per hour on eligible compute? You might promise five dollars an hour for a year, and in return, the discount follows your usage wherever it goes across the eligible services and regions right up to that hourly amount. The advertised saving here reaches up to sixty five percent of pay as you go prices. That ceiling is generally lower than a fully used reservation, and there's a straightforward reason for it.

4:13 Flexibility costs something. The more freedom Microsoft gives you, the less discount they can offer, and a plan is built to be freer than a reservation. A detailed matters here, and it's easy to miss. Discount rates vary by the length of your term and by the product, not by the size of your commitment. So committing one hundred dollars an hour doesn't earn you a better percentage than committing five. How the discount gets applied each hour explains everything that follows. Azure looks at your eligible usage for that hour and discounts the piece with the biggest saving first, then works down the list until your hourly commitment is used up. Anything above the commitment is billed at your normal pay as you go rate. Now for the line that changes how you think about all of this unused commitment in an hour expires and it doesn't roll over. If you promised five dollars for this hour and only use three, the other two are gone and you don't get them back next hour or next month.

4:57 Microsoft calls this use it or lose it, and it's the sharpest edge on the whole product. Azure offers two plans one for compute and one for databases, and both come in one year and three year versions. The compute plan reaches a wide set of services, from virtual machines and app servers to container apps and functions on a premium plan, but it leaves software networking and storage charges out just like a reservation does. One more difference matters before you commit, a reservation can be exchanged or refunded within limits, and a savings plan cannot be cancelled or refunded at all, so the plan carries fewer exits. If you change your mind what each one actually covers, it helps to see the range. Because these products aren't only for virtual machines. Reservations exist for a long list of Azure services.

5:38 There are reservations for virtual machines, for blob storage capacity, for Azure files, and for cosmos DB throughput. The list keeps going with reservations for SQL database and SQL managed instance compute for Synapse Analytics, for Databricks, for Azure Cache, for readers, for dedicated host, and for premium SSDs above a certain size. The two savings plans are narrower by design one covers compute and one covers databases. The databases plan reaches SQL database, SQL Managed Instance, PostgreSQL, MySQL, cosmos DB, and a few others. If you're ever unsure whether something you run is covered, Microsoft publishes an included products list you can check before you buy, and the purchase page in the portal shows exactly what a given reservation will apply to. The common thread matters more than the list, though, and it points you toward the right product.

6:22 A commitment discount attaches to the metered cost of the thing you reserved, which is usually compute or capacity, and it stops at the edge of that meter. Anything outside the meter, like software, networking or storage sits on its own, which is why the advertised percentage rarely matches the drop you see on a real invoice. Which one fits the cleanest way to split them is this reservations. Reward stability and savings plans reward change a reservation delivers the deeper discount when you use all of it because you're giving up the most freedom to get it. A savings plan gives you a smaller discount, but the benefit follows your usage across services and regions, so it's much harder to waste if your workload sits still. The reservation wins. If your workload moves, the plan protects you. Something about how the two work together surprises people when an account has both.

7:05 Azure applies the reservation benefit first and only then reaches for the savings plan. The reason is practical, since the reservation is the more restrictive commitment and usually the bigger discount. So using it first means less of that value goes unused. The system is trying to squeeze the most out of what you already bought. Microsoft's own guidance lines up with that logic. Choose a reservation when your workloads run continuously, and you don't expect the instance type the family or the region to change. Choose a savings plan when your workloads are changing, when they use several families or services, or when they're moving between regions. The point of that guidance is that you don't have to guess which camp you're in, because you can look at how your resources behaved over the last few months and let the pattern tell you. If you want to begin a size test, try this one.

7:45 Ask yourself whether you bet your own money that this exact resource keeps running at this exact size, in this exact place for a full year. A comfortable yes means a reservation belongs on the table. Any hesitation at all means the plan is the safer shape because it doesn't care where your usage moves next. That settles the shape of the commitment. The other half of the decision is how long you're willing to promise one year or three. Both products come in two terms one year and three years, and the only thing that changes between them is how long you're locked in. A longer promise buys a deeper discount, and a shorter promise buys you an earlier exit. That trade is simple to describe and harder to live with. A three year commitment means three years of exposure, so if the workload shrinks, moves, or disappears, you're still on the hook for the promise you made, and the discount only helps when there's still usage for it to land on a one year term costs you some savings, but it costs you far less when you turn out to be wrong.

8:37 Microsoft has a recommended order for this, and it's worth repeating in plain words fix the waste first by removing or shrinking resources you aren't really using. Then deal with the commitments you already own by exchanging or trading in the ones that no longer fit. Only after that should you commit to anything new. And even then, you start with the stable workloads before you add the flexible ones. Microsoft sums the whole idea up in a single line that discounts reduce rates and not waste for someone new to Azure. The honest version is this you rarely have three years of certainty about anything you just built, and that doesn't make the longer term wrong. It just means the bigger bet should come later, once your usage has settled down enough to trust. A good rule for a beginner is to earn your way up.

9:18 Start with the shorter term. Watch how your usage actually behaves for a year and let that evidence decide whether the longer commitment deserves your money. A small comfort is built in as well. When a term ends, the discount simply stops and Microsoft doesn't renew it automatically unless you switch renewal on. That gives you a natural checkpoint every year or three to ask whether the commitment still matches what you're running. Length is one lever and where the discount is allowed to land is the other where your discount applies. Scope answers one simple question which is where your discount is allowed to reach? Azure gives you four places to point it. You can tie a reservation to one resource group, so the discount only lands on matching usage. Inside that group, you can pin it to one subscription. You can also attach it to a management group, which is just a container that holds a set of subscriptions, or you can set it to shared, which lets the discount follow matching usage across every subscription inside your billing context, the narrow options feel tidy, and they're easy to get wrong.

10:09 A discount scoped to one resource group can only land on usage inside that group. If the resource moves or the group empties out, or you rebuild the workload somewhere else, the discount has nowhere to go and it sits unused. A shared scope is messier to think about, but it gives the discount more places to land, which is usually what a beginner wants. Scope also explains why people end up with an unused discount. It decides where the benefit is allowed to land and not what you're allowed to run. You can still run anything you like, but the discount simply won't help pay for usage outside the fence. A reassuring detail hides in this and a lot of people never notice it. You can change scope after you by changing. It isn't a new purchase and it doesn't reset your term. So a decision you make on day one is not permanent. If you start narrow and later wish you'd gone wider, you can widen it.

10:52 The order Azure applies these in explains a behavior you might see when several reservations could apply. It works from the narrower scope to the widest, starting with resource groups, then subscriptions, then management groups, and finally shared. So the most specific match gets used first. So scope is a fence. You draw around your discount and you can redraw that fence later. Which brings us to the number that decides whether any of this was worth doing. The only math that matters we promised a number. So here it is. The thing that decides whether a commitment is worth it is not the discount percentage, it's how much of the commitment you'll actually consume. The arithmetic is simple. Once you see it, compare what you're promising to spend against what you'd confidently have spent anyway at pay as you go rates. If you're going to use all of what you're committed to, the discount is real money in your pocket.

11:35 If you only use half, you paid full price for the half you used and got nothing at all for the half you didn't. And that's the whole calculation. This is why the headline percentages can mislead you. Seventy two percent off sounds like a fortune, but seventy two percent of a commitment you only half use is a smaller real saving than a modest discount you use completely. A smaller discount that matches your usage beats a bigger discount that doesn't. Every single time. Stretching for the deepest rate is how people end up paying for capacity they never touch. Another way to hold it is that a discount is a rate, and a rate only saves you money on usage that exists. No usage means no saving, no matter how deep the percentage looks on the page. That number isn't a mystery either, because Azure works it out for you. Azure Advisor, the purchase experience in the portal and the available APIs all generate recommendations based on your actual usage history.

12:20 Those recommendations show you what a reasonable commitment looks like for the resources you already run, which turns the bet into something closer to a measurement keep one caveat in mind prices change, and Microsoft applies current pricing when it applies the benefit. No matter when you bought a number that looks right. Today is a snapshot and not a guarantee. So it's worth checking again before you commit to anything long. Now that you know the math, let's look at how people still manage to get it wrong. The mistakes that waste money. Mistake number one is committing to a discount for something that isn't actually stable. It's the most common version of the whole problem. And it usually happens because a resource looks permanent the week you buy the commitment and turns out to be temporary six months later. Mistake number two is scoping too narrowly.

13:01 A discount pin to one resource group can't follow your usage when the workload moves, and a discount that can't follow your usage turns into a discount you can't use. Mistake number three is grabbing the longest term without the certainty to back it. Three years at the best price is a great deal right up until the workload changes. And then it's an expensive promise you're still paying for. Mistake number four is forgetting what the discount doesn't cover licensing, data transfer, and storage site outside a reservation or a plan so the bill never drops by the full percentage you saw. If you're expecting the whole invoice to fall by seventy two percent, the first real bill will disappoint you. Mistake number five is treating a recommendation as an order, as your suggestions are, a starting point built from past usage and past usage doesn't always predict the next year, use the recommendation as evidence rather than as an instruction.

13:46 A safety net does exist and its shape is worth knowing. Reservations can be exchanged for another reservation in the same product family, and they can be refunded up to fifty thousand dollars within a rolling twelve month window. A savings plan gives you no refund at all, which makes it the riskier of the two. To get wrong, the product with the fewest exits is the one that deserves the most caution before you buy. None of these mistakes are exotic. They all come down to the same thing, which is committing faster than you can be. Sure. A quick recap and one question. So that's the whole idea. Both options trade freedom for a lower rate, and the only discount that counts is the one you actually use. If this helped, subscribe to M365 FM, where we keep turning the tools and the mindset into plain words. And here's the one question I'd leave you with.

14:27 Looking at your own Azure usage. Would you bet a full year of spend that it stays exactly as it is?