For most organizations with steady cloud usage, commitment-based discounts are the biggest single lever for reducing the bill. They are also one of the easiest places to lose money: buy too much and you pay for capacity you do not use; buy too little and you leave savings on the table; buy the wrong type and you lock yourself into instance families or regions you will want to leave. In 2025 the major providers added and reshaped several commitment products, which makes it a good moment to revisit how your organization manages them.
This playbook walks through what changed, how the main commitment instruments compare, and a step-by-step process for buying, layering and governing commitments across AWS, Azure and Google Cloud.
What Changed in 2025 and 2026
Three changes stand out for teams planning commitment portfolios now.
- AWS Database Savings Plans. Announced at re:Invent 2025, they extend the Savings Plans model to managed databases. According to ProsperOps’ analysis, they cover services including RDS, Aurora (including Serverless and DSQL), DynamoDB, ElastiCache for Valkey, DocumentDB, Neptune, Keyspaces, Timestream, DMS and OpenSearch, with discounts of roughly 12 to 35 percent. They come with a one-year term and no-upfront payment only, and provisioned instance coverage applies to newer instance generations, so older families still need Reserved Instances. Redshift and MemoryDB remain Reserved Node or Reserved Instance only.
- Google Cloud Compute Flex CUDs and a new billing model. In September 2025 Google expanded spend-based Compute Flexible Committed Use Discounts to cover memory-optimized and HPC-optimized VM families and Cloud Run. It also introduced a new spend-based CUD model that charges discounted rates directly instead of applying credits, which changes billing exports. Google stated that remaining customers would move to the new model automatically on January 21, 2026.
- FinOps scope expansion. Summaries of the State of FinOps 2026 report describe leadership attention shifting from raw savings toward unit economics, forecasting and governance across cloud, AI, SaaS and licensing. Commitment management is no longer just a purchasing task; it is part of financial planning.
The Commitment Instruments, Compared
Each provider offers a mix of resource-based commitments, which lock specific capacity attributes, and spend-based commitments, which lock a dollar amount per hour and float across eligible usage.
AWS
- Compute Savings Plans: spend-based, apply across EC2, Fargate and Lambda regardless of family, region or operating system. Most flexible, slightly lower discount.
- EC2 Instance Savings Plans: tied to an instance family in a region, deeper discount, less flexibility.
- SageMaker Savings Plans: for SageMaker machine learning usage.
- Database Savings Plans: spend-based across many database services, one-year, no upfront.
- Reserved Instances and Reserved Nodes: still required for some services, such as Redshift, and often offer deeper discounts than Database Savings Plans for stable, specific database instances. ProsperOps’ example shows a large Aurora instance at about 20 percent under a Database Savings Plan versus 33 percent under a Reserved Instance.
Azure
- Azure reservations: resource-based commitments for virtual machines, databases, storage capacity and other services, with options to scope to a subscription, resource group or shared across a billing scope.
- Azure savings plan for compute: a spend-based hourly commitment applying across eligible compute services and regions, trading some discount for flexibility.
Google Cloud
- Resource-based CUDs: commit to specific vCPU, memory, GPU or local SSD quantities in a region for one or three years.
- Spend-based CUDs, including Compute Flex CUDs: commit to an hourly spend that applies across eligible VM families and services, now including Cloud Run.
- Sustained use discounts: automatic discounts for some VM families that run for a large part of the month, which interact with commitment decisions.
The Playbook: Step by Step
Step 1: Clean Up Before You Commit
Commitments lock in the shape of your usage. If that usage is wasteful, you are paying a discounted price for waste. Before any significant purchase, run a rightsizing and cleanup sprint: remove idle resources, downsize over-provisioned instances, migrate to current-generation families where feasible, and schedule non-production environments to shut down outside working hours. This is also the moment to decide on architectural moves, such as adopting Arm-based instances or serverless, that would change which commitment types fit.
Step 2: Establish a Reliable Baseline
Use at least three, ideally six to twelve, months of hourly usage data to find your steady-state floor. Normalize data across providers, for example with the FinOps Open Cost and Usage Specification, so you can compare effective rates. Separate usage into three bands:
- Floor: usage that runs every hour and is unlikely to disappear in the commitment term.
- Predictable variable: usage that follows business patterns, such as weekday peaks or seasonal events.
- Uncertain: new projects, migrations in progress and experimental AI workloads.
Commit primarily against the floor. Cover predictable variable usage partially and leave uncertain usage on demand or spot.
Step 3: Layer Commitments From Specific to Flexible
Because discounts generally increase with specificity, a common pattern is to layer: the most stable and well-understood usage gets the deepest, most specific commitments, and flexible spend-based plans sit on top to catch the rest. On AWS that might mean Reserved Instances for long-lived database instances and Redshift, EC2 Instance Savings Plans for stable fleets, Compute Savings Plans for the remaining compute floor, and Database Savings Plans where database usage is likely to shift between engines or services. On Azure, reservations for stable VMs and databases plus a savings plan for compute to cover variable compute. On Google Cloud, resource-based CUDs for steady machine shapes and Flex CUDs for the rest.
Understand the order in which discounts apply. On AWS, Reserved Instances apply before Savings Plans, and Savings Plans apply to usage with the highest discount first. Mixing instruments without modeling the interaction can produce lower savings than expected.
Step 4: Choose Term and Payment Deliberately
Three-year terms deliver deeper discounts but carry more risk of usage changing, especially with AI workloads and modernization programs underway. One-year terms preserve flexibility. Upfront payment raises discounts slightly but ties up cash. Decide using your organization’s cost of capital and confidence in the baseline, not just the headline percentage. Note that some newer instruments restrict options; Database Savings Plans, for example, are one-year and no-upfront only.
Step 5: Purchase Incrementally
Rather than one large annual purchase, buy in smaller tranches monthly or quarterly. This staggers expiries, reduces the risk of a big misjudgment, and lets you respond to changes in usage. It also avoids the scramble when a large block of commitments expires on the same day.
Step 6: Check Contract Interactions
Enterprise agreements and private pricing complicate the math. ProsperOps warns that Database Savings Plans apply to list rates and can cancel out service-specific private pricing discounts, which can reduce total savings. Similar interactions exist on other clouds. Involve procurement and model total effective cost before purchasing.
Step 7: Monitor, Reallocate and Report
Track utilization (how much of what you bought is used) and coverage (how much of eligible usage is discounted) weekly. Watch for falling utilization after migrations or decommissioning. Use available levers such as reservation exchanges, scope changes and, where permitted, returns within the allowed window. Report effective savings rate, the overall discount achieved relative to on-demand, as the headline metric, because it captures both utilization and coverage.
Commit to your floor, not your hopes. Clean up first, layer from specific to flexible, buy in small increments, and measure effective savings rate rather than discount percentages.
Allocation and Showback
Commitments are typically purchased centrally, but the benefit lands on many teams’ workloads. If you do not allocate it carefully, product teams either see inflated costs or receive invisible subsidies, and neither drives good behavior. Options include:
- Amortized allocation: spread upfront and recurring commitment costs across the usage that benefited, which most cost tools support.
- Blended internal rates: charge teams a standard discounted rate for covered services and keep the variance centrally.
- Unused commitment as a central cost: make the commitment owner accountable for waste, so purchasing discipline stays with the team that makes the decision.
Whichever approach you use, document it and keep it stable, because frequent changes make unit-cost trends meaningless.
Commitments for AI and GPU Workloads
AI workloads complicate commitment planning. Usage can grow quickly, hardware generations change fast, and capacity for popular GPUs can be scarce. Practical guidance includes committing only to steady inference baselines, preferring flexible or shorter instruments where available, considering capacity reservations separately from pricing commitments when guaranteed availability matters, and revisiting the plan each quarter as models and serving architectures evolve. Pair commitment planning with the efficiency work, such as model routing, batching and caching, that reduces the GPU hours you need in the first place.
A Pre-Purchase Checklist and Governance Model
A short, repeatable checklist prevents most expensive mistakes. Before approving any commitment tranche, the purchasing team should be able to answer yes to each of the following:
- Has the targeted usage been through a rightsizing review in the last quarter?
- Is the usage covered by this purchase part of the observed floor for at least the past three months?
- Have engineering leads confirmed there are no planned migrations, decommissions or architecture changes that would strand it during the term?
- Has the interaction with existing commitments and with enterprise or private pricing agreements been modeled?
- Is the expected effective savings rate after the purchase higher than before?
- Is there a named owner accountable for utilization of this commitment, and is the allocation method documented?
Governance does not need to be heavy. Many organizations run a monthly commitment review with the FinOps lead, a finance partner, procurement and representatives of the largest engineering groups. The FinOps team prepares recommendations and the analysis behind them; finance approves spend against an agreed policy, such as a maximum term or a target coverage band; engineering confirms roadmap assumptions; and procurement checks contract terms. Delegating smaller, lower-risk purchases, for example one-year, no-upfront tranches under a set threshold, to the FinOps lead keeps the process fast while reserving large three-year decisions for the full group. Record each decision and its assumptions so that the next review can learn from what actually happened to usage.
Hypothetical Worked Example: A Fintech Platform on AWS
Consider a hypothetical fintech company spending a substantial amount monthly on AWS, with compute on EC2 and EKS, a large Aurora PostgreSQL estate, DynamoDB tables and a Redshift warehouse. Existing coverage is patchy: a handful of three-year RIs bought years ago for instance families now being retired, and no Savings Plans.
The team starts with a six-week cleanup: rightsizing EKS node groups, moving batch jobs to spot capacity and migrating Aurora instances to current Graviton-based generations. With a new baseline established, it purchases Reserved Nodes for the Redshift cluster, which has stable usage and no Savings Plan option; a Compute Savings Plan covering about the observed compute floor; and a Database Savings Plan covering the Aurora and DynamoDB floor, chosen over Aurora RIs because the team plans to consolidate some databases and try Aurora Serverless for spiky workloads during the year. Purchases are split into monthly tranches. Procurement confirms that the company’s private pricing terms are cross-service rather than service-specific, avoiding the interaction issue. The team tracks effective savings rate and utilization on a weekly dashboard and reviews the portfolio each quarter.
Common Pitfalls
- Committing before cleanup, which locks in waste at a discount.
- Chasing the deepest discount percentage instead of the best effective savings rate.
- Buying one large tranche that expires all at once.
- Ignoring migration and modernization roadmaps, then stranding commitments on retired instance families.
- Forgetting contract interactions with enterprise discounts and private pricing.
- Leaving unused commitments unallocated, so nobody feels accountable for them.
Outlook: Toward Autonomous Commitment Management
Commitment management is increasingly automated. Third-party platforms and provider tools now recommend and in some cases purchase and exchange commitments algorithmically, and FinOps agents are emerging that can analyze coverage and draft purchase plans for human approval. Expect providers to continue moving toward spend-based, cross-service instruments, as the Database Savings Plans and Google’s expanded Flex CUDs illustrate. The human role shifts to setting risk appetite, aligning commitments with architecture roadmaps and governing the automation.
Conclusion
Commitments remain the most powerful single cost lever in the cloud, but only when they are matched to a clean, well-understood baseline and governed continuously. Clean up first, commit to the floor, layer instruments from specific to flexible, buy in small increments, watch for contract interactions, and measure effective savings rate. The 2025 product changes give more flexibility than ever, which rewards organizations that manage commitments as an ongoing portfolio rather than an annual purchase.
How Hanoi Technology Can Help
Hanoi Technology helps teams clean up cloud usage, model commitment portfolios across AWS, Azure and Google Cloud, and run ongoing commitment governance.