EC2 Instance Savings Plans: Complete Guide to 72% Savings

You're running EC2 instances around the clock and watching your AWS bill climb. You know Savings Plans can help, but you've landed on this page because you want specifics: What exactly are EC2 Instance Savings Plans, and when do they make sense over Compute Savings Plans?

Here's the headline number: EC2 Instance Savings Plans offer up to 72% off On-Demand rates, the highest discount available for EC2 workloads. That 6% edge over Compute Savings Plans (which cap at 66%) translates to real money at scale.

But there's a catch. EC2 Instance Savings Plans lock you to a specific instance family and region. This guide covers everything you need to know: how they work, when to choose them over alternatives, real cost calculations, and how to avoid the mistakes that waste your commitment.

What Are EC2 Instance Savings Plans

EC2 Instance Savings Plans are a commitment-based pricing model where you agree to a specific dollar-per-hour ($/hour) spend on a particular instance family in a chosen AWS Region. In return, AWS gives you a discount of up to 72% off On-Demand rates.

The commitment isn't tied to specific instances. It's a billing-level discount that automatically applies to eligible usage within your committed family and region. This means you don't need to worry about which specific instances receive the discount; AWS handles that optimization for you.

A quick clarification on terminology: AWS sometimes uses "EC2 Savings Plans" to refer to EC2 Instance Savings Plans. They're the same thing. I'll use both interchangeably throughout this guide.

How the Commitment Works

When you purchase an EC2 Instance Savings Plan, you commit to spending a consistent amount measured in dollars per hour. For example, a $10/hour commitment for the m5 family in us-east-1 means:

1. Every hour, AWS applies Savings Plans pricing to your eligible m5 usage in us-east-1
2. Your commitment covers usage up to $10/hour at the Savings Plans discounted rate
3. Any usage beyond the commitment is charged at On-Demand rates
4. If your usage is less than the commitment, you still pay the full commitment amount (unused portion is lost)

Critical detail: The hourly commitment is the Savings Plans rate, not the On-Demand equivalent spend. A $10/hour commitment might cover $20-30/hour of On-Demand equivalent usage depending on your discount percentage.

AWS defines a year as 365 days (31,536,000 seconds), and three years as 1,095 days. This matters for precise cost modeling.

What Makes EC2 Instance SP Different

EC2 Instance Savings Plans sit between Compute Savings Plans and Reserved Instances in terms of flexibility:

Higher discount than Compute SP: Up to 72% versus 66%. That 6% difference compounds significantly at scale. On $10/hour of commitment over 3 years, you're looking at roughly $15,000 in additional savings.

Less flexibility than Compute SP: You're locked to a specific instance family (like m5) and a specific region (like us-east-1). Compute Savings Plans work across any family and any region.

More flexibility than Reserved Instances: Unlike Standard RIs that lock you to a specific configuration, EC2 Instance Savings Plans let you change size, OS, tenancy, and AZ within your committed family and region.

No capacity reservation: EC2 Instance Savings Plans don't guarantee capacity. If you need guaranteed capacity, combine them with On-Demand Capacity Reservations. The SP discount applies automatically to ODCR usage.

How Commitment and Pricing Work

Understanding the commitment structure helps you make the right trade-off between upfront payment and discount depth. The pricing varies based on term length, payment option, instance family, region, and operating system.

Let me walk you through each dimension that affects your discount.

Term Length Options (1-Year vs 3-Year)

You have two term options:

1-year term: Lower commitment, lower discount. Use this when you're less certain about long-term infrastructure stability or want flexibility to adjust your strategy after 12 months.

3-year term: Higher commitment, maximum discount potential. The savings increase significantly, but you're locked in for three times longer. AWS defines three years as exactly 1,095 days.

You cannot change the term length after purchase. Choose based on your confidence in workload stability.

Payment Options and Discount Levels

Three payment options are available for each term length:

The combination of 3-year term with All Upfront payment provides the maximum possible discount (up to 72%). But this requires locking up capital for the full term.

Discount Ranges by Configuration

The actual discount percentage varies based on several factors. Here are typical ranges:

• 1-year, No Upfront: ~30-40% savings
• 1-year, All Upfront: ~40-50% savings
• 3-year, No Upfront: ~50-60% savings
• 3-year, All Upfront: Up to 72% savings

Memory-optimized families (X2, X1, X1e) often offer higher savings percentages. The exact rates vary by family, region, and OS; check AWS Savings Plans pricing for current rates.

EC2 Instance Savings Plans vs Compute Savings Plans

This is the comparison that matters most for your decision. Both offer significant savings, but they make fundamentally different trade-offs between flexibility and discount depth.

If you've already read my Compute vs EC2 Savings Plan comparison, you'll recognize some of this. Here I'm focusing specifically on when EC2 Instance Savings Plans make sense.

Side-by-Side Comparison

The critical insight: EC2 Instance Savings Plans apply before Compute Savings Plans in the billing calculation. This matters when you have both types.

Decision Framework: Which Should You Choose?

Here's the flowchart I use to help teams decide:

The key takeaway: If you answer "yes" to any of the first three questions, Compute Savings Plans are likely your better choice. EC2 Instance Savings Plans only make sense when you can confidently answer "no" to all flexibility questions.

The Layered Approach (Recommended)

For organizations with mixed workload characteristics, AWS and FinOps practitioners recommend a layered pricing strategy:

Base layer: EC2 Instance Savings Plans for your stable, predictable minimum usage on known instance families.

Flexibility layer: Compute Savings Plans for variable usage that spans multiple families, regions, or services.

On-Demand: For spiky, unpredictable, or short-term workloads where commitment doesn't make sense.

Spot: For fault-tolerant, interruptible workloads where cost savings (up to 90%) outweigh availability guarantees.

This approach lets you capture the maximum 72% discount where your usage is predictable while maintaining flexibility for everything else.

EC2 Instance Savings Plans vs Reserved Instances

You might be wondering where Reserved Instances fit into this picture. This comparison addresses a common question from AWS re:Post forums: "What are the main differences between EC2 Instance Savings Plans and Reserved Instances?"

Three-Way Comparison Table

Key Differences That Matter

Marketplace resale: This is the one advantage Reserved Instances still have. If your workload disappears, you can sell Standard RIs on the RI Marketplace. Savings Plans cannot be sold or transferred.

Modification options: Convertible RIs can be exchanged for different configurations. Savings Plans cannot be modified after purchase; you're locked in.

Flexibility: EC2 Instance Savings Plans are more flexible than Standard RIs within your family and region. You can change size, OS, tenancy, and AZ without modification.

Simplicity: Savings Plans are easier to purchase and manage. No need to match specific configurations to specific instances.

Why AWS Recommends Savings Plans Over RIs

AWS now recommends Savings Plans for most use cases. The reasoning is straightforward:

1. Simpler purchasing and management with automatic application to eligible usage
2. Better flexibility for modern workloads that change over time
3. No need to manage configuration-specific commitments like RI exchanges

The exception: If marketplace resale is critical for your risk management, Standard RIs still offer that option. For everything else, Savings Plans are the modern approach.

Understanding Flexibility and Limitations

One of the most confusing aspects of EC2 Instance Savings Plans is understanding exactly what you can and cannot change. Let me clarify this with specific examples.

What IS Flexible (Size, OS, Tenancy, AZ)

Within an EC2 Instance Savings Plan commitment, you CAN change:

Instance size within the family. Move from c5.xlarge to c5.2xlarge to c5.4xlarge freely. The discount applies to any size within your committed family.

Operating system. Move from Windows to Linux or vice versa. The discount applies regardless of OS within your committed family and region.

Tenancy. Move from Default to Dedicated tenancy. Both are covered.

Availability Zone. Move from us-east-1a to us-east-1b within the same Region. AZ choice doesn't affect discount eligibility.

What is NOT Flexible (Family, Region, Service)

With EC2 Instance Savings Plans, you CANNOT change:

Instance family. A commitment to m5 does NOT apply to m6i, c5, r5, or any other family. This is the critical lock-in to understand.

Region. A commitment to us-east-1 does NOT apply to us-west-2 or any other Region.

Service. EC2 Instance Savings Plans do NOT apply to Fargate or Lambda. Only Compute Savings Plans cover those services.

Special Limitations to Know

A few edge cases catch people off guard:

U-type (high memory) instances: Only virtual u-type instances are covered. U-type metal instances are NOT supported by EC2 Instance Savings Plans.

Dedicated Instance fee: The $2/hour dedicated fee charged per Region with at least one Dedicated Instance running is NOT discounted by Savings Plans.

Container services: EC2 instances running in EKS, ECS, and EMR clusters ARE covered by EC2 Instance Savings Plans (within your committed family and region). However, the EKS control plane fee is NOT covered.

Real Cost Calculations with Examples

Abstract percentages don't tell the full story. Let me show you real cost calculations with actual numbers so you can estimate savings for your own workloads.

Note: These examples use representative rates. Actual rates vary by family, region, and time. Use the AWS Savings Plans pricing page or Cost Explorer for current rates. For a complete breakdown of On-Demand pricing by instance type, see the Amazon EC2 pricing guide.

Example 1: Basic m5 Instance Commitment

Scenario: You have 10 m5.xlarge instances running 24/7 in us-east-1 on Linux.

Monthly cost calculation:

• On-Demand: 10 instances x $0.192/hr x 730 hours = $1,401.60/month
• With EC2 Instance SP: 10 x $0.121/hr x 730 = $883.30/month
• Monthly savings: ~$518/month
• Annual savings: ~$6,216/year

Your hourly commitment would be $1.21/hour (not $1.92). Remember: you commit to the SP rate, not the On-Demand equivalent.

Example 2: Maximum Savings (3-Year All Upfront)

Scenario: Same 10 m5.xlarge instances, but maximizing discount with 3-year All Upfront payment.

Monthly cost calculation:

• On-Demand: $1,401.60/month
• With 3-yr All Upfront SP: 10 x $0.054/hr x 730 = $394.20/month equivalent
• Monthly savings: ~$1,007/month
• 3-year total savings: ~$36,252

The upfront payment is significant (roughly $14,200 for this commitment), but the 3-year savings are substantial.

Example 3: Mixed Usage Within Family

Scenario: You run various c5 instance sizes throughout the month, not a consistent fleet.

Calculation:

• Total On-Demand: (500 x $0.17) + (200 x $0.34) + (30 x $0.68) = $173.40
• Total with SP: (500 x $0.107) + (200 x $0.214) + (30 x $0.428) = $109.14
• Savings: $64.26 (~37%)

The flexibility within the c5 family means you don't need to predict exact instance sizes. Your commitment covers any mix.

Breakeven Analysis: When Commitments Pay Off

Before committing, calculate how long you need to run the workload to break even:

Breakeven Formula:

Breakeven months = (1 - discount %) x Term months

For a 1-year, No Upfront commitment with ~37% discount:

• Breakeven: ~7-8 months of consistent usage

For a 3-year, All Upfront commitment with ~72% discount:

• Breakeven: ~10-12 months of consistent usage

The implication: If your workload might not last beyond the breakeven period, reconsider the commitment. A 3-year commitment that you abandon after 6 months is worse than paying On-Demand.

For help modeling costs with your specific instance types, the EC2 pricing calculator can help you establish your On-Demand baseline.

When to Choose EC2 Instance Savings Plans

Now that you understand the mechanics, let's get practical. Here's when EC2 Instance Savings Plans are the right choice, and when you should look elsewhere.

Ideal Use Cases

EC2 Instance Savings Plans are best when:

Predictable, stable workloads on specific instance families. Production databases that have run on r5 for two years and will continue. Core application servers on a proven instance family.

Single-Region deployments. Your production environment is firmly established in one Region with no plans to migrate or expand.

Maximum savings priority over flexibility. You've done the math and the extra 6% over Compute SP is significant for your spend level.

Established instance family strategy. You've already right-sized your workloads and know your optimal instance families. You're not in the middle of optimization or migration.

When to Choose Compute Savings Plans Instead

Prefer Compute Savings Plans when:

• Multi-Region workloads that may shift between Regions
• Instance family uncertainty because you may migrate from m5 to m6i or Intel to Graviton
• Serverless adoption plans with Fargate or Lambda in your roadmap
• Workload migration from EC2 to containers or serverless
• Early cloud journey where you're still discovering optimal configurations

When to AVOID EC2 Instance Savings Plans

Be honest with yourself about these scenarios:

If you might migrate instance families. Planning to move from m5 to m6i or c5 to c6g in the next 1-3 years? Your m5 commitment keeps charging while your new workload pays On-Demand. You effectively pay double.

If workloads are unpredictable or seasonal. Committing to $10/hour when your usage varies from $5 to $20/hour means significant waste.

If you need marketplace resale. Savings Plans cannot be sold. If exit flexibility is critical, Standard Reserved Instances offer marketplace resale.

If you're uncertain about long-term architecture. The immutability is real. You cannot modify, exchange, or cancel a Savings Plan. Make sure your confidence matches your commitment.

How to Buy EC2 Instance Savings Plans

If you've decided EC2 Instance Savings Plans fit your workload, here's how to purchase them effectively.

Step-by-Step Purchase Process

1. Access the console: AWS Billing and Cost Management > Savings Plans
2. Choose plan type: Select "EC2 Instance Savings Plans"
3. Select Region: Choose the AWS Region for the commitment
4. Select instance family: Choose the instance family (e.g., m5, c5, r5)
5. Choose term: Select 1-year or 3-year term
6. Enter hourly commitment: Specify the $/hour commitment amount
7. Select payment option: No Upfront, Partial Upfront, or All Upfront
8. Review and purchase: Add to cart and submit order

Using the Purchase Analyzer

Before committing, use the Savings Plans Purchase Analyzer to model scenarios:

• Estimate cost, coverage, and utilization impact before buying
• Model different scenarios with customizable parameters
• Adjust lookback period (7, 30, or 60 days) based on workload stability
• Exclude expiring Savings Plans from analysis to see true coverage needs

The Purchase Analyzer helps you avoid the most common mistake: over-commitment. For a broader look at tools that help estimate AWS costs, see the guide to AWS cost estimation tools.

The 7-Day Return Policy (Risk Mitigation)

AWS offers a limited return window for qualifying purchases. You can return a Savings Plan if ALL of these conditions are met:

• Hourly commitment is $100 or less
• Purchased within the last 7 days
• Purchased in the same calendar month (UTC time)
• Return limit not reached (max 10 returns per management account per calendar year)

When returned:

• 100% refund for any upfront charges (reflected in bill within 24 hours)
• Usage covered by the plan is charged at On-Demand rates retroactively

This policy provides a safety net for smaller commitments. Use it to test your commitment sizing.

Queuing Future Purchases

You can schedule Savings Plan purchases to start on a future date:

• Queue purchases up to 3 years in advance
• Specify exact start time (to the second)
• Upfront/recurring fees only charged when the queued purchase processes
• Can delete queued purchases before start date

This feature is essential for renewals. Queue your replacement plan before the current one expires to avoid coverage gaps.

Monitoring and Optimizing Your Savings Plans

Purchasing is step one. Ongoing monitoring ensures you're getting expected value and helps you plan renewals intelligently.

Understanding Utilization Reports

The utilization report shows the percentage of your commitment being used:

Utilization Formula:

Utilization % = (Usage billed at SP rates / Hourly commitment) x 100

Example: $10/hour commitment, $9.80 billed at SP rates = 98% utilization.

Target: 100% utilization means you're using everything you pay for. Below 100% means you're paying for unused commitment.

Access utilization reports at: Billing and Cost Management console > Savings Plans > Inventory > Select plan > View utilization report.

Coverage Reports and Gap Analysis

The coverage report shows what percentage of eligible On-Demand spend is covered by Savings Plans:

Key metrics to monitor:

• On-Demand spend not covered
• Average coverage percentage
• Potential monthly savings vs On-Demand

Low coverage (e.g., 50%) indicates opportunity for additional purchases. High coverage (e.g., 95%) might mean you're over-committed if utilization is also low.

Setting Up Alerts and Budgets

Configure alerts to catch problems early:

Expiration alerts: Set notifications for 1, 7, 30, or 60 days before Savings Plans expire. You can add up to 10 email recipients per alert subscription.

AWS Budgets for Savings Plans:

• Utilization budgets: Alert when utilization drops below your threshold (e.g., 80%)
• Coverage budgets: Alert when coverage drops below target

Budget periods can be daily, monthly, quarterly, or annual. I recommend monthly reviews with quarterly deep dives.

Multi-Account and AWS Organizations Considerations

If you're running multiple AWS accounts under an organization, Savings Plans benefits can be shared across accounts. Here's how it works.

How Discount Sharing Works

Application order in Organizations:

1. Savings Plans apply first to the owner account's usage
2. Remaining benefit shares to other accounts based on highest discount
3. Management account can control sharing at organization, group, or account level

Sharing modes:

• Organization-wide sharing: Benefits owner first, then shares across all accounts
• Prioritized group sharing: Benefits owner, then group members, then organization
• Restricted group sharing: Benefits only shared within defined groups

Centralized vs Decentralized Purchasing

Centralized Management (Recommended):

• Purchase all Savings Plans from management account or designated account with no workloads
• Ensures plans apply to highest discount rates across all usage
• Simplifies management and maximizes organization-wide savings

Decentralized Management:

• Each business unit purchases their own Savings Plans
• Maintains departmental budget accountability
• May result in lower overall savings due to fragmented optimization

For most organizations, centralized purchasing maximizes utilization. See the AWS Organizations guide and multi-account strategy for governance patterns.

Application Priority Across Accounts

When calculating bills, discounts apply in this order:

1. Reserved Instances apply first (most specific)
2. EC2 Instance Savings Plans apply second (narrower applicability)
3. Compute Savings Plans apply last (broadest applicability)

Account affinity: Savings Plans always apply to the purchasing account first. This is why centralized purchasing in an account with no workloads maximizes organization-wide savings. The benefit flows to accounts with actual usage.

Common Mistakes to Avoid

Let me share the mistakes I see most often so you can avoid them.

Over-Commitment

The mistake: Committing to more than your minimum consistent usage.

The result: Paying for unused commitment. Utilization drops below 100%, and that unused portion every hour is money lost.

Prevention: Start with commitment covering ~80% of minimum hourly usage. Monitor utilization and add incremental commitments over time. Better to under-commit and pay some On-Demand than over-commit and waste money.

Wrong Instance Family Selection

The mistake: Committing to an instance family you plan to migrate away from.

Example: Buying m5 commitment when planning to migrate to m6i or Graviton within the commitment term.

Prevention: Verify instance family aligns with your long-term architecture. If migration is likely, consider Compute Savings Plans instead. Check AWS roadmap for newer generation availability.

Ignoring Regional Distribution

The mistake: Buying EC2 Instance SP for one Region when workloads span multiple Regions.

Prevention: Analyze your usage distribution across Regions before purchasing. Use Compute SP for cross-Region workloads. Consider separate EC2 Instance SP per Region only for stable, region-specific usage.

Not Leveraging the Return Window

The mistake: Discovering a purchase error after the 7-day return window closes.

Prevention: Set up automated alerts for newly purchased plans. Review utilization within the first 7 days. If the commitment amount is wrong, return and re-purchase with the correct amount.

Remember the conditions: $100/hour max, same calendar month, and you have 10 returns per management account per year.

Not Accounting for Seasonality

The mistake: Basing your commitment on peak usage periods or short-term spikes.

The result: Paying for commitment capacity that sits unused during normal operating periods. If you commit based on December traffic and January drops 40%, that's 40% waste every hour.

Prevention: Select a lookback period that represents typical usage, not peak usage. Consider seasonal patterns in your business. Commit to your minimum baseline and use On-Demand for seasonal peaks.

Forgetting to Renew Expiring Plans

The mistake: Letting Savings Plans expire without replacement, causing usage to revert to On-Demand rates.

The result: Sudden cost increases when plans expire. A $10/hour commitment expiring without replacement means ~$7,200/month in additional costs (assuming 72% discount).

Prevention: Set up expiration alerts 30-60 days before expiry. Use the queue feature to schedule renewals. Review expiring plans monthly. Add calendar reminders for renewal decisions.

Key Takeaways

EC2 Instance Savings Plans offer up to 72% savings, the highest discount available for EC2 workloads. They require commitment to a specific instance family and Region, but offer flexibility on size, OS, tenancy, and AZ within that scope.

Choose EC2 Instance SP for stable, predictable workloads. If you know you'll run m5 in us-east-1 for the next 1-3 years, the extra 6% over Compute SP is real money.

Choose Compute SP for flexibility. If you use Lambda or Fargate, deploy across multiple regions, or might change instance families, Compute SP is your better option despite the lower maximum discount.

Start conservative. Commit to ~80% of minimum usage and add incrementally. Over-commitment is the most expensive mistake.

Use the 7-day return policy as a safety net for qualifying purchases. Test your commitment sizing with the option to correct mistakes.

Your next step: Use AWS Cost Explorer to analyze your EC2 usage by instance family and Region. Identify your most stable, consistent workloads as candidates for EC2 Instance Savings Plans. For the broader picture of all Savings Plans types including Database Savings Plans for database workloads, see the comprehensive AWS Savings Plans guide.

Have questions about whether EC2 Instance Savings Plans fit your workload? Drop a comment below and I'll help you work through it.

Frequently Asked Questions