Skip to main content
FinOps
Cost Optimization
AWS
Reserved Instances
Savings Plans

AWS Reserved Instances & Savings Plans: A Strategic Buying Guide

Stop overpaying for predictable workloads. Learn exactly when to commit, how much to cover, and which discount program delivers the highest ROI for your infrastructure.
Published February 12, 2026 · 18 min read
Executive Summary

AWS On-Demand pricing is the most expensive way to run cloud infrastructure. For workloads with predictable, steady-state usage, AWS offers two primary discount mechanisms: Reserved Instances (RIs) and Savings Plans (SPs). Together, they can reduce your compute bill by up to 72%.

Yet the majority of organizations either under-commit (leaving money on the table) or over-commit (paying for capacity they never use). The difference between a well-executed commitment strategy and a naive one can be hundreds of thousands of dollars per year.

This guide provides the analytical framework, tooling, and decision trees you need to build a commitment portfolio that maximizes savings while preserving operational flexibility. We cover the full lifecycle: analyzing usage patterns, choosing the right instrument, sizing your commitments, and continuously optimizing coverage.

Reserved Instances vs Savings Plans: Understanding the Options

Before committing a single dollar, you need to understand the fundamental difference between the two programs. Reserved Instances were introduced in 2009 and are the original commitment discount. Savings Plans, launched in November 2019, represent AWS's modernized, simplified alternative. Both reduce your effective rate, but they differ significantly in scope, flexibility, and management overhead.

Head-to-Head Comparison

AttributeStandard RIConvertible RICompute SPEC2 Instance SP
Max Discount (3yr)Up to 72%Up to 66%Up to 66%Up to 72%
Term Options1 year or 3 years1 year or 3 years1 year or 3 years1 year or 3 years
Payment OptionsAll, Partial, No UpfrontAll, Partial, No UpfrontAll, Partial, No UpfrontAll, Partial, No Upfront
ScopeSpecific instance type, AZ or RegionSpecific instance type, RegionAny instance family, region, OS, tenancySpecific instance family & region
FlexibilityCannot change instance familyCan exchange for different configHighest — applies across servicesWithin instance family only
Capacity ReservationYes (AZ-scoped)NoNoNo
Marketplace ResaleYesNoNoNo
Applies ToEC2, RDS, ElastiCache, Redshift, OpenSearchEC2 onlyEC2, Fargate, LambdaEC2 only
Management OverheadHigh — manual matchingMedium — exchange processLow — automatic applicationLow — automatic application
Best ForStable, predictable EC2/RDS workloadsEC2 workloads likely to changeDynamic, multi-service environmentsStable EC2 within one family

The key takeaway: Savings Plans are easier to manage and more flexible, while Standard RIs offer slightly higher peak discounts and capacity guarantees. Most modern organizations use a blended strategy — Savings Plans for the flexible baseline, Standard RIs for known-stable workloads, and On-Demand or Spot for variable peaks.

The Commitment Decision Framework

Committing to Reserved Instances or Savings Plans without understanding your usage patterns is like signing a three-year lease on an office before knowing your headcount. The commitment decision framework ensures every dollar committed is backed by data.

Step 1: Establish a Usage Baseline

Before buying anything, you need at least 30 days of stable, production-grade usage data — ideally 90 days. This means no commitments during migrations, right after a major architecture change, or during seasonal ramp-up periods. Pull your data from AWS Cost Explorer and look at hourly usage patterns for EC2, RDS, ElastiCache, and any other services that support reservations.

Step 2: Identify Steady-State vs Variable Usage

Every workload has two components: a baseline floor (the minimum resources running 24/7) and a variable peak (additional capacity needed during business hours, traffic spikes, or batch jobs). Your commitment should cover only the baseline floor. Variable peaks should remain on On-Demand or Spot.

Warning: The Over-Commitment Trap

Committing to your average usage instead of your baseline is the single most expensive mistake in RI/SP purchasing. If your EC2 fleet averages 50 instances but drops to 30 at night, committing to 50 means you are paying for 20 idle reservations for 12 hours every day. Over a 3-year term, that wasted commitment can exceed the savings from the discount itself.

Step 3: Run the Break-Even Analysis

For each commitment option, calculate the break-even utilization — the percentage of time the reserved capacity must be used for the commitment to be cheaper than On-Demand. The formula is straightforward:

Break-Even Utilization = RI Effective Hourly Rate / On-Demand Hourly Rate

Example (m6i.xlarge in us-east-1):
On-Demand: $0.192/hr
1yr No Upfront RI: $0.121/hr → Break-even = 63%
1yr All Upfront RI: $0.114/hr → Break-even = 59%
3yr All Upfront RI: $0.072/hr → Break-even = 37.5%

If your instance runs more than 37.5% of the time,
a 3yr All Upfront RI saves money vs On-Demand.

For 24/7 production workloads, break-even is trivially met. The real value of this analysis is for workloads running 8-16 hours per day, where the margin between savings and loss is thinner.

Step 4: Choose Your Commitment Term

The decision between 1-year and 3-year terms is fundamentally about confidence in your architecture's stability. Use this decision tree:

Choose 3-year term when:
→ Workload has been stable for 6+ months
→ No planned migration (e.g., Graviton, containerization)
→ Cash flow allows upfront payment
→ The additional 15-25% discount justifies the lock-in risk

Choose 1-year term when:
→ Still optimizing architecture (rightsizing, Graviton migration)
→ Rapid growth may change instance mix within 12 months
→ First time purchasing commitments — start conservative
→ Using Convertible RIs or Compute Savings Plans for flexibility

Coverage Analysis: How Much to Commit

Coverage analysis answers the most critical question: what percentage of your On-Demand spend should be covered by commitments? The industry benchmark is 70-80% coverage of steady-state compute spend, but the optimal number depends on your specific usage patterns.

Using AWS Cost Explorer API for Coverage Analysis

AWS provides built-in recommendations, but for a rigorous analysis you should pull raw usage data and build your own coverage model. The following CLI command retrieves your Savings Plans coverage over the past 90 days, broken down by service:

# Pull Savings Plans coverage for the last 90 days
aws ce get-savings-plans-coverage \
  --time-period Start=$(date -d '-90 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output json > sp-coverage.json

# Pull RI utilization to find underused reservations
aws ce get-reservation-utilization \
  --time-period Start=$(date -d '-90 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["Amazon Elastic Compute Cloud - Compute"]
    }
  }' \
  --output json > ri-utilization.json

# Get RI purchase recommendations
aws ce get-reservation-purchase-recommendation \
  --service "Amazon Elastic Compute Cloud - Compute" \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --output json > ri-recommendations.json

# Get Savings Plans purchase recommendations
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --output json > sp-recommendations.json

Interpreting the Output

The coverage report shows three key metrics for each time period: SpendCoveredBySavingsPlans, OnDemandCost, and CoveragePercentage. A healthy portfolio looks like this:

Coverage LevelAssessmentAction
70-80%Optimal — good balance of savings and flexibilityMaintain; review quarterly
< 50%Under-committed — significant savings left on the tablePurchase additional SPs/RIs targeting 75%
>90%Over-committed — likely paying for unused reservationsCheck utilization; sell excess on Marketplace
50-70%Under-optimized — room for incremental improvementAdd Compute SP to cover the gap

The Layered Commitment Strategy

Rather than purchasing all commitments at once, build your portfolio in layers. This approach reduces risk and allows you to adjust as you learn:

Layer 1 — Compute Savings Plan (50-60% of baseline): Start here. Covers EC2, Fargate, and Lambda. Maximum flexibility. Commit to 50-60% of your minimum hourly compute spend.

Layer 2 — EC2 Instance Savings Plan (10-15% additional): For stable instance families you are confident about (e.g., m6i, r6g). Higher discount than Compute SP for the same commitment.

Layer 3 — Standard RIs for RDS/ElastiCache (as needed): Savings Plans do not cover RDS, ElastiCache, Redshift, or OpenSearch. Use Standard RIs for these services when usage is predictable.

Layer 4 — On-Demand + Spot (remaining 20-30%): Keep the top of your usage curve on On-Demand for predictability and Spot for fault-tolerant batch workloads.

Convertible vs Standard Reserved Instances

If you are going to use Reserved Instances (instead of or alongside Savings Plans), the choice between Standard and Convertible is one of the most consequential decisions you will make.

When Standard RIs Make Sense

Standard RIs offer the highest possible discount — up to 72% for 3-year All Upfront. They are the right choice when:

• Your workload runs on a fixed instance type with no plans to change (e.g., a production database on db.r6g.2xlarge)
• You need a capacity reservation in a specific Availability Zone for compliance or latency guarantees
• You want the option to sell on the RI Marketplace if plans change (Convertible RIs and SPs cannot be resold)
• You are purchasing RIs for non-EC2 services like RDS, ElastiCache, or OpenSearch where Savings Plans do not apply

When Convertible RIs Make Sense

Convertible RIs sacrifice roughly 6 percentage points of discount (66% vs 72% at 3yr All Upfront) in exchange for the ability to exchange your reservation for a different configuration at any time. This is valuable when:

• You are migrating to Graviton processors and want to exchange x86 RIs for ARM-based ones mid-term
• Your engineering team is actively rightsizing instances and the target size may shift
• You expect to change operating systems (e.g., Windows to Linux) during the commitment period
• You want RI-level discounts but with more flexibility than Standard RIs

Pro Tip: The Exchange Strategy

You can exchange a Convertible RI for a different instance type, OS, tenancy, or even payment option — as long as the new reservation's value is equal to or greater than the old one. Savvy teams use this to “upgrade” their reservations: buy Convertible RIs for current-gen instances, then exchange them for next-gen instances when AWS launches new families — capturing both the RI discount and the better price-performance of newer hardware.

Savings Plans Deep Dive: Compute vs EC2 vs SageMaker

AWS offers three types of Savings Plans, each targeting different levels of flexibility. Understanding the tradeoffs is critical to choosing the right instrument for your workload mix.

Compute Savings Plans

The most flexible option. Your commitment (expressed as $/hour) automatically applies to any EC2 instance usage regardless of region, instance family, size, OS, or tenancy. It also covers AWS Fargate (ECS and EKS) and AWS Lambda usage. Discounts are slightly lower than EC2 Instance Savings Plans (up to 66% vs 72% for 3yr), but the flexibility is unmatched.

Best for: Organizations running a diverse mix of compute services, containerized workloads on Fargate, or those actively migrating between regions and instance types. If you only purchase one type of commitment, this should be it.

EC2 Instance Savings Plans

Locked to a specific instance family and region (e.g., m6i in us-east-1), but flexible on size, OS, and tenancy within that family. Offers up to 72% discount — matching Standard RI pricing — with the simpler management model of Savings Plans (automatic application, no manual matching).

Best for: Workloads that are firmly anchored to a specific instance family and region. If you are running a fleet of m6i instances in us-east-1 and have no plans to change the family or region, EC2 Instance Savings Plans give you the best discount with less management overhead than Standard RIs.

SageMaker Savings Plans

Dedicated to Amazon SageMaker usage — covering SageMaker Studio notebooks, training jobs, real-time inference endpoints, batch transform jobs, and data processing. Offers up to 64% discount. These apply automatically across instance families, sizes, and regions within SageMaker.

Best for: Teams with consistent ML/AI workloads on SageMaker. If your SageMaker spend exceeds $5,000/month and is stable, this is a high-impact commitment. Note that Compute Savings Plans do not cover SageMaker, making this the only Savings Plan option for ML workloads.

Decision Matrix: Which Savings Plan to Buy

ScenarioRecommended PlanRationale
Multi-region, multi-service computeCompute SPMaximum flexibility across all compute
Stable EC2 fleet, single regionEC2 Instance SPHigher discount, predictable instance family
Heavy Fargate / Lambda usageCompute SPOnly SP type covering Fargate and Lambda
Production ML on SageMakerSageMaker SPOnly option for SageMaker discounts
First-time buyer, uncertain usageCompute SP (1yr)Lowest risk; learn before committing further
RDS / ElastiCache / RedshiftStandard RIsSavings Plans do not cover these services

Common Mistakes That Erode Savings

After working with dozens of organizations on commitment optimization, we consistently see the same mistakes repeated. Avoiding these pitfalls is as important as making the right purchases.

Mistake 1: Buying Too Early

The scenario: A startup launches on AWS and immediately buys 3-year RIs based on their initial architecture. Three months later, they migrate to Graviton for 20% better price-performance, but their x86 RIs are locked for 33 more months.

The rule: Wait until your architecture is stable and you have at least 30-90 days of production usage data. Never commit during the first 90 days of a new workload deployment, a major migration, or immediately after a re-architecture.

Mistake 2: Over-Committing to Peak Usage

The scenario: A company sees that AWS recommends $50/hr in Savings Plans based on their average usage. They buy the full recommendation without realizing their usage drops to $30/hr every weekend and holiday. Result: $20/hr of wasted commitment for roughly 30% of the year.

The rule: Commit to the P10 (10th percentile) of your hourly usage, not the average or the AWS recommendation. The AWS recommendation often targets maximum savings at the expense of utilization risk. Start at 60-70% of the recommendation and increase quarterly.

Mistake 3: Ignoring Flexibility in Favor of Maximum Discount

The scenario: An engineering team buys all Standard RIs to get the 72% discount. Six months later, they need to switch from m5 to m6i instances for better performance. The Standard RIs cannot be exchanged, and selling on the Marketplace nets only 50 cents on the dollar.

The rule: The 6% difference between Standard RIs (72%) and Compute Savings Plans (66%) is often worth the flexibility. Unless you are absolutely certain the instance type will not change, prefer Convertible RIs or Compute Savings Plans. The cost of being wrong far exceeds the extra discount.

Mistake 4: Set-and-Forget Management

The scenario: Commitments are purchased once and never reviewed. Over time, workloads shift, new services launch, and the portfolio drifts out of alignment. Utilization drops from 95% to 70% but no one notices because there is no review process.

The rule: Review your commitment portfolio monthly. Track utilization and coverage metrics. Set alerts for utilization dropping below 90%. Schedule quarterly “FinOps commitment reviews” to assess whether to add, exchange, or let expiring commitments lapse.

Mistake 5: Not Using the RI Marketplace

The scenario: A company decommissions a workload but lets the associated Standard RIs run out their term — paying the full commitment for capacity no one uses.

The rule: List unused Standard RIs on the AWS Reserved Instance Marketplace immediately. Even at a discounted price, recovering 40-60% of the remaining value is better than paying 100% for nothing. Note: only Standard RIs can be resold; Convertible RIs and Savings Plans cannot.

Case Study: Israeli Startup Saves $240K/Year with Strategic RI Purchasing

Company Profile

Industry: B2B SaaS (cybersecurity analytics platform)
Location: Tel Aviv, Israel
Team size: 85 engineers
Monthly AWS spend: $180,000 (pre-optimization)
Infrastructure: 120+ EC2 instances, 15 RDS databases, 8 ElastiCache clusters, EKS workloads on Fargate

The Challenge

The startup had grown rapidly from $40K/month to $180K/month in AWS spend over 18 months. Their cloud bill was the second-largest operating expense after salaries. The CFO mandated a 25% cost reduction without impacting product performance. Previous ad-hoc RI purchases covered only 30% of compute spend, and several RIs were underutilized after a partial Graviton migration left unused x86 reservations.

The HostingX Approach

HostingX conducted a comprehensive 4-week analysis and implemented a layered commitment strategy:

Week 1 — Usage Audit: Pulled 90 days of hourly usage data from Cost Explorer. Identified that the minimum baseline compute spend was $42/hr, while the average was $58/hr and the peak was $85/hr. Previous commitments targeted $55/hr (the average), resulting in $13/hr wasted during low-traffic periods.

Week 2 — Portfolio Restructuring: Listed 8 unused x86 Standard RIs on the Marketplace, recovering $18,000 of remaining value. Converted the RI strategy from Standard to a mix of Compute Savings Plans and targeted RIs.

Week 3 — New Purchases:
→ $28/hr Compute Savings Plan (1yr, No Upfront) — covering the stable baseline across EC2 and Fargate
→ $8/hr EC2 Instance Savings Plan (1yr, Partial Upfront) for the Graviton r7g fleet — higher discount for the stable database tier
→ Standard RIs for 12 RDS instances (db.r6g.xlarge, 1yr, All Upfront) — $4,200/month in savings
→ Standard RIs for 6 ElastiCache nodes (cache.r6g.large, 1yr, All Upfront) — $1,800/month in savings

Week 4 — Monitoring Setup: Deployed automated alerts for utilization dropping below 85%, monthly coverage reports, and quarterly review calendar.
Results After 6 Months
Monthly AWS spend: $160,000 → reduced to approximately $140,000 after commitments + rightsizing
Commitment coverage: 30% → 76% of eligible compute spend
RI/SP utilization: 97% (up from 72% with the old portfolio)
Annual savings: ~$240,000/year ($20,000/month reduction)
Effective discount rate: 48% blended across all committed spend
Payback period: Immediate for No Upfront; 2.5 months for Partial/All Upfront purchases

The critical insight from this engagement was that the startup's initial approach — buying Standard RIs for everything at the average usage level — was actually costing them money on underutilized reservations. By switching to a layered strategy anchored on the usage baseline (not the average), they achieved higher net savings with lower risk.

How HostingX Optimizes Your Commitment Portfolio

Managing Reserved Instances and Savings Plans requires continuous attention, deep AWS pricing knowledge, and tooling to track utilization and coverage. HostingX provides end-to-end FinOps services that take the guesswork out of commitment purchasing.

Our FinOps Commitment Management Service Includes:
Commitment Audit & Optimization: We analyze your existing RI/SP portfolio, identify underutilized commitments, and restructure for maximum savings. Typical clients see a 15-30% improvement in effective discount rates.

Coverage Analysis & Recommendations: Using proprietary tooling layered on top of AWS Cost Explorer data, we build a custom commitment model based on your actual hourly usage patterns — targeting 75-80% coverage at > 95% utilization.

Purchase Execution: We handle the purchasing process, including payment option selection (All Upfront, Partial, No Upfront), term optimization, and phased rollout to reduce risk.

Ongoing Monitoring: Monthly utilization and coverage reports, automated alerts for anomalies, and quarterly portfolio reviews with actionable recommendations.

Marketplace Management: For clients with Standard RIs, we manage listings on the RI Marketplace to recover value from unused reservations.

FinOps Training: We train your engineering and finance teams on commitment best practices, empowering them to make informed decisions about infrastructure spending.

Frequently Asked Questions

What is the difference between AWS Reserved Instances and Savings Plans?

Reserved Instances (RIs) are capacity reservations tied to a specific instance type, region, and OS, offering up to 72% discount. Savings Plans are flexible commitment-based discounts where you commit to a consistent hourly spend (measured in $/hour) for 1 or 3 years. Savings Plans automatically apply to any matching usage regardless of instance family, size, OS, or region (for Compute Savings Plans), making them easier to manage. RIs offer slightly higher discounts for identical configurations, while Savings Plans provide greater flexibility.

How much can I save with AWS Reserved Instances or Savings Plans?

Savings range from 30% to 72% compared to On-Demand pricing depending on the commitment type and payment option. 1-year No Upfront commitments save approximately 30-40%. 1-year All Upfront commitments save approximately 40-45%. 3-year No Upfront commitments save approximately 45-55%. 3-year All Upfront Standard RIs offer the maximum discount of up to 72%. Most organizations achieve 40-60% effective savings by combining commitment types with their On-Demand baseline.

Should I buy Standard or Convertible Reserved Instances?

Choose Standard RIs when your workload is stable and you are confident the instance type will not change for the commitment period — they offer the highest discount (up to 72%). Choose Convertible RIs when you anticipate changes in instance types, operating systems, or tenancy — they allow exchanges for equal or greater value and offer up to 66% discount. For most growing startups, Convertible RIs or Compute Savings Plans provide the best balance of savings and flexibility.

How do I determine the right coverage ratio for commitments?

Analyze at least 30-90 days of usage data using AWS Cost Explorer's RI/SP recommendations. Identify your baseline (minimum consistent usage) and commit to 70-80% of that baseline. Never commit to peak usage — cover peaks with On-Demand or Spot. Use the AWS Cost Explorer API or CLI to export hourly usage patterns and calculate the P10 (10th percentile) of your usage as the safe commitment floor. Review and adjust quarterly as your workloads evolve.

Can I sell unused Reserved Instances on the AWS Marketplace?

Yes, Standard Reserved Instances can be listed for sale on the AWS Reserved Instance Marketplace. You must have a US bank account, the RI must have at least one month remaining, and there is a 12% service fee on the sale. Convertible RIs and Savings Plans cannot be sold on the marketplace. This provides an exit strategy if your infrastructure needs change, though selling typically involves some discount to attract buyers. HostingX can manage the listing process to maximize recovery value.

Stop Overpaying for Predictable Workloads

The average HostingX client saves 40-55% on committed compute spend with a properly structured RI/SP portfolio. Let us analyze your usage and build a commitment strategy that maximizes savings without sacrificing flexibility.

Related Articles

HostingX Solutions company logo

HostingX Solutions

Expert DevOps and automation services accelerating B2B delivery and operations.

michael@hostingx.co.il
+972544810489
EmailIcon

Subscribe to our newsletter

Get monthly email updates about improvements.


© 2026 HostingX Solutions LLC. All Rights Reserved.

LLC No. 0008072296 | Est. 2026 | New Mexico, USA

Legal

Terms of Service

Privacy Policy

Acceptable Use Policy

Security & Compliance

Security Policy

Service Level Agreement

Compliance & Certifications

Accessibility Statement

Privacy & Preferences

Cookie Policy

Manage Cookie Preferences

Data Subject Rights (DSAR)

Unsubscribe from Emails