Contoso Airlines' July invoice was €17,800, and every cent of it was paid at pay-as-you-go rates: the most flexible there is and, precisely for that reason, the most expensive. Azure charges a premium for not requiring any commitment from you, and when you have spent nine months running the same seven Kubernetes nodes twenty-four hours a day, paying for flexibility you never use is throwing money away.

This lesson is about Azure's most powerful discount mechanism and the one that gets used least: committing. You will see what reserved instances are — terms, payment options, scopes, instance size flexibility, exchange and refund — how they differ from savings plans, when a workload can tolerate spot instances, how licenses get reused with Azure Hybrid Benefit, what Dev/Test pricing is, and Contoso's complete purchase decision with its savings table and its break-even point. And above all you will see the risk, because this is the only chapter in the module where getting it wrong actually costs money: reserving before the architecture has stabilized is the most expensive way there is to save.

Reminder: every figure and discount percentage in this lesson is illustrative and fictitious. Real discounts depend on the service, the region, the SKU, the term, the currency and your commercial agreement, and they change frequently. Always check the official calculator and the service's pricing page before buying anything.

1. The principle: flexibility versus price
2. Reserved instances
3. Instance size flexibility and how the discount is applied
4. Exchange, refund and cancellation
5. Azure savings plans
6. Reservation or savings plan: decision criteria
7. Spot instances
8. Azure Hybrid Benefit
9. Dev/Test pricing
10. Contoso's purchase decision
11. The risk of committing
12. Utilization, tracking and automatic recommendations
13. Common Mistakes and Tips
14. Exercises
15. Conclusion

The whole chapter boils down to a single axis. At one end, pay-as-you-go: switch on and off whenever you like, pay by the hour, maximum price. At the other, a three-year commitment paid upfront: minimum price, and if you change your architecture tomorrow the money is already spent.

The percentages are illustrative and vary enormously by service and region. What does not vary is the shape of the curve: the more you commit, the less you pay. The skill is not in committing a lot, but in committing exactly to the part of the platform you know will still be there.

A reservation is a commitment to consume a specific capacity — a VM size, a quantity of SQL vCores, a number of Cosmos DB RU/s — for one or three years, in exchange for a reduced hourly price. It is important to understand what it is not: it is not a machine Azure sets aside for you, and it does not oblige you to keep anything running. It is a billing discount that is applied automatically to usage that matches what you reserved. If you have no matching usage, that hour is lost.

The purchase parameters:

Scope is the decision that produces the most mistakes. Shared lets the discount apply to any subscription in the billing account, which maximizes the chance of using it; a single subscription or resource group scope restricts it, and only makes sense when you want the discount to benefit a specific cost center — chargeback, section 7 of the previous lesson. The management group scope is the middle ground: the discount applies to any subscription inside that group, which is what Contoso uses so that reservations bought by the platform team do not "leak" into unrelated projects.

Services that support reservations (an illustrative list, it changes over time):

And the underlying criterion: you reserve what runs continuously. If a resource is switched off half the time — because of the Detener-IniciarEntornosDev runbook, because of autoscale, or because it is seasonal — the reservation pays for hours you do not consume and the effective discount falls apart.

A reasonable doubt when buying a VM reservation: do I have to run exactly that size? For most families, no. Instance size flexibility expresses the reservation in "units" of the family and applies it to any size in the same series within the same region.

An example with Contoso's machines (illustrative ratios within one series):

So if Contoso buys a reservation for two Standard_D8s_v5 for the aplicaciones nodes of aks-contoso-operaciones and months later the team resizes to four Standard_D4s_v5, the discount keeps applying in full: 8 units reserved, 8 units consumed. That greatly reduces the fear of committing, though it does not remove it: flexibility operates within the series and the region, not across series. Moving from the D series to the E series, or moving the workload to North Europe, leaves the reservation with nothing to apply to.

How the discount is applied each hour, which is the thing to visualize:

1. Azure groups the usage in that hour that matches the reservation (same region, same family, within the scope).
2. It applies the discount until the reserved quantity runs out, starting with the most expensive usage — which is good news: you do not have to sort anything by hand.
3. The remaining usage is billed at pay-as-you-go.
4. Reserved capacity that is not consumed is lost: it does not carry over to the next hour.

That fourth point is the reason for the golden rule: you reserve the baseline, not the average and certainly not the peak. With vmss-api-disponibilidad-pro, which swings between 2 and 20 instances with an average of 6, Contoso reserves 2. In the hours when there are 6 instances, two run at a discount and four on demand; in the hours when there are 2, both run at a discount. Had it reserved 6, it would lose four reservations every night.

Reservations are not entirely irreversible, but their exits have limits worth knowing before you buy:

Two important warnings. First: the exchange and refund terms have changed several times, and what was possible two years ago may not be today; check the current terms in the official documentation at the moment you buy, not in a blog post. Second, and more useful: plan as if there were no way out. If your purchase decision depends on being able to undo it, you do not yet have enough data to make it.

An Azure savings plan for compute solves the weak point of reservations: rigidity. Instead of committing to a specific capacity, you commit to an hourly spend on compute.

Example: Contoso commits to spending €0.80 per hour on compute for one year. In exchange, all of its compute consumption up to that amount is billed at savings plan prices, which are reduced relative to pay-as-you-go. Consumption above that goes to pay-as-you-go; consumption below is billed up to the commitment anyway — that is, you commit to paying those €0.80 every hour, whether you use them or not.

The decisive part is what it covers: a savings plan applies to different compute families and services, and in different regions. A VM in West Europe, a Premium v3 App Service plan, a Container App, a Function on a Premium plan and an AKS node can all consume the same commitment, and if tomorrow you redesign and swap some for others, the discount keeps applying. That is exactly the flexibility a reservation does not have.

An important detail: reservations are applied before the savings plan. If you have both, Azure discounts whatever matches the reservations first and only then consumes the plan's commitment. That is why the usual strategy — and Contoso's — is to reserve the immovable core and cover the moving periphery with a savings plan, rather than choosing one or the other.

Spot instances use Azure's surplus capacity with discounts that can reach 70-90% off the list price. The trade-off is harsh and has to be taken literally: Azure can evict the machine with about 30 seconds' notice when it needs the capacity or when the price exceeds your maximum. There is no SLA.

What characterizes a workload suitable for spot:

• It is interruptible: if it dies halfway through, it is retried and nothing bad happens.
• It keeps no local state: everything important lives outside the instance.
• It has no strict time commitment with a user waiting at the other end.
• It can scale horizontally: losing one of ten instances is an inconvenience, losing the only one is an outage.

At Contoso, two workloads qualify and are already on spot:

And what never goes on spot at Contoso: app-contoso-reservas-pro, vmss-api-disponibilidad-pro, the sistema AKS nodes — on which the cluster's own operation depends — and anything serving a passenger in real time.

--spot-max-price -1 means "pay up to the pay-as-you-go price", which avoids price-based evictions and leaves only capacity-based ones. The taint is essential: without it, the scheduler would place normal workloads on nodes that can disappear, and the saving would turn into an incident. And --min-count 0 lets the pool drop to zero nodes when there are no batches to run, which is a saving on top of spot itself.

Azure Hybrid Benefit lets you reuse Windows Server and SQL Server licenses you already own with Software Assurance or an active subscription, so that Azure charges you only for the infrastructure and not for the license included in the price.

Three characteristics make it especially attractive. It stacks with reservations: first the reservation lowers the price of the infrastructure, then Hybrid Benefit removes the license component. It is switched on and off with a toggle, with nothing to migrate. And it costs nothing to try, because the effect shows up on next month's invoice.

And now the warning that cannot be left out, because what is at stake here is not money but compliance: ticking the box is a declaration that you own the licenses with the appropriate coverage. The requirements — edition, core count, dual use during a migration, active Software Assurance — are the customer's responsibility and an audit can demand proof. At Contoso, engineering does not touch that toggle: the organization's licensing owner validates and authorizes it in writing, and that authorization is stored alongside the Bicep template that applies it. No saving justifies a license violation.

Azure offers reduced prices for environments that are not production, through Dev/Test subscriptions:

Contoso Airlines - Desarrollo is a subscription of this type, and its usage rule is written down: nothing that serves a real passenger lives there. The temptation to move a "small" production workload to the cheap subscription always appears, and it has to be shut down the first time.

With three months of real usage data in stlagocontosopro (08-02), Marta and Nuria put the proposal together. Illustrative and fictitious figures, in euros per month:

A saving of 16% of the invoice with no change to a single line of architecture, nothing switched off and no service degraded. It is by far the highest result-to-effort lever in the whole module.

What is deliberately left on demand, and why:

That last row holds the best lesson in the table: committing capacity on data you are about to stop ingesting is paying a discount for junk.

The break-even point. The three-year reservation on the AKS nodes, paid upfront, costs €27,540 against the €61,200 that the same usage would cost on demand over 36 months. Dividing the outlay by the current monthly cost:

• €27,540 ÷ €1,700/month = 16.2 months to break even.
• From month 17 onwards it is all saving; if the workload is abandoned before then, money has been lost.

The question Contoso asked itself, and the one you always have to ask, is not "how much do I save?" but "am I reasonably confident that this workload will still exist, in this shape, in 17 months?". For the AKS nodes and for db-reservas, the answer was yes. For the MySQL portal, the answer was no, and that is why it was not reserved.

Reserving badly is the only action in this entire module that can increase your cost. The four scenarios where that happens:

• Reserving before stabilizing. The team buys three years of a SKU, redesigns the component two months later and the reservation has nothing to apply to. You keep paying.
• Reserving the peak instead of the baseline. Unconsumed capacity is lost hour by hour, and the effective discount can fall below pay-as-you-go.
• Reserving and then optimizing. Buying the reservation and then right-sizing, switching things off at night or migrating to serverless leaves the reservation stranded. The correct order is to optimize first and reserve afterwards, over the already slimmed-down platform.
• Too narrow a scope. A reservation scoped to a resource group stops applying as soon as somebody moves the resource to another group.

Hence Contoso's four written rules, which are worth copying verbatim:

1. Nothing is reserved with less than three months of real usage data.
2. No component with an open architecture review is reserved.
3. You optimize first and reserve afterwards.
4. You reserve the observed baseline, not the average and not the peak.

Plus a fifth, common-sense one: when in serious doubt, 1 year instead of 3. You give up part of the discount in exchange for an exit option, and that option has value.

A reservation you have bought is not forgotten: it is watched. Cost Management provides reservation utilization reports — what percentage of the reserved capacity is being consumed each day — and savings achieved reports.

One specific pattern to recognize: a reservation that was at 100% and drops sharply almost always means somebody moved or resized the workload without knowing there was a reservation behind it. That is why Contoso configures an alert on reservation utilization and records in the README of contoso-infra which resources are covered by a commitment, so that anybody about to touch them knows in advance.

Azure also generates automatic purchase recommendations, visible both in Cost Management and in Azure Advisor (08-04): it analyzes the last 7, 30 or 60 days of usage and proposes the reservation that would maximize the saving, with its estimated percentage.

These recommendations are not accepted blindly, and there are three concrete reasons:

• They look backwards, not forwards. They recommend three years based on 30 days of usage of a component that may be retired next quarter. Advisor does not know what is on the roadmap.
• They recommend based on the current state, not the optimized one. If a VM is oversized, the recommendation proposes reserving it oversized. First you fix the size (08-04), then you reserve.
• They assume shared scope and a long term by default, which is what maximizes the theoretical saving and is not always what suits you.

The right way to use them: as the starting point of a conversation between whoever knows the technical roadmap and whoever signs off the outlay. At Contoso, that conversation is a standing item in the monthly cost review (08-05).

• Believing a reservation sets capacity aside. It does not: it is a billing discount. If you run nothing that matches, the hour is lost.
• Reserving the peak or the average. You reserve the baseline. With vmss-api-disponibilidad-pro, 2 and not 6.
• Reserving before optimizing. Right-size and switch things off first; commit afterwards, over the already slimmed-down platform.
• Committing to an architecture that is under discussion. If there is an open review, nothing gets reserved.
• Resource group scope by default. Moving a resource leaves the reservation unapplied. Shared or management group scope unless there is an explicit reason.
• Taking exchange or refund for granted. The terms change; plan as if there were no way out.
• Enabling Hybrid Benefit without validating the licenses. It is a contractual declaration, not an optimization checkbox.
• Putting workloads on spot with no taint or toleration in AKS: the scheduler will place things there that must not be there.
• Tip: always start with 1 year for anything that has not been stable for six months. The smaller discount is the price of the exit option.
• Tip: record in contoso-infra which resources are covered by a commitment. You will stop somebody resizing a reserved VM without realizing.
• Tip: review reservation utilization once a month. A sharp drop is always a sign that something changed.

Exercise 1. vmss-api-disponibilidad-pro has the following monthly profile: 2 instances for 7 hours a day, 6 instances for 17 hours a day, and a peak of 14 instances for three weeks in summer. Each instance costs an illustrative €220/month on demand. Decide what quantity to reserve and on what term, and calculate the approximate saving and what would have been lost by reserving 6.

Exercise 2. Contoso Miles (centro-coste=CC-2077) has been in production for four months with an App Service Premium v3, a 2-vCore PostgreSQL flexible server, blobs and a Function on a consumption plan. The project has business approval for two years, but a migration of the website to Container Apps is being evaluated. Propose the complete commitment strategy, stating what to reserve, what to cover with a savings plan and what to leave on demand.

Exercise 3. Azure Advisor recommends a three-year reservation on six Standard_D8s_v5 of aks-contoso-operaciones with an estimated saving of 45%. You know that: the aplicaciones pool is oversized and running at 20% CPU, a migration to Standard_D4s_v5 is planned for two months' time, and the cluster will exist for at least three years. Do you accept, postpone or reject? Justify it with numbers.

Solution 1: the real baseline is 2, because it is the minimum present at any moment of the month. Reserving 2 instances for 1 year with an illustrative 30% discount: 2 × €220 × 30% ≈ €132/month of saving, at 100% utilization because there are never fewer than 2 instances running. Reserving 6 breaks the arithmetic: during the 7 night hours there are only 2 instances, so 4 reservations are lost every night; over a month, utilization falls to roughly (7×2 + 17×6) / (24×6) ≈ 81%, and the effective discount on total spend drops accordingly, on top of having tied up a larger commitment. The summer peak is never reserved: it is three weeks a year, and a reservation would pay for that capacity the remaining 49 weeks. Term: 1 year, because the autoscale rules and the apertura-temporada-verano profile are still being tuned and because the extra saving of 3 years on a €440 base does not justify the rigidity. Generalizable rule: reserve the minimum of the lowest observed percentile, never the average.

Solution 2: reserve the 2-vCore PostgreSQL flexible server for 1 year — it has been stable for four months, it is not under discussion, the business has a two-year horizon and the server runs 24x7 — with an illustrative saving of 20-25% on compute; storage is billed separately and is not reserved. Do not reserve the App Service Premium v3: although it is reservable and would be the largest saving, a migration to Container Apps is under evaluation, and Contoso's rule 2 expressly forbids it. Instead, a 1-year compute savings plan sized below the current App Service spend — for example, at 70% of the observed hourly spend: you get a smaller discount but it survives the migration, because Container Apps also consumes the plan. Leave on demand: the Function on a consumption plan, whose cost is proportional to usage and does not accept this kind of commitment, and the blobs, whose volume is still growing and has no reliable baseline. Add Storage reserved capacity only when growth stabilizes. And a prior check: the scope of every commitment must be shared or management group, not resource group, because the project is still reorganizing its groups. Expected saving: modest in absolute euros, but with no risk at all of ending up with an orphaned commitment.

Solution 3: you postpone, and the arithmetic proves it. Accepting the recommendation means committing three years of six Standard_D8s_v5; two months later, the migration to Standard_D4s_v5 halves the units consumed. Thanks to instance size flexibility the reservation is not lost — six D8s are 24 units and twelve D4s would also be 24 — but if the resize is to six D4s (12 units), utilization drops to 50% and you will be paying 34 months of capacity nobody consumes. Translated: on €1,700/month of current spend, half the reservation sitting idle wastes on the order of €380/month for nearly three years, more than the well-used part would save. The correct sequence is rule 3: optimize first, reserve afterwards. Apply the resize to D4s over the two planned months, observe 30 days of already-optimized usage, identify the new baseline and then buy the three-year reservation on that baseline — the cluster will still exist, so the long term is justified. In the meantime, if you want to capture some discount with no risk, a small compute savings plan is appropriate, sized on the spend that will certainly remain after the migration. And record it in the monthly review's follow-up list, so the decision does not get lost.

You have now internalized the axis that governs the whole chapter: flexibility and price are inversely related, and the skill is not in committing a lot but in committing exactly to the part of the platform you know will still be there. You know reserved instances with all their parameters — a 1- or 3-year term, upfront or monthly payment with no penalty, shared, subscription, resource group or management group scope, quantity and region — the list of services that support them, and the two operating facts that avoid almost every mistake: instance size flexibility within the series and region, and the fact that unconsumed reserved capacity is lost every hour, from which the rule of reserving the baseline and never the peak follows. You also know what exits exist — scope change, split, restricted exchange, limited refund — and that you have to plan as if there were none.

You can tell savings plans apart from reservations: a commitment to hourly spend versus a commitment to specific capacity, applicable across compute series, services and regions, with a smaller discount in exchange for much more flexibility, and always applied after reservations — which is why the sensible strategy is to reserve the immovable core and cover the moving periphery with a savings plan. You know when a workload tolerates spot instances and how they are configured with their taint on the lotes pool of aks-contoso-operaciones, and when they must never be used. You understand Azure Hybrid Benefit, which stacks with reservations and is enabled with a toggle, with the unavoidable warning that compliance is validated by the licensing owner, not by engineering. And you can place Dev/Test pricing with its Visual Studio subscriber requirement and its contractual prohibition on hosting production.

You also have Contoso's complete decision: some €2,900 a month, 16% of the invoice, with no architecture change, nothing switched off and no service degraded, spread across three-year reservations on AKS, App Service and db-reservas compute, one-year reservations on the VMSS baseline, Cosmos and Storage, a savings plan for the periphery and Hybrid Benefit; along with what is deliberately left on demand and the reason for each exclusion, and a break-even point of 16.2 months that turns the economic question into a technical one: will this workload still exist, like this, in seventeen months? And you carry the four rules that stop a saving turning into a loss — three months of data, no architecture under discussion, optimize before reserving, baseline and not average — plus utilization tracking and the criteria for not accepting automatic recommendations blindly, since they look backwards and at the unoptimized state.

And there is the loose thread that opens the next lesson. Two of the three reasons to distrust a purchase recommendation point at the same place: before committing you have to optimize, and to optimize you need to know what is badly sized, what is orphaned and what has been running for months without anybody using it. Azure knows, and it will tell you for free. Azure Advisor analyzes your real subscription — it does not give generic advice — and produces recommendations on reliability, security, operational excellence, performance and cost: the VM at 3%, the disks nobody detached, the public IPs reserved and forgotten, the year-old snapshots, the gateways with no connections. That is the silent waste, and in the next lesson you will find all of it: with Advisor first, and then with the Azure Resource Graph queries that uncover what Advisor does not see.