Three commitment instruments, three different trades between discount depth and flexibility. This is how reserved instances, savings plans, and committed use discounts compare across AWS, Azure and GCP, and which one fits which workload.
The choice between reserved instances, savings plans, and committed use discounts is the choice between depth of discount and freedom to change your mind. Every cloud sells the same basic trade, commit ahead of time and pay a lower rate, but the instruments differ in how tightly they bind you and how deep the discount goes. Picking the wrong one does not just cost a few points of rate; it can strand a commitment on capacity you no longer use.
This comparison sits inside the broader complete guide to cloud commitment management, the cluster pillar that covers coverage, utilization, and the buying order. Here we focus narrowly on the instrument decision: what each one is, how the discount applies, and the rule of thumb for matching it to a workload. Across the 500-plus environments we have optimized since 2019, getting this single choice right is worth several percentage points on the total bill.
Reserved instances are the oldest and most rigid: you commit to a specific instance configuration and get the deepest rate. Savings plans (AWS and Azure) are the flexible middle: you commit to a dollar-per-hour spend rather than a specific machine, and the discount follows you as you change instance types. Committed use discounts (Google Cloud) come in two flavors, resource-based, which locks vCPU and memory like a reserved instance, and flexible spend-based, which behaves like a savings plan. The table below sets them side by side.
| Instrument | Clouds | You commit to | Flexibility | Typical max discount |
|---|---|---|---|---|
| Reserved Instances | AWS, Azure (Reservations) | A specific instance family / VM size, region, term | Low (Standard) to medium (Convertible) | Up to ~72% (AWS, 3-year, all upfront) |
| Savings Plans | AWS, Azure | A committed hourly compute spend | High, applies across families and regions | Up to ~66% (AWS Compute SP, 3-year) |
| Committed Use Discounts | Google Cloud | vCPU/memory (resource) or a dollar amount (flexible) | Low (resource-based) to high (flexible) | Up to ~57% resource-based; higher on some services |
Discount ranges reflect publicly documented programs as of 2026 and should be confirmed against each provider's current pricing pages before purchase, since percentages and instrument names change. The relative trade-off between them, depth against flexibility, has been stable for years and is the part that actually drives the decision.
A reserved instance discounts a specific instance configuration. On AWS, a Standard RI locks the family, size, region, OS, and tenancy for one or three years and returns the deepest discount available. The price you pay is rigidity: if you migrate off that instance type, the RI keeps charging. AWS softens this with Convertible RIs, which let you exchange for a different family mid-term at a slightly lower discount, a trade covered in detail in convertible vs standard reserved instances. Azure Reservations work similarly, applying to a matching VM size family.
Reserved instances make sense for steady, well-understood workloads you are confident will run unchanged for the full term, a stable database tier, a baseline of always-on application servers. They are the wrong tool for anything you might re-architect, and a classic source of the hidden cost of idle commitments when a team retires the workload but the reservation lives on.
Savings plans flip the model. Instead of committing to a machine, you commit to a dollar amount of compute spend per hour. AWS Compute Savings Plans apply that commitment across any instance family, region, operating system, and even across EC2, Fargate, and Lambda. AWS EC2 Instance Savings Plans narrow it to one family in one region for a deeper rate. Azure's savings plan for compute works on the same principle for Azure VMs.
The advantage is that a savings plan keeps applying as you rightsize, migrate families, or shift regions, which makes it the safer default for a fluid fleet. You give up a few points of discount versus a Standard RI in exchange for not being stranded. For most modern, actively managed environments, the spend-based flexibility is worth more than the marginal rate, which is why we lean on savings plans for the bulk of coverage and reserve RIs for the genuinely static base. The structural version of this choice is covered in spend-based vs resource-based commitments.
We map your fleet, separate the static base from the fluid layer, and build a commitment portfolio that mixes RIs, savings plans and CUDs to the right depth. On the performance model, if we do not save you money, there is no fee.
Get a commitment audit →Google Cloud splits the difference into two instruments. Resource-based CUDs commit you to a quantity of vCPU and memory in a region for one or three years, behaving like a reserved instance with the deepest GCP rate. Flexible (spend-based) CUDs commit you to a dollar amount across eligible services and behave like a savings plan, following you as you change machine types. GCP also layers sustained use discounts on top automatically for steady running, which reduces how much you need to commit in the first place.
The choice on GCP mirrors the RI-versus-savings-plan decision: resource-based for the static base where the deeper rate is worth the rigidity, flexible for everything that moves. The OCI equivalent, annual universal credits negotiated against a spend commitment, is covered in the commitment pillar and in how to build a commitment purchase strategy.
The decision reduces to one question per workload: how confident are you it will run unchanged for the term? The more stable, the more it makes sense to trade flexibility for depth.
Whatever the mix, the order matters more than the instrument. Rightsize and clear waste first, then commit on the clean baseline, then ladder the purchases so nothing expires all at once. Buying the wrong instrument loses you a few points; buying any instrument before rightsizing locks in waste for the whole term.
In our SaaS-on-AWS engagement we covered the static database tier with Standard RIs for the deepest rate, then laddered Compute Savings Plans across the actively-managed application fleet so the discount survived ongoing rightsizing. The blend held utilization above 98% and contributed to a 33% reduction in the annual bill. One instrument would not have done it.
Instrument selection is one decision inside a continuous discipline. Read the complete guide to cloud commitment management for the full portfolio view, and download The Commitment Strategy Playbook: RIs, Savings Plans, CUDs for the worksheets we use to size and audit a portfolio. When you want it run for you, our commitment management service does it as a continuous program.
New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.