Buy the most flexible commitment that still gives you a discount you care about, and buy it for one year the first time. On AWS that means a Compute Savings Plan rather than a Reserved Instance. On Azure it usually means a savings plan for compute rather than a reservation. On Google Cloud it means a flexible committed use discount unless your machine shape has genuinely settled. You give up a few percentage points and you keep the ability to change your mind, which for most teams is the better trade.
The three shapes of commitment
Underneath the branding there are only three mechanisms, and once you can name them the vendor documentation stops being confusing.
- Commit to a resource. A specific instance family and size, in a specific region. AWS Reserved Instances, Azure reservations and Google Cloud resource-based committed use discounts all work this way. Deepest discount, least flexibility.
- Commit to a spend rate. You promise a dollar amount per hour and the provider discounts whatever eligible usage you run against it. AWS Savings Plans, Azure savings plans and Google Cloud flexible CUDs. Slightly shallower discount, far more room to move.
- Commit to nothing. Spot or preemptible capacity, where you take spare capacity at a steep discount and accept that it can be reclaimed. AWS documents savings of up to 90% against on-demand.
Everything else is detail about which services each instrument covers. If the underlying service categories are still fuzzy, our guide to IaaS, PaaS and SaaS is the shorter read to do first.
What each provider publishes
These are the published ceilings from each vendor’s own documentation, checked in October 2026. Treat them as ceilings: the discount you are actually offered depends on machine family, region, term and payment option.
| Instrument | Provider | Published ceiling | Terms | What it follows |
|---|---|---|---|---|
| Compute Savings Plan | AWS | Up to 66% | 1 or 3 years | Any instance family, size, region, OS, tenancy, plus Fargate and Lambda |
| EC2 Instance Savings Plan | AWS | Up to 72% | 1 or 3 years | One instance family in one region, any size or OS |
| Database Savings Plan | AWS | Up to 35% | 1 or 3 years | Aurora, RDS, DynamoDB, ElastiCache, DocumentDB and others |
| SageMaker AI Savings Plan | AWS | Up to 64% | 1 or 3 years | SageMaker AI instance usage regardless of family |
| Reservation | Azure | Up to 72% | 1 or 3 years | A specific VM size in a specific region |
| Savings plan for compute | Azure | Up to 65% | 1 or 3 years | Eligible compute services, including VMs, App Service and Functions premium |
| Resource-based CUD | Google Cloud | Up to 55%, or 70% memory-optimised | 1 or 3 years | vCPU and memory in one region and project |
| Flexible CUD | Google Cloud | 28% one year, 46% three years | 1 or 3 years | An hourly spend across most general-purpose and compute-optimised families |
| Spot capacity | AWS | Up to 90% | None | Spare capacity, reclaimable |
Two things stand out. The flexible instruments cost you roughly six to eight percentage points against the rigid ones on AWS and Azure, which is a small premium for being able to change instance family. And Google Cloud’s flexible CUD is a flat published rate rather than a ceiling, which makes it unusually easy to model.
A worked example with real prices
Percentages are easy to argue about, so here is a real machine with real prices, pulled from the Azure retail prices API in October 2026. The VM is a Standard_D4s_v5 running Linux in West Europe: four virtual CPUs and 16 GB of memory, which is a sensible size for a small production application server.
| Purchase option | Published price | Effective hourly rate | Cost per year | Saving |
|---|---|---|---|---|
| Pay-as-you-go | $0.23 per hour | $0.2300 | $2,014.80 | — |
| One-year reservation | $1,243 for the term | $0.1419 | $1,243.00 | 38.3% |
| Three-year reservation | $2,388 for the term | $0.0909 | $796.00 | 60.5% |
| Spot (low priority) | $0.046 per hour | $0.0460 | $402.96 | 80.0% |
The three-year reservation saves $1,219 a year against pay-as-you-go on a single machine. Run ten of them and the commitment is worth more than $12,000 a year, which is the point at which this stops being a tidying exercise and starts being a budget decision. It is also the point at which being wrong about the machine shape becomes expensive.
The discount is not the risk. The forecast behind it is.
How much flexibility you are giving up
The published percentage is the headline. The flexibility clause is the thing you will actually feel, usually eight months in when somebody wants to move a workload.
AWS Compute Savings Plan
A dollar-per-hour commitment that follows your usage almost anywhere.
- Moves across instance families, sizes and regions
- Covers Fargate and Lambda as well as EC2
- Survives a re-architecture that changes instance type
- Six percentage points shallower than an EC2 Instance Savings Plan
- Cannot be cancelled outside the narrow return window
AWS EC2 Instance Savings Plan
The deepest published AWS compute discount, in exchange for picking a family.
- Deepest published discount for EC2
- Still flexible on size, OS and tenancy within the family
- Locked to one instance family in one region
- A move from m-series to c-series wastes the commitment
Azure savings plan for compute
An hourly spend commitment across eligible Azure compute services.
- Applies across VMs, App Service and Functions premium plans
- No need to predict individual VM sizes
- Shallower than an Azure reservation
- Does not cover software licensing charges
Google Cloud flexible CUD
A published flat discount on an hourly spend across most VM families.
- Flat, predictable published rate rather than a ceiling
- Applies across families and regions in the billing account
- Materially shallower than resource-based commitments
- Rates differ for specialised families such as H3 and G4
There is a quiet detail in the AWS documentation worth repeating: a Compute Savings Plan keeps applying if you move a workload from EC2 to ECS on Fargate, or shift usage from Ireland to London. That is the clause that earns the six-point premium. If you have ever had to abandon a Reserved Instance because a workload outgrew its instance family, you already know what that is worth.
Getting out: refunds, exchanges and the seven-day window
Exit terms differ more than the discounts do, and they are the part nobody reads until they need to.
| Provider | Can you cancel? | Can you exchange? | The actual rule |
|---|---|---|---|
| AWS Savings Plans | Only in a narrow window | No | Returnable if the hourly commitment is $100 or less, within seven days of purchase and in the same calendar month, subject to a return limit |
| Azure reservations | Refund, with a cap | Yes, same reservation type | Refunds up to $50,000 per year; exchanges allowed for another reservation of the same type |
| Azure savings plans | No | No | The hourly commitment runs for the full term |
| Google Cloud CUDs | No | No | The commitment runs for the full one or three-year term |
On AWS, assume a Savings Plan is permanent the moment the calendar month ends. On Azure, a reservation has a genuine escape hatch with a cap, and the savings plan does not. On Google Cloud, nothing unwinds. Size your first commitment so that being wrong is annoying rather than serious: cover 50% to 70% of your steady baseline, not 100%.
Spot capacity is the other half of the answer
Commitment discounts and spot capacity solve different halves of the same problem, and teams that use both end up with the lowest bills. AWS documents spot savings of up to 90% against on-demand, with a two-minute interruption notice. In the Azure example above, spot capacity for the same VM was $0.046 an hour against $0.23 pay-as-you-go: 80% off, for capacity that can disappear.
That trade is excellent for continuous integration runners, batch jobs, media encoding, data processing and anything else that can be restarted without a human noticing. It is wrong for your primary database and usually wrong for the web tier that serves your checkout. The useful mental model is three layers: spot for work that can be retried, commitments for the baseline that must always be there, and on-demand for the spiky middle.
How much to cover, and when to buy
Coverage is the number to manage, and it is simpler than it sounds. Look at the last 90 days of usage, find the floor that your usage never goes below, and commit to somewhere between half and three quarters of that floor on a one-year term. Review it next quarter. If coverage is comfortable and the floor has held, add more.
- Delete and rightsize first. Committing before you have cleaned up locks in the waste at a discount, which is the most common mistake in this whole area.
- Start at one year. The extra saving on a three-year term is real, and so is the probability that your architecture changes inside three years.
- Buy the flexible instrument unless the workload is genuinely frozen.
- Stagger purchases. Three commitments bought in different quarters expire in different quarters, which keeps you from one large renegotiation.
- Re-check coverage every quarter alongside the rest of the cost review.
We set out that review in detail in FinOps for Small Teams: The Quarterly Cloud Cost Review, and if you are weighing up providers before you commit to anything, our comparison of the leading cloud providers covers how their pricing models differ beyond compute. For the underlying concepts, start with the introduction to cloud technology.
Eudora Technology works through commitment decisions with clients remotely, including the part where somebody has to produce a defensible 90-day usage floor rather than a guess. Our cloud solutions page explains how we normally structure that work.
Frequently asked questions
Reserved Instances or Savings Plans on AWS?
Savings Plans for almost everyone. The published ceiling for an EC2 Instance Savings Plan matches a Standard Reserved Instance at up to 72%, with more flexibility on size and operating system, and a Compute Savings Plan at up to 66% follows your workload across families and regions. Reserved Instances still have a place for capacity reservations in a specific availability zone, which Savings Plans do not provide.
What happens if our usage drops below the commitment?
You pay the commitment anyway. That is the deal. On AWS and Google Cloud there is no refund outside the narrow windows described above; on Azure you can refund a reservation up to $50,000 a year. This is why coverage should sit below your usage floor rather than at your average usage.
Is all upfront worth it over no upfront?
Marginally, and it costs you cash flow. Paying everything upfront buys a slightly deeper discount than paying monthly for the same term. For a small business the interest on that cash usually matters more than the extra percentage point, so no-upfront or partial upfront is the pragmatic default.
Can we use commitments and spot capacity together?
Yes, and you should. They apply to different workloads. Commitments cover the baseline that must always run; spot covers work that can be interrupted and retried, at up to 90% off on-demand according to AWS. The only thing to avoid is committing to spend that your spot workloads were going to absorb, because the commitment will then go unused.
Do commitments cover managed services as well as virtual machines?
Increasingly, yes, but read the scope. AWS now sells a Database Savings Plan at up to 35% across Aurora, RDS, DynamoDB and others, and Azure sells a savings plan for databases at a similar level. Google Cloud offers spend-based commitments for several managed services. None of them covers everything on your bill, so check the eligible service list before you model the saving.
If you are about to sign a one or three-year commitment and want a second opinion on the coverage number, we will read the usage data with you first. Get in touch with Eudora Technology to talk about your project.
.jpg){kind=link}