When to Use AWS Savings Plans
vs. Reserved Instances

AWS offers two commitment-based discount mechanisms: Reserved Instances (RIs) and Savings Plans. Both require you to commit to a usage level for 1 or 3 years in exchange for discounts of up to 72% compared to On-Demand pricing. But they work differently, apply to different services, and carry different operational tradeoffs.

Most teams default to one or the other without understanding the full picture. This article explains when each is the right choice, how they interact, and the most common mistakes teams make when managing them.

How Reserved Instances Work

Reserved Instances are a billing construct, not an actual instance reservation. When you purchase an RI, AWS applies a discount to any running On-Demand instance that matches the RI's attributes: instance type, Region, OS, and tenancy. If no matching instance is running, the RI discount is wasted.

There are three RI types:

• Standard RIs: highest discount (up to 72%), least flexible. Locked to a specific instance type and size. Can be sold on the AWS Marketplace if unused.
• Convertible RIs: lower discount (up to 54%), but can be exchanged for a different instance type, OS, or tenancy during the term. Cannot be sold on the Marketplace.
• Scheduled RIs: deprecated and no longer sold. Not relevant for new purchases.

RIs can be purchased for a specific Availability Zone (which reserves capacity) or for a Region (which applies the discount across all AZs in the Region but does not reserve capacity). For most workloads, Regional RIs are preferable because they flex across AZs and work with Auto Scaling.

How Savings Plans Work

Savings Plans are a newer, more flexible commitment model. Instead of committing to a specific instance configuration, you commit to a dollar amount of compute usage per hour (e.g., $10/hr). AWS applies the discount rate to your usage until the committed amount is consumed each hour. Usage beyond your commitment is billed at On-Demand rates.

There are two Savings Plans types relevant to most teams:

• Compute Savings Plans: apply to EC2 (any instance family, size, AZ, OS, or tenancy), AWS Lambda, and AWS Fargate. Most flexible; discount is up to 66% compared to On-Demand.
• EC2 Instance Savings Plans: apply to a specific EC2 instance family in a specific Region (e.g., m5 in us-east-1), but flex across size, AZ, and OS. Higher discount than Compute Savings Plans (up to 72%) but less flexible than Compute Savings Plans.

A third type, SageMaker Savings Plans, applies only to SageMaker ML instance usage and is out of scope here.

Direct Comparison

When to Use Each

Use Standard RIs when:

• You are running a stable, long-lived workload on a specific instance type that is unlikely to change for 1-3 years (e.g., a fixed-size RDS database, a legacy application tier that does not autoscale)
• You need capacity reservation in a specific AZ (zonal RIs reserve capacity; Savings Plans do not)
• You want the option to exit the commitment by selling unused RIs on the AWS Marketplace

Use Compute Savings Plans when:

• Your workload uses multiple instance families, and you expect the mix to evolve (e.g., migrating from m5 to m6i, or shifting from EC2 to Fargate over the commitment period)
• You run Lambda or Fargate workloads with meaningful and predictable spend
• You want maximum flexibility with a single commitment instrument
• You are a startup or growing team that cannot predict which specific instances you will be running in 18 months

Use EC2 Instance Savings Plans when:

• You have a stable instance family commitment in a specific Region, but your instance sizes may change (e.g., you know you will always run m6i in us-east-1, but you are not sure whether those will be m6i.2xlarge or m6i.4xlarge)
• You want the near-RI discount level (up to 72%) but with more size flexibility than a Standard RI provides

How Savings Plans and RIs Interact

AWS applies discounts in this priority order:

1. Zonal Reserved Instances (applied first, to their specific AZ)
2. Regional Reserved Instances
3. EC2 Instance Savings Plans
4. Compute Savings Plans
5. On-Demand (remaining usage)

This means RIs and Savings Plans can coexist without conflict, and you can use them to cover different portions of your fleet. A common pattern: use Standard RIs for stable, predictable instance types you have run for years, and layer Compute Savings Plans on top to capture the flexible remainder of your compute spend.

Common Mistakes

Committing before understanding your baseline

Before purchasing any commitment, you need at least 30 days of Cost Explorer data showing your actual On-Demand usage patterns. Committing without this baseline often leads to over-purchasing in one area while leaving high-spend areas uncovered. Use the Cost Explorer Savings Plans Recommendations tool to get a data-backed starting point.

Purchasing All Upfront without modeling cash flow

All Upfront payments have the highest discount, but Partial Upfront and No Upfront options often have better NPV when you account for the opportunity cost of the cash. Model this with your actual discount rate before defaulting to All Upfront.

Treating Savings Plans as an RI replacement for everything

Savings Plans are more flexible, but they do not reserve capacity. If you are running latency-sensitive workloads in a specific AZ and need a capacity guarantee, a zonal RI is still the right instrument. This matters most in Regions where capacity can be constrained.

Forgetting that Savings Plans apply to the account that purchases them

In an AWS Organizations setup, Savings Plans purchased in the management account or a delegated account apply across the organization by default. RIs also share across the organization. If you purchase commitments in individual member accounts, they do not automatically share. Centralize commitment purchasing in your management account or a dedicated billing account.

Over-committing to cover 100% of usage

The goal is not 100% coverage. Targeting 70-80% of your stable, predictable baseline with commitments and leaving headroom for On-Demand provides better financial outcomes than over-committing, especially when workloads fluctuate month to month.

Practical Starting Point

For most teams that have been running on AWS for more than 6 months:

1. Pull 90 days of EC2 On-Demand spend from Cost Explorer, broken down by instance family and Region.
2. Identify your stable baseline: the compute footprint that has been running consistently every day for the past 3 months.
3. For any instance type or family that has been stable and you expect to continue, evaluate Standard RIs or EC2 Instance Savings Plans.
4. For the remaining variable or mixed compute spend, apply a Compute Savings Plan at 70-75% of that spend level.
5. Review coverage and utilization monthly in Cost Explorer and adjust at each renewal cycle.