- Vendors advertise savings up to 72%. The number is real but only achievable under specific conditions.
- Cloud usage is elastic. Commitments are not. That mismatch is where the advertised savings leak away.
- The fix is to layer Standard RIs, Convertible RIs, and Savings Plans to emulate an elastic commitment portfolio.
- Sizing the layers correctly is a calculation problem, not a judgement call — automate it.
The advertised number and the delivered number
AWS and Azure advertise “up to 72% savings” on RIs and Savings Plans. The number is not marketing fluff. If you dig into the pricing pages, it is occasionally even a touch higher.
But there is a word in that claim that does all the work: up to. The 72% is the best case. It assumes your workload runs continuously for the full term of the commitment and matches the reservation exactly.
In practice, that is rare. Most cloud workloads have off-hours, weekend shutdowns, scaling events, migrations, and retired instances. Each of those erodes the delivered savings compared to what the brochure promised.
Advertised savings vs. reality (illustrative)
72% ████████████████████████████████ ← vendor brochure
(24/7 workload, exact match)
55% ███████████████████████ ← workload runs 20h/day
instead of 24h/day
40% █████████████████ ← weekend shutdowns
plus some dev/test elasticity
~0% ██ ← over-committed or mismatched
(sometimes negative)Commitments have no elasticity. You pay the committed amount whether or not the usage is there. The moment your workload stops running for an hour, that hour’s commitment cost is sunk — and the “savings” it would have generated disappears with it.
The condition for the full discount
The 72% number assumes one thing: the covered resource runs continuously for the full term. That is it. An RDS database that never sleeps. A production API tier that scales but never fully scales to zero. A core controller that is on 100% of the time.
As soon as you introduce any elasticity — scheduled shutdowns, scale-to-zero off-hours, seasonal traffic — the delivered discount starts dropping. Sometimes it drops below zero, meaning the commitment cost more than paying On-Demand would have. Article #02 walks through the specific examples.
So if most of your workload is not 24/7, the question is not “how do I hit 72%?” — that was never on the table. The question is “how do I get the best possible discount rate given that my usage is elastic?”
Emulating an elastic commitment portfolio
The ideal product would be a commitment that expands and contracts with your actual usage — you get the discount when running, pay nothing when idle. That product does not exist. But you can approximate it by layering the three commitment types against different slices of your usage.
Your compute usage over a day (an illustrative shape)
Usage
▲
│ ┌──┐
│ ┌──┘ └──┐ Peak (spiky)
│ ┌──┘ └──┐
│ ┌──┘ └──┐ Daytime baseline
│──┘ └── Night floor (always on)
└──────────────────────────────▶ Time
00 08 18 24
How to cover it:
┌────────────────────────────────┐
│ │
│ ▲ Peak / burst On-Demand │ No commitment. Let it burst freely.
│ │
│ ■ Daytime baseline Savings │ Flexible. Covers whatever shape
│ Plans │ the fleet takes this quarter.
│ │
│ ■ Evening/shift Convertible│ Some flexibility for instance-type
│ RIs │ changes without losing the commit.
│ │
│ █ 24/7 night floor Standard │ Tightest commitment, deepest
│ RIs │ discount. Reserved for the known
│ │ permanent baseline.
└────────────────────────────────┘The principle: match the rigidity of the commitment to the stability of the usage.
- Identify the 24/7 floor. What will definitely run for the full term? Cover that with Standard RIs — biggest discount, tightest lock-in.
- Identify the flexible core. Workloads that are permanent but may change instance shape (tech refreshes, family migrations). Cover with Convertible RIs.
- Cover the variable middle. Everything that is reasonably steady in dollar terms but not in instance shape goes to Savings Plans.
- Leave the peaks and the experiments on On-Demand. Short-lived, bursty, or uncertain workloads are cheaper on On-Demand than on a wasted commitment.
Why this is a calculation problem, not a judgement call
The plan above is simple to state. Sizing each layer correctly is not.
To decide how many Standard RIs to buy, you need to know:
- The minimum floor of usage across a 1- or 3-year horizon
- The confidence level on that floor
- The instance-family distribution of that floor today and in 12 months
- The marginal cost of mis-sizing (over vs. under)
And that is just for one layer. Convertible RIs and Savings Plans add more dimensions: conversion paths, hourly $ commitments, term lengths. Multiply by every region and every instance family you run, and you get a multi-dimensional optimisation problem.
Could you calculate this manually in a spreadsheet? Technically yes. I have seen it done, usually by someone who then burns out within three months. The combinations grow faster than human patience.
This is the exact kind of problem automation exists for. A commitment-management tool (first-party or third-party) that can:
- Ingest your usage history
- Run the layer-sizing calculation continuously
- Convert and adjust commitments as usage shifts
…will always beat a quarterly spreadsheet exercise, because the optimal mix drifts every week and you are not going to re-run the spreadsheet every week.
In my opinion, for any organisation spending more than roughly $100K/month on compute, manual commitment management is a false economy. The tool cost is small relative to the savings you leave on the table by sizing once a quarter with last quarter’s data.
Summary
- The advertised “up to 72%” assumes 24/7 usage. Most workloads do not hit that.
- Elasticity is the gap between advertised and delivered savings. You cannot close it by committing harder — you close it by layering commitment types against the shape of your usage.
- Standard RIs for the 24/7 floor, Convertible RIs for the flexible core, Savings Plans for the variable middle, On-Demand for the peaks.
- Sizing the layers is a continuous calculation, not a quarterly exercise. Automate it.
Thanks for reading. If this helped, share it. Questions or topic suggestions — send them through.