Why Reserved Instances and Savings Plans Are Not Enough
Published 03-31-2025
Rethinking the Foundations of Cloud Cost Management
If your team manages AWS spend, you've probably spent time wrangling Reserved Instances (RIs) or Savings Plans. And on paper, it makes sense: these commitment-based models promise significant cost reductions—sometimes over 70%—for workloads you expect to be steady over time.
But here’s a question that doesn’t get asked often enough: What if the resources you're locking in were poorly chosen in the first place?
This isn’t a theoretical risk. It’s a structural flaw in the way most organizations approach cloud cost optimization.
The Hidden Cost of Premature Commitment
Reserved Instances and Savings Plans are designed to help you pay less—but only under the assumption that you're already using the right resources. And that assumption is often wrong.
Why? Because most cloud resource decisions are made in conditions of uncertainty:
- Developers overprovision to avoid performance issues.
- Engineers inherit configurations from older projects.
- New services are launched before usage patterns stabilize.
- Business needs evolve faster than infrastructure reviews happen.
The result? You're making long-term commitments on resource choices that were either conservative, rushed, or no longer relevant. Instead of saving money, you're just locking in inefficiency.
It’s important to understand the distinction between the two dominant models:
- Reserved Instances (RIs) lock you into a commitment based on specific instance attributes: type, size, region, and OS. You can’t easily adapt if your workloads change.
- Savings Plans give more flexibility in type of resource, but you're locked into a dollar amount commitment. You can reallocate how you spend it, but not how much you’ve committed to spend.
So while Savings Plans offer more agility than RIs, both require a solid understanding of your true resource needs before committing.
Optimization Should Precede Commitment
This is where many cost strategies invert the natural order. Organizations often jump to RIs and Savings Plans to cut costs without first evaluating whether their current cloud architecture reflects actual needs.
In reality, the sequence should be:
- Monitor usage and performance trends.
- Continuously validate resource choices.
- Right-size infrastructure based on real patterns.
- Then—and only then—commit.
In short: optimize first, commit later. Anything else is premature.
A practical best practice is to commit to approximately 80% of your expected spend, keeping the remaining 20% uncommitted to maintain elasticity. This hybrid approach allows you to capitalize on discounts without sacrificing agility.
The Psychological Trap of “Savings”
There’s also a deeper, psychological reason RIs and Savings Plans are so appealing: they provide a clear, quantifiable number you can bring to leadership. “We’re saving $100,000 per year” sounds great—until someone asks, “Compared to what?”
If you’ve locked in 30% savings on an instance type that’s 3x larger than you need, you’re still overpaying. The illusion of savings can actually make it harder to justify real optimization efforts later, because the decision is “already made.”
Optimization Should Precede Commitment
In reality, the sequence should be:
- What is the actual utilization of our committed resources over time?
- Are we tracking the variance in performance demand, or just averages?
- Have our original sizing assumptions ever been revalidated?
- Are we committing to “safe” defaults or to evidence-based configurations?
It’s not that RIs and Savings Plans are bad tools—they’re valuable. But they should be used at the end of an optimization pipeline, not the beginning.
Final Thought: Optimizing for Agility
Cloud environments are inherently dynamic. Locking into fixed assumptions—without ongoing validation—undermines the very agility the cloud is meant to provide.
True optimization isn't about locking in the best deal; it's about maintaining the flexibility to change course as your workloads and business evolve. That requires tooling and processes that continuously challenge your decisions, not just track your spend.
Question for You
How often does your team revisit the resource commitments you've made? And when you do, are you evaluating them against live usage data—or just trying to “fill the gap” on existing spend? We would love to hear your perspective.