How to Avoid Stranded Commitments After Rightsizing

Last updated: June 2026

Written by Fredrik Filipsson and reviewed by Morten Andersen. Method: See, Cut, Lock, Run. We have optimized $420M+ in cloud spend across 500+ environments.

A stranded commitment is a reservation or savings plan you keep paying for but can no longer fully use, because the workload it was bought for has since been rightsized, moved, or retired. Avoiding stranded commitments after rightsizing comes down to one rule with three supports: commit only after you cut, and only against the stable floor that survives the cut, using instruments flexible enough to follow the workload. This article is part of our commitment cluster; the pillar it links up to is the complete guide to cloud commitment management. Buying commitments is the Lock step in our See, Cut, Lock, Run method, and the order is always Cut before Lock.

What is a stranded commitment?

A stranded commitment is prepaid or term-committed capacity you can no longer match to live usage, so the discount disappears while the obligation remains. With AWS, a standard Reserved Instance bought against an m5.2xlarge fleet is stranded the moment you rightsize that fleet to m5.large and have nothing else consuming the larger size. A Compute Savings Plan is more forgiving because it commits to a dollar-per-hour of spend rather than a specific instance, but it still strands if your total eligible usage falls below the committed rate. Either way you are paying for a discount on capacity you removed, which is the opposite of what optimization is supposed to do.

Why does rightsizing strand commitments?

Rightsizing strands commitments because it changes the very baseline a commitment was sized against. Reservations and savings plans are bets on future usage; you buy a one or three year discount in exchange for guaranteeing a level of consumption. Rightsizing deliberately lowers and reshapes that consumption, so any commitment placed before the cut is now larger than the workload it covers. This is why sequencing matters more than any single instrument choice: if you commit on an un-rightsized estate, you are locking a multi-year discount onto resources you have already decided to shrink. The discipline is identical to the one behind setting a commitment coverage target, where the target is always the clean, stable baseline rather than the inflated one.

How do you avoid stranded commitments, step by step?

These five steps keep every commitment matched to capacity you will actually keep.

1. Rightsize and clear waste before you commitFinish rightsizing, schedule non-production to off-hours, and remove idle and zombie resources first. The result is a baseline that reflects steady-state demand rather than accumulated waste.
2. Size commitments to the post-rightsize floorCover only the stable usage that survives the cut, not the pre-cut peak. The result is that no commitment ever outlives the resource it was bought for.
3. Prefer flexible instrumentsUse Compute Savings Plans and convertible reserved instances so coverage can follow the workload across instance families, sizes, operating systems, and regions. The result is that a later architecture change re-targets coverage instead of stranding it.
4. Ladder coverage in tranchesBuy in staged tranches as each layer of usage proves stable rather than committing the full recommendation at once. The result is that a single future cut can only ever strand one small tranche, never the whole program.
5. Monitor utilization and remediateTrack coverage and utilization continuously and act early: exchange convertibles, list unused standard RIs on the Marketplace, or re-target a Savings Plan. The result is that drift is corrected within days, not discovered at renewal.

Should you rightsize or buy commitments first?

Rightsize first, then commit. Buying commitments on an un-rightsized estate is the single most common cause of stranded spend we see, because it guarantees you a discount on capacity you are about to delete. The correct order is the Cut step before the Lock step: eliminate idle and oversized resources, schedule what can be scheduled, then read the remaining steady-state usage as your commitment floor. If you have inherited an estate that was committed in the wrong order, you do not unwind the commitments first; you run eligible workloads into them until they expire while you rightsize everything else, then rebuild coverage cleanly. Pairing this with a modeled savings plan commitment ladder makes the floor explicit before any money is spent.

How do you fix a commitment that is already stranded?

You remediate based on the instrument. A convertible reserved instance can be exchanged for one that matches current usage, with equal or greater value, at no extra fee. An unused standard RI can be listed for sale on the AWS Reserved Instance Marketplace to recover some of its remaining value. A Compute Savings Plan can be re-targeted simply by running other eligible EC2, Fargate, or Lambda usage under it, since it commits to spend rather than to a specific resource. For anything that genuinely cannot move, the only economic move left is to consolidate eligible workloads onto it until the term ends. The lesson, every time, is that the instrument you choose up front decides how recoverable a mistake will be later.

Instrument behavior, exchange rules, and Marketplace eligibility reflect AWS as of June 2026. Verify current commitment and exchange terms in the linked AWS documentation before acting, because commitment products change.

Frequently asked questions

The short version

Stranded commitments are a sequencing failure, not a bad-luck event. Cut first, size to the clean floor, prefer flexible instruments, ladder the purchase, and monitor utilization so any change stays recoverable. When you want the estate rightsized and the coverage rebuilt correctly, that is exactly what our commitment management service delivers.