Reserved instances vs savings plans vs commitments

PUBLISHED JUNE 16, 2026 · REVIEWED JUNE 16, 2026

Reserved instances vs savings plans vs commitments is the question of how three different discount instruments fit together under one cloud bill, and which one to reach for first. They are not alternatives competing for the same dollar. They are layers. Reserved instances and savings plans discount specific usage in exchange for a usage or hourly commitment. An enterprise commitment, like an AWS EDP or an Azure MACC, discounts your total spend in exchange for a dollar commitment. Understanding reserved instances vs savings plans vs commitments means seeing how the layers stack, where they overlap, and where committing to one undercuts another.

Providers rarely lay this out plainly, because the stack is where confusion lives and confusion favors the seller. A buyer who does not see how the instruments interact tends to double commit, overlap coverage, and pay for discounts twice. Clarity here is money.

Reserved instances vs savings plans vs commitments: what each one does

Reserved instances

A reserved instance commits you to a specific resource configuration, broadly defined, for a one or three year term in exchange for a discount against on demand. As of June 2026, reserved instances are resource specific and best suited to steady, predictable workloads whose shape you can name in advance (source: AWS and Azure reservation documentation). The discount is deep, but the commitment is narrow: change the workload and the reservation can strand.

Savings plans

A savings plan commits you to an hourly dollar amount of compute spend for a term, in exchange for a discount, with more flexibility across instance families and regions than a classic reservation. As of June 2026, savings plans trade a little discount depth for that flexibility (source: AWS Savings Plans documentation). They suit workloads that are steady in volume but may shift in shape.

Enterprise commitments

An enterprise commitment operates a layer up. An AWS EDP is a spend commitment over a one to five year term that unlocks tiered discounts scaling with the committed amount, and it stacks on top of reserved instances and savings plans (source: AWS EDP program terms). Azure MACC commits a fixed dollar amount of consumption and is complementary to reservations and savings plans (source: Microsoft MACC documentation). GCP offers committed use discounts plus automatic sustained use discounts, and as of June 2026 CUDs and SUDs do not double stack on the same resource (source: Google Cloud documentation). The commitment discounts the whole bill, the reservations and plans discount the workloads inside it.

How the layers stack

The mental model is simple once you see it. Reservations and savings plans reduce the unit cost of specific workloads. The enterprise commitment then applies its discount on top of the resulting spend, and the committed dollar amount counts your post reservation spend toward the tier. So optimizing reservations first lowers the spend that flows into the commitment, which is exactly why you size the commitment after you optimize, not before. This sequencing is the heart of how to size a cloud commitment correctly.

Get the order wrong and you commit to inefficiency. If you size an enterprise commitment to spend that is full of waste and unreserved on demand, you lock in a number you are about to drive down, and then you risk a shortfall when your own optimization succeeds.

Where the instruments overlap and bite

• Over reserving inside a committed estate can strand reservations if workloads change, while the commitment still demands its dollar floor.
• On GCP, CUDs and SUDs do not double stack on the same resource as of June 2026, so assuming both apply overstates your discount.
• Sizing a commitment before optimizing reservations commits you to spend you are about to reduce.
• Stacking deep multi year reservations under a deep multi year commitment compounds lock in and removes future leverage.

The waste point deserves emphasis. Reservations and savings plans should sit on workloads you have already right sized. Reserving a bloated instance just locks in the bloat. We treat the sequence in commitment coverage ratios explained, where the coverage target depends on how much of your estate is genuinely stable.

A practical order of operations

Right size workloads first, so you are not discounting waste. Apply reservations and savings plans to the stable core, matching reservation rigidity to workload stability and savings plan flexibility to workloads that shift. Then, and only then, size the enterprise commitment to the post optimization spend you are confident will recur, leaving genuinely variable spend on demand. Each layer covers what the layer below could not, and nothing is committed twice.

Matching the instrument to the workload

The instrument should fit the workload, not the other way around. A steady, named workload that will not change shape for years is a candidate for a reserved instance, where the deeper discount rewards the rigidity you can safely accept. A workload that is steady in volume but shifting in shape suits a savings plan, which flexes across instance families for a slightly shallower rate. Total spend that recurs regardless of the underlying mix belongs under the enterprise commitment. Force a rigid reservation onto a shifting workload and it strands, while leaving stable spend on demand under a commitment wastes the deeper instrument level discount you could have captured.

There is a leverage dimension too. The deeper and longer your reservations sit under a deep multi year commitment, the more layers of lock in you stack at once, and the less room you keep to move at renewal. As of June 2026 multi year lock in that removes future leverage is a recurring buyer risk, so the goal is enough coverage to capture the discount and not so much that every dollar is committed for years. Coverage is a dial, not a switch.

A worked illustration

Take a composite SaaS company spending ten million a year. Before optimizing, a provider proposes an enterprise commitment sized to the full ten million. The buyer instead right sizes, covers the stable core with savings plans for flexibility and reservations on the truly fixed workloads, which lowers effective spend, then sizes the enterprise commitment to the eight million of post optimization spend that genuinely recurs. The result captures the tiered commitment discount on top of the reservation savings, without committing to the two million of waste and variable spend that should never have been in the number. The instruments stack instead of fighting.

Seen clearly, reserved instances vs savings plans vs commitments is not a choice but a sequence. For the full framework see the cloud commitment structuring guide, and if you want the layers modeled against your actual usage before you sign, a commitment structuring and sizing service will sequence the optimization and the commitment so you never pay for the same discount twice.