Public cloud committed spend options are supposed to save you money, that’s the entire point of having them. Far too often though, Level Up’s clients actually tell us that deciding on an optimal AWS EC2 instance pricing strategy can feel taking like a multiple choice test… but with wrong answers only. In this Cloud Cloud Management Practice post, we slice through some common confusion between AWS On-Demand Instances vs. Reserved Instances vs. Spot Instances vs. Savings Plans. You’ll learn when and where each option likely makes the most sense, how to properly model your workload pricing strategy, and how to avoid any annual or multi-year commitment overspending.
How Can the Same EC2 Instance End Up Being Priced So Many Different Ways?
When you run compute in the cloud, you’re not just choosing the OS and instance size, you’re also choosing how much commitment and control you’re willing to trade for long-term savings.
Here’s how the main AWS EC2 options stack up today:
| Option | Flexibility | Discount (vs. Retail) | Risk / Tradeoffs | Likely Best For |
|---|---|---|---|---|
| On-Demand (Retail) | Max | 0% | Easiest to scale and experiment, but $$$ to keep running | Early dev, experimentation |
| On-Demand w/ Scheduling | High | ~30-50% | Manual savings via auto-shutdown | Internal tools, dev boxes, training |
| Reserved Instances (RI) | Low | ~30-60% | Locked to instance family, region | Predictable, fixed workloads |
| Spot Instances | Medium | ~70-90% | Can be interrupted anytime | Batch jobs, fault-tolerant workloads |
| Savings Plans (Compute) | High | ~20-60% | Must maintain usage levels | Evolving infra with steady baseline |
A quick live comparison via the AWS Pricing Calculator reveals a wide range of savings opportunities for one m5.xlarge running a Linux OS, including under $1,900 for an EC2 SP, vs. a projected $5,000+, over the same 3-year period, for the same EC2 instance, if On-Demand and running all the time. That’s a potential savings of over 60%. But it all depends on your company’s current usage and future plans for each EC2 instance, doesn’t it? Paying for an SP or RI for the next 3 years for an EC2 instance that you won’t end up needing, is always going to be more expensive than simply not running it at all.
BTW, the potential tradeoff between On-Demand vs. Spot gets a lot more interesting if you model for only running an On-Demand Instance 60 hours per week (e.g., 12 hours per weekday). These are practically the same monthly price:
Reserved Instances: Savings with Strings Attached
If you can commit to specific instance types and configurations (region, OS, tenancy, etc.), Reserved Instances (RI’s) offer significant cost savings compared to on-demand pricing.
- Best for: Predictable, long-lived workloads where the instance type won’t change (e.g., database servers, steady backend services).
- Typical savings: 30-60% depending on term length and payment type.
- Flexibility: Low. You’re locked into specific instance families and regions.
- Term options: 1 or 3 years, with no upfront, partial upfront, or all upfront payments.
The Catch? RI pricing rewards certainty, but penalizes change. If you’re continually iterating on your infra, RI’s can end up becoming deadweight.
Savings Plans: Flexibility, at a Slight Premium
Savings Plans (SP’s) offer similar discounts to RI’s, but with less rigidity, especially if you go with Compute Savings Plans, which apply across EC2, Lambda, and Fargate.
- Best for: Teams in motion: migrating, scaling, or refactoring services.
- Typical savings:
- Compute SP’s: 20-40%
- EC2 SP’s: up to ~60%, in optimal cases
- Flexibility: High. Compute SP’s work across instance types, regions, and services.
- Term options: 1 or 3 years, any upfront model.
RI’s vs. SP’s: How Do You Actually Choose?
Here’s a decision tree that boosts real savings signal above all the cost noise:
- Are your workloads stable, predictable, and long-lived?
→ Strongly consider RI’s, especially for known infrastructure like managed databases or legacy services. - Do your workloads shift, scale, or move across services (EC2 → Lambda → Fargate)?
→ Compute SP’s are your friend. - Do you want to optimize cost without sacrificing agility?
→ Lean toward SP’s, especially if you’re still evolving your IaaS. - Are you managing multiple accounts or a large org with varied workloads?
→ Use SP’s pooled at the org level to absorb usage shifts gracefully.
What This Actually Means in Practice
- On-Demand = Freedom at a Premium
You’re paying top dollar for maximum optionality. Ideal for testing, iterating, or variable loads. - Scheduled On-Demand = Easy Wins
You still pay full price per second, but you decide not to run 24/7/365. Shutdown instances on nights/weekends and you can see instant 40–60% savings on non-prod environments. No commitment, no lock-in. - RI’s = Locked Savings
You commit to specific instance types for 1 or 3 years. Great when your workloads won’t change. But if you re-platform, resize, or move regions? You’re stuck with sunk cost. - Spot = Deep Discounts, If You Can Tolerate Some Chaos
Spot instances can be interrupted with 2 minutes’ notice. But for stateless, parallelizable workloads, they can cut costs by 80-90%. Just don’t rely on them for anything mission-critical! - SP’s = Middle Ground (in the Enterprise Especially)
You commit to dollars per hour of compute usage, not instance types. So you can change instance families, regions, or even shift from EC2 to Fargate or Lambda. You still get big savings (~20-50%), with far less lock-in than RIs.
How to Model Commitments Like a Pro
Before you commit:
- Analyze historical usage: Use AWS Cost Explorer or third-party tools to identify consistent usage patterns.
- Forecast future scaling: Talk to engineering teams. What’s likely to grow, migrate, or disappear?
- Diversify commit types: Mix and match SP’s and RI’s to balance certainty vs. flexibility.
- Set clear thresholds for On-Demand usage: Sometimes paying a little extra for optionality is the smarter long-term play.
Avoiding the Common Trapdoors
- Overcommitting: It’s tempting to chase the biggest discount, but unused commitments are almost always pure waste.
- Forgetting regional constraints: Standard RI’s are region-locked; moving workloads breaks the savings. Convertible RI’s provide a little more freedom of movement and resizing, but with the downside of reduced savings.
- Ignoring architectural change: If you’re adopting containers, serverless, or replatforming, RI’s may become obsolete.
- Failing to revisit commitments regularly: Things change fast in the cloud. What made sense 9 months ago may make zero sense today.
TL;DR: Think Like a Cloud Portfolio Manager
Level Up’s view is that, in the end, smart FinOps isn’t about finding one commitment model. It’s about layering strategies:
- Use On-Demand with scheduled shutdowns for dev/test/staging. Unless your developers are working 24/7, why should their dev instances be?
- Lock in RI’s for fixed, predictable infra that won’t likely change.
- Opt for SP’s for more dynamic, yet mission-critical services.
- Buckle up with Spot Instances for CI/CD, rendering, or batch jobs.
- Launch some On-Demand for bursty (think: Auto-Scaling Groups) or new services, where overcommitting early could hurt your budget down the road.
Ready to get started remixing your EC2 instance fleet to optimize your overall cloud costs?
Show us your latest public cloud bill. We’ll show you 5 things you probably didn’t know about it: cloudcostmgmt@levelupla.io.
Level Up’s Cloud Cost Management Practice turns cloud spend into clarity, and clarity into confidence