Reserved vs On-Demand Instances: When to Use Each

Teams waste thousands of dollars monthly by running stable production workloads on expensive on-demand instances, while simultaneously locking themselves into multi-year Reserved Instance commitments for experimental projects that shut down after six months. The core problem isn't understanding that Reserved Instances offer discounts—it's knowing which workloads justify commitment and which benefit from on-demand flexibility.

This guide breaks down the actual economics of Reserved versus On-Demand instances across AWS, GCP, and Azure, examining when each pricing model makes financial sense. You'll learn how to calculate breakeven points for different commitment terms, which workload characteristics predict stable capacity needs, how to avoid common RI purchase mistakes that lock you into obsolete infrastructure, and strategies for mixed deployments that balance savings with flexibility.

We structure the article around core decision criteria—workload stability, growth trajectory, and budget constraints—followed by detailed scenarios showing optimal instance purchasing strategies for different business contexts.

Understanding the Fundamental Trade-Off

On-demand instances let you pay for compute capacity by the hour or second with no long-term commitments. You start instances when needed, stop them when done, and pay only for runtime. This flexibility costs a premium—on-demand represents the highest per-hour pricing cloud providers offer.

Reserved Instances (called Committed Use Discounts on GCP, Reserved VM Instances on Azure) exchange commitment for savings. You commit to running specific instance types in specific regions for one or three years, receiving 30-70% discounts compared to on-demand pricing. The discount increases with commitment term (3-year RIs save more than 1-year) and upfront payment (all-upfront saves more than no-upfront).

The economic equation is straightforward: if an instance runs continuously for the full commitment period, Reserved Instances always cost less. The complexity arises from uncertainty—will this workload actually run for one or three years? Will instance requirements change? Will you need to scale down or shut down?

Calculating Breakeven Points

Before committing to Reserved Instances, calculate how long the instance must run to recoup the commitment cost compared to on-demand.

No-Upfront Reserved Instances

No-upfront RIs require no initial payment—you pay monthly at a discounted hourly rate. For a 1-year AWS RI with no upfront payment, you typically save 38-42% compared to on-demand. The breakeven point is approximately 7.5 months—if the instance runs for 7.5 months, you pay the same total cost as on-demand. Beyond that, you save money.

This calculation assumes continuous runtime. If the instance runs only during business hours (40 hours/week instead of 168 hours/week), your effective uptime is 24% of total hours, extending the breakeven point to 31 months—longer than the 12-month commitment. In this scenario, the RI costs more than on-demand would have.

Partial and All-Upfront Options

Partial upfront RIs require approximately 50% payment upfront, with the remainder paid monthly at further reduced hourly rates. All-upfront RIs require 100% payment upfront but offer the deepest discounts (55-60% for 1-year, 65-72% for 3-year).

All-upfront RIs have faster breakeven—typically 6 months for 1-year commitments—but they tie up capital. A $10,000 all-upfront RI locks that capital for the full year, whereas no-upfront RIs preserve liquidity. For startups where cash runway matters, no-upfront or partial-upfront RIs often make more sense despite slightly lower savings.

Three-Year Commitments

Three-year RIs offer maximum savings—up to 72% off on-demand pricing with all-upfront payment. However, three years represents significant technology evolution. Instance types that are optimal today may be obsolete or inefficient compared to new offerings within 36 months. AWS's Graviton instances didn't exist three years ago; teams locked into Intel-based RIs couldn't take advantage of Graviton's 40% lower pricing without abandoning their commitments.

The 3-year breakeven point for no-upfront RIs is approximately 20-22 months. While this seems favorable, it doesn't account for opportunity cost—being locked into old instance types while more efficient options emerge.

Workload Characteristics That Favor Reserved Instances

Certain workload patterns strongly indicate RI suitability, while others suggest on-demand flexibility is worth the premium.

Stable Production Workloads

Applications that have been running consistently for 6+ months with minimal instance type changes are strong RI candidates. Your production database that's been running on db.m5.xlarge for eight months will likely continue for another year—purchasing a 1-year RI saves 40% with minimal risk.

The key metric is consistency. If you've changed instance types or sizes more than twice in the past six months, your workload is too volatile for RIs. Stability doesn't mean zero growth—it means predictable growth where you can anticipate capacity needs.

Baseline Capacity in Auto-Scaling Groups

Applications with variable load often maintain baseline capacity that runs continuously with spikes handled by additional instances. If your auto-scaling group's minimum size is 10 instances and rarely drops below that, purchasing RIs for 8-9 of those baseline instances reduces costs while maintaining flexibility to scale beyond baseline on-demand.

This mixed strategy—RIs for baseline, on-demand for variable load—optimizes economics without sacrificing elasticity. The worst approach is purchasing RIs for peak capacity, leaving them idle during low-traffic periods.

Known Long-Term Projects

When launching a new product with committed customer contracts or multi-year funding, infrastructure requirements are more predictable. If you've signed a 2-year B2B contract requiring dedicated infrastructure, purchasing 1-year RIs (renewing after year 1) makes clear economic sense.

Contrast this with speculative projects or experiments where duration is uncertain. A side project that might grow massively or get shut down within months should run on-demand until stability is evident.

Scenarios Where On-Demand Makes More Sense

On-demand instances cost more per hour but provide value through flexibility in specific scenarios.

Development and Testing Environments

Dev and test instances that run only during work hours (40-50 hours weekly) have low utilization rates. An RI requires payment for 168 hours weekly regardless of usage, making it 3-4x more expensive than on-demand for these workloads.

Better strategy: run dev/test on-demand, implementing automated start/stop schedules. Start instances at 8 AM, stop at 6 PM on weekdays. This reduces runtime to approximately 50 hours weekly, costing 30% of running the same instance continuously—far cheaper than an RI.

Temporary Workloads

Batch processing jobs, CI/CD runners, machine learning training runs, and data migrations often need significant compute for hours or days, then nothing for weeks. On-demand instances serve these workloads perfectly—you pay only for actual usage without commitment overhead.

Spot instances offer even better economics for interruptible workloads (70-90% off on-demand), but that's a separate consideration. Between RIs and on-demand for temporary workloads, on-demand wins clearly.

Rapidly Changing Architectures

Early-stage companies iterating rapidly on product architecture should avoid RIs. If you're experimenting with different database types, considering serverless migrations, or unsure whether Kubernetes is the right platform, purchasing RIs locks you into current architecture decisions.

Wait until architecture stabilizes—typically 6-12 months into a project—before committing to RIs. The higher on-demand costs during experimentation are offset by freedom to make architectural changes without financial penalty.

Savings Plans as a Middle Ground

AWS Savings Plans and GCP's Flexible Committed Use Discounts offer a compromise between RI rigidity and on-demand flexibility.

How Savings Plans Work

Instead of committing to specific instance types, you commit to a dollar amount of compute usage per hour (e.g., $10/hour) for one or three years. This commitment applies to any EC2 instance type, Fargate, or Lambda usage, automatically covering your most expensive resources first.

The flexibility advantage is significant. If you commit to $10/hour and initially run m5.large instances, then later migrate to m6g.large (Graviton), the commitment transfers automatically. With traditional RIs, you'd be locked into m5.large, unable to benefit from cheaper m6g instances without abandoning your commitment.

Savings Plans vs. Reserved Instances

Savings Plans typically offer 3-5% less discount than equivalent RIs. A 1-year EC2 Instance RI might save 42%, while a comparable Compute Savings Plan saves 38-40%. This discount gap is the price of flexibility.

For teams that change instance types quarterly or run workloads across multiple instance families, the flexibility justifies the slightly lower savings. For teams with very stable workload requirements that haven't changed instance types in over a year, traditional RIs maximize savings.

Compute Savings Plans vs. EC2 Instance Savings Plans

AWS offers two Savings Plan types: Compute Savings Plans cover EC2, Fargate, and Lambda with maximum flexibility but lower discounts (50-54% vs on-demand). EC2 Instance Savings Plans cover only EC2 but offer higher discounts (60-66%) and allow instance family changes within the same region.

Most teams benefit from EC2 Instance Savings Plans—they provide most of the flexibility (changing from m5.large to m5.xlarge or m6g.large) while maintaining strong discounts. Compute Savings Plans make sense for teams running significant serverless workloads alongside EC2.

Reserved Instance Purchasing Strategy

Effective RI management requires systematic approach, not one-time purchase decisions.

Start Conservative

When first adopting RIs, purchase coverage for only 50-60% of your stable workload. If you run 20 production instances continuously, buy RIs for 10-12 of them. This provides savings while maintaining flexibility if requirements change.

After 3-4 months, evaluate actual usage. If those RIs ran continuously without issue, expand coverage to 70-80%. Approaching 100% RI coverage is risky—it leaves no flexibility for architectural changes or optimization opportunities.

Quarterly Review Process

Schedule quarterly reviews of RI utilization and coverage. AWS Cost Explorer and similar tools show RI utilization rates—aiming for 95%+ utilization ensures you're not paying for unused commitments.

Also review coverage—what percentage of your instance usage is covered by RIs versus running on-demand? If coverage drops below 60% for stable workloads, you're missing savings opportunities. If it exceeds 90%, you've likely over-committed and lack flexibility.

Regional Considerations

RIs can be regional or zonal. Zonal RIs (AZ-specific) offer capacity reservations—you're guaranteed instance availability in that AZ—but only apply to instances in that specific availability zone. Regional RIs provide flexibility to run instances in any AZ within the region but don't guarantee capacity.

For most workloads, regional RIs are superior. The slight discount difference (1-2%) isn't worth losing AZ flexibility. Zonal RIs make sense only for capacity-constrained instance types during peak demand periods (like training large ML models on GPU instances).

Common Reserved Instance Mistakes

The most expensive mistake is purchasing RIs for workloads you plan to change. Teams often buy RIs for current state, then realize they want to migrate to different database engines, switch to serverless, or adopt new instance families. The RI becomes a sunk cost that actually increases total spending by preventing optimization.

Over-Committing on Three-Year Terms

Three-year RIs offer maximum savings but maximum risk. Your infrastructure needs three years from now are fundamentally unpredictable—you might migrate to Kubernetes, adopt serverless architectures, or find that new instance types offer 50% better price-performance.

If you do purchase 3-year RIs, limit them to core infrastructure that's extremely unlikely to change: established databases serving long-term customers, authentication services, internal tooling that's stable for years. Avoid 3-year RIs for application servers, experimental services, or anything running on cutting-edge instance types.

Ignoring Instance Family Evolution

AWS releases new instance families every 12-18 months with 20-40% better price-performance. Purchasing RIs when instance families are near end-of-life locks you into obsolete pricing. The m5 family launched in 2017; by 2020, m6g (Graviton2) offered 40% better price-performance. Teams locked into 3-year m5 RIs couldn't capitalize on this improvement.

Before purchasing, research instance family timelines. If the current family has been available for 2+ years, newer generations are likely imminent. Either wait for the new family or purchase shorter-term (1-year) RIs to maintain flexibility.

Buying RIs for Variable Workloads

Some teams purchase RIs covering peak capacity, then wonder why utilization is only 40%. RIs make sense for baseline capacity—the instances running 24/7 regardless of traffic. Variable load above baseline should use on-demand or spot instances.

Analyze your workload's capacity profile over time. If minimum capacity is 10 instances and peak is 50, consider RIs for 8-12 instances (your true baseline) rather than all 50.

Marketplace and Exchanging Reserved Instances

When you've purchased the wrong RIs or your needs have changed, AWS offers mechanisms to recover some value.

Reserved Instance Marketplace

AWS allows selling unused Standard RIs (not Convertible RIs) through the Reserved Instance Marketplace. You list your RI, set a price (typically 70-85% of remaining value), and other AWS customers can purchase it.

The marketplace provides liquidity for RI mistakes but at significant loss. You'll recover 60-80% of remaining value, losing 20-40%. This beats letting an RI sit unused (0% recovery), but it's expensive compared to never over-purchasing in the first place.

RI Modifications and Exchanges

AWS allows modifying Standard RIs within instance families—changing from m5.large to m5.xlarge or splitting one m5.xlarge into two m5.large. This provides limited flexibility without marketplace losses.

Convertible RIs allow exchanging for different instance families, operating systems, or tenancies, but with lower discounts (45-55% vs 65-72% for Standard RIs). If you anticipate potential architecture changes, Convertible RIs reduce risk through exchange flexibility, accepting lower savings as insurance against change.

GCP and Azure Equivalent Strategies

While this guide focuses on AWS terminology, similar principles apply to GCP's Committed Use Discounts and Azure's Reserved VM Instances.

GCP Committed Use Discounts

GCP offers 1-year and 3-year commitments with discounts of 37% and 55% respectively for most instance types. GCP's committed use discounts automatically apply to any matching instances—you don't purchase specific instances but commit to vCPU and memory amounts.

This resource-based model provides more flexibility than AWS's instance-specific RIs. If you commit to 100 vCPUs and 400GB RAM, GCP applies the discount to whatever combination of instances uses that capacity—whether it's 25 n2-standard-4 instances or 10 n2-standard-10 instances.

Azure Reserved VM Instances

Azure offers 1-year and 3-year reservations with similar discount structures (40-65% savings). Azure allows instance size flexibility within the same series—a reservation for D2s_v3 applies to D4s_v3 instances at proportional coverage.

Azure's distinctive feature is the cancellation policy—you can cancel up to $50,000 of reservations per year with a 12% early termination fee. This provides an exit strategy for commitments that no longer align with needs, though the fee makes it expensive insurance.

When to Mix On-Demand, Reserved, and Spot

Optimal cost efficiency often combines all three pricing models for different workload components.

Three-Tier Strategy

Layer your infrastructure across pricing models: Reserved Instances for baseline capacity (the minimum instances always running), on-demand for variable load (scaling beyond baseline during traffic spikes), and spot instances for fault-tolerant workloads (batch jobs, CI/CD, development environments).

A practical example: an e-commerce platform might run its database and core 10 application servers on RIs (stable baseline), scale to 30 additional application servers on-demand during peak hours, and run product image processing as batch jobs on spot instances. This balances savings (70% on RIs), flexibility (on-demand scaling), and maximum cost efficiency (spot for interruptible work).

Percentage Allocations

A reasonable starting allocation for production workloads: 60-70% coverage with RIs (baseline capacity), 20-30% on-demand (variable load), and 0-10% spot (wherever fault-tolerance allows). This provides significant savings while maintaining operational flexibility.

Adjust based on workload characteristics. Stable enterprise SaaS platforms might achieve 80% RI coverage. High-growth consumer apps with unpredictable traffic might maintain only 40% RI coverage to preserve scaling flexibility.

Financial and Planning Considerations

Beyond pure cost optimization, RI decisions involve financial planning and cash management.

Capital Allocation

All-upfront RIs require significant capital—$50,000+ for meaningful production coverage. For startups where cash runway is measured in months, preserving liquidity often matters more than maximizing savings. No-upfront RIs provide 80-90% of the savings while preserving cash for product development and team growth.

Established companies with predictable revenue can treat all-upfront RIs as infrastructure investments with 40-60% ROI over the commitment period—excellent returns compared to most investment options.

Budget Predictability

RIs provide cost predictability valuable for financial planning. A 1-year RI commitment sets known monthly costs, simplifying budgeting and financial forecasting. On-demand costs fluctuate with usage, making month-to-month budgeting more challenging.

For publicly-traded companies or those with detailed board reporting requirements, RI predictability can justify even in scenarios where pure cost savings are marginal.

Frequently Asked Questions

How long should instances run before I buy Reserved Instances?

Wait until instances have run continuously in the same configuration for 6 months. This demonstrates stability sufficient to justify 1-year commitments. Avoid purchasing RIs for instances less than 3 months old—workload requirements are still stabilizing and you're likely to discover optimizations that change instance types or sizes.

Can I use Reserved Instances with auto-scaling groups?

Yes—RIs automatically apply to matching on-demand instances regardless of how they're launched. If you purchase 10 m5.large RIs and run an auto-scaling group that launches m5.large instances, the RIs discount the first 10 instances. Additional instances beyond RI coverage run at on-demand rates. This makes RIs effective for baseline capacity in auto-scaling groups.

What happens if I stop a Reserved Instance?

You continue paying for the RI whether instances are running or not. Stopping an instance covered by an RI doesn't pause charges—the commitment fee applies regardless of usage. This is why RI utilization matters—unused RIs waste money. Only purchase RIs for instances you're confident will run continuously.

Should I buy Reserved Instances before or after rightsizing instances?

Always rightsize first. Analyze CloudWatch metrics to determine optimal instance types and sizes, implement those changes, run for 2-4 weeks to verify performance, then purchase RIs. Buying RIs before rightsizing locks you into suboptimal configurations, negating the RI savings through waste from oversized instances.

Do Reserved Instances apply to stopped instances?

No—RIs discount running instances only. If you have a 1-year RI for an m5.large and stop that instance, you still pay the RI rate but receive no compute capacity. The RI will automatically apply to any other matching running instance (m5.large in the same region), but stopped instances consume RI benefits without providing value.

How do I choose between Standard and Convertible RIs?

Choose Standard RIs when you're highly confident in instance type stability and want maximum savings (65-72% for 3-year all-upfront). Choose Convertible RIs when you anticipate potential architecture changes and want flexibility to exchange for different instance types, accepting lower savings (45-55%) as insurance. For most teams, 1-year Standard RIs balance savings and flexibility better than Convertible RIs.

Can Reserved Instances span multiple AWS accounts?

Yes, within AWS Organizations. If you enable RI sharing, RIs purchased in the payer account or any linked account automatically apply to matching instances across all organization accounts. This lets you centralize RI purchasing while benefiting multiple teams or environments, improving utilization rates.

What's the difference between RI coverage and utilization?

Coverage measures what percentage of your running instances are covered by RIs versus running on-demand. Utilization measures what percentage of purchased RIs are actually being used. High coverage (70-80%) indicates you're maximizing savings opportunities. High utilization (95%+) indicates you're fully using purchased RIs without waste. Aim for high utilization first (don't waste RIs), then increase coverage (buy more RIs).

Should I buy RIs for databases separately from application servers?

Yes—analyze database and application workloads independently. Databases often run continuously and are stable for years, making them strong 1-year or even 3-year RI candidates. Application servers may change more frequently as you optimize architecture, suggesting more conservative RI purchases or shorter terms. Separate analysis prevents over-committing on volatile workloads.

How do Savings Plans interact with existing Reserved Instances?

RIs apply first, then Savings Plans cover remaining on-demand usage. If you have 10 m5.large RIs and a $5/hour Savings Plan, the RIs discount 10 m5.large instances, then the Savings Plan applies to remaining usage starting with the most expensive instance types. This stacking lets you layer commitments, though it also increases complexity in managing commitment inventory.

Conclusion

The Reserved vs On-Demand decision isn't binary—most organizations benefit from strategic combinations. Use RIs for stable baseline capacity, on-demand for variable load and experimentation, and spot instances where fault-tolerance allows. Start conservatively with 1-year RIs covering 50-60% of stable workloads, then expand coverage as you build confidence in workload stability.

The key is matching commitment duration to certainty. Workloads running unchanged for 6+ months justify 1-year RIs. Only extremely stable infrastructure warrants 3-year commitments. When in doubt, choose flexibility—the premium paid for on-demand instances is often cheaper than the opportunity cost of being locked into obsolete architecture.

Finally, treat RI purchasing as an ongoing practice, not a one-time decision. Quarterly reviews of utilization, coverage, and workload stability ensure your commitment strategy evolves with your infrastructure needs. The goal isn't maximizing RI coverage—it's optimizing total infrastructure costs while preserving operational flexibility.