AWS Savings Plans vs Reserved Instances: Weighing the Lock-In

A reserved instance commits to a specific instance type in a specific region, which earns a strong discount but only applies if you keep running that exact configuration. A savings plan commits to a dollar amount of compute spend per hour, applied automatically across instance types and, depending on the plan, across services and regions, at a slightly smaller discount than the most specific reserved instance option, in exchange for real flexibility if your infrastructure shifts.

AI workloads change faster than the traditional infrastructure this pricing model was designed around: a model gets replaced, an instance family gets swapped for a newer generation with better price to performance, or a project gets deprioritized entirely. A three year reserved instance on the wrong instance type after that change becomes a sunk cost you keep paying for as it depreciates in usefulness, not just on the balance sheet but in the actual work it can no longer usefully do for you.

The deeper discount a longer term offers is real, but it's a discount on a bet, not a discount on a certainty, and the size of that bet grows with every additional year of term length. Treat the extra discount on a three year term as compensation for taking on real forecasting risk, not as free money left on the table if you choose the shorter, safer option instead.

Because AI workloads shift instance types more often than traditional web infrastructure, following whichever GPU or compute generation currently offers the best price to performance, the flexibility a savings plan offers across instance families is usually worth more than the marginally deeper discount a reserved instance would offer on one specific type you might move away from within the term.

Look at your trailing three to six months of actual compute spend and commit against the lowest sustained level in that window, not the average and not the peak. This leaves genuine growth to run at on-demand or spot rates until it's proven durable enough to fold into next year's commitment, which is a far cheaper mistake to make than over-committing against usage that turns out to be a temporary spike.

Size a commitment with these steps:

1. Pull your trailing three to six months of actual compute spend.
2. Commit against the lowest sustained level in that window, not the average and not the peak.
3. Let genuine growth run at on-demand or spot rates until it has proven durable enough to fold into next year's commitment.
4. Favor a savings plan over a longer reserved instance term when your workloads are likely to change instance families.
5. Put the renewal date on the calendar and compare usage against the commitment at least one billing cycle before it renews.

Put the renewal date on the same calendar you use for other contract renewals, and pull actual usage against the commitment at least one billing cycle before that date. A commitment that made sense when it was purchased can be meaningfully oversized a year later if a workload moved, shrank, or was retired, and catching that before an automatic renewal is far cheaper than catching it after.

Bring whoever owns the underlying infrastructure into that review, not just finance. They're the ones who know whether the workload the commitment was sized against is still running the way it was when the commitment was purchased, and that context is what turns a renewal review from a rubber stamp into an actual decision.

A commitment sized correctly at purchase time doesn't always stay matched to a single workload. Say the project it was bought for ends up splitting into two: a steady production service and a separate, more variable research effort spun off from it. The original commitment now covers a blend of two different usage patterns, and treating the whole thing as still belonging to the original project can hide which piece is actually driving cost.

When that happens, allocate the existing commitment across both workloads based on actual usage rather than leaving the split undocumented, and evaluate any additional capacity the newer, more variable piece needs on its own terms rather than assuming it should inherit the same commitment structure as the steady piece it split off from. A variable workload is usually a poor fit for a new multi-year commitment even if the original workload it came from was a good one.

This kind of split is common enough after a reorg or a product pivot that it's worth checking for specifically whenever a commitment comes up for renewal, rather than only checking whether the total usage still clears the original commitment's size.