Fix unused Reserved Instances and Savings Plans

A Reserved Instance or Savings Plan is a contract you've already signed: a discounted rate in exchange for paying for a fixed amount of capacity — or a fixed dollar-per-hour of compute — every hour, for one or three years, used or not. The saving only materialises if a workload actually runs against it. When utilisation falls below 100%, the unused slice is money leaving the bank for nothing, and unlike most cloud waste you can't switch it off — it's locked in until the term ends.

This happens because commitments are bought against a snapshot of usage, and usage moves. Engineering right-sizes a workload to a smaller instance, migrates it to Graviton for better price-performance, changes a database engine, or retires the service entirely — all good things — but the commitment underneath was sized to the old, larger, x86 shape and is now stranded. The very optimisation work you want teams doing can orphan a commitment that was bought before the work happened. On the invoice this shows up not as a new charge but as a discount that quietly stopped applying.

Two numbers belong on every monthly review, and they are not the same thing. Coverage is the share of your eligible spend that a commitment is discounting — too low means you're overpaying On-Demand on a predictable baseline. Utilisation is how much of what you committed to was actually used — anything below ~98% means you have stranded commitment burning cash. A healthy program runs both high; this lesson is specifically about the case where utilisation has slipped, because that's the one you can't undo by waiting for next month's usage to recover.

Sam is the finance partner embedded with the platform team. At the monthly cost review the discount line looks healthy at a glance, but Sam asks the question that's now standard on the agenda: "What's our commitment utilisation, and is it still near 100%?" The dashboard says 84% on the Savings Plans and 55% on a block of Standard RIs — meaning the company is paying for roughly $3,800/month of reserved capacity that nothing is consuming, and it's contractually locked in. Coverage being fine is irrelevant; this is the utilisation gap.

The conversation isn't technical. Sam doesn't ask about instance families or regions in detail — she asks three things: what changed in usage right before utilisation dropped, can the unused commitment be put back to work, and if not, can any of it be recovered or exchanged. The engineering lead explains: one workload was right-sized (good), one migrated to Graviton (good), and both moves shrank the usage the old commitments were matching. The right-sizing gap can be closed by steering other eligible workloads under the Savings Plan; the migrated RIs are Standard and can't be exchanged, so the only recovery is selling them on the Marketplace at a haircut.

Sam adds utilisation as a permanent line on the finance pack — separate from coverage — and sets the expectation that it stays at or above ~98%. The deeper fix she pushes is sequencing: no new commitment gets approved until the relevant fleet is right-sized, so the floor can't shrink out from under it later. She also notes that Savings Plans have no resale market, so an over-sized one can't be unwound the way an RI can — which makes buying conservatively to the proven floor a finance discipline, not an engineering preference. A few months later utilisation is back to 99% and the next purchase is a Convertible RI that survived the following migration untouched.

The direct budget impact is a discount you already paid for that has stopped paying out. When utilisation slips from 99% to, say, 85% on a sizeable commitment, the bill doesn't show a new line item — it shows a saving that quietly evaporated, which is harder to spot and harder to explain in variance analysis. Per commitment the gap can look small; across a portfolio that drifted after a migration it reaches five figures a month, and every dollar of it is contractually locked for the rest of the term.

The reason this is more serious than most waste is that it's irreversible on your side. Ordinary cloud waste is self-correcting — turn the resource off and the cost stops. A commitment is take-or-pay: the obligation runs to term-end regardless. Standard RIs offer a partial escape through the Reserved Instance Marketplace, but you recover only the unused portion and only at a discount. Savings Plans have no resale market at all, so an over-sized one cannot be unwound — it must be either fed with matching usage or carried to the end. That makes conservative sizing a finance discipline, not an engineering nicety.

The metric to govern is utilisation, kept distinct from coverage on the monthly pack. Coverage tells you whether you're capturing available discounts; utilisation tells you whether the discounts you bought are actually landing. Healthy utilisation sits at or above ~98%. If it drops below that two reports running, you have stranded commitment, and the right move is to investigate what changed in usage — almost always a right-sizing or a migration that happened after the commitment was bought — and work the recovery ladder before it compounds.

The most important budget discipline is sequencing, and it's finance's to enforce: no commitment gets approved until the relevant fleet has been right-sized. Committing to an over-sized fleet locks a multi-year discount onto capacity that shouldn't exist, and strands it the moment the fleet is corrected. The order is always right-size, then commit, then commit to the proven floor rather than the average or the peak. Reversed, the company carries an obligation it can neither use nor unwind.

Commitments — Reserved Instances and Savings Plans — are how a mature cloud program gets 30 to 70 percent off the rate on predictable compute. But a commitment is take-or-pay: you pay for the reserved capacity every hour whether anything uses it or not. When a workload is right-sized, migrated, or retired after the commitment was bought, the commitment is left paying for capacity no one is consuming — a saving that has silently turned into a sunk cost locked in for the rest of the term.

The single number to ask for is commitment utilisation. High utilisation means the discounts you bought are landing; utilisation below the high-90s percent means you're carrying stranded commitment that can't simply be switched off. The discipline that prevents it is sequencing — right-size the fleet first, then commit only to the stable floor — so the bottom of usage never moves out from under the commitment you bought.

At one company the quarterly cloud review used to show a healthy-looking discount rate and stop there. The exec sponsor started asking a sharper pair of questions: "How much of what we committed to are we actually using, and when usage changes, what happens to the commitment?" The first time anyone looked, utilisation had quietly fallen into the 80s because a migration had stranded a block of reservations against instances that no longer existed.

Within two quarters the posture changed. The team made right-sizing a gate before any commitment was bought, shifted new purchases toward flexible instruments — Convertible RIs and Compute Savings Plans that follow the workload — and put utilisation on the cost pack as a first-class number next to coverage. When a later Graviton migration ran, the commitments followed automatically and utilisation never moved.

That's the right outcome state. The goal was never "never let utilisation dip" — it's "commit to the stable floor, buy instruments flexible enough to follow the architecture, and right-size before you sign." The discount line stopped being something to admire and became a confidence signal that the commitments were actually being consumed.

Commitment utilisation is one of the clearest signals of whether the cloud cost program is being run with discipline. High utilisation means the discounts the company committed to are actually being consumed; utilisation below the high-90s means money is being paid for reserved capacity nothing is using — and, critically, that gap is locked in for the rest of a one- or three-year term and can't simply be switched off. The trend on this one number says more about cost maturity than the headline discount rate does.

The risk to watch is the mirror image of under-buying: over-commitment that strands when usage changes. Because commitments are take-or-pay and Savings Plans have no resale, an aggressively sized commitment — or one bought before the fleet was right-sized — can become a multi-year sunk cost the day engineering improves the workload it was bought for. The mature posture is to right-size before committing, commit only to the predictable floor, and favour flexible instruments (Compute Savings Plans, Convertible RIs) while the architecture is still moving. The one question to ask is whether utilisation is high and stable; if it isn't, something was committed too early or too large.