Compute Savings Plans: The Complete Guide (2026)

You know Savings Plans can reduce your AWS bill. But the specifics of Compute Savings Plans remain frustratingly unclear. Which Lambda charges are actually discounted? What Fargate costs are covered versus excluded? How do you calculate an hourly commitment without over-committing?

Most guides tell you to "check Cost Explorer" and call it a day. That's not guidance, that's a cop-out.

This guide is different. By the end, you'll understand exactly how Compute Savings Plans apply to your EC2, Lambda, and Fargate workloads, how to calculate your optimal hourly commitment with real numbers, and how to avoid the mistakes that cost organizations thousands in wasted commitment.

What Are Compute Savings Plans?

Compute Savings Plans are AWS's most flexible pricing model for compute services. You commit to a consistent dollar-per-hour spend ($/hour) for a 1-year or 3-year term, and AWS applies discounted rates to your eligible usage. The key distinction: you're committing to spending, not to specific instance configurations.

This is fundamentally different from Reserved Instances. With Compute Savings Plans, your commitment automatically applies across EC2, Fargate, and Lambda, regardless of which services you use or how your architecture evolves.

The Hourly Commitment Model

You commit to a dollar amount per hour (anywhere from $0.001 to $5,000). Each hour operates independently:

• Usage up to your commitment: Charged at Savings Plans rates (discounted)
• Usage beyond your commitment: Charged at On-Demand rates
• Unused commitment: Lost. There's no rollover to the next hour.

Example: You have a $10/hour commitment. During one hour, your eligible usage totals $8. You pay $8 at the discounted rate. The remaining $2 of commitment? Gone. The next hour your usage is $15. You pay $10 at the discounted rate, $5 at On-Demand.

This "use it or lose it" model is why commitment sizing matters so much. Over-commit by even 10%, and you're wasting money every single hour.

Key Flexibility Features

Your commitment automatically applies to:

• Any EC2 instance family, size, region, OS, and tenancy
• AWS Fargate: vCPU and memory charges for ECS and EKS
• AWS Lambda: Duration charges (GB-seconds)

You can migrate from C4 to M5, shift workloads between regions, or move from EC2 to Fargate without losing your discount. Your architecture can evolve while your commitment continues applying.

How Compute SP Differs from EC2 Instance SP

The 6% discount difference sounds small, but on a $50,000/month compute spend, that's $3,000/month or $108,000 over three years. For a detailed decision framework, see my Compute vs EC2 Savings Plan guide. If you're running machine learning workloads on SageMaker, see the SageMaker AI Savings Plans guide for ML-specific commitment strategies.

Service Coverage Deep Dive

Understanding exactly what Compute Savings Plans cover (and don't cover) prevents nasty billing surprises. This is where most guides fail.

Amazon EC2 Coverage

What's covered: All instance families, sizes, regions, operating systems, and tenancies. Also covers EC2 instances in EMR, EKS, and ECS clusters.

What's NOT covered:

• U-type metal instances: Only virtual u-type instances are eligible
• Dedicated Instance fees: The $2/hour per-region fee is NOT discounted
• EKS control plane charges: The $0.10/hour cluster fee is NOT covered

AWS Lambda Coverage (What's Included and What's Not)

This is where competitor guides consistently fail you. Lambda billing has two components, and Compute Savings Plans only cover one.

COVERED: Duration charges (GB-seconds) - The compute portion of your bill.

NOT COVERED: Request charges ($0.20 per million) - Receives 0% savings.

Why this matters: If your Lambda functions are request-heavy (many short invocations), your actual discount will be lower than you expect.

Example: Suppose your Lambda bill is 60% duration charges and 40% request charges. Even with a 50% discount on duration, your effective Lambda discount is only 30% (50% of the 60% that's eligible).

Before committing, analyze your Lambda cost breakdown. Use our Lambda pricing calculator to model your specific cost split.

AWS Fargate Coverage (Dimensions and Limitations)

COVERED:

• vCPU per hour: The compute dimension
• GB per hour (memory): The memory dimension

NOT COVERED:

• OS license fees: When running Windows containers, the per-vCPU-per-hour OS license fee is NOT discounted

This matters if you run Windows containers. The OS license component remains at full price. To understand your full Fargate cost structure, use our Fargate pricing calculator.

Pricing and Discount Structure

Compute Savings Plans offer up to 66% off On-Demand rates. Your actual discount depends on instance type, operating system, region, term length, and payment option.

Payment Options

My recommendation: Start with No Upfront. The discount difference is typically only 3-5%, and you preserve cash while learning whether your commitment sizing is correct.

How Savings Plans Apply to Your Bill

When you have multiple commitment types, AWS applies them in this order:

Within Compute Savings Plans, AWS applies discounts based on highest savings percentage first. When multiple usages have equal percentages, it applies to the lowest Savings Plans rate first. See how Savings Plans apply to usage for complete details.

Worked Example with Dollar Amounts

Let's see this in action with a $10/hour commitment:

Hour 1: Normal usage

• EC2: $6 On-Demand equivalent
• Fargate: $3 On-Demand equivalent
• Lambda duration: $2 On-Demand equivalent
• Total eligible: $11

Your $10 commitment applies to highest-savings usage first. You pay $10 at discounted rates, $1 at On-Demand.

Hour 2: Light usage

• EC2: $4, Fargate: $2, Lambda: $1
• Total eligible: $7

All $7 covered, but $3 of commitment goes unused and is lost. You still pay for the full commitment.

Hour 3: Heavy usage (deployment, load test)

• EC2: $15, Fargate: $5, Lambda: $3
• Total eligible: $23

Your $10 commitment covers $10. The remaining $13 is charged at On-Demand.

This illustrates why commitment sizing based on baseline (minimum consistent usage) matters more than average usage.

Compute Savings Plans vs Reserved Instances

If you're coming from Reserved Instances, understanding the differences helps you transition effectively.

Key differences:

• No capacity reservation: Savings Plans do NOT guarantee instance availability. If you need capacity guarantees, use On-Demand Capacity Reservations separately.
• Automatic application: Unlike RIs that require matching attributes, Compute SP discounts apply automatically to your highest-savings eligible usage.
• Same discount potential: While Compute SP maxes at 66% vs RI's 72%, EC2 Instance Savings Plans match RI discounts at 72%.

AWS recommends transitioning from Regional Reserved Instances to Savings Plans for most use cases. The flexibility benefits typically outweigh the slightly lower maximum discount. For a detailed decision framework comparing all options, see my Compute vs EC2 Savings Plan guide.

How to Calculate Your Commitment

This is where most organizations struggle. Here's an actual methodology with worked numbers.

Step 1: Identify Your Baseline Usage

Your baseline is your minimum consistent usage, not your average.

1. Open AWS Cost Explorer with hourly granularity
2. Filter to On-Demand only: Exclude Spot and RI-covered usage
3. Look at 30-60 days of data representing normal operations
4. Identify the floor, not the average: Your consistent minimum
5. Exclude anomalies: Load tests, migrations, one-time events

Why minimum matters: Your commitment charges every hour regardless of usage. If your average is $15/hour but your baseline minimum is $10/hour, committing to $15 means wasting money during every below-average hour.

Step 2: Convert Monthly Spend to Hourly

Formula: Monthly On-Demand spend / 730 hours = $/hour

Example:

• EC2 On-Demand: $6,000/month
• Fargate: $2,500/month
• Lambda duration: $1,500/month
• Total eligible: $10,000/month
• Hourly equivalent: $10,000 / 730 = $13.70/hour

Step 3: Apply the 80% Rule

Commit to 80% of your baseline, not 100%.

Why 80%?

• Leaves room for hourly variation
• Accounts for optimization efforts that may reduce usage
• Better to under-commit and add more than over-commit and waste money

Example:

• Baseline hourly: $13.70/hour
• Apply 80%: $13.70 x 0.80 = $10.96/hour
• Recommended commitment: $11/hour

This single Compute SP covers EC2, Fargate, and Lambda automatically. As your workload shifts between services, the discount follows.

Understanding AWS Recommendations

AWS Cost Explorer generates recommendations based on historical usage. Understand their limitations.

How Recommendations Work

• Based on hourly granularity analysis over your lookback period (7, 30, or 60 days)
• Minimum threshold: $0.10/hour average On-Demand spend
• Tell you what would have maximized savings during the lookback period, not what will work for future usage

Payer vs Linked Account Views

Payer view: Analyzes organization-wide usage. Captures cross-account optimization (dev peaks during day, batch at night).

Linked view: More conservative. Excludes cross-account sharing benefits.

Recommendation: Use payer account recommendations for centralized purchasing.

When to Adjust Recommendations

• Workloads recently changed: Use 7-day lookback
• Planned architecture changes: Historical data doesn't represent future usage
• Seasonal patterns: Lookback may miss important cycles

Purchasing Compute Savings Plans

Step-by-Step Process

1. Enable Cost Explorer (can take 24 hours)
2. Navigate to Savings Plans in Billing and Cost Management
3. Review AWS recommendations
4. Run Purchase Analyzer (see below)
5. Configure: type, term, payment option, commitment amount
6. Add to cart and complete

Using Purchase Analyzer (November 2024)

Introduced November 2024, Purchase Analyzer lets you model scenarios before committing:

• Model different commitment amounts
• Adjust lookback periods
• Exclude expiring Savings Plans (critical for renewal planning)
• Estimate coverage, utilization, and cost impact

Usage limit: 20 runs per account per day.

The 7-Day Return Window

Introduced March 2024, this provides a safety net for smaller purchases.

Eligibility (ALL must be met):

• Hourly commitment $100 or less
• Purchased within last 7 days
• Purchased in same calendar month
• Return limit not exceeded (10 per year per management account)

What happens: 100% refund for upfront charges. Usage during the period charged at On-Demand.

Queuing Future Purchases

Queue purchases for future start dates to plan renewals seamlessly or align with budget cycles. You can delete queued purchases before the start date.

Multi-Account Strategies (AWS Organizations)

Centralized vs Decentralized Purchasing

Centralized (recommended): Purchase from management account with sharing enabled. Maximizes cross-account optimization.

Decentralized: Each account purchases independently. Maintains budget accountability but may result in lower utilization.

Avoid mixing approaches without strategy, this leads to overlapping commitments and lower utilization.

For organizational guidance, see the AWS Organizations guide and multi-account strategy.

Group Sharing (November 2025)

AWS introduced Group Sharing for more granular control:

Prioritized Group Sharing: Owner first, then defined groups (using Cost Categories), then other accounts.

Restricted Group Sharing: Benefits stay exclusively within defined groups. Use for business unit chargeback or regulatory isolation.

Monitoring Utilization and Coverage

Use Savings Plans utilization and coverage reports to track performance.

Utilization: Are You Wasting Commitment?

Calculation: (SP commitment used) / (Total commitment) x 100%

Target: 100%

Low utilization = over-commitment. If utilization is 70%, you're wasting 30% of your commitment every hour.

Coverage: What's Still at On-Demand?

Calculation: (Usage covered by SP) / (Total eligible usage) x 100%

Target: 70-90%

Low coverage = opportunity for additional Savings Plans.

Setting Up Alerts

• Utilization alert: Set at 80% threshold
• Coverage alert: Based on your target (e.g., 70%)
• Expiration alerts: 1, 7, 30, or 60 days before expiration

Available via email (up to 10 recipients), SNS, and AWS Chatbot (Slack/Chime).

Best Practices and Common Mistakes

Best Practices

1. Start conservative with smaller, additive plans instead of one large commitment
2. Right-size resources before committing using Compute Optimizer and Trusted Advisor
3. Use 1-year terms for first purchases for flexibility to adjust
4. Review quarterly and add incremental commitments
5. Match lookback period to workload stability (7 days after changes, 60 days for stable)

Common Mistakes

Over-committing based on average: Commit to baseline minimum, not average. Apply the 80% rule.

Not right-sizing first: Eliminate waste before committing to discounts on it.

Ignoring hourly patterns: Always analyze at hourly granularity.

Expecting capacity reservations: Savings Plans do NOT reserve capacity. Use ODCR separately.

Forgetting the 7-day return window: Set up alerts for newly purchased Savings Plans and review immediately.

Not accounting for Spot/RI usage: Filter to On-Demand only when sizing. Savings Plans don't apply to Spot or RI-covered usage.

Quotas and Restrictions

Key restrictions: Cannot cancel or modify after purchase (except 7-day window). No Spot coverage. No RI-covered usage coverage.

Real-World Scenarios

Let's see how Compute Savings Plans apply to common situations.

Startup with rapidly changing architecture

Your fast-growing startup frequently changes instance types, experiments with containers, and might go serverless.

Recommendation: Compute Savings Plans, 1-year term, No Upfront. Maximum flexibility to shift between EC2 families, add Fargate, and expand Lambda without losing discount.

Enterprise with stable production + variable dev

Large enterprise with predictable production databases on R5 instances, but dev environments vary.

Recommendation: Mix of EC2 Instance Savings Plans (72% for stable R5 production) and Compute Savings Plans (66% for variable workloads).

Multi-region global application

Application serving users across multiple AWS regions with traffic patterns that shift throughout the day.

Recommendation: Compute Savings Plans. Cross-region flexibility means your commitment follows traffic regardless of which region is busiest.

Containerized microservices on Fargate

Organization moving from EC2 to Fargate for containerized workloads, with some EC2 remaining.

Recommendation: Compute Savings Plans. Only option that covers both EC2 and Fargate. As you migrate, the discount automatically follows your workloads.

Serverless-first architecture

Heavy Lambda usage for event processing, some EC2 for specific workloads.

Recommendation: Compute Savings Plans (if duration charges dominate Lambda bill). But analyze your Lambda cost split first. If request charges dominate, Savings Plans benefits are limited.

Hybrid dev/prod environment

Dev environments peak during business hours, batch processing runs overnight.

Recommendation: Centralized Compute Savings Plans at payer account level. Complementary usage patterns maximize 24-hour utilization.

Key Takeaways

1. Lambda coverage is partial: Duration (GB-seconds) discounted, requests ($0.20/million) NOT.

2. Fargate coverage excludes OS fees: vCPU and memory covered, Windows license fees NOT.

3. Calculate from baseline, not average: Hourly granularity, minimum consistent usage, 80% rule.

4. Use Purchase Analyzer before every purchase: Model scenarios to validate commitment.

5. Monitor utilization monthly: Target 95%+. Low utilization = wasted money.

Your next step: Open AWS Cost Explorer, analyze your last 30 days at hourly granularity, filter to On-Demand, identify your baseline, and run Purchase Analyzer.

For help choosing between plan types, see my decision guide. For all four Savings Plans types including Database Savings Plans, see the AWS Savings Plans guide.

Frequently Asked Questions