Reserved capacity vs committed-use: the contract details that matter
AWS RI scope rules, GCP CUD exchange policy, Azure RI cancellation policy. The fine print that decides whether your commitment is worth signing.
Every hyperscaler offers a "save up to X%" commitment program. The headline numbers are similar across all three. The contract terms are not. Here's the fine print that decides whether a 3-year commitment is a smart move or a mistake.
The commitment program landscape
| Program | Term | Max savings | Flexibility |
|---|---|---|---|
| AWS Compute Savings Plan | 1y / 3y | ~27% (1y) / ~50% (3y) | Any region, any family, any tenancy |
| AWS EC2 Instance Savings Plan | 1y / 3y | ~40% (1y) / ~66% (3y) | Specific family in specific region |
| AWS Standard RI | 1y / 3y | ~40% / ~72% | Specific family, can't change |
| AWS Convertible RI | 1y / 3y | ~31% / ~54% | Can exchange for different family |
| GCP 1y / 3y CUD (resource-based) | 1y / 3y | ~37% / ~55% | Specific machine series |
| GCP Spend-based CUD | 1y / 3y | ~25% / ~50% | Cross-resource flexibility |
| Azure RI | 1y / 3y | ~40% / ~72% | Specific region + family, exchange allowed |
The 5 contract details that actually matter
1. Region scope
AWS Compute Savings Plans cover any region — useful if you're growing internationally and might shift workloads. EC2 Instance SP and AWS Standard RIs are region-locked. Move your workload across regions for a DR drill or just because Azure is undercutting in us-west-2 next year, and your commitment is stranded.
Azure RIs are region-locked but allow one free exchange per RI per year to a different region. GCP resource-based CUDs are region-locked, spend-based CUDs are project-wide.
2. Family lock-in
AWS Standard RI is family-locked. Buy 3 years of m6i in 2026, AWS releases m7i in 2027 at the same price with 25% more performance, and you're paying for older hardware until 2029.
AWS Convertible RIs and Compute Savings Plans dodge this. The convertible exchange is one-way — exchange for instances of equal or greater commitment value, never less. GCP CUDs don't allow family exchange at all without canceling.
3. Cancellation policy
AWS: No cancellations. You can sell unused RIs on the AWS RI Marketplace (for Standard, not Convertible), but the secondary market sometimes lags primary pricing.
GCP CUDs: No cancellations.
Azure RIs: Cancellation allowed with up to 50% early-termination fee, up to $50,000 per year. This is the most flexible of the three but the termination fee is real.
Plan for "what happens if we shut down this workload" before signing.
4. Payment options
- All upfront: biggest discount, highest opportunity cost on cash.
- Partial upfront: middle ground.
- No upfront: smallest discount but no cash impact.
Mathematically, "all upfront" is usually 4-8% better than "no upfront" over the term. For most companies with a positive cost of capital, "no upfront" or "partial upfront" is the rational choice — the cash you would have spent upfront earns more in T-bills than the additional discount.
5. Operating system / tenancy
AWS RIs are tied to a specific OS family (Linux, RHEL, Windows). Move from Linux to Windows on the same instance and your RI doesn't apply. Tenancy (default, dedicated) is also locked. Most teams pick Linux + default and never think about it again, but for regulated workloads moving to dedicated tenancy mid-term, this matters.
The "right size first" gotcha
Buying RIs for instances you haven't right-sized is a classic mistake. A team commits to 3 years of m5.2xlarge because that's what they're running today, then realizes the workload could comfortably run on m5.xlarge with autoscaling. The RI is for the larger size — they're committed to capacity they don't need.
Always right-size before committing. Run with on-demand for at least 60 days, monitor real CPU/RAM utilisation, then commit to the actually-needed size.
The "coverage ratio" approach
Aim to cover 70-80% of your steady-state compute with commitments, never 100%. The remaining 20-30% absorbs growth, instance type churn, and workloads you can't predict. Common pattern:
- Compute Savings Plan covering ~60% of baseline — for the bulletproof core.
- Spot for ~25% — for stateless workers and CI/CD.
- On-Demand for ~15% — the elastic top.
This balance has the best risk-adjusted savings I've seen, about 35-45% effective discount on the total compute bill, with no scenarios where the commitment becomes a millstone.
Spend-based CUDs are different
GCP spend-based CUDs are essentially "AWS Compute Savings Plans for GCP" — commit to dollars/hour, apply to any compute resource in the project. Same flexibility, similar discounts. If you're on GCP and not already using these, switch from resource-based CUDs.
Note: GCP also offers automatic Sustained Use Discounts on top of CUDs. Run a VM for 25%+ of the month, get a small discount automatically. CUDs apply on top. This is genuinely better than AWS' all-or-nothing model.
The 3-year math
3-year commitments offer roughly double the discount of 1-year. The cash question: am I sure this workload will still exist, at this size, in 3 years? For mature SaaS workloads, yes. For new products, maybe.
A halfway hedge: stagger your commitments. Buy 1/3 of your baseline in 3-year RIs, 1/3 in 1-year, 1/3 on-demand. Re-evaluate every year.
The actual savings, honestly
Most teams I've worked with land at 25-40% effective compute discount after factoring in:
- Under-commitment (intentionally) to avoid waste.
- Right-sizing changes that reduce baseline mid-term.
- Some workloads that don't fit the commitment's family/region.
The headline "72% savings" is only available if you commit perfectly to a workload that runs unchanged for 3 years. Nobody does that.
To compare on-demand and committed pricing per instance, every row in the cloudprice catalogue shows both. For a cross-provider view of how the discount programs stack up, see AWS vs GCP.
External: AWS Savings Plans, GCP CUDs, Azure Reservations.