Commitments are the largest single lever on a cloud bill and the easiest one to get wrong. This guide covers how to buy, balance, and ladder reservations, savings plans, and committed use discounts across AWS, Azure, GCP and OCI, on a rightsized baseline, so the savings hold.
Cloud commitment management is the discipline of trading flexibility for a lower rate, on purpose, in the right order, and only on capacity you are confident you will use. Done well, it is where the deepest and most durable savings on a cloud bill come from. Done badly, it locks waste in for one to three years and quietly inflates the very bill it was supposed to cut.
Across the 500-plus environments we have optimized since 2019, commitments are the lever that moves the bill most and the lever buyers most often pull in the wrong sequence. The pattern is familiar: a finance deadline arrives, someone buys a large three-year reservation against last quarter's usage, the workload is then rightsized or re-architected, and the company spends the next two years paying for instances it no longer runs. The rate looked like a discount. It became a liability.
This pillar is the map for the whole commitment management cluster. It explains the instruments, the two numbers that decide whether a portfolio is healthy, the buying order that keeps you from committing to waste, and the governance that keeps a commitment program honest over time. Every section links down to a focused guide on the specific decision, and out to the work we do when a team wants it run for them: commitment management as a continuous service.
Rightsize first, commit second. Cover the stable base of your usage, not the peak. Track two numbers, coverage and utilization, and ladder your purchases so nothing expires all at once. Commitments are not a one-time purchase. They are a portfolio you manage continuously.
Cloud commitment management is the ongoing practice of buying and maintaining discount instruments, reserved instances, savings plans, and committed use discounts, against a baseline of usage you are confident is stable. In exchange for committing to a one or three year term, or to a fixed hourly or annual spend, the cloud provider gives you a lower rate than on-demand, typically 30 to 72 percent off compute depending on the instrument, term, and payment option.
The core tension is simple. On-demand pricing is expensive but infinitely flexible: you pay only for what you run, and you can stop at any moment. Commitments are cheap but rigid: you pay for the term whether or not you use the capacity. Commitment management is the work of placing the boundary between the two in the right place, and moving it as your usage changes. It is not a procurement event. It is a continuous portfolio discipline, which is why we treat it as part of continuous rate optimization rather than an annual purchase.
Every major provider offers a discount-for-commitment trade, but the instruments differ in flexibility, scope, and how they apply. The first job of commitment management is choosing the right instrument for each workload. The dedicated comparison, reserved instances vs savings plans vs CUDs, walks the trade-offs in full; the table below is the orientation.
| Cloud | Instruments | How the discount applies | Typical max discount |
|---|---|---|---|
| AWS | Reserved Instances (Standard, Convertible), Compute & EC2 Instance Savings Plans | Savings Plans apply to a committed hourly spend across instance families and regions; RIs apply to specific instance attributes | Up to ~72% (3-year, all upfront) |
| Azure | Reservations, Azure Savings Plan for compute, Azure Hybrid Benefit | Reservations apply to matching VM size families; the savings plan applies to a committed hourly compute spend | Up to ~65% on reservations; Hybrid Benefit adds further license savings |
| Google Cloud | Committed Use Discounts (resource-based and spend-based / flexible), sustained use discounts | Resource-based CUDs lock vCPU and memory; flexible CUDs apply to a dollar commitment across eligible services | Up to ~57% resource-based, ~70% on some database and specialized commitments |
| OCI | Universal Credits, Annual Flex (Annual Universal Credits), capacity reservations | Committing to an annual spend unlocks lower rates across most OCI services | Varies by contract; negotiated against annual commitment |
Two structural choices cut across all four clouds. The first is spend-based vs resource-based commitments: do you commit to a dollar figure that follows you as you change instance types, or to specific hardware that locks the deepest rate but loses value the moment you migrate? The second is convertible vs standard reserved instances on AWS, where convertibles trade a few points of discount for the right to change instance family mid-term. Flexibility is not free, but neither is rigidity. The right mix depends on how stable each workload is.
Rates and discount ranges above reflect publicly documented programs as of 2026 and should be confirmed against each provider's current pricing pages before a purchase, since instruments and percentages change. The discipline does not.
A commitment portfolio has exactly two health metrics, and almost every mistake shows up as a problem in one of them. Coverage and utilization are the two numbers that matter, and they pull in opposite directions.
Coverage is the share of your eligible usage that a commitment is paying the discounted rate for. Low coverage means you are leaving on-demand money on the table: usage that is stable enough to commit but is still paying the full rate. Utilization is the share of what you committed to that you actually used. Low utilization means you over-committed: you are paying for reserved capacity that is sitting idle, the hidden cost of idle commitments.
Push coverage too high and utilization falls, because you have committed to usage that is not actually stable. Keep utilization near 100% and coverage may be too conservative, leaving cheap savings unclaimed. Healthy portfolios run high utilization (97%+) with coverage set deliberately at the stable base of usage, not the peak.
The goal is not to maximize either number in isolation. It is to cover the predictable base of your workload at near-perfect utilization, and let the variable top of the curve ride on-demand. Where that line sits is a forecasting question, which is why forecasting commitment needs is the input to every purchase decision.
The single most expensive mistake in commitment management is buying in the wrong order. The locked sequence we use on every engagement is: see, then cut, then lock. You map usage, you rightsize and clear waste, and only then do you commit on the clean baseline. Reservations come last, on purpose.
The reason is mechanical. A reservation discounts a rate; it does not reduce usage. If you commit to an oversized instance, you have locked in the discount on waste, and the discount is smaller in absolute terms than simply running the right-sized instance on-demand would have been. This is why you should rightsize before you commit is the first rule of the cluster, not the last.
For the financial side of step two and three, the worked example in how to model break-even on a reserved instance shows exactly how many months of use a commitment needs before it beats on-demand, and the full sequence is laid out in how to build a commitment purchase strategy.
We audit your existing reservations and savings plans, find the idle commitments and the uncovered base, and rebuild the portfolio on a rightsized baseline. On the performance model, if we do not save you money, there is no fee.
Get a commitment audit →A portfolio where every commitment expires in the same month is a portfolio with a cliff. When the term ends you face a single large renewal decision under time pressure, usually with stale usage data, which is exactly how teams end up over-committing again. Laddering commitments spreads expiry dates across the year so renewals are continuous and small.
Laddering also hedges the term-length decision. Rather than betting the whole portfolio on one or three years, you blend them, which is the practical answer to the 1-year vs 3-year question: three-year commitments on the most stable, well-understood base for the deepest rate, one-year commitments on the layer that is stable but still evolving. The deeper risk of getting the proportion wrong, paying for capacity you grow out of, is covered in the risk of over-committing to cloud discounts.
In any organization past a single account, commitments stop being a per-team purchase and become a shared portfolio. AWS, Azure and GCP all share commitment benefits across linked accounts or projects, which means a savings plan bought by one team can cover another team's usage. That is powerful and also a governance problem: who owns the commitment, who gets the saving, and who is accountable for utilization. Managing commitments across multiple accounts covers the mechanics and the allocation; the policy side belongs in a commitment governance policy.
Commitments also have to survive change. A migration between clouds, a re-platforming, or a major architecture shift can strand resource-based commitments on hardware you no longer use. Handling commitments during a migration and selling and exchanging unused reservations cover the exits. For workloads that are inherently spiky, commitment management for variable workloads and the question of when to use on-demand instead of committing set the floor: not everything should be committed, and forcing coverage onto a genuinely variable workload is how utilization collapses.
At scale, commitment purchasing should not be a quarterly spreadsheet exercise. Automating commitment purchasing against coverage and utilization targets turns the portfolio into a control loop that buys small tranches as the baseline grows and stops before utilization slips. Specialized workloads need specialized handling: commitment management for Kubernetes workloads deals with the fact that pods, not instances, are the unit of consumption.
Two reporting concepts round out the discipline. Blended vs unblended rates explains why the number on a consolidated bill can hide which account actually benefited from a shared commitment, and tracking commitment ROI closes the loop by proving, in dollars, that the program is earning its keep. If you cannot show the realized saving against the on-demand counterfactual, you cannot defend the next purchase.
In our SaaS-on-AWS engagement we rightsized the EC2 fleet first, then laddered Savings Plans across one and three year terms on the settled baseline. The combination took the annual bill from $4.2M to $2.8M, a 33% reduction, and utilization held above 98% because nothing was committed before the fleet was clean. The sequence did the work, not the discount.
The decisions above, instrument selection, the coverage and utilization targets, the laddering schedule, and the break-even models, are collected in our gated white paper, The Commitment Strategy Playbook: RIs, Savings Plans, CUDs. It includes the worksheets we use on engagements to size a first purchase and to audit an existing portfolio.
Commitment management is one of four levers in our method, and it deliberately comes after rightsizing and waste elimination. It sits inside the full picture laid out in the complete cloud cost optimization playbook for 2026, the master guide that connects commitments to visibility, governance, and the FinOps operating model that keeps all of it running. Read the playbook for the whole system; read the linked guides in this cluster for the specific decision in front of you.
New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.