Reserved Instances, Savings Plans or pay-as-you-go: the layered strategy

The last step in cost optimization in Azure is also the easiest to get wrong, because it is the only one that cannot be undone.

Reservations and savings plans are financial tools, not technical ones. They don't change anything in your architecture — they only change the price you pay for exactly the same resources, in exchange for a commitment of one or three years. The discounts are substantial. And that's exactly why it's important to buy them last, not first.

The most important order rule

Before any technical detail, one rule, because it fixes the most expensive possible mistake:

Resize first. Buy commitments afterwards.

A three-year reservation on an oversized machine means you got a consistent discount on a resource you didn't need — and you locked in the mistake for 36 months. The discount creates the illusion of optimization exactly at the moment you institutionalized waste.

That's why this series is in this order. The previous articles were about making sure you pay for the right resources, at the right size. Only now does it make sense to discuss how much you pay for them.

Practical corollary: if your infrastructure is less than six months old or is going through a migration, don't buy anything yet. You need stable usage data to choose correctly. The cost of waiting a few months on pay-as-you-go is almost always lower than the cost of a wrong commitment.

The three tools

Pay-as-you-go

List price. You pay for the consumed hour, you commit to nothing, you can stop anytime. It is expensive, but it is the only one that costs nothing if you change your mind.

It has a permanent role in any healthy strategy: it covers peaks and the variable part of consumption, that is exactly the portion you don't want to commit to.

Reserved Instances

You commit to a specific resource — a machine family, in a certain region — for 1 or 3 years. In exchange, you get the deepest available discount, which can reach, approximately, up to 72% off the list price over the three-year term.

It applies automatically, without changing anything in the configuration: Azure matches the reservation with eligible running resources and bills the difference at the reduced rate.

An important point, often missed: reservations do not cover only virtual machines. There is reserved capacity also for Azure SQL Database, Cosmos DB, and other stateful services — and there the savings are often the largest in the entire portfolio, because databases are the most stable resources you have.

Savings Plans for Compute

You commit to a dollar amount per hour, not to a resource. You say “I will spend at least 5 dollars per hour on compute” and Azure automatically applies the discount on eligible consumption up to the committed level.

The discount is smaller — approximately up to about 65% over three years — but the flexibility is much greater: it applies across machine families, regions, and compute services, including App Service and Premium plans for Functions.

Consumption exceeding the commitment is billed at the normal price. Unused commitment is paid anyway.

The comparison that matters

Two operational details are worth remembering:

• Order of application. When both are eligible for the same consumption, reservations apply first, being more advantageous. You don't have to manage this manually.
• Asymmetry on exit. Reservations can be, under certain conditions, exchanged or partially refunded. Savings plans cannot. A Savings Plan is a firm obligation until the end of the term — which makes deliberate undercommitment the prudent strategy.

Layered strategy

Here is the central idea of the article: the three tools are not alternatives to choose between. They are layers you overlay on your consumption profile.

Imagine your monthly consumption graph. It has a base that never falls below a certain level, an intermediate zone that varies predictably, and some occasional peaks.

Layer 1 — the hard base: Reserved Instances

Resources that run 24/7 for over six months, in the same region, without migration plans. The production database. Machines behind a mature service. Here you buy the maximum discount, for three years if you are sure, for one year if not.

Layer 2 — stable but mobile consumption: Savings Plans

Above the reserved base, a compute consumption that is constant in volume but moves between services: App Service, containers, Premium functions, machines that resize. You accept 7 percentage points less discount in exchange for the right to change architecture without losing the commitment.

Layer 3 — the peaks: pay-as-you-go

The rest. Scaling from peaks, ephemeral environments, experiments. You pay full price on a small portion of the total and keep complete freedom.

The sizing rule for layers: commit to the minimum observed level, not the average. Look at consumption from the last six months and commit at the level below which you have never dropped. An unused commitment is money thrown away for sure, while uncommitted consumption is just money paid at full price. The asymmetry is clear.

Four costly mistakes

1. Buying before resizing

Already discussed, but it is first for good reasons. Order matters more than the tool.

2. Committing on average, not on minimum

If your average is 10 dollars per hour but the minimum is 6, a commitment of 10 means you pay for 4 dollars per hour of unused capacity in all periods below average. The discount evaporates quickly under poor utilization of the commitment.

3. Buying 3 years by default

The three-year term brings a significantly better discount. It is worth it only if you have a real conviction that your architecture will look the same in 2029. For a team actively migrating to containers or serverless, one year is the honest choice.

4. Forgetting stateful services

The public discussion is dominated by virtual machines, but for a modern application the database is often the largest and most stable line in the bill. Reserved capacity for Azure SQL or reserved throughput in Cosmos DB are often the most profitable purchases in the entire exercise — and the most often ignored.

Series recap

With this we conclude the five articles about cost optimization in Azure. The common thread, if I were to compress it:

1. Cost anatomy — fixed, variable, and idle cost; the latter is what produces surprise bills. Measure in cost per business unit, not in dollars per month.
2. Azure Functions — the decision between plans depends on network, latency, and the memory × duration profile, almost never on volume. Flex Consumption eliminated the false binary between cold start and Premium plan.
3. Auto-scaling — minReplicas and the KEDA threshold are the two most expensive parameters in Container Apps. Defaults are chosen not to annoy you, but not to cost you little.
4. Cost Management — without automatic tagging, the rest of the tools produce unattributable numbers. Alerts on forecasted cost, twenty-minute monthly audit.
5. Commitments — the last step, not the first. In layers, sized on minimum.

What ties all five together: cost optimization is not an emergency operation triggered by a large bill. It is a property of the architecture and a process with its own rhythm — just like security or observability, and just as difficult to add retroactively.

The best news is that most of the savings do not come from negotiations or expensive tools. They come from three simple things: not paying for what you don't use, not keeping warm what can be cold, and looking at the bill once a month.

Note: discount percentages are indicative and vary depending on service, region, term, and contract type. Check concrete values in the portal before any purchase.