Three ways to buy the same hardware
| Model | Commitment | Typical saving | Risk |
|---|---|---|---|
| On-demand | None | Baseline | None |
| Reserved or committed | One to three years | Substantial | You pay whether or not you use it |
| Spot or preemptible | None | Large | Can be reclaimed at short notice |
The right answer is usually a mix rather than one model for everything.
On-demand for anything uncertain
Pay per second or hour with no commitment. This is the right choice for new workloads, anything whose shape you do not yet understand, and short-lived environments.
It is the most expensive per hour and the cheapest in flexibility, which is worth paying for while you are still learning what the workload does.
Reserved for the steady baseline
If a workload runs continuously and will keep running, committing to a term reduces the rate substantially. Longer terms and larger upfront payments increase the discount.
The risk is straightforward: you pay for the term regardless. Only commit to the floor of your usage, the capacity you are confident you will still be running in a year, and leave the variable part on demand.
Spot for interruptible work
Spot capacity is spare capacity sold cheaply on the condition it can be reclaimed, usually with a short warning. Discounts are large.
It suits batch processing, CI runners, rendering, and training jobs that checkpoint. It does not suit anything that must stay up, and building around it means handling interruption properly rather than hoping.
Rightsize before you commit
Committing to an oversized instance for three years locks in the waste. Look at actual utilisation first: if a workload is using a fraction of its allocation, resize it and then commit to the smaller shape.
This order matters. Rightsizing then committing compounds two savings; committing then discovering the instance was too large wastes both.
Developer clouds work differently
Flat-rate providers such as DigitalOcean, Linode and Hetzner mostly do not have this structure. Their pricing is a single predictable monthly figure with no commitment tiers to optimise.
That is worth factoring into a comparison. A hyperscaler’s list price is not what a committed customer pays, but a developer cloud’s price is what everyone pays, and it is often still lower.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- IBM Cloud vs Oracle Cloud: Which Cloud Account Should You Buy?
- IaaS, PaaS and SaaS: Which Layer You Actually Need
- Oracle Cloud vs IBM Cloud: Which Cloud Account Should You Buy?
- Hetzner vs OVHcloud: Which Cloud Account Should You Buy?
Frequently asked questions
It varies by provider and term, but the discount against on-demand is substantial and increases with longer commitments and larger upfront payments.
Options are limited. Some providers allow exchange or resale, but the general assumption should be that a commitment is binding.
Only for components that tolerate interruption. Anything that must stay available should not depend on it alone.
