7 Common EC2 Savings Plan Mistakes That Cost You Money

Overcommitting an EC2 Savings Plan is one of the fastest ways to hand AWS money for nothing in return. You pay the hourly commitment rate whether or not your instances are running. When the commitment doesn’t match actual usage, the discount becomes a penalty.

This post covers the seven mistakes that FinOps engineers see most often in real AWS accounts, what each one actually costs in dollar terms, and exactly how to avoid them.

What Is an EC2 Savings Plan and Why Do Mistakes Compound?

An EC2 Savings Plan is a commitment to a minimum hourly compute spend (measured in $/hour) in exchange for discounts of up to 40-72% off On-Demand rates (verify at Amazon Compute and EC2 Instance Savings Plans as  rates change). Unlike Reserved Instances, Savings Plans apply automatically to any matching usage within the defined scope, which means the application logic is largely invisible to the buyer.

That invisibility is where mistakes start. You buy a commitment at one point in time based on data that may already be stale. The commitment runs for 1 or 3 years. If the data was wrong, or if usage patterns shift, you pay for that error for the entire term.

EC2 Instance Savings Plans provide the highest discount rates (up to 72% off On-Demand for specific instance families in specific regions) but lock you into a single instance family within a single region. Compute Savings Plans offer lower maximum discounts but apply across any instance family, size, OS, tenancy, and AWS region, including Fargate and Lambda.

Mistake 1: Buying Before You Rightsize

Buying a Savings Plan for an over-provisioned instance family locks in a high hourly rate that’s already wasteful. If an m5.4xlarge running at 15% CPU should actually be an m5.large, you’ve committed to paying 8x more compute than you need, and the discount only applies to the committed rate, not to the over-provisioned headroom above your actual workload.

What it costs: An m5.4xlarge in us-east-1 runs approximately $0.768/hour On-Demand. A 3-year No Upfront EC2 Savings Plan brings that to roughly $0.278/hour. An m5.large at $0.096/hour On-Demand with equivalent savings would cost roughly $0.035/hour. If you’re running 100 instances for a year, you’re paying roughly $243,528 instead of $30,660 on compute. The discount is real, but the base is wrong.

The fix: Run AWS Compute Optimizer before purchasing any Savings Plan. Optimizer analyzes 14 days of CloudWatch metrics by default and recommends right-sized instance types. Complete rightsizing first, then analyze 30 days of post-rightsizing usage, then purchase. 

Mistake 2: Overcommitting Based on Peak Usage Instead of Baseline

Savings Plans should be sized to your steady-state baseline usage, not your peak. Peak usage should be covered by On-Demand or Spot. When you commit to a rate that covers both baseline and peak, you’re paying the committed rate for capacity you only need intermittently.

What it costs: 

Say your EC2 fleet runs at $2,000/hour during normal hours and spikes to $5,000/hour at peak.

If you commit at $5,000/hour to cover both:

• You pay $3,650,000/month in commitment fees (730 hours x $5,000)
• But for 530 of those hours, you only needed $2,000/hour
• That means $3,000/hour x 530 hours = $1,590,000 paid for nothing

If you commit at $2,000/hour (baseline only) and let peaks run On-Demand:

• Commitment cost: $1,460,000/month (730 hours x $2,000)
• On-Demand for 200 peak hours: $3,000/hour overage x 200 hours = $600,000
• Total: $2,060,000/month

The difference: $1,590,000 saved in a single account, in a single month, just by committing to baseline instead of peak.

RULE OF THUMB If you commit to the floor, your workload will never drop below. Let Auto Scaling handle the spikes at On-Demand rates. The On-Demand premium on spikes is almost always cheaper than paying a committed rate for capacity that sits idle 70% of the time.

The fix: Pull 60 to 90 days of hourly EC2 usage from Cost Explorer. Sort by hour and identify the consistent floor, the usage level that never drops below a threshold. Commit to 80-90% of that floor to leave a safety margin for workload changes.

Mistake 3: Choosing EC2 Instance Savings Plans Over Compute Savings Plans for Unstable Workloads

EC2 Instance Savings Plans lock you into a specific instance family within a specific AWS region. Compute Savings Plans apply across all instance types, regions, Fargate, and Lambda. The discount gap between them is roughly 10-15 percentage points depending on the instance family.

Many engineers choose EC2 Instance Savings Plans to maximize discount percentage without accounting for the migration risk. If your team shifts from m5 to m6i instances, migrates a workload to a different region, or moves containerized workloads to Fargate, the EC2 Instance Savings Plan does not follow. You continue paying the committed rate while the discount applies to nothing.

What it costs: Assume a $50,000/month committed spend under an EC2 Instance Savings Plan. After a migration to m6i, $30,000/month of that commitment is now mismatched. Over the remaining 18 months of a 3-year term, that’s $540,000 in committed spend with no offsetting discount benefit.

The fix: Default to Compute Savings Plans for any workload that may evolve. Accept the slightly lower headline discount in exchange for flexibility. If you have genuinely stable, single-region, single-family workloads that have not changed in 12 months, EC2 Instance Savings Plans are appropriate, but document that assumption explicitly with a review checkpoint at 6 months. 

Mistake 4: Committing to 3-Year Terms for Non-Stable Workloads

A 3-year Savings Plan offers a higher discount than a 1-year plan, roughly 10-15% more, depending on the family. But that additional discount only pays off if your workload stays consistent for all 36 months. For any workload that changes in architecture, scale, or region within that window, the 3-year term is a liability.

What it costs:

Take 100 x m5.xlarge instances in us-east-1:

• 1-year No Upfront rate: ~$0.149/hour
• 3-year No Upfront rate: ~$0.124/hour
• Difference: $0.025/hour per instance

Over 36 months, that $0.025/hour gap across 100 instances adds up to ~$65,700 in additional savings from the 3-year plan.

That math only works if the workload stays stable for all 36 months.

If your team migrates to a different instance family or region at month 18, the remaining 18 months of commitment applies to nothing. You’re paying $0.124/hour for instances that no longer exist in that family. At 100 instances, that’s $0.124 x 100 x 4,380 hours = ~$543,000 in committed spend generating zero discount return — more than 8x the savings you were trying to capture.

The 3-year plan only wins if the workload outlasts the term. Most don’t.

The fix: Match term length to architectural stability horizon. If your roadmap includes Kubernetes migration, major refactoring, or significant scale changes within 24 months, buy 1-year terms. Only buy 3-year terms for workloads with demonstrated multi-year stability and explicit business continuity plans. See EC2 Savings Plans: 1-Year vs 3-Year Commitment ROI Analysis.

Mistake 5: Ignoring Savings Plan Utilization After Purchase

A Savings Plan commitment runs whether or not it’s being applied to active EC2 usage. Engineers who buy a plan and don’t monitor utilization often discover weeks or months later that utilization has dropped to 40 or 50% — meaning they’re paying the committed rate for capacity that’s running nothing.

What it costs: A Savings Plan with $10,000/month committed spend running at 60% utilization means $4,000/month in committed spend generating no discount benefit. Over 12 months, that’s $48,000 of guaranteed waste.

The monitoring gap that costs you before you even know there’s a problem

AWS Cost Explorer refreshes Savings Plan utilization data every 72+ hours. That means if your utilization drops sharply today, due to a scale-down event, a workload decommission, or a team finishing a project, you won’t see it in the dashboard for up to 3 days.

Here’s what that lag looks like in dollar terms:

Day	What’s happening	What your dashboard shows
Day 1	Utilization drops to 55%	Still showing yesterday’s 92%
Day 2	Committed spend running at ~40% waste	No alert, no signal
Day 3	$18,000–$36,000 in waste has accumulated	Dashboard finally updates

By the time the data surfaces, the waste has already happened. There’s no retroactive credit. You pay for all three days.

At $6,000–$12,000/day in underutilized committed spend, a single undetected scale-down event costs $18,000–$36,000 before you can act on it.

The fix: Set CloudWatch alarms on Savings Plans utilization metrics. Configure alerts when utilization drops below 85%. Review utilization weekly, not quarterly.

Mistake 6: Failing to Use AWS Organizations for Multi-Account Commitment Sharing

Savings Plans apply at the account level by default. If you’re running AWS Organizations with multiple linked accounts and have not enabled Savings Plan sharing at the management account level, each account’s unused commitment stays isolated. A linked account with 100% utilization pays On-Demand rates for additional usage while another linked account’s commitment sits at 50% utilization in the same organization. See Amazon EC2 Pricing Explained: Models, Costs & How to Save.

What it costs: 

Let’s take two accounts of the same organization. Neither is aware the other exists from a billing perspective

	Account A	Account B
Monthly committed spend	$5,000	$0
Utilization	55%	—
Unused commitment	$2,250/month	—
EC2 On-Demand spend	—	$5,000/month
Eligible for SP discount (~40% off)	—	Yes

Without org-level sharing:

• Account A wastes $2,250/month in unused commitment
• Account B pays full On-Demand on $5,000 of spend that qualifies for a 40% discount
• Combined monthly waste: ~$4,250 (unused commitment and foregone discount)

With org-level sharing enabled:

• Account A’s unused $2,250 automatically applies to Account B’s eligible usage
• Account B’s $5,000 On-Demand spend gets partially covered at committed rates
• Recovered value: $2,000–$2,500/month with zero additional spend

That’s $24,000–$30,000/year left on the table by not checking a single setting in the management account.

The fix: In the management account, navigate to AWS Billing and Cost Management, select Savings Plans, and verify that “Compute Savings Plans” sharing is enabled across the organization. Confirm via the Savings Plans coverage report that linked accounts are consuming shared commitments before purchasing additional plans for individual accounts.

Mistake 7: Buying on Stale Recommendations

AWS Cost Explorer Savings Plan purchase recommendations update every 72+ hours. If you pull a recommendation on Monday afternoon and your usage profile shifted over the weekend, the recommended commitment amount reflects a usage pattern that may no longer exist. Buying the full recommended amount without verifying current usage results in over-commitment.

What it costs quantified: Suppose the recommendation suggests a $3,000/hour commitment based on Thursday’s data. Over the weekend, three large batch workloads completed and were decommissioned. 

• Actual current usage justifies only a $2,000/hour commitment. 
• You’ve over-committed by $1,000/hour. 

Over one year, at a blended hourly commitment cost, that mismatch costs roughly $8,760,000 in committed spend generating no discount return. Even at a smaller scale, say a $100/hour over-commitment, that’s $876,000/year in misallocated spend.

The fix: Cross-reference Cost Explorer recommendations against your current Cost and Usage Report data before purchasing. Look at the past 7 days of actual hourly EC2 usage, not just the Cost Explorer recommendation window. If your usage has changed materially in the past 72 hours, recalculate the commitment manually using current usage data.

How Usage.ai Addresses All Seven Mistakes Systematically

Each of the seven mistakes above has a root cause in common: point-in-time purchasing decisions applied to continuously changing workloads, monitored with tools that don’t refresh fast enough to catch drift.

• On recommendation latency: Usage.ai refreshes EC2 Savings Plan recommendations every 24 hours. AWS Cost Explorer refreshes every 72+ hours. That 48-hour gap matters because underutilized commitments compound: at $6,000-$12,000/day in uncovered spend, a 48-hour additional lag adds $12,000-$24,000 to each drift event before the data surface allows action.
• On over-commitment protection: Usage.ai’s Autopilot mode manages Savings Plan purchasing continuously, sizing commitments to current baseline usage rather than historical peak data. When workloads scale down, the system detects the drift within 24 hours and adjusts future purchasing strategy accordingly.
• On cashback vs. credits: If a commitment purchased through Usage.ai becomes underutilized due to workload changes, Usage.ai provides cashback on the underutilized portion, not credits. Credits stay inside the cloud billing ecosystem. Cashback is real money returned to the business. This distinction matters when you’re managing a FinOps P&L.
• On rightsizing integration: Usage.ai recommends rightsizing before commitment, operating at the billing layer only — no infrastructure changes, no code modifications required.
• On multi-account management: Usage.ai supports multi-organization reporting and showback, making it possible to identify cross-account commitment sharing gaps before they become waste.

Companies including Motive, EVGo (NASDAQ: EVGO), Secureframe, and Blank Street Coffee manage EC2 commitments through Usage.ai. The platform has delivered $100M+ in verified savings across enterprise customers, with individual customer outcomes including $5.2M, $2.3M, and $1.8M in annual savings.

Setup takes 30 minutes and requires billing-layer access only. No infrastructure changes. No upfront cost. Usage.ai charges a percentage of realized savings only. If the platform saves nothing, the fee is zero.

Learn how EC2 Savings Plan automation works at Usage.ai and book a 15-minute savings assessment to see exactly how your current commitments compare to Usage.ai’s recommendations.

EC2 Savings Plan Mistakes: Quick Reference Table

Mistake	Root Cause	Est. Annual Cost at $100K/mo Spend	Fix
Buying before rightsizing	Wrong instance baseline	$200K-$400K in over-committed cost	Compute Optimizer first, then buy
Overcommitting to peak	Peak vs. baseline confusion	20-40% of committed spend wasted	Commit to 80-90% of floor usage
EC2 Instance vs. Compute SP	Chasing max discount	Full term loss on migration	Default to Compute SP unless stable
3-year terms for volatile workloads	Discount optimization without stability	Commitment mismatch after architecture change	1-year for any workload in flux
No utilization monitoring	Set-and-forget mentality	$48K/yr at 60% utilization on $10K/mo plan	CloudWatch alerts below 85%
No Org-level sharing	Account-silo purchasing	$24K-$30K/yr in cross-account waste	Enable sharing at management account
Stale recommendation data	72-hr refresh lag	$876K+ at $100/hr over-commitment	Verify against last 7 days of CUR

(All estimates are illustrative ranges based on described scenarios. Verify current rates at aws.amazon.com)

 

Frequently Asked Questions

1. What happens if I overcommit on an EC2 Savings Plan?

If you overcommit, you pay the full hourly committed rate for the portion of your Savings Plan that does not apply to actual EC2 usage. AWS does not refund the unused commitment. The committed spend is a floor, not an estimate. You pay it regardless of whether instances are running.

 

2. Is a 1-year or 3-year EC2 Savings Plan better?

For workloads with demonstrated multi-year stability, 3-year No Upfront plans offer the highest discount rates, roughly 10-15% more than 1-year plans, depending on instance family. For workloads undergoing architecture changes, team growth, or regional migration within 24 months, 1-year plans are almost always more cost-effective because the break-even on the additional 3-year discount requires consistent usage for the full 36-month term.

 

3. What is the difference between an EC2 Instance Savings Plan and a Compute Savings Plan?

An EC2 Instance Savings Plan locks the discount to a specific instance family within a specific AWS region, delivering the highest possible discount (up to 72% off On-Demand in some families). A Compute Savings Plan applies to any instance family, region, size, OS, tenancy, Fargate, and Lambda, at a lower maximum discount. The key decision factor is workload stability: if your fleet composition or region may change over the plan term, a Compute Savings Plan protects against commitment mismatch.

 

4.How do I check if my EC2 Savings Plan is being fully utilized?

In AWS Cost Explorer, navigate to “Savings Plans” and select the “Utilization report.” This shows utilization percentage per plan, unused commitment in dollars, and net savings. Set CloudWatch billing alerts to trigger when utilization drops below your target threshold. AWS refreshes utilization data every 72+ hours, so same-day monitoring requires cross-referencing the Cost and Usage Report (CUR) directly.

 

5. Should I rightsize EC2 instances before or after buying a Savings Plan?

Always rightsize before purchasing. A Savings Plan discount applies to whatever hourly rate you’ve committed at. If your instances are over-provisioned, you’re committing to a high hourly rate that reflects wasted capacity. AWS Compute Optimizer and Cost Explorer Right Sizing recommendations both provide instance resizing guidance. Complete rightsizing, confirm stable usage at the new instance sizes for 30+ days, then purchase a Savings Plan sized to that verified baseline.

 

6. Can EC2 Savings Plans be shared across multiple AWS accounts?

Yes, if you’re using AWS Organizations, Savings Plans can be shared across linked accounts when enabled at the management account level. By default, each account’s Savings Plans apply to that account’s usage first. Enabling organizational sharing allows unused commitment in one account to apply to eligible usage in linked accounts. Not enabling this sharing is one of the most common and avoidable sources of waste in multi-account AWS environments.

 

7. What is cashback insurance for EC2 Savings Plans and how is it different from credits?

Cashback insurance means that if a Savings Plan commitment purchased through a third-party platform becomes underutilized due to workload changes, the provider returns real money, not AWS credits, to the customer for the unused portion. AWS credits stay inside the billing ecosystem and can only be applied against future AWS charges. Cashback is liquid and returns directly to the business. Usage.ai is the only platform offering cashback on underutilized commitments, compared to competitors that provide credits only.