AWS Savings Plans vs. Reserved Instances: A Framework for Platform Teams

The single biggest FinOps decision most platform teams make is how much to commit and for how long. The math looks like a bargain: give AWS a promise to spend $500K over the next year, get a 30% discount on that spend, book the savings. Then the business pivots, half the workload migrates to Fargate, and you spend the next 11 months paying for capacity you no longer use.

Committed capacity is a great tool. It is also the fastest way to lose seven figures on a bet against your own growth curve. The framework below is how to make the bet without losing the money.

What is the difference between Savings Plans and Reserved Instances?

Both are commitments to spend a certain amount over 1 or 3 years in exchange for a discount. They differ in what they cover and how flexible they are.

• Compute Savings Plans cover EC2, Fargate, and Lambda across any region, family, size, or operating system. Buy $10 per hour of commitment, and any compute usage up to that amount gets the discount, regardless of what shape it takes.
• EC2 Instance Savings Plans cover only a specific instance family in a specific region. Deeper discount, less flexible. Similar to a Convertible RI in scope.
• Reserved Instances apply to a specific service and instance type. Standard RIs are the least flexible. Convertible RIs let you change families within the term.
• RDS, ElastiCache, OpenSearch, Redshift, MemoryDB RIs are the only way to get commit-based discount on those services. Savings Plans do not apply here at all.

The framework flows from these constraints, not from a preference.

Which vehicle should each workload use?

Match the tool to the workload's flexibility profile.

The one line that gets skipped most often is the last. Committing on dev and test environments has ended more FinOps careers than any other single decision.

How much of the baseline should you commit?

Between 60 and 75% of steady-state usage. Never 100%.

Steady-state usage is the compute you have consistently run for the last 90 days, measured at the hour level, not the daily average. The 25 to 40% gap between commit and total usage is the buffer that absorbs growth spikes, new workloads, and the inevitable architectural change nobody warned you about.

The math is asymmetric, and this is the crux of the framework.

• Undercommit. You pay on-demand rates for the gap. The penalty is roughly 20% compared to a committed rate.
• Overcommit. You pay the committed rate for zero usage. The penalty is 100%.

Overcommitting by $100K costs you $100K. Undercommitting by $100K costs you $20K. Always err toward undercommitting.

When does a 3-year term make sense?

Only for the bottom 40% of your commitment stack. Never for the top.

A 3-year term is 15 to 20% deeper than 1-year. The extra discount is real, but so is the risk of being locked into capacity your business no longer needs. Three years is longer than most engineering roadmaps, longer than most cloud contracts, and longer than most CTOs stay in a role.

The safe pattern: layer your commitments so that the bottom 40% is on 3-year terms, the next 30% is on 1-year terms, and the top 30% is on-demand. Every 6 months, evaluate whether the bottom layer can grow by another 10%, based on the last 12 months of stability.

How do you monitor commitment health?

Two metrics, both should be visible in a weekly FinOps report.

• Coverage. Percentage of eligible on-demand spend covered by a commitment. Target 60 to 75%. Below 50%, you are leaving money on the table. Above 85%, you are one architecture change from stranded capacity.
• Utilization. Percentage of committed capacity actually used. Target above 95%. Below 90%, part of the commit is stranded and you should investigate why.

Watch the trend, not the point-in-time value. Coverage drifting down by 5 points per quarter means you are outgrowing your commitment stack and need to buy more. Utilization dropping by 5 points means a workload moved or shrunk and you may need to convert or sell.

What should trigger a new commitment purchase?

Three conditions, all of them together, not any one alone.

• Ninety days of steady usage at the new level. Not 30, not 60. Three months is the shortest window that filters out seasonal spikes and one-off migrations.
• A written business reason the workload is not going away. Contracted customer, regulated system, board-visible product. If nobody can say why the workload will still exist in 12 months, do not commit to 12 months.
• Coverage below 65%. If you are already covered, buying more concentrates risk rather than saving money.

Any two of the three, and you wait. All three, and you buy the smallest commitment that closes the gap, not the largest.

What is the exit strategy if we overcommit?

Different vehicles have different escape hatches.

• EC2 Standard RIs. Sellable on the AWS Marketplace, usually at a 5 to 15% discount to the remaining commit value. Not great, but recoverable.
• EC2 Convertible RIs. Not sellable, but you can exchange them for different families or sizes.
• Savings Plans. Not sellable, not exchangeable. Once purchased, the commitment holds for the full term. Assume zero exit optionality when buying.
• Reserved Instances for RDS and other managed services. Non-transferable. Same posture as Savings Plans.

The lack of exit on Savings Plans is the single biggest reason to under-buy rather than over-buy. There is no undo button.

The mistake to avoid

The most common seven-figure FinOps mistake is buying 3-year Savings Plans at 85% coverage during a growth quarter, then hitting a re-architecture that shifts half the workload to a service the plan does not cover. The commit stays. The usage moves. The team pays twice, at full retail for the new service and at committed rates for capacity nobody uses. Cap 3-year commitments at 40% of baseline, cap total commitment at 75%, and treat every purchase as an obligation your future self will have to honor whether the business still exists in that shape or not.