Reserved capacity is a commitment-for-discount trade: you commit to a baseline of compute usage for one or three years and the cloud provider discounts it 30-70% off on-demand pricing. It's one of the largest, lowest-effort levers available in FinOps — and one of the easiest to get wrong by over-committing to capacity that doesn't match how the workload actually grows or shifts.
The commitment models, and how they differ
AWS offers both Reserved Instances (tied to a specific instance family and region, less flexible, historically slightly deeper discount) and Savings Plans (a dollar-per-hour compute commitment that applies automatically across instance families, sizes, and even to Fargate and Lambda — far more flexible, now the generally recommended default for AWS). Azure Reserved VM Instances work similarly to AWS RIs, with Azure Savings Plans for Compute as the newer, more flexible equivalent. GCP takes a different default approach entirely: Committed Use Discounts require an explicit commitment much like AWS RIs, but GCP also applies Sustained Use Discounts automatically with no commitment at all, simply for running an instance for a large fraction of the billing month — a meaningfully different default posture from AWS and Azure.
AWS
On-Demand baseline
Savings Plan (1yr) ~20-40% off, flexible across instance family
Savings Plan (3yr) ~40-60% off, flexible across instance family
Reserved Instance up to ~72% off, locked to instance family+region
Azure
Pay-as-you-go baseline
Reserved VM Instance up to ~65-72% off, 1yr or 3yr
Azure Savings Plan ~similar to AWS Savings Plans, more flexible
GCP
On-Demand baseline
Sustained Use Discount automatic, no commitment, up to ~30% off
Committed Use Discount 1yr or 3yr, up to ~57% offCoverage vs. utilization — the two numbers that matter
Coverage measures what percentage of your actual usage is covered by a commitment; utilization measures what percentage of the commitment you're actually using. Low coverage means you're leaving discount on the table by paying on-demand rates for usage that's stable enough to commit. Low utilization means you bought more commitment than you're using and are paying for idle reserved capacity — arguably the worse mistake, because that money is gone whether you use it or not. The healthy target is high coverage on your genuinely stable baseline and near-100% utilization of whatever you've committed to.
Workloads shrink — a service gets deprecated, a migration moves load elsewhere, a team over-provisioned and later rightsizes. Committing to 100% of today's baseline against a 3-year term means you're paying for capacity you may not need in year two. A common rule of thumb is committing to 60-80% of the trailing baseline and covering the rest with on-demand or shorter-term commitments, leaving room to shrink without stranding a commitment.
1-year vs. 3-year: the real tradeoff isn't just discount depth
The deeper discount on a 3-year term is tempting, but it assumes you know what your infrastructure looks like three years out — a bet that's much safer for a stable, mature workload than for a team still finding product-market fit or mid-migration to a new architecture. A 1-year term costs a few percentage points of discount in exchange for the ability to re-evaluate annually as the workload, pricing, and even provider strategy evolve.
The review cadence that prevents waste
Reserved capacity isn't a set-and-forget purchase. A quarterly review of coverage and utilization reports (AWS Cost Explorer's RI/Savings Plans utilization report, Azure's Reservation utilization view, GCP's Committed Use Discount reports) catches drift before a commitment turns into stranded spend — a team that migrated off EC2 to Fargate, for instance, needs its RI strategy to follow. AWS's Savings Plans and GCP's Committed Use Discounts can often be modified or exchanged mid-term with more flexibility than classic Reserved Instances, which is another reason the more flexible commitment types are usually the safer default for teams without years of stable historical usage data.
Savings Plans and Committed Use Discounts apply automatically across a broader set of resource types with less operational overhead than instance-family-locked Reserved Instances. Unless you have a very stable, well-understood workload and want the last few points of discount that RIs offer over Savings Plans, the flexible option is the safer starting point.
Reserved capacity is worth pursuing once a workload's baseline is predictable enough to commit against — usually visible after a few months of stable usage data. Commit to the trailing baseline, not the peak, prefer the flexible commitment type, and review coverage and utilization quarterly so the discount doesn't quietly turn into waste.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.