Choosing between Reserved Instances (RIs) and Savings Plans (SPs) shouldn’t require a finance degree. But the way AWS presents these options — with dozens of combinations of term length, payment option, instance family, region, and tenancy — makes it feel like one.

This guide cuts through it. We’ll use real numbers, show you the actual break-even math, and give you a framework for deciding what to buy (and when to buy nothing at all).

The Core Difference in 30 Seconds

Reserved Instances are a commitment to a specific instance configuration. You say “I will run an m5.xlarge in us-east-1 for the next year” and AWS gives you a discount.

Savings Plans are a commitment to a dollar amount of compute per hour. You say “I will spend at least $0.10/hour on compute for the next year” and AWS gives you a discount on usage up to that amount.

That’s the fundamental distinction. RIs lock you to a specific instance type (with some flexibility). Savings Plans lock you to a spending level but let you shift what you’re running underneath.

Real Pricing: m5.xlarge in us-east-1

Let’s make this concrete. Here’s what an m5.xlarge (4 vCPU, 16 GB RAM) actually costs under each model as of early 2026:

Pricing Model	Hourly Rate	Monthly (730 hrs)	Annual Cost	Savings vs On-Demand
On-Demand	$0.192	$140.16	$1,681.92	—
1-yr EC2 RI (No Upfront)	$0.120	$87.60	$1,051.20	37%
1-yr EC2 RI (All Upfront)	$0.113	$82.49	$989.88	41%
3-yr EC2 RI (No Upfront)	$0.081	$59.13	$709.56	58%
3-yr EC2 RI (All Upfront)	$0.070	$51.10	$613.20	64%
1-yr Compute SP	$0.122	$89.06	$1,068.72	36%
1-yr EC2 Instance SP	$0.120	$87.60	$1,051.20	37%
3-yr Compute SP	$0.084	$61.32	$735.84	56%
3-yr EC2 Instance SP	$0.081	$59.13	$709.56	58%

A few things jump out immediately:

EC2 Instance Savings Plans and Standard RIs have nearly identical pricing. This is by design. AWS wants you to migrate from RIs to Savings Plans, so they made the discount equivalent.

Compute Savings Plans cost slightly more than EC2 Instance SPs — you pay a 1–2% premium for the flexibility to change instance families, regions, and even move between EC2, Fargate, and Lambda.

3-year terms roughly double the discount compared to 1-year terms. But they also double your risk, which we’ll get to.

How Each Option Actually Works

Standard Reserved Instances

You commit to a specific combination of:

Instance type (e.g., m5.xlarge)
Region (e.g., us-east-1)
Platform (Linux/Windows)
Tenancy (shared/dedicated)

Within an instance family, you get size flexibility. If you buy an m5.xlarge RI but run an m5.2xlarge, the RI covers half of it. If you run two m5.large instances, the RI covers both. This normalization is based on a unit system where m5.large = 4 units, m5.xlarge = 8 units, and so on.

What you can’t change: instance family (m5 to m6i), region, or platform.

Convertible Reserved Instances

Same as Standard RIs, but you can exchange them for a different instance family, OS, or tenancy — as long as the new RI has equal or greater value. The trade-off: smaller discount (roughly 30% for 1-year vs 37% for Standard).

In practice, Convertible RIs are rarely worth it anymore. Savings Plans offer similar flexibility with less hassle.

EC2 Instance Savings Plans

You commit to a $/hour spend on a specific instance family in a specific region. For example: “$0.10/hour of m5 usage in us-east-1.”

You get size flexibility within the family (m5.large, m5.xlarge, m5.2xlarge all count). You don’t get family flexibility — if you migrate from m5 to m6i, the plan doesn’t apply.

Compute Savings Plans

You commit to a $/hour spend on any compute, anywhere. EC2 (any family, any region), Fargate, and Lambda all qualify.

This is the most flexible option. If you migrate from m5.xlarge in us-east-1 to m7g.xlarge in eu-west-1, the plan still applies. If you move a workload from EC2 to Fargate, it still applies.

The Break-Even Calculation

Commitment pricing only saves money if you actually use what you committed to. Here’s how to calculate the break-even utilization rate.

For a 1-year No Upfront EC2 RI on m5.xlarge:

RI hourly cost:    $0.120
On-Demand hourly:  $0.192
Monthly RI cost:   $0.120 × 730 = $87.60

Break-even hours = Monthly RI cost / On-Demand hourly rate
Break-even hours = $87.60 / $0.192 = 456.25 hours

Break-even utilization = 456.25 / 730 = 62.5%

If the instance runs more than 62.5% of the time (about 19 hours/day), the RI saves you money. If it runs less, you’d have been cheaper on On-Demand.

For a 3-year All Upfront EC2 RI:

Total upfront cost: $0.070 × 8,760 × 3 = $1,839.60
Equivalent monthly: $1,839.60 / 36 = $51.10

Break-even hours = $51.10 / $0.192 = 266.15 hours/month
Break-even utilization = 266.15 / 730 = 36.5%

The longer the term and the more you pay upfront, the lower the break-even utilization. A 3-year all-upfront RI breaks even at just 36.5% utilization. But you’re locked in for three years.

For Savings Plans, the math is identical — just substitute the SP hourly rate for the RI rate. The break-even utilization for a 1-year Compute Savings Plan on the same instance is:

$89.06 / $0.192 / 730 = 63.5%

Almost the same as the RI. The flexibility premium barely moves the needle on break-even.

When NOT to Buy Commitments

This matters more than the comparison table. There are specific situations where On-Demand (or Spot) is the right answer, and buying commitments would cost you money.

Volatile or Unpredictable Workloads

If your compute usage swings 3x between months — maybe you’re a seasonal business, or your product is pre-product-market-fit and usage patterns change quarterly — don’t commit. The break-even math assumes consistent utilization. Wild swings break the model.

Early-Stage Companies (< 18 months of stable infra)

Your architecture will change. Your instance types will change. Your regions might change. Buying a 1-year commitment when you might migrate from a monolith to microservices in six months is a bet against yourself.

Wait until your infrastructure has been stable for at least two quarters before committing.

Active Architecture Migration

If you’re in the middle of moving from x86 to Graviton, from EC2 to Kubernetes, from one region to another, or from self-managed to managed services — hold off. Buy commitments after the migration is done and usage has stabilized.

Dev/Staging Environments

These should not run 24/7 in the first place. Schedule them to shut down outside business hours (saving 65%+ immediately) rather than buying RIs for always-on non-production environments.

When Spot Instances Are Viable

For fault-tolerant batch workloads, Spot Instances give you 60–90% off On-Demand pricing with zero commitment. If your workload can handle interruptions (CI/CD, data processing, rendering, training jobs), Spot beats any commitment plan.

The Decision Framework

Use this flow to decide what to buy:

START
  │
  ├── Is this workload running 24/7 with consistent utilization?
  │     ├── NO → Use On-Demand or Spot. Don't commit.
  │     └── YES ↓
  │
  ├── Has the workload been stable for 6+ months?
  │     ├── NO → Wait. Use On-Demand. Revisit next quarter.
  │     └── YES ↓
  │
  ├── Are you planning to change instance families or regions
  │   in the next 12 months?
  │     ├── YES → Buy 1-year Compute Savings Plan (most flexible)
  │     └── NO ↓
  │
  ├── Is the workload tied to a specific instance family?
  │     ├── YES → Buy EC2 Instance Savings Plan or Standard RI
  │     │         (same price, SP is easier to manage)
  │     └── NO → Buy Compute Savings Plan
  │
  └── Term length?
        ├── High confidence for 3 years → 3-year (biggest discount)
        ├── Moderate confidence → 1-year (still 35%+ savings)
        └── Uncertain → Don't commit. Revisit in 3 months.

When in doubt, start with 1-year Compute Savings Plans with no upfront payment. You get 36% off, maximum flexibility, and no cash tied up. You can always go deeper on commitment once you’re confident.

Real-World Mistake: The 3-Year RI Overcommitment

A team we worked with bought 3-year Standard Reserved Instances for their entire production fleet in early 2024. Twenty m5.xlarge instances, all upfront. Total commitment: about $38,000.

Six months later, AWS released Graviton3-based m7g instances. The team benchmarked them and found 25% better price-performance. Their application ran perfectly on ARM.

The problem: Standard RIs can’t be converted to a different instance family. They were locked into m5 for another 2.5 years. They couldn’t use the m7g instances without effectively paying double — the RI charges plus On-Demand m7g charges.

Their options:

Sell on the RI Marketplace. Standard RIs can be listed for resale, but you typically get 10-20% less than face value and it can take weeks to find a buyer. They recovered about $25K of the remaining $31K commitment.
Run both and eat the loss. Some teams just accept the sunk cost and run On-Demand alongside unused RIs. Painful.
Wait it out. Use the m5 instances until the term expires, missing out on the m7g savings. This is what they partially did for the instances they couldn’t sell.

Total cost of the mistake: approximately $9,000 in unrealized savings over 2.5 years, plus the marketplace haircut. Not catastrophic, but entirely avoidable.

The fix that would have prevented this:

Buy 1-year terms instead of 3-year (you lose some discount but gain the ability to re-evaluate annually)
Use Compute Savings Plans instead of Standard RIs (they would have applied to the m7g instances automatically)
Commit to only 70–80% of steady-state usage, leaving headroom for changes

Building Your Commitment Strategy

Here’s the approach we recommend for most engineering teams:

Step 1: Measure Baseline Usage

Pull 3 months of hourly EC2 usage data from Cost Explorer. Identify the minimum sustained usage — the floor that never drops below a certain level, even during low-traffic periods.

aws ce get-cost-and-usage \
  --time-period Start=2025-12-01,End=2026-03-01 \
  --granularity HOURLY \
  --metrics "UsageQuantity" \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["Amazon Elastic Compute Cloud - Compute"]
    }
  }' \
  --output json > ec2_usage.json

Step 2: Commit to the Floor, Not the Average

If your baseline is 20 m5.xlarge instances but you regularly burst to 35, commit to 15–17 instances (70–85% of baseline). Cover the rest with On-Demand or Spot.

Over-committing is the most expensive mistake in commitment purchasing. Under-committing just means you pay On-Demand for the gap — which is where you started.

Step 3: Layer Your Commitments

Don’t buy everything at once. Stagger your purchases:

Month 1: Buy Compute Savings Plans covering 50% of stable baseline
Month 3: Review and add EC2 Instance SPs for workloads that haven’t changed
Month 6: Fill remaining gap with additional SPs based on 6 months of data

This layering approach means your commitments expire at different times, giving you regular opportunities to re-evaluate.

Step 4: Monitor Coverage

Check your Savings Plans utilization weekly. AWS provides this in Cost Explorer under Savings Plans → Utilization Report.

aws ce get-savings-plans-utilization \
  --time-period Start=2026-03-01,End=2026-03-18 \
  --output table

If utilization drops below 90%, investigate. Either you over-committed, or your usage pattern has changed and you need to adjust your next purchase.

Quick Reference: Which to Buy

Scenario	Recommendation
Stable EC2 fleet, same instance family for 1+ year	EC2 Instance Savings Plan, 1-year, no upfront
Mixed compute (EC2 + Fargate + Lambda)	Compute Savings Plan, 1-year, no upfront
Absolutely certain about instance type for 3 years	Standard RI, 3-year, all upfront (maximum discount)
Planning Graviton migration	Compute Savings Plan (covers both x86 and ARM)
Mostly Spot-eligible workloads	Don’t buy commitments. Use Spot.
Less than 6 months of stable usage data	Don’t buy commitments yet. Wait.
Dev/staging environments	Don’t buy commitments. Schedule shutdown instead.

Final Thought

The best commitment strategy is the boring one: start small, go short-term, pick the flexible option, and increase commitment as your confidence grows. The engineers who get burned are the ones who chase maximum discount percentage without accounting for what might change.

A 36% savings on a Compute SP you fully utilize is worth more than a 64% savings on a 3-year RI you need to sell on the marketplace at a loss eight months in.

If tracking all of this across multiple accounts and instance families sounds tedious — it is. Tools like Xplorr can continuously monitor your usage patterns and recommend the right commitment level automatically. But the framework above gives you everything you need to make the decision yourself.

Keep reading

See how Xplorr helps → Features

Xplorr finds an average of 23% in unnecessary cloud spend. Get started free.