Reserved Instances vs. Savings Plans - Which One Saves You More Money

AWS has two ways to get lower prices in exchange for a commitment: Reserved Instances and Savings Plans. Both can reduce compute costs by 30-70%, depending on the term length and payment method. The real question is not which one is cheaper. The real question is which one you can commit to safely - without paying for resources you do not need.

How Reserved Instances work

An RI is a billing discount for a specific instance type in a specific region. For example, you buy a 1-year RI for m6i.xlarge in us-east-1. After that, any on-demand m6i.xlarge usage in that region gets the lower price automatically. The discount is large - up to 72% for a 3-year all-upfront commitment. But the restriction is strict. If you change that instance to m6i.large next month, the RI does not apply to the new size.

Convertible RIs give you more flexibility. You can exchange them for a different instance family during the term. The discount is smaller (typically 54% instead of 72% for a standard 3-year). But you are not stuck if your workload changes. The exchange process is manual and has rules. You can only exchange for equal or greater value.

How Savings Plans work

A Savings Plan is a commitment to spend a fixed dollar amount per hour on eligible usage. In return, you get a discount. For compute, there are two common types: Compute Savings Plans apply across EC2, Fargate, and Lambda in any region and any instance family. EC2 Instance Savings Plans are locked to one instance family in one region, but give a deeper discount. AWS also now offers Database Savings Plans for eligible database usage, including Amazon RDS.

The main difference from RIs is that Savings Plans follow your usage. If you move from m6i to m7g, or shift workloads from EC2 to Fargate, a Compute Savings Plan still applies. You commit to a spend level, not to a specific instance.

When to use which

• Stable workloads that will not change instance type: Standard RIs give the biggest discount.
• Teams that are actively right-sizing or modernizing (ARM migration, containerization): Use Compute Savings Plans. The flexibility is worth the slightly smaller discount.
• Mixed compute (EC2 + Fargate + Lambda): Compute Savings Plans. RIs only cover EC2.
• Database workloads: RDS RIs are no longer the only commitment option. Database Savings Plans can cover eligible RDS usage with more flexibility across supported database services, engines, instance families, sizes, deployment options, and regions. Use RDS RIs only when the workload is very stable and the RI discount beats the flexibility of a Database Savings Plan.

The coverage question

Do not try to cover 100% of your compute with commitments. For most teams, the best target is 60-75% commitment coverage on the stable baseline. Keep the remaining 25-40% on-demand for traffic spikes, testing, and flexibility. Over-committing costs more than under-committing. This is because unused commitments are pure waste.

Finoptic tracks your commitment coverage and utilization all the time. When utilization drops below 90% on any commitment, it flags the waste and recommends changes for the next purchase cycle. The goal is not the maximum discount. The goal is the maximum net savings after you subtract the cost of unused commitments.

How we approach it with customers

Our standard process has four steps. (1) Right-size everything first. (2) Wait 2-4 weeks for usage to become stable. (3) Commit on the stable baseline with Compute Savings Plans. (4) Add EC2 Instance Savings Plans or Standard RIs only for workloads that have not changed for 6+ months. This order is important. Committing before right-sizing is the most expensive FinOps mistake we see.

If you want to see what your commitment strategy should look like, we will model it for free as part of our cost assessment. Most customers find they are either under-committed (missing 20-30% in possible savings) or committed to the wrong things (paying for capacity they no longer use).