On-Demand, Reserved and Spot: Cloud Pricing Models Explained
The same virtual machine can be bought four different ways, and the contract around it decides the invoice. This guide explains on-demand pricing, commitment discounts, spot capacity and the flat monthly plans used by developer clouds.
The same server, bought four different ways
Two teams can run identical virtual machines in identical regions and receive very different invoices. The hardware is the same. What differs is the contract wrapped around it, and cloud providers sell several at once.
Broadly there are four purchasing modes. You can rent by the second with no commitment. You can promise a level of spend or usage over a year or more in exchange for a lower rate. You can bid for spare capacity that the provider may reclaim. Or, on the developer clouds, you can buy a flat monthly product and stop thinking about it.
Each mode trades flexibility for price in a specific way. Getting the mix right is one of the highest-leverage cost decisions available, and unlike most optimisation work it requires no code changes at all.
On-demand: paying for the option to change your mind
On-demand is the default. You launch, the meter runs, you stop, the meter stops. There is no commitment, no term and no penalty for deleting the resource an hour later. Billing granularity is usually per second with a short minimum, which makes short-lived infrastructure genuinely cheap to experiment with.
What you are actually paying for is optionality. The provider holds capacity available for you at any moment without knowing your plans, and charges a premium for that uncertainty. That premium is entirely reasonable for workloads that are new, spiky or short-lived.
The mistake is leaving steady workloads on on-demand indefinitely. A database that has run continuously for eight months is not exercising any optionality, so you are paying for flexibility you never use. Every commitment discount discussed below exists to capture exactly that case.
One nuance is worth knowing: Google Compute Engine applies sustained use discounts automatically to instances that run for a large share of a month, with no action required. It is the only major platform that discounts long-running on-demand usage without a contract.
Commitment discounts and their different shapes
Commitment pricing is a simple bargain. You tell the provider how much you will use for one or three years, and the provider lowers the rate. The shapes differ enough that the vocabulary is worth learning properly.
AWS
Reserved Instances apply to a specific instance family in a specific region, with Standard reservations offering the deepest reduction and Convertible reservations allowing exchanges. Savings Plans are the newer and generally more flexible mechanism: you commit to an hourly spend figure rather than to particular instances, and Compute Savings Plans apply across instance families, regions and even across EC2, Fargate and Lambda. Payment can be all upfront, partial upfront or no upfront.
Microsoft Azure
Azure Reservations cover virtual machines, databases and several other services for a one or three year term, scoped either to a single subscription or shared across a billing account. The Azure savings plan for compute works more like a spend commitment and applies across eligible compute services. Azure Hybrid Benefit sits alongside both and applies existing licences to reduce the software portion of a bill.
Google Cloud
Committed use discounts come in two forms. Resource-based commitments buy a quantity of vCPUs and memory in a region. Flexible, spend-based commitments buy a level of hourly spend that can move between machine types and regions. Both attach to the billing account rather than to an individual instance.
Across all three, the risk is identical: a commitment you stop using is still owed. Size commitments against the floor of your usage, not the peak, and let on-demand or spot capacity cover everything above that line.
Spot capacity: cheap because it can be taken back
Providers keep spare capacity for demand they have not yet received. Rather than let it idle, they sell it at a steep reduction on the condition that they can reclaim it when a full-price customer wants it. AWS calls this Spot Instances, Azure calls it Spot Virtual Machines, and Google Cloud calls it Spot VMs, having evolved the idea from its earlier preemptible instances.
Reclamation is not gentle. Your instance receives a brief termination notice and then goes away. Anything held only in memory or on a local disk is lost. That single property defines which workloads belong here.
Good candidates share a trait: the unit of work is retryable and the deadline is soft. Batch processing, media encoding, CI build agents, data pipeline stages, scientific simulation and stateless web capacity behind a load balancer all qualify. Anything holding the only copy of state does not.
Practical defences make spot viable in production. Spread requests across several instance families and zones so one capacity crunch does not remove everything at once. Checkpoint long jobs to durable storage. Handle the interruption notice by draining connections and marking work incomplete. And keep a baseline of non-spot capacity so an eviction wave degrades service rather than ending it.
The flat model on developer clouds
DigitalOcean, Hetzner, Vultr, UpCloud and their peers take a different approach. A plan has a published monthly figure, billing accrues hourly and is capped at that monthly figure, and the bundle usually includes a transfer allowance and storage in the same line.
There is no reservation to buy and no spot market to manage, which removes an entire category of financial engineering. What you lose is the ability to trade commitment for a deeper discount at scale, and the granularity that lets a hyperscaler bill for exactly the seconds consumed.
For small and midsize workloads the flat model is frequently cheaper in practice, largely because the transfer allowance absorbs traffic that would be metered elsewhere. The AWS and Hetzner comparison examines that trade, and hyperscalers versus developer clouds covers the wider difference in philosophy.
Matching the mode to the workload
Most estates end up using three modes at once. The table below is a starting point rather than a rule.
| Workload | Suitable mode | Reasoning |
|---|---|---|
| Production database, always on | Commitment | Usage floor is predictable and the resource cannot be interrupted |
| Baseline web tier | Commitment for the floor, on-demand above it | Traffic has a stable minimum and a variable peak |
| CI runners and build agents | Spot | Jobs are short, retryable and tolerant of a restart |
| Batch analytics and encoding | Spot with checkpointing | Deadlines are soft and progress can be saved |
| New service, unknown shape | On-demand | Committing before the pattern is known wastes money |
| Small site or internal tool | Flat monthly plan | Operational simplicity outweighs marginal savings |
Review the blend quarterly rather than annually. Instance families are refreshed, workloads change shape, and a commitment sized against last year's architecture quietly becomes waste. Tie the review to the reporting described in cost monitoring and budget alerts.
Pricing questions worth settling
Do commitment discounts require me to keep a specific instance running?
It depends on the instrument. A resource-based reservation is tied to a family and region, so idle capacity in that shape is wasted. Spend-based instruments such as AWS Savings Plans or a Google flexible commitment apply to whatever eligible usage exists, which is far more forgiving as architectures change.
Is spot capacity safe for anything user-facing?
It can be, provided spot instances are only ever a fraction of a pool behind a load balancer and the pool can survive losing them. Never run a stateful component or the last healthy replica on spot. Combine it with autoscaling so replacement capacity is requested automatically, as described in autoscaling explained.
Why is my bill dominated by something other than compute?
Usually network transfer or storage operations. Compute is the line everyone optimises and transfer is the line nobody forecasts, which is exactly the problem examined in the guide to egress costs. Check the invoice breakdown before assuming instance pricing is the lever.
Where are the official explanations?
AWS documents the spend-commitment model in its Savings Plans user guide, and Google Cloud explains both commitment styles in its committed use discounts documentation. For what an individual account provides before any of this applies, the AWS account listings set out the options in their own terms.
Keep reading
All articles
Egress Costs: The Cloud Bill Line Nobody Plans For
Data transfer out is the invoice line that no capacity estimate predicts. This guide maps which directions are charged, the…
Cloud Cost Monitoring and Budget Alerts
Cloud bills arrive weeks after the decision that caused them. This guide covers the tagging discipline that makes reports useful,…
Autoscaling Explained: Horizontal, Vertical and Scheduled
Autoscaling works only on workloads designed to be replaced at any moment. This guide separates horizontal, vertical and scheduled scaling,…
Questions about a cloud account?
Ask about products, variants, availability or purchasing on either channel.