Cloud commitment discounts are lower rates in exchange for a promise to use a quantity of resources or to spend an amount per hour for one or three years, and all three providers offer them in two families: usage-based on a configuration and spend-based on an amount. The type sets what the commitment binds, an instance family, a region, a service or only money, and so what a change to the infrastructure does to the discount. For the bill, that means the tighter a type binds, the higher the discount the provider usually states, and the more likely a fee keeps running without matching usage after a change.
How it works
Two families
FOCUS separates them in the column CommitmentDiscountCategory as Usage, a committed quantity, and Spend, a committed amount. Usage-based are Reserved Instances at AWS, reservations at Azure and resource-based committed use discounts at Google. Spend-based are Savings Plans at AWS and Azure and Google's spend-based CUDs, as a compute flexible commitment, per service, or as a Flexible Savings Plan with a monthly rather than an hourly window. The FinOps Foundation's Rate Optimization capability draws the same line between resource-based and spend-based commitment discounts and notes that the discount grows with the restriction; the terms are placed in context in the four FinOps domains and their capabilities.
Comparison
| Programme | Binds | Term and payment | Flexibility | Exit | Capacity |
|---|---|---|---|---|---|
| AWS Reserved Instances | instance type, region, platform, tenancy | 1 or 3 years; All, Partial or No Upfront | size within the family for regional Linux RIs; Convertible exchangeable | Standard sellable, Convertible exchangeable | zonal RIs only |
| AWS Savings Plans | USD per hour; EC2 Instance also family and region | 1 or 3 years; three payment options; Database 1 year, no upfront only | Compute: family, size, region, operating system, Fargate, Lambda | return within narrow limits only | no |
| Azure reservations | product, region, scope | 1 or 3 years; upfront or monthly | instance size flexibility; scope can change | exchange and refund within limits | no, separate capacity reservations instead |
| Azure savings plans | amount per hour | 1 or 3 years; upfront or monthly | services and regions within scope | none | no |
| Google resource-based CUDs | vCPU, memory, GPU, local SSD of one machine series, region, project | 1 or 3 years, extendable; monthly fee | CUD sharing across projects; merge, split, upgrade | none | only with an attached reservation |
| Google spend-based CUDs | amount per hour, per month for Flexible Savings Plans | 1 or 3 years; monthly fee | projects, all regions depending on the service | none | no |
The ceilings the providers state on 2026-10-16: AWS up to 72% for Standard RIs and EC2 Instance Savings Plans, 66% for Convertible RIs and Compute Savings Plans, 35% for Database Savings Plans; Azure up to 72% for reservations and 65% for the savings plan for compute; Google up to 55% for resource-based hardware commitments, 70% for memory-optimised series, and for compute flexible commitments on general-purpose series such as E2, N2 and C4, 28% for one year and 46% for three.
Order of application
Where both families could cover the same usage, a fixed order applies. AWS applies Reserved Instances first, then Savings Plans, EC2 Instance before Compute. Azure applies reservations before savings plans, and among savings plans three-year and more narrowly scoped plans first. Google uses resource-based commitments first, then compute flexible commitments; service-specific commitments take precedence over a compute flexible commitment. The broader commitment only sees what the narrower one leaves.
The questions the providers name
Microsoft's page on choosing between a savings plan and a reservation matches reservations to workloads that run continuously with no change of instance type, family or region in sight, and savings plans to workloads that move across families, services or regions. It also names a sequence: rightsizing first, then exchanging or trading in poorly used reservations, and only then new commitments. The AWS FAQ sets, for databases, flexibility across services and instance types against stable workloads on specific instance types and three-year terms. Google matches resource-based CUDs to steady usage in one project, region and configuration, and compute flexible commitments to usage that is not tied to them. Four questions follow: how stable type, family and region are, how many services the usage spreads over, whether the discount has to follow a planned migration, and which commitments already apply first. How much to buy and when is the subject of the chapter optimisation and savings.
What it means for your cost
In the billing data both families appear as a fee or purchase and as covered usage. Usage-based commitments can be analysed in hours or normalised units, spend-based ones only in money; coverage and utilisation are described in commitment coverage and utilisation.
Rate stability differs as well. AWS keeps a Savings Plan's rates the same for the term. Google fixes the fee of a spend-based commitment at the list price on the purchase date, and bases that of a resource-based commitment on the prevailing on-demand price on the day it becomes active, the day after purchase; later price changes affect neither. For Azure savings plans, by contrast, Microsoft states that current savings plan pricing applies, with changes taking effect on the first of the month. What an exit costs and when it is possible is covered in exchange, cancellation and expiry. For load that tolerates interruption, spot capacity is a further rate lever without a term.
Where it goes wrong
- Type chosen by the highest discount. Symptom: after a change of instance family or region the fee keeps running while the new usage pays on-demand. Cause: the higher discount binds more attributes, and without an exchange right the commitment stays with the old configuration.
- Two families on the same usage. Symptom: a savings plan stays partly unused although enough eligible usage runs. Cause: reservations and resource-based CUDs apply first, and the plan only sees the rest.
- Compute commitment expected to cover databases. Symptom: a Compute Savings Plan does not lower the RDS or SQL bill. Cause: databases have their own programmes at AWS and Azure, described in reserved capacity.
- Exchange right assumed to last. Symptom: an Azure reservation for virtual machines bought from 2027-02-01 cannot be exchanged. Cause: for services that savings plans cover, Microsoft excludes such reservations from exchange.
- One-year flexible commitment on M series. Symptom: a compute flexible commitment at Google burns down with no visible discount. Cause: memory-optimised VMs get the discount on three-year terms only, and a one-year commitment is used up without one.
Sources
Read on 2026-10-16. AWS What are Savings Plans?, Savings Plans types, how Savings Plans apply to your usage, Savings Plans FAQs, Reserved Instances for Amazon EC2, EC2 Reserved Instances pricing; Microsoft Decide between a savings plan and a reservation, What are Azure Reservations?, What are savings plans?, How a savings plan discount is applied, Reserved VM Instances, Self-service exchanges and refunds for Azure Reservations; Google Cloud Committed use discounts, Committed use discounts for Compute Engine, Resource-based committed use discounts; FinOps Foundation Rate Optimization; FOCUS Column Library, Commitment Discount Category.