A commitment is only a discount if the usage shows up. For workloads that are short-lived, unpredictable, or about to change, paying the full on-demand rate is the cheaper and safer choice. Knowing which spend to leave uncommitted is as important as knowing what to reserve.
Knowing when to use on-demand instead of committing is the discipline that keeps commitment management honest. On-demand is the full, undiscounted price you pay per second or per hour with no lock-in. A commitment trades that flexibility for a lower rate in exchange for promising to keep spending for one or three years. The trade only pays off when the usage is steady enough that the promised spend actually materializes. When it is not, the commitment becomes a bill for capacity you no longer use, and the supposed discount turns into a net loss. On-demand is the correct answer more often than discount-hungry teams assume.
This article is part of the complete guide to cloud commitment management. The cases below are drawn from the 500-plus environments we have optimized since 2019, where over-committing against volatile or temporary spend is one of the most expensive mistakes we unwind.
Every commitment is a bet that future usage will look like recent usage. On-demand carries a higher hourly rate but zero risk: you pay only for what you run, and you can stop at any moment with no residual obligation. A commitment lowers the rate but transfers the risk to you. If usage drops, migrates, or changes shape, you still owe the committed amount. The right question is never simply how big the discount is; it is whether the workload is predictable enough that the discount will be earned across the entire term.
Commit the spend you are confident will still be running in twelve months. Keep everything else on demand. The discount on covered spend is worth more than a slightly bigger discount that strands when the workload moves.
Several situations make on-demand the cheaper option even though its sticker rate is higher.
Proof-of-concept environments, time-boxed projects, seasonal campaigns, and anything you expect to tear down within months should stay on demand. A one-year commitment cannot break even if the workload disappears in three months. Match the commitment term to the life of the workload, and when the workload is shorter than the shortest term available, do not commit at all.
Workloads whose usage swings widely day to day, or that exist only to absorb bursts, do not present a stable floor to commit against. The autoscaling band above a cluster's baseline, batch jobs that run irregularly, and event-driven spikes all belong on demand or on spot. The pattern of committing only the steady floor and flexing the top is the same one we apply to commitment management for variable workloads.
If a workload is heading for a migration, a re-platform, a move to Arm-based instances, or a rewrite that will change its compute profile, committing now locks you to a shape you are about to abandon. Stay on demand through the transition and commit once the new baseline settles. Handling commitments through change is covered in how to handle commitments during a cloud migration.
You cannot size a commitment against a workload that has only been running for two weeks. Let it run long enough to establish a stable usage floor, typically a month or more, before committing anything. Premature commitments on new workloads are a frequent source of idle discount.
Even on a stable workload, you rarely commit to 100 percent. The last slice of usage, the part that varies month to month, is cheaper left on demand than covered by a commitment that sometimes sits idle. The trade between coverage and utilization is the subject of coverage and utilization, the two numbers that matter.
A commitment that discounts the rate by 30 percent but goes unused 40 percent of the time delivers a negative return against simply paying on demand. Before committing, ask what utilization the commitment needs to break even and whether the workload reliably clears it. The full method is in how to model break-even on a reserved instance.
Over-committing is more dangerous than under-committing because it is harder to reverse. Unused on-demand capacity simply stops costing you money the moment you turn it off. An idle commitment keeps billing for its full term whether you use it or not, and exit options are limited. That asymmetry is why we treat on-demand as the safe default and commitment as the deliberate exception, the logic behind the risk of over-committing to cloud discounts.
Leaving spend on demand is not a licence to ignore it. On-demand capacity should still be rightsized, scheduled off when idle, and cleared of zombie resources, because the full rate makes waste twice as expensive. On-demand means uncommitted, not unmanaged. The optimization work on that spend continues; it simply happens through scheduling and rightsizing rather than rate commitments.
We separate the stable floor that earns a discount from the volatile spend that should stay on demand, so you capture the savings without carrying idle commitments. On the performance model, if we do not save you money, there is no fee.
Get a commitment audit →On-demand is one half of a balanced commitment strategy. Read the complete guide to cloud commitment management for the full discipline, see commitment management for variable workloads for the spiky case, and download The Commitment Strategy Playbook: RIs, Savings Plans, CUDs for the coverage and break-even worksheets. When you want the split decided 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.