Commitment-based discounts trade flexibility for a lower rate: commit to a level of usage over a term, pay significantly less than on-demand. This page goes deep on running that as a discipline, the metrics, the flexibility curve, and the one rule that matters most. For general cloud waste and rightsizing, see the cloud cost optimization guide; for attributing shared-cluster cost, the Kubernetes cost allocation guide.
Commitment-based discounts are the mechanism cloud providers use to reward predictable demand. In exchange for committing to a defined level of usage or capacity over a fixed term, typically one or three years, you receive a significantly lower rate than on-demand pricing. The provider gets revenue certainty, you get a discount. That is the whole trade: you give up flexibility, and you get a better price for the usage you were going to run anyway.
Two commitment models dominate. Reserved capacity commitments have you commit to specific resources, for example a particular instance family in a particular region, in return for a deeper discount. Usage or spend-based savings commitments have you commit to a steady rate of consumption or spend, measured per hour, and the discount is applied automatically across whatever eligible usage matches. This pillar treats commitments as a discipline in their own right.
Two metrics govern whether a commitment portfolio is healthy. Coverage is the share of your eligible usage that sits under a commitment versus running at full on-demand rates. Utilization is the share of what you committed to that you actually consumed. High coverage without high utilization means you are paying for a commitment you are not using. High utilization without high coverage means you are leaving discountable usage on-demand and overpaying for it. The goal is high coverage of your stable baseline together with high utilization of everything you bought.
The tension between the two is the core of the discipline. Push coverage up by committing aggressively and you risk buying more than your real baseline, so utilization falls when usage dips. Protect utilization by committing conservatively and coverage falls, so more of your steady usage pays the on-demand premium. You manage the portfolio to the point where both stay high, which in practice means committing only to the load that is genuinely always on and letting the variable top layer float.
Every commitment sits somewhere on a flexibility curve, and where you sit determines both the discount and the risk. The most specific commitments, a single instance type pinned to a single region, earn the deepest discount because you have given the provider the most certainty. They also carry the most exposure: if your usage shifts to a different instance family, a different region, or a different service, a rigidly scoped commitment can strand, still billing while covering nothing you now run.
More flexible instruments sit at the other end. Convertible reserved commitments that can be exchanged for different attributes, and spend-based savings commitments that apply across families, regions, or even services, earn a shallower discount but adapt as your footprint evolves. The right choice is a function of how predictable that footprint is. Load you are confident will look the same in three years can justify a specific, deep-discount commitment. Load that is mid-migration, mid-re-architecture, or simply young and changing belongs on a flexible instrument, or on-demand until it settles.
Do not price the deepest discount as free money. The gap between specific and flexible is the premium you pay for optionality, and optionality is worth exactly as much as the probability your usage moves.
A commitment locks a rate to a quantity of usage for the whole term. If you commit to oversized or wasteful usage, you have not saved money, you have locked the waste in and signed up to pay for it for one to three years at a discounted rate you can no longer escape. The discount on waste is still waste.
The correct order is deliberate. First, optimize and rightsize the workload so it runs on the capacity it actually needs, which is the work described in the cloud cost optimization guide. Second, let the rightsized workload run long enough to reveal its stable baseline, the floor of demand present in nearly every hour. Third, commit to that baseline, not to today's inflated or pre-optimization number. Committing before rightsizing inverts the value: you cement the current shape of the workload precisely when you were about to change it, and you remove your own incentive to clean it up because the meter is already paid.
| Dimension | Reserved capacity commitment | Usage/spend-based savings commitment |
|---|---|---|
| What you commit to | Specific capacity, for example a defined instance family and region for the term | A steady rate of usage or spend per hour, applied automatically to matching eligible usage |
| Flexibility | Lower, tied to specific attributes unless a convertible variant is chosen | Higher, adapts across families, regions, and often services as your footprint shifts |
| Typical discount depth | Deeper, because the provider gets the most specific certainty | Shallower relative to a like-for-like specific reservation, in exchange for the added flexibility |
| Best fit | Stable, predictable workloads whose shape you are confident will not change over the term | Evolving or mixed footprints where you know the spend floor but not the exact resource mix |
| Main risk | Stranding if usage moves off the committed attributes, leaving it billing but covering nothing | Lower coverage precision, and still full term lock-in on the committed rate if overall usage declines |
Commitment risk is term lock-in risk. Once bought, the commitment bills for its full term whether or not the underlying usage still exists, so the real danger is committing to demand that later declines: a workload migrated to another platform, a service shut down, a re-architecture that changes the resource shape, or a business line wound down. The primary control is scope discipline. Commit only to the stable baseline you are confident persists for the term, and leave variable, seasonal, or uncertain usage on-demand where it costs more per hour but carries zero lock-in. It is cheaper to pay the on-demand premium on the top slice of demand than to strand a commitment against the whole of it.
The second control is laddering. Rather than committing your entire baseline on one date at one term, stagger start dates and mix term lengths so that commitments expire on a rolling schedule. Laddering means you are never forced to re-commit the whole estate at one moment, which protects you from having to renew a large block right after a migration or during a period of change, and it lets you fold each renewal decision into current, rightsized reality instead of a stale forecast.
Rightsize before you commit. Find the baseline worth committing to.
Cloud Cost Optimizer