DEV Community: Aman Singh

7 EC2 Savings Plan Mistakes That Are Costing You Millions

Aman Singh — Wed, 20 May 2026 11:13:32 +0000

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.

Here are the seven mistakes FinOps engineers see most often in real AWS accounts, what each one actually costs, and how to fix them.

What Makes Savings Plan Mistakes So Expensive
An EC2 Savings Plan is a commitment to a minimum hourly compute spend ($/hour) in exchange for discounts up to 40–72% off On-Demand rates. Unlike Reserved Instances, Savings Plans apply automatically to any matching usage which means the application logic is largely invisible to the buyer.

That invisibility is where mistakes start. You buy 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 usage patterns shift, you pay for that error for the entire term.

Quick reference on plan types:

EC2 Instance Savings Plans: highest discounts (up to 72%) but locked to a single instance family in a single region.
Compute Savings Plans: lower max discounts but apply across any instance family, size, OS, tenancy, and region, including Fargate and Lambda.

Mistake 1: Buying Before You Rightsize

Buying a Savings Plan for an over-provisioned instance locks in a high hourly rate that's already wasteful. The discount 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 ~$0.768/hour On-Demand. A 3-year No Upfront Savings Plan brings that to ~$0.278/hour. An m5.large the right size for a workload running at 15% CPU costs ~$0.035/hour under equivalent savings. At 100 instances for a year, that's $243,528 vs. $30,660. The discount is real; the base is wrong.

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

Mistake 2: Committing to Peak Instead of Baseline

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

What it costs: Say your fleet runs at $2,000/hour normally and spikes to $5,000/hour at peak.

Committing at $5,000/hour to cover everything:

$3,650,000/month in commitments (730 hours × $5,000)
530 of those hours only needed $2,000/hour
$1,590,000/month paid for nothing

Committing at $2,000/hour (baseline only):

Commitment: $1,460,000/month
On-Demand for 200 peak hours: $600,000
Total: $2,060,000/month saving $1,590,000

Commit to the floor. Let Auto Scaling handle spikes at On-Demand rates. The On-Demand premium on spikes is almost always cheaper than paying a committed rate for idle capacity.

The fix: Pull 60–90 days of hourly EC2 usage from Cost Explorer. Identify the consistent floor, the usage level that never drops below a threshold. Commit to 80–90% of that floor.

Mistake 3: Using EC2 Instance Savings Plans for Unstable Workloads

EC2 Instance Savings Plans lock you to a specific instance family and region. The discount is ~10–15 percentage points higher than Compute Savings Plans but if your workload migrates to a new instance family, region, or moves to Fargate, the plan doesn't follow.

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

The fix: Default to Compute Savings Plans for any workload that may evolve. EC2 Instance Savings Plans are appropriate only for genuinely stable, single-region, single-family workloads unchanged for 12+ months and only with a documented 6-month review checkpoint.

Mistake 4: Buying 3-Year Terms for Non-Stable Workloads

A 3-year plan offers ~10–15% more discount than a 1-year plan. That math only works if your workload stays consistent for all 36 months.

What it costs: 100 × m5.xlarge in us-east-1:

1-year No Upfront: ~$0.149/hour
3-year No Upfront: ~$0.124/hour
Over 36 months, the gap = ~$65,700 in additional savings

But if the workload migrates to month 18, the remaining 18 months generates zero discount return: $0.124 × 100 instances × 4,380 hours = ~$543,000 in committed spend 8× the savings you were trying to capture.

For a full ROI breakdown on term length, see EC2 Savings Plans: 1-Year vs 3-Year Commitment ROI Analysis

The fix: Match term to architectural stability horizon. If your roadmap includes Kubernetes migration, major refactoring, or significant scale changes within 24 months, buy 1-year terms.

Mistake 5: Not Monitoring Utilization After Purchase

A Savings Plan commitment runs whether or not it's being applied to active usage. Utilization can drop to 40–50% without triggering any default alert.

What it costs: $10,000/month committed at 60% utilization = $4,000/month in spend generating no discount. Over 12 months: $48,000 in guaranteed waste.

AWS Cost Explorer refreshes utilization data every 72+ hours. A utilization drop today won't surface in your dashboard for up to 3 days:
Day What's happening What your dashboard shows
Day 1 Utilization drops to 55% Still showing yesterday's 92%
Day 2 ~40% of committed spend wasted No alert, no signal
Day 3 $18,000–$36,000 accumulated waste Dashboard finally updates

There's no retroactive credit. You pay for all three days.

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

Mistake 6: Not Using AWS Organizations for Commitment Sharing

Savings Plans apply at the account level by default. In a multi-account org without sharing enabled, one account's unused commitment stays isolated while another pays full On-Demand for eligible usage.
What it costs: Account A Account B
Monthly committed spend $5,000 $0
Utilization 55% —
Unused commitment $2,250/month —
EC2 On-Demand spend — $5,000/month

Without org-level sharing: ~$4,250/month wasted (unused commitment + foregone discount on Account B's eligible spend).

With sharing enabled: Account A's unused $2,250 automatically covers Account B's usage. Recovered value: $2,000–$2,500/month with zero additional spend or $24,000–$30,000/year from one setting.

For a broader overview of EC2 pricing models, see Amazon EC2 Pricing Explained: Models, Costs & How to Save

The fix: In the management account, go to AWS Billing and Cost Management → Savings Plans → verify sharing is enabled. Confirm via the coverage report that linked accounts are consuming shared commitments before purchasing additional plans per account.

Mistake 7: Buying on Stale Recommendations

AWS Cost Explorer recommendations update every 72+ hours. If usage shifted over the weekend and you buy on Monday, you're committing to a pattern that no longer exists.

What it costs: A recommendation suggests $3,000/hour. Over the weekend, three batch workloads completed and were decommissioned. Actual usage justifies $2,000/hour. You've over-committed by $1,000/hour at scale, that's $876,000/year in misallocated spend (at $100/hour over-commitment).

The fix: Cross-reference Cost Explorer recommendations against your current Cost and Usage Report. Look at the past 7 days of actual hourly usage. If usage changed materially in the past 72 hours, recalculate manually.

How These Mistakes Share a Root Cause

Every mistake here has the same underlying problem: point-in-time purchasing decisions applied to continuously changing workloads, monitored with tools that don't refresh fast enough to catch drift.

At $6,000–$12,000/day in uncovered spend, a 48-hour additional lag on detecting drift adds $12,000–$24,000 per event before the data allows action.

Usage.ai refreshes EC2 Savings Plan recommendations every 24 hours vs. Cost Explorer's 72+. Its Autopilot mode manages purchasing continuously sizing to current baseline, not historical peak. If a commitment purchased through Usage.ai becomes underutilized due to workload changes, it provides cashback on the underutilized portion, not credits. Cashback is real money returned to the business.

Companies including Motive, EVGo (NASDAQ: EVGO), Secureframe, and Blank Street Coffee manage EC2 commitments through the platform. Setup takes 30 minutes, requires billing-layer access only, and charges a percentage of realized savings only if it saves nothing, the fee is zero.

Which of these have you run into in your own accounts? Curious whether the utilization monitoring gap (Mistake 5) catches people as often as I think it does.

Why Cloud Cost Optimization Is No Longer Optional for DevOps and FinOps Teams

Aman Singh — Tue, 19 May 2026 11:31:08 +0000

Cloud computing promised flexibility and speed and it delivered. But it also introduced something no one fully anticipated at scale: unpredictable, fast-growing infrastructure costs.

For organizations running workloads across AWS, Azure, or Google Cloud, cloud spend has quietly become one of the largest line items in the entire engineering budget, often rivaling payroll and software licensing combined.

That's why cloud cost optimization isn't a nice-to-have anymore. It's a business discipline.

What Cloud Cost Optimization Actually Means

Cloud cost optimization is the process of reducing infrastructure spending while keeping application performance, scalability, and reliability intact.

Most cloud platforms run on a pay-as-you-go model, every compute instance, storage volume, and network request adds to your bill. That flexibility is great for scaling fast, but it creates real cost inefficiencies when resources aren't actively managed.

In practice, optimization means:

Continuously analyzing usage patterns
Identifying idle or overprovisioned resources
Buying discounted pricing commitments when workloads are stable enough to predict

On-Demand vs. Commitment-Based Pricing

Cloud providers offer two main billing approaches:

On-demand pricing gives you full flexibility to spin up infrastructure instantly and pay per use. It's the most expensive option at scale.

Commitment-based discounts (like AWS Savings Plans or Reserved Instances) offer significantly lower rates in exchange for committing to a usage level over 1–3 years. Think of it like a bulk subscription discount: you commit to predictable usage, and the provider rewards you with lower per-unit pricing.

Most waste happens when teams default entirely to on-demand because it's the path of least resistance.

Why This Has Become a C-Suite Priority

A few years ago, cloud costs were a backend engineering concern. Today, CFOs are tracking infrastructure efficiency metrics the same way they track revenue.

Here's what changed:

Cloud adoption accelerated across every industry. More workloads, more data pipelines, more ML systems all continuously billed.

Elasticity cuts both ways. Auto-scaling handles traffic spikes without manual intervention. It also means costs can multiply fast when experiments run across multiple environments or new services launch without guardrails.

Engineering decisions are now financial decisions. Instance type selection, autoscaling policies, container orchestration strategies these aren't just technical choices. They directly impact the bill. A team running dev environments 24/7 instead of on-demand is burning the budget quietly every week.

FinOps has emerged as its own practice. Organizations now have dedicated FinOps functions that work alongside engineering and platform teams to monitor spending, improve commitment coverage, and make sure infrastructure investments align with actual business growth.

Wondering where cost monitoring ends and cost control begins? We broke down the difference in detail: Cloud Cost Monitoring vs Cost Control: What's the Real Difference?

The Challenges That Make This Hard

Understanding why optimization matters is the easy part. Actually doing it at scale is where most teams run into problems.

Limited visibility across accounts and teams In large organizations, infrastructure spans multiple cloud accounts, dozens of regions, and hundreds of services deployed independently by separate engineering teams. Without centralized visibility, idle resources and underutilized instances stay hidden and accumulate cost over time.
Complex, overlapping pricing models Compute alone can be purchased across multiple tiers with different discount levels, flexibility tradeoffs, and usage requirements. Without real usage data, most teams default to on-demand which is straightforward but expensive.
Commitment risk Long-term commitments offer real savings, but they require predicting future usage. If a workload gets deprecated or migrated, you may end up paying for capacity you no longer need. This risk is why many organizations under-commit even when committing would save significant money.
Infrastructure that changes constantly Cloud environments aren't static. Product launches, architectural migrations, feature rollouts; all of these shift usage patterns. An optimization decision that was right six months ago may no longer apply today.
Manual processes don't scale Periodic dashboard reviews and spreadsheet-based cost audits work for small setups. For environments with thousands of resources changing daily, manual analysis simply can't keep up.

Strategies That Actually Move the Needle

Rightsizing: Analyze CPU, memory, and network utilization on long-running workloads. Applications often run on oversized instances selected for "just in case" capacity that never gets used. Moving those workloads to appropriately sized instances reduces cost with no performance impact.

Eliminating idle resources: Development environments left running overnight, unattached storage volumes, outdated snapshots these are quiet cost leaks. Regular audits to identify and remove unused infrastructure can generate meaningful savings without touching production.

Increasing commitment coverage: For stable, predictable workloads, commitment-based pricing is the highest-leverage optimization available. If 100 compute instances run consistently and only 60 are covered by commitments, there's a clear 40% gap where on-demand rates are being paid unnecessarily.

Automating commitment management: Manually evaluating commitment purchases requires analyzing historical usage, predicting future demand, and timing purchases correctly. Automated platforms like Usage.ai do this continuously, surfacing recommendations based on real workload behavior rather than periodic manual review.

Continuous monitoring: Optimization isn't a one-time project. Tracking utilization, commitment coverage rates, cost anomalies, and per-service spend over time lets teams catch inefficiencies before they compound.

Why Automation Is Becoming the Standard

Native cloud cost tools: AWS Cost Explorer, Azure Cost Management, GCP's billing dashboard are useful for visibility but largely passive. They show you what happened. They don't act on it.

As environments scale, the gap between what native tools show and what actually gets optimized grows wider. This is where dedicated automation platforms close the loop:

Continuous commitment analysis based on live usage data, not monthly snapshots
Cashback models on underutilized commitments, which allow organizations to increase coverage without taking on full financial risk if usage drops
Real-time alerting on cost anomalies and utilization changes
Continuous re-optimization as infrastructure evolves

The shift is from treating cost optimization as a quarterly review to making it an ongoing operational process one that runs in parallel with engineering velocity rather than lagging behind it.

If your team is looking to put governance around cloud spending, this is a solid starting point: What Is Cloud Cost Governance: Framework, Best Practices, and KPIs

The Bottom Line

Cloud cost optimization has moved from a technical concern to a strategic business capability. Organizations that treat it as a continuous discipline not a periodic cleanup will scale more efficiently and compound savings over time as their infrastructure grows.

For DevOps and FinOps teams, the goal is straightforward: build cloud environments that are technically powerful and economically sustainable. Rightsizing, commitment coverage, idle resource removal, and automation aren't separate projects. Together, they're how modern teams keep infrastructure costs from outpacing business growth.