Cloud Commitments in 2026: What Changed, and Who Owns the ROI
Some of the biggest changes to cloud commitments in years landed within ten months of each other. AWS and Microsoft both launched savings plans for databases. Microsoft set an end date for Azure reservation exchanges. Google changed how its spend-based discounts appear on your bill. Each one moves money between finance, procurement and engineering, so the question isn't only what changed, but who now owns which part of the return on investment.
What's new, in one line each (all checked against the providers' own announcements on 21 October 2026):
AWS: Database Savings Plans, up to 35% off across database engines, families and Regions, one-year, no upfront.
Azure: a savings plan for databases (March 2026), up to 35% off, one-year.
Azure: from 1 February 2027, new reservations for services covered by savings plans can't be exchanged. Existing ones get one final exchange.
Google Cloud: spend-based CUDs are now billed as discounted rates, not list price plus a credit.
Standards: FOCUS 1.3 and 1.4 added a Contract Commitment dataset, so commitments can finally be compared across providers in one schema.
1. AWS: Database Savings Plans
AWS announced Database Savings Plans on 2 December 2025. You commit to a consistent amount of spend per hour for one year, with no upfront payment, and save up to 35%. The discount follows your usage across engines, instance families, sizes, deployment options and Regions, covering Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream and DMS. In March 2026 AWS added OpenSearch Service and Neptune Analytics.
Why it matters: until now, database commitments meant Reserved Instances tied to an engine and instance family. That quietly penalised modernisation: move from RDS for SQL Server to Aurora PostgreSQL and the reservation was stranded. A spend-based plan removes that penalty, so engineering's roadmap and finance's commitment no longer pull in opposite directions.
2. Azure: a savings plan for databases
Microsoft followed with its own version. On 18 March 2026 it introduced a savings plan for databases: a spend-based, one-year commitment to a fixed hourly amount, saving up to 35% against pay-as-you-go across eligible Azure database services. Microsoft notes that the 35% figure is for one Azure SQL Database serverless scenario, and that actual savings vary by service, location and usage. Unlike the savings plan for compute, there's no three-year option.
Why it matters: it brings databases into "services covered by savings plans", which is exactly the group the next change applies to.
3. Azure: reservation exchanges end on 1 February 2027
Microsoft's updated exchange policy says that reservations purchased on or after 1 February 2027 can't be exchanged if the service is covered by savings plans. Microsoft names Virtual Machines, App Service and Azure SQL Database among them. Reservations bought before that date keep one final exchange.
The detail most teams will miss: Microsoft processes an exchange, and an automatic renewal, as a cancellation plus a new purchase. So a reservation that auto-renews after 1 February 2027 comes back under the new terms and can't be exchanged. What doesn't change: instance size flexibility for VMs, the $50,000-per-12-months cancellation allowance, and the ability to trade a reservation in for a savings plan at any time.
Why it matters: the exchange was Azure's "undo" button. Without it, buying a reservation for a workload that might move becomes a real bet. Microsoft's own guidance is now explicit: savings plans for dynamic workloads, reservations for predictable ones.
4. Google Cloud: spend-based CUDs move from credits to discounted rates
Google has changed how spend-based committed use discounts are billed. Google's documentation describes the old model as usage billed at list price with a credit offsetting it, and the new one as usage billed directly at the discounted rate. Google says the change doesn't increase total costs. New billing accounts moved first, and remaining accounts were migrated in early 2026 (DoiT's explainer has the timeline). Coverage now includes services such as BigQuery, Cloud SQL, Spanner, Bigtable and Memorystore.
Why it matters: nothing got more expensive, but reports broke. Any dashboard, chargeback model or savings report that measured CUD benefit by summing credits now under-reports it. Savings have to be recalculated as on-demand cost minus what you actually paid.
5. FOCUS 1.3 and 1.4: commitments get a common language
FOCUS, the FinOps Foundation's open billing-data specification, added a Contract Commitment dataset in version 1.3 (ratified 5 December 2025). FOCUS 1.4 (ratified 4 June 2026) expanded it from 13 to 30 columns and added a column showing which commitment program each charge could qualify for, whether or not one is applied. That last part is the useful one: it shows what was coverable but not covered, in the same format on every provider that supports it. (What is FOCUS?)
The direction of travel: spend-based, and less undo
Put together, all three providers are pushing the same way. Commitments are measured in money per hour and follow your usage wherever it moves, and the ability to undo a resource-specific commitment is narrowing. That trades some discount depth for much lower stranding risk.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Spend-based ($/hour) | Compute Savings Plans, EC2 Instance Savings Plans, Database Savings Plans (new) | Savings plans for compute and, since March 2026, for databases | Spend-based (flexible) CUDs, now billed as discounted rates |
| Resource-specific | Reserved Instances (e.g. RDS, ElastiCache, OpenSearch) | Reservations (1 or 3 years) | Resource-based CUDs (machine family + region) |
| Automatic discount | None | None | Sustained use discounts (eligible VMs) |
| The "undo" option | Convertible RIs can be exchanged. A Savings Plan can be returned only within 7 days of purchase (same month, $100/hour or less); after that it can't be cancelled | Exchanges end for new purchases from 1 Feb 2027; trade-in to a savings plan stays | Commitments can't be cancelled |
Who owns which part of the ROI
A commitment is one decision with five stakeholders, and each of these changes lands on a different one. Using the FinOps Framework personas:
| Persona | What they own | What changed for them | The number they should watch |
|---|---|---|---|
| Finance | Cash flow, amortisation, forecasts, savings reporting | Google's billing change breaks credit-based savings reports. AWS Database Savings Plans need no upfront cash | Effective savings rate, calculated on-demand minus actual |
| Procurement | Term, flexibility, renewals, enterprise agreements | Azure's exchange deadline and auto-renewals now need a calendar entry | Commitments expiring or renewing in the next 6 months |
| Engineering | Architecture, migrations, rightsizing | Database savings plans on AWS and Azure stop commitments blocking engine and Region moves | Steady-state floor per service (what can safely be committed) |
| FinOps practitioner | Coverage, utilisation, the commitment portfolio | FOCUS 1.4's eligibility column shows uncovered-but-eligible spend across providers | Coverage of the floor, and utilisation (target 90%+) |
| Leadership | The trade-off: savings versus lock-in | Less undo means each commitment is a firmer bet | Annual savings achieved versus stranded commitment written off |
The ROI arithmetic everyone should share
Every commitment has a break-even utilisation of roughly one minus the discount. At a 30% discount you break even at 70% utilisation. Above that you save, below it you'd have been better on demand.
Illustrative example. A team runs $40,000 a month of compute on demand. Its steady floor, the lowest it ever drops, is $32,000. It commits that floor at a 30% discount, paying $22,400 a month for usage that would cost $32,000 on demand: $9,600 a month saved, about $115,000 a year, at full utilisation. If a migration later drops that usage to $24,000, it still pays $22,400 and still saves $1,600 a month, because 75% utilisation is above the 70% break-even. Had it committed the average instead of the floor, the same drop would have cost money.
That's why the rule hasn't changed even though the products have: commit the floor, not the average, prefer spend-based instruments for anything on the roadmap, and keep resource-specific commitments for workloads you're genuinely sure about.
What to do in the next 90 days
- Azure: list every reservation, its renewal setting and its expiry. Decide before 1 February 2027 which ones deserve their final exchange, which to trade in for a savings plan, and which auto-renewals to switch off and re-buy deliberately.
- AWS: compare your RDS, ElastiCache and DynamoDB reservations with Database Savings Plan rates, especially for any database on a migration plan.
- Google Cloud: check that your savings and chargeback reports recalculate CUD benefit from on-demand minus actual, not from credits.
- All three: put every commitment in one register with owner, expiry, utilisation and coverage. If your providers export FOCUS 1.3 or 1.4, the Contract Commitment dataset gives you that register in one format.
See your own coverage and utilisation. The CloudFinOpsKit assessment reads your reservations, savings plans and CUDs read-only, prices the gaps from your actual billed cost, and shows them next to everything else on the bill. It runs in about 10 minutes, from $40. Per-cloud detail: AWS · Azure · Google Cloud.
What this article doesn't cover
Negotiated agreements (AWS private pricing, Microsoft MACC, Google commitments in enterprise contracts), Marketplace purchases, and exact discount rates, which vary by service, term and payment option. Check your provider's current pricing before buying. Policies quoted here were read on 21 October 2026 and can change.
FAQ
Do Azure reservations still make sense after February 2027?
Yes, for predictable, stable workloads. Microsoft says reservations remain the right option there, and instance size flexibility and the $50,000 cancellation allowance are unchanged. What goes away is the ability to exchange new reservations for services covered by savings plans, so buy them only for usage you're confident will stay put, and use savings plans for anything likely to move.
Should we move AWS RDS Reserved Instances to Database Savings Plans?
Not automatically. Database Savings Plans trade some discount depth (up to 35%) for flexibility across engines, instance families and Regions, on a one-year term with no upfront payment. If you're planning an engine migration or Region move, that flexibility is worth a lot. If a database will sit unchanged for three years, compare the plan's rate with your current reservation before switching.
Why did our Google Cloud 'CUD savings' report change in 2026?
Google moved spend-based committed use discounts from a credit model to a discounted-rate model. Usage is now billed directly at the discounted price instead of list price minus a credit. Google says total cost doesn't increase, but any report that measured savings by summing credits will now show them shrinking or disappearing. Recalculate savings as on-demand cost minus what you actually paid.
What is the break-even utilisation for a commitment?
Roughly one minus the discount. A 30% discount breaks even at about 70% utilisation: below that you'd have paid less on demand. That's why commitments are sized to your steady floor, not your average or peak.
Sources: AWS: Database Savings Plans · Microsoft: reservation exchange policy changes · Microsoft: savings plan for databases · Google Cloud: spend-based CUD model · FinOps Foundation: FOCUS 1.4
Related reading: the FinOps Framework 2026 and the ROI chain · FinOps KPIs · forecasting Azure spend