On-Demand, Reserved and Spot: Which Pricing Model Fits Your Workload
Three ways to buy the same compute, at very different prices, with very different commitments. Picking the wrong one is expensive in both directions.
The larger cloud platforms sell the same virtual machine three different ways.
The hardware does not change. What changes is how much notice you give, how much
you commit to, and how much the provider is allowed to interrupt you. The price
difference between the cheapest and most expensive option for identical compute
is substantial, which makes this worth ten minutes of thought.
The three models
On-demand is the default. You create an instance, you pay
the published rate for as long as it exists, and you destroy it whenever you
like. No commitment, no discount, no interruption. This is what you are buying
unless you have deliberately chosen otherwise.
Reserved means committing in advance, usually for one or
three years, in exchange for a lower rate. You are promising to pay for that
capacity whether or not you use it. Some providers call these reservations,
others savings plans or committed use discounts, and the mechanics differ, but
the trade is the same: predictability for you, predictability for them, discount
for you.
Spot means buying capacity the provider currently has
spare, at a steep discount, on the condition that it can take the instance back
at short notice when someone paying full price wants it. You get a brief warning
and then the machine goes away.
| Model | Commitment | Can be interrupted | Typical use |
|---|---|---|---|
| On-demand | None | No | Development, unpredictable load, anything new |
| Reserved | One or three years | No | Steady baseline capacity you are confident about |
| Spot | None | Yes, at short notice | Batch jobs, rendering, CI, anything restartable |
How to decide, in order
Start on demand, always
You cannot reserve capacity sensibly until you know what you actually use,
and you will not know that for at least a few weeks. Running on demand first is
not wasted money, it is the measurement that makes the later decision correct.
Reserving the wrong instance family for three years costs far more than a month
of on-demand pricing.
Reserve only the baseline you are sure of
Look at your usage over a month or two and find the floor: the capacity that
is in use at three in the morning on a quiet Sunday. That floor is what is safe
to reserve. Everything above it is variable demand and belongs on demand.
Two cautions. A reservation is usually tied to a specific instance family and
region, so it stops applying if you re-architect. And a three year commitment
assumes your workload still exists in three years, which for a young product is
a real assumption rather than a formality. A one year term at a smaller discount
is often the better risk-adjusted choice.
Use spot only for work that can be killed
Spot is excellent for a specific shape of job: one that can be stopped
halfway through and restarted without anybody noticing. Batch processing,
rendering, test suites, data transformation and training runs that checkpoint to
storage all fit. A web server handling live traffic does not, unless you have
built the surrounding machinery to replace it instantly.
The failure mode with spot is subtle. It works fine for weeks, so the
interruption handling never gets tested, and then capacity tightens and
everything stops at once. If you use spot, make the interruption path the normal
path and exercise it deliberately.
What this looks like in practice
A typical mature setup is a mixture. A reserved baseline covering the
capacity the service always needs. On-demand capacity absorbing daily and
seasonal peaks. Spot capacity running the batch work that happens overnight. The
proportions matter less than the principle, which is that each piece of the
workload is bought on the terms that match its tolerance for interruption and
its predictability.
When none of this applies
These models belong to the hyperscalers. The developer-focused providers
mostly sell one thing: a server at a flat monthly rate, with no commitment tiers
and no spot market. That is not a missing feature, it is a different product
philosophy, and for a workload that fits on a predictable number of servers it
removes an entire category of decision. If you have found yourself reading about
reservation coverage for a two-server deployment, the question to ask is not
which model to choose but whether you needed a platform with models at all.
Our comparison of
the three hyperscalers
and the guides to
Hetzner and
DigitalOcean set out
that difference in more detail.