Every cloud commitment is built on one of two models. Spend-based commitments lock in a dollar-per-hour figure and apply flexibly to whatever runs. Resource-based commitments lock in a specific instance shape for a deeper discount. The choice between them is the choice between flexibility and rate, and getting it right is the difference between high utilization and stranded spend.
Spend-based vs resource-based commitments is the most fundamental distinction in cloud commitment buying. A spend-based commitment is a promise to spend a fixed dollar amount per hour, which the provider then applies as a discount to any matching usage regardless of instance family or, in some cases, service; an AWS Savings Plan and a Google Cloud spend-based committed use discount are the clearest examples. A resource-based commitment locks you to a specific configuration, such as a particular instance family in a particular region, in exchange for a deeper discount; a standard reserved instance is the classic example. Spend-based trades a slightly shallower discount for far more flexibility and far lower stranding risk; resource-based trades flexibility for the deepest possible rate.
This article is part of the complete guide to cloud commitment management, and it builds on the instrument-by-instrument view in reserved instances vs savings plans vs CUDs. The framing below comes from the commitment portfolios we manage across the 500-plus environments we have optimized since 2019.
A spend-based commitment fixes an hourly dollar amount you agree to pay, and the provider applies the committed rate to your usage automatically, prioritizing the resources where it saves you the most. Because the commitment is denominated in dollars rather than tied to a machine type, it keeps matching your bill even as you change instance families, sizes, or regions. That flexibility is its defining advantage: utilization stays high because there is almost always something for the commitment to apply to. The trade-off is that the discount is typically a little shallower than the deepest resource-locked rate.
A resource-based commitment is tied to a defined resource specification: instance family, size or normalized footprint, often region, sometimes operating system. In exchange for that specificity, the provider offers its deepest discount. The risk is the mirror image of the benefit: if your usage moves off that exact specification, the commitment can sit idle while you pay for resources it no longer covers. Resource-based commitments reward stable, predictable workloads and punish change.
Spend-based: more flexible, higher utilization, slightly shallower discount, lower stranding risk. Resource-based: deepest discount, but only if your usage stays on the exact specification. Pick flexibility where the future is uncertain and rate where the baseline is rock solid.
The instruments differ by provider, so confirm current behavior in each provider's documentation, but the general mapping holds. AWS offers both: Compute Savings Plans are spend-based and the most flexible, EC2 Instance Savings Plans sit in between, and standard reserved instances are the most resource-locked. Google Cloud offers spend-based committed use discounts that apply flexibly across services and resource-based CUDs tied to specific machine types. Azure reservations are largely resource-based, while Azure savings plans for compute are spend-based. Oracle Cloud commitments are typically structured around committed spend. Knowing which model an instrument follows tells you immediately how much stranding risk you are taking on.
The decision turns on how stable and predictable the workload is. Favor spend-based commitments when usage is changing, when you are mid-migration, when instance families are likely to evolve, or when you simply want resilience against the unknown. Favor resource-based commitments only for a stable, long-lived base of usage you are confident will stay on the same specification for the full term, where the extra discount depth is worth surrendering flexibility. A healthy portfolio usually layers both: a resource-based floor on the rock-solid base and spend-based commitments on top to capture the variable layer without stranding risk. That layering is the heart of how to build a commitment purchase strategy.
The whole reason this distinction matters is utilization. A commitment only delivers its discount on usage it actually matches, so the model you choose directly drives the utilization number explained in coverage and utilization. Spend-based commitments tend to keep utilization near full because they follow your spend; resource-based commitments can drop to low utilization the moment usage shifts. When in doubt, the higher utilization of a spend-based commitment usually beats the deeper rate of a resource-based one that risks going idle, a risk quantified in the risk of over-committing to cloud discounts.
We analyze your usage stability, layer spend-based and resource-based commitments to the right depth, and keep utilization high as your workloads change. On the performance model, if we do not save you money, there is no fee.
Get a commitment audit →The spend-based versus resource-based choice underlies every commitment decision in this cluster. Read the complete guide to cloud commitment management for the full discipline, and download The Commitment Strategy Playbook: RIs, Savings Plans, CUDs for the model-selection worksheets. When you want the portfolio structured for you, see our commitment management service.
New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.