AWS Savings Plans vs Reserved Instances 2026: The Decision Guide Engineers Actually Need

By Dima Kramskoy — Senior Cloud Architect at DoiT International

The Question Everyone Gets Wrong

When I was handling cloud optimization tickets, this was the #1 question customers asked me: "Should we use Savings Plans or Reserved Instances?" I'd see it three, four times a week from different customers.

It's the wrong question.

The right question is: What does your workload look like in 12 months?

Here's why this reframe matters: An organization planning a Graviton migration will waste money on Standard RIs that can't follow their workloads to new instance families. A team with a rock-solid RDS cluster that hasn't changed configuration in two years is leaving money on the table with Compute Savings Plans when a Standard RI delivers 6–9 more percentage points of discount.

The SP-vs-RI decision isn't about products. It's about architectural direction. Your commitment strategy should mirror your infrastructure roadmap — not the other way around.

And here's the uncomfortable truth: most customers I work with don't know what their workload looks like in 12 months. They're not sure if they'll migrate to Graviton next quarter, move to containers, or double their compute. That's not a failure of planning — that's reality. If you don't know where your workload is heading, that IS your answer. Uncertainty = flexibility. Choose Compute Savings Plans at minimum — or better yet, let a tool carry the commitment risk for you entirely (more on that at the end).

Let me give you the framework I use with enterprise customers, updated for everything that changed in 2025–2026.

Quick Answer: Decision Flowchart

Before we go deep, here's the fast path:

START: What's your primary compute workload?
│
├─ EC2 only, single instance family, 12+ months stable
│   └─ → EC2 Instance Savings Plan or Standard RI
│       ├─ Need capacity reservation? → Zonal Standard RI
│       └─ Want simpler management? → EC2 Instance SP
│
├─ EC2 across multiple instance families
│   └─ → Compute Savings Plan
│
├─ Planning Graviton migration (x86 → arm64)
│   └─ → Compute Savings Plan (auto-applies to new family)
│
├─ Fargate, Lambda, or serverless-first
│   └─ → Compute Savings Plan (only type that covers these)
│
├─ RDS / Aurora / database tier
│   └─ Stable config, max discount? → Standard RI (up to 69%)
│   └─ Multi-engine, Gen 7+, flexibility? → Database SP (up to 35%)
│
└─ Actively re-architecting or migrating off AWS
    └─ → Don't commit. Use On-Demand/Spot until stable.

Quick Comparison Table

What Changed in 2025–2026

Four significant shifts since my last cost optimization review:

1. Database Savings Plans Launched (December 2025)

The biggest announcement from re:Invent 2025 for FinOps. Database Savings Plans cover 10 services — Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS, and OpenSearch.

The catch: only 1-year terms (no 3-year), No Upfront only, and they require Gen 7+ instances (db.r7g, db.m7g). Maximum discount is ~35%, well below the 69% achievable with Standard RDS RIs. So these aren't a replacement for DB RIs — they're a flexibility play for organizations with diverse, evolving database estates.

2. RI/SP Sharing Restrictions (June 2025)

AWS prohibited MSPs and resellers from sharing RI/SP discounts across multiple end customers. If you buy through a partner, your commitments are now restricted to your usage only. Direct enterprise buyers: largely unaffected.

3. Group Sharing Feature — GA (November 2025)

This one flew under the radar but solves a real pain point. You can now control exactly which accounts in your Organization benefit from shared commitments using two modes:

• Prioritized Group Sharing: Commitment applies to designated group first, then spills to the broader org
• Restricted Group Sharing: Complete isolation — only the designated group benefits

This kills the "wrong team benefits from our RI" problem that plagued consolidated billing for years. Uses Cost Categories to define groups. If you're running a multi-BU organization with chargeback models, this changes the game.

4. RIs Are NOT Deprecated

Despite recurring speculation, Reserved Instances remain fully supported. AWS pricing pages are actively maintained (last updated May 2026), Cost Explorer still generates RI recommendations, and RI Marketplace remains operational. AWS clearly favors Savings Plans in new feature development and documentation, but RIs aren't going anywhere.

One more thing: Savings Plans with commitments over $100/hour cannot be returned. Under $100/hour, you get a 7-day window within the same calendar month, with a maximum of 10 returns per year. At enterprise scale, these commits are permanent. Plan accordingly.

Deep Dive: Compute SP vs EC2 SP vs Standard RI vs Convertible RI

Here's the full comparison I wish existed when I was making these decisions:

*EDP customers cannot sell on RI Marketplace.

Billing Application Order (This Matters)

AWS applies discounts in this priority:

1. Reserved Instances apply first (to matching usage)
2. EC2 Instance Savings Plans apply second
3. Compute Savings Plans apply last (broadest net)

Within each tier, the highest savings-percentage usage gets covered first. This means you can safely layer all three without conflicts — AWS optimizes application automatically.

Workload Portability: When Flexibility Beats Discount

The discount gap between Compute SP (66%) and EC2 Instance SP (72%) is about 6 percentage points. At typical enterprise conditions (1-year, no-upfront), it narrows to 2–4 points. Let me show you when paying that "flexibility premium" is obviously correct.

Graviton Migration

Moving from x86 (m5, c5, r5) to Graviton (m7g, c7g, r7g):

• Compute SP: Seamless. Discount auto-applies to Graviton instances the moment you launch them.
• EC2 Instance SP: Breaks. m5 ≠ m7g — different instance family.
• Standard RI: Completely unusable for new instances. Stranded commitment.
• Convertible RI: Requires manual exchange, equal-or-greater value, and stays region-locked.

If you're on the Graviton migration path (and you should be — it's 20–40% better price-performance), Compute SPs are structurally superior.

Containerization / Serverless Transition

Moving from EC2 to ECS/Fargate or Lambda:

• Compute SP: Covers Fargate and Lambda automatically. Your discount follows you.
• Everything else: Zero coverage for container or serverless compute.

Cross-Region Expansion

Opening a new region or consolidating from 4 regions to 2:

• Compute SP: Discount applies globally across all regions.
• All others: Region-locked. Consolidation strands your commitments.

The Math

On $5M annual compute spend, a 6-percentage-point gap costs approximately $300K over 3 years. That sounds significant — until you realize one failed Graviton migration (because you can't afford to move off locked-in RIs) costs you the 20–40% performance improvement on your entire fleet. The flexibility premium is insurance, and it's cheap insurance.

The Anti-Patterns (What Happens When You Get It Wrong)

In 10+ years of cloud cost optimization, I've seen these mistakes cost organizations millions. Here are the five most expensive:

Anti-Pattern 1: Committing to Peak Instead of Baseline

The mistake: Buying commitments based on maximum observed usage.

What happens: You commit $50/hour because that's your Monday morning peak. Your sustained baseline is $35/hour. You're running at 70% utilization on your commitment — the other 30% is pure waste.

The cost: On a $50/hour commit, 30% waste = $131K/year burned.

The fix: Commit to 70–80% of your sustained floor (use 60–90 days of data). Cover spikes with Spot and On-Demand.

Anti-Pattern 2: Standard RIs for Workloads About to Migrate

The mistake: Buying 3-year Standard RIs for an m5 fleet with a Graviton migration on the roadmap.

What happens: Six months in, you're ready to move to m7g. Your Standard RIs can't follow. They're not convertible. If you're an EDP customer, you can't sell them on the Marketplace either. You're paying for instances you're no longer running.

The cost: A stranded 3-year RI on r5.4xlarge: ~$278/month commitment producing zero benefit for 30 remaining months = $8,340 wasted per instance. Scale that across a fleet.

The fix: If any architectural change is planned within the commitment window, use Compute SPs.

Anti-Pattern 3: Letting Commitments Expire Silently

The mistake: No expiration monitoring or renewal queuing.

What happens: A batch of RIs expires on a Tuesday. No one notices until the month-end bill arrives. Your effective rate jumps from $278/month to $736/month per r5.4xlarge — a 62%+ overnight cost increase.

The cost: A fleet of 20 instances reverting to On-Demand for even one month: ~$9,160 in unexpected spend.

The fix: AWS Budgets expiration alerts + queued Savings Plan purchases before the expiration date.

Anti-Pattern 4: Ignoring Non-EC2 Compute

The mistake: Only committing against EC2, while 40%+ of compute spend is in Lambda, Fargate, or EKS.

What happens: Significant serverless/container spend remains at full On-Demand rates. Organizations optimizing only EC2 commitments think they're "done" while leaving 20–30% savings on the table for their fastest-growing workloads.

The cost: $200K/year in Lambda + Fargate at On-Demand when a Compute SP would save 20–66% = $40K–$132K/year missed savings.

The fix: Audit ALL eligible services. A single Compute SP covers EC2, Lambda, and Fargate simultaneously.

Anti-Pattern 5: Committing During Active Re-Architecture

The mistake: Buying commitments while right-sizing, re-platforming, or migrating.

What happens: You commit $80/hour today. Over the next 6 months, optimization reduces your baseline to $55/hour. You're locked into $25/hour of waste for the remainder of your term.

The cost: $25/hour × 8,760 hours remaining on a 1-year term = $219K in stranded commitment.

The fix: Stabilize first, then commit. Use staged commitments that match your confidence level — small commits during migration, larger commits once usage patterns solidify.

Decision Framework

This is the table to screenshot:

The Layered Strategy (What I Recommend for Most Organizations)

Don't pick one type. Layer them:

1. Layer 1 — Compute SPs (60–80% of baseline): Cover your minimum compute floor with maximum flexibility
2. Layer 2 — EC2 Instance SPs: Add on top for families you're confident about (captures extra 6pp discount)
3. Layer 3 — Standard RIs: Reserve for ultra-stable data-tier workloads + capacity needs
4. Layer 4 — On-Demand/Spot: Keep variable and uncertain workloads uncommitted

Start with 1-year terms to validate patterns. After 12 months of stable usage data, layer in 3-year terms for your proven baseline (15–22 percentage points deeper discount).

How DoiT Automates This

Remember what I said about uncertainty? Most customers don't know what their workload looks like in 12 months. That's exactly the case FlexSave for Compute was built for.

Here's the pitch in one sentence: You get 1-year Savings Plan discount rates with zero commitment from you. DoiT carries the risk.

Here's what it does:

• Monitors your on-demand usage — analyzes what's running, what's stable, what's changing
• Auto-applies optimal discount mechanisms — covers eligible workloads that aren't already covered by your own RIs/SPs
• Adjusts continuously — migrating to Graviton? Scaling down? Moving to Fargate? FlexSave adapts without you touching a spreadsheet
• No commitment from you — DoiT carries the commitment risk. You get the discount. Walk away anytime.
• Covers the full compute stack — EC2, ECS, EKS, Fargate, Lambda, SageMaker (not just EC2)

For databases: AWS's new Database Savings Plans (Dec 2025) are your best bet for RDS and Aurora. FlexSave focuses on compute — where the uncertainty and flexibility needs are highest.

For visibility into what's happening across your commitment portfolio, DoiT Cloud Analytics gives you utilization, coverage, and waste metrics in one place — so you always know whether your strategy is working.

The combination solves both problems: FlexSave handles the "I don't know what's coming next" execution, Cloud Analytics provides the oversight. Uncertainty isn't a problem when your tooling adapts with you.

TL;DR

1. Compute SPs are the default choice for most organizations — the flexibility premium (2–4pp at typical terms) is almost always worth it for teams with any architectural change on the roadmap.

2. Standard RIs still win for ultra-stable workloads — database tiers, compliance-driven capacity reservations, and workloads with 18+ months of proven stability.

3. Database Savings Plans (new in Dec 2025) are a flexibility play, not a discount play — 35% vs. 69% for Standard RIs. Choose them for multi-engine, Gen 7+ estates.

4. Layer your commitments — Compute SP as your base, EC2 Instance SP for confident families, Standard RIs for stable databases, On-Demand for everything else.

5. Never commit during active migration — stabilize first, commit second. The cost of stranded commitments always exceeds the cost of waiting.

The right commitment strategy isn't about maximizing discount — it's about matching your commitment to your architectural direction.

Ready to stop managing this manually? Book a demo to see how FlexSave optimizes your AWS commitments automatically.

Dima Kramskoy is a Senior Cloud Architect at DoiT International with 20+ years in software engineering, 10 AWS certifications, and an AWS Community Builder (2026). He specializes in FinOps and cloud cost optimization for enterprise organizations.