Every major cloud sells the same compute under several pricing models, and the differences are less about price than about what you promise in return. On-demand asks nothing of you. Commitments trade flexibility for a lower rate. Spot trades reliability for a lower rate. Choosing well is mostly an exercise in understanding your own workloads.

I will avoid quoting rates here because they differ by provider, region and time, and they change. Check each provider’s current pricing and terms before deciding.

The Three Models, Plainly

On-demand means you pay for what you use, when you use it, with no promise. It is the most flexible and, per unit, the most expensive. It is ideal for new, unpredictable or short-lived workloads, and as the layer that absorbs spikes.

Commitment-based discounts go by various names: reserved instances, savings plans, committed use contracts. You agree to a level of usage for a fixed term in exchange for a reduced rate. The details differ. Some are tied to a specific instance family and region, some to a dollar-per-hour spend that applies more broadly, and some offer more flexibility to change. Read your provider’s current terms carefully, including what happens if your usage falls below the commitment, because you generally pay regardless.

Spot or preemptible capacity is spare capacity sold at a discount, which the provider can reclaim with short notice. It can be very cheap, but your workload must tolerate being interrupted at any time.

Think in Layers

A helpful mental model is to split your usage into layers by predictability.

• The baseline: capacity that has been running steadily and will continue to. This is the candidate for commitments.
• The variable layer: demand that rises and falls with traffic or schedules. Cover this with on-demand, perhaps with autoscaling.
• The interruptible layer: work that can stop and resume without harm. This is the candidate for spot.

Looking at a usage graph over several months, the baseline is the flat floor of the chart. Commit to a comfortable portion of that floor, not to the average and certainly not to the peak.

Which Workload Fits Which Model

Workload	Good fit	Why	Caution
Always-on production services with stable load	Commitment for the baseline	Predictable usage justifies the promise	Do not commit before the service has settled
Autoscaled web tier	Commitment for the minimum, on-demand above it	Floor is steady, peaks are not	Commit to the floor, not the average
Batch jobs, data processing, rendering	Spot	Can retry and checkpoint	Needs interruption handling
CI build runners	Spot or on-demand mix	Jobs can be rerun	Long, critical builds may suffer if interrupted
Stateful databases	Commitment	Stability matters; interruption is costly	Usually unsuitable for spot
New products and experiments	On-demand	Needs are uncertain	Review after usage stabilises
Development environments	On-demand with schedules	Idle outside work hours	Switching off beats discounting

How Not to Overbuy

The failure mode of commitments is committing to something you stop using. A few habits reduce the risk:

1. Rightsize first. Committing to an oversized fleet locks in waste at a discount. Clean up before you buy.
2. Start conservative. Cover a modest slice of the stable baseline, observe, and add more in increments over time rather than one large purchase.
3. Prefer flexibility when unsure. Commitment types that apply across instance sizes or families are safer if your architecture is changing, such as a move to containers or newer hardware. The trade-off is often a slightly lower discount. Confirm specifics in current documentation.
4. Match term to certainty. Longer terms usually give bigger discounts but demand more confidence about future usage.
5. Track utilization of the commitment itself. A commitment you are not using is a recurring bill for nothing. Review coverage and utilization on a schedule.
6. Account for migrations. If you plan to change runtime, region or architecture, factor that into what you commit to.

Making Spot Work

Spot rewards workloads designed for interruption. Practical requirements:

• Handle the interruption notice gracefully by finishing or checkpointing work.
• Make jobs idempotent so a retry is safe.
• Spread across several instance types and zones, since a pool that dries up affects one type more than a diversified request.
• Keep a fallback to on-demand so work completes even when spot capacity disappears.
• Keep state off the instance.

Orchestration platforms commonly support mixing spot and on-demand nodes with different priorities. Check the current documentation for the platform you use.

A Realistic Example

Imagine a team with a steady application tier, a nightly data-processing job and some experimental services. Looking at several months of usage, they see that the application tier never drops below a certain amount, while traffic above that floor varies daily.

They commit to a conservative portion of that floor and leave everything above it on-demand with autoscaling. The nightly job, which checkpoints its progress, moves to spot with a fallback. The experiments stay on-demand, since nobody knows if they will survive the quarter.

Six months later they review commitment utilization, find it high, and add a further modest layer. They avoided the opposite story, a large upfront purchase followed by a re-architecture that left half of it unused.

Frequently Asked Questions

Is a longer commitment term always better? Not necessarily. Deeper discounts come with more risk if your needs change. Match the term to how confident you are about future usage and architecture.

What happens if I stop using committed capacity? Generally you still pay for the commitment. Some offerings allow exchanges or resale under conditions, but terms vary, so read the provider’s current rules before buying.

Can I run databases on spot? Rarely a good idea for a primary. Interruptions risk availability and data consistency. Replicas or analytics copies built to tolerate loss are a different matter.

Who should decide on commitments? A shared decision between finance and engineering. Finance understands budgeting and risk appetite; engineering knows what is going to change. Neither can decide well alone.

Should I commit before or after cost cleanup? After. Eliminate idle and oversized resources first, otherwise you commit to waste.

Next Step

Export several months of compute usage and mark the lowest steady level. Check that those resources are rightsized, then model a small commitment covering part of that floor, using your provider’s own calculator and current terms, and bring that figure to finance for a joint decision.