Cloud Reserved Instance Strategy: Commitment-Based Discounts That Actually Save Money
How to build a reserved instance and savings plan strategy that maximizes cloud discounts without over-committing — covering AWS, Azure, and GCP commitment models.
Reserved instances (RIs) and savings plans offer 30-72% discounts over on-demand pricing, but the wrong commitment strategy can cost more than it saves. This guide covers how to analyze usage, right-size commitments, and manage a portfolio of cloud reservations.
The Commitment Spectrum
On-Demand ←→ Spot/Preemptible ←→ Savings Plans ←→ Reserved Instances
$$$ $ $$ $
No commit Interruptible Flexible commit Fixed commit
Max flex Fault tolerant Moderate flex Least flexibleDiscount Comparison (Approximate)
| Commitment Type | Discount vs On-Demand | Flexibility | Risk |
|---|---|---|---|
| On-Demand | 0% | Complete | Zero |
| Spot/Preemptible | 60-90% | None (can be reclaimed) | High |
| 1-Year Savings Plan | 20-35% | Instance family flexible | Low |
| 3-Year Savings Plan | 35-55% | Instance family flexible | Medium |
| 1-Year Reserved | 30-40% | Instance-specific | Medium |
| 3-Year Reserved | 55-72% | Instance-specific | High |
Step 1: Analyze Your Baseline
Before committing, you need to understand your steady-state usage.
Minimum Coverage Analysis
Look at 90 days of usage data to identify the floor — the minimum compute you always need running:
Hour-by-hour usage (simplified):
├── Peak: 200 instances
├── Average: 120 instances
├── P10 (floor): 80 instances
└── Minimum: 60 instancesRule: Only commit to the floor (P10 or below). Cover the rest with on-demand or spot.
Right-Sizing First
Don’t reserve instances you haven’t right-sized. Common waste patterns:
- Instances running at 10-15% CPU (oversized by 2-4x)
- Memory-optimized instances running CPU-bound workloads
- GPU instances used for non-ML workloads
Right-size first, then commit. Reserving a c5.4xlarge when you need a c5.xlarge locks in 4x the waste.
Step 2: Choose Your Commitment Model
AWS
Savings Plans (recommended for most):
- Compute Savings Plans: Flexible across instance families, regions, and OS
- EC2 Instance Savings Plans: Specific instance family in a region
Reserved Instances:
- Standard: Cheapest, least flexible
- Convertible: Exchange for different instance types
Azure
Reservations: 1-year or 3-year commitments for VMs, SQL, Cosmos DB, etc.
Azure Savings Plans: Flexible across VM families and regions.
GCP
Committed Use Discounts (CUDs): 1-year or 3-year, machine-type specific.
Flexible CUDs: Shared across projects in a billing account.
Step 3: Portfolio Strategy
The 60/25/15 Model
60% — Committed (RIs/Savings Plans)
└── Covers your steady-state baseline
└── Mix of 1-year (flexibility) and 3-year (max discount)
25% — On-Demand
└── Covers variable workloads and growth
└── Buffer for seasonal spikes
15% — Spot/Preemptible
└── Fault-tolerant batch processing
└── Dev/test environments
└── Non-critical background jobsStaggered Expiration
Don’t let all reservations expire at once:
- Buy in quarterly batches
- Mix 1-year and 3-year terms
- This prevents cliff-edge re-commitment decisions
Multi-Account Distribution
In AWS Organizations, RIs can be shared across linked accounts. Ensure sharing is enabled and monitor for unused capacity in any account.
Step 4: Monitor and Optimize
Key Metrics
| Metric | Target | Action if Behind |
|---|---|---|
| RI Utilization | > 95% | Sell unused RIs on marketplace |
| RI Coverage | 60-75% of steady state | Purchase additional commitments |
| Effective Savings Rate | > 25% | Review commitment strategy |
| Waste (unused commits) | < 5% | Downsize or sell reservations |
Quarterly Review Cycle
- Review utilization of existing commitments
- Analyze expiring reservations (what to renew vs. let lapse)
- Assess new workloads that have stabilized
- Adjust spot/on-demand mix based on actual patterns
Common Mistakes
Over-Committing Early
Don’t buy 3-year reservations for a service you launched last month. Wait 3-6 months until usage stabilizes.
Ignoring Instance Family Changes
Cloud providers release new instance generations regularly. A 3-year reservation on a c5.xlarge can’t be upgraded to c7g.xlarge (unless convertible).
No Exchange Strategy
AWS allows exchanging convertible RIs. If your workload changes, exchange — don’t let reservations go unused.
Treating RIs as “Set and Forget”
Usage patterns change. Applications are decommissioned. Teams migrate to containers. Review commitments quarterly.
Not Using the RI Marketplace
AWS allows selling unused standard RIs on the marketplace. If you have 6 months left on an unused RI, sell it and recover some value.
Automation
Tools
- AWS Cost Explorer — Built-in RI recommendations
- Azure Advisor — Reservation purchase recommendations
- Infracost — RI analysis in CI/CD pipelines
- CloudHealth / Apptio — Enterprise FinOps platforms
- Spot.io (NetApp) — Automated commitment management
Automated Purchasing Rules
auto_purchase_rules:
- condition: "steady_state_usage > 30_days"
action: "recommend_1yr_savings_plan"
- condition: "steady_state_usage > 90_days AND growth < 5%"
action: "recommend_3yr_savings_plan"
- condition: "ri_utilization < 80% for 14_days"
action: "alert_finops_team"The best cloud cost strategy balances commitment discounts with operational flexibility. Over-commit and you’re locked into waste. Under-commit and you’re leaving money on the table. The sweet spot requires continuous monitoring and quarterly adjustment.
