Spot Instances and Savings Plans: Cutting Compute Costs Without Risk

On-demand is the price you pay for buying nothing

The default way to run cloud compute — on-demand, per-second, no commitment — is also the most expensive way, by a wide margin. It buys one thing: total flexibility to start and stop anything at any moment. Most production workloads do not need that much flexibility. A baseline of servers runs 24/7 for years; batch and CI jobs can tolerate interruption; a web tier is fault-tolerant behind a load balancer. Paying the on-demand premium for workloads that never use the flexibility it buys is the single most common source of avoidable cloud spend.

Cloud providers offer two fundamentally different discount mechanisms for giving up some of that flexibility, and they are frequently confused. Commitment-based discounts (Savings Plans, Reserved Instances, committed-use discounts) trade a usage promise for a lower rate. Spare-capacity pricing (spot / preemptible) trades interruptibility for a steep discount. They solve different problems, carry different risks, and the strongest cost strategies use both together.

The three pricing planes

Think of compute pricing as three planes, each with a distinct bargain:

• On-demand. Full price, full flexibility, no commitment, no interruption. The right choice only for genuinely unpredictable, short-lived, or spiky workloads that neither commitments nor spot can cover.
• Commitment discounts. You commit to a consistent amount of usage — measured in dollars-per-hour of compute (Savings Plans / committed-use) or specific instance reservations — for a one- or three-year term, in exchange for a substantially lower rate. The capacity behaves exactly like on-demand; only the price changes. The risk is financial: you owe the commitment whether or not you use it.
• Spot / preemptible. You run on the provider's spare capacity at a deep discount, accepting that it can be reclaimed with little notice when the provider needs it back. The capacity is identical to on-demand while you have it. The risk is operational: interruption.

The insight that unlocks savings: these are not competing choices for the whole estate. They are tools for different portions of it. Match each workload to the plane whose bargain it can actually accept.

Commitment discounts without the lock-in trap

Commitments are the lowest-risk savings if you buy them correctly, and a liability if you overbuy. The discipline that keeps them safe:

• Commit only to your proven baseline. Look at months of usage and find the floor — the amount of compute that is always running. Commit to that, and let usage above it stay on-demand or spot. Committing to peak or to optimistic growth is how you end up paying for reservations you do not use.
• Prefer the flexible instruments. Modern Savings Plans and committed-use discounts apply to a dollar amount of compute rather than a specific instance family, so they keep discounting as you change instance types, sizes, and regions. Rigid, instance-specific reservations save slightly more but lock you to a shape you may outgrow.
• Watch coverage and utilization as live metrics. Coverage is how much of your eligible usage a commitment discounts; utilization is how much of your commitment is actually consumed. Aim for high utilization first — an unused commitment is pure waste — then raise coverage toward your stable baseline.
• Ladder the terms. Staggering shorter and longer commitments over time avoids a cliff where everything expires at once and keeps your committed floor tracking a changing baseline.

The same model exists across providers under different names, so a mixed estate can apply the identical discipline everywhere.

Spot without the operational risk

Spot capacity carries the deepest discount and the interruption that scares teams away from it. The discount is real and so is the interruption — the skill is confining it to workloads that shrug interruption off.

• Good spot workloads are fault-tolerant by nature. Stateless web and API tiers behind a load balancer, batch and data-processing jobs, CI/CD runners, and horizontally scaled queue consumers all lose a worker gracefully. Losing one node degrades throughput briefly rather than causing an outage.
• Bad spot workloads hold irreplaceable state. A single-instance database, a stateful leader, or anything where losing the node means losing data or a long unrecoverable computation. Do not put these on spot.
• Heed the interruption signal. Providers give a short warning — on the order of a couple of minutes — before reclaiming spot capacity. Wire your workloads to catch it and drain gracefully: stop taking new work, checkpoint, and hand off, so an interruption is a controlled handoff rather than a crash.
• Diversify across instance pools. Spot availability is per instance type, per zone. Requesting capacity from many types and zones with a capacity-optimized strategy dramatically lowers the odds of being reclaimed all at once. Concentrating on one popular type is the classic way to get mass interruptions.
• Keep a non-spot floor. Run enough baseline capacity on commitments or on-demand that a broad spot reclamation degrades service rather than removing it.

Treated this way, spot is not gambling — it is running interruption-tolerant work on cheaper capacity while engineering for the interruption you already expect.

Blending the three into one strategy

The mature pattern layers all three planes onto a single workload profile:

• Commitments cover the always-on baseline — the floor that runs regardless — at the lowest safe rate.
• Spot carries the elastic, fault-tolerant burst on top, where the deep discount applies to work that can absorb interruption.
• On-demand fills the thin gap for genuinely unpredictable spikes that neither of the above should cover.

In practice a mixed autoscaling group or node pool can draw baseline from committed capacity and scale out onto spot automatically, with on-demand as the fallback when spot is scarce. Dense, well-utilized high-performance servers under that scheme squeeze the most work out of every committed and spot dollar.

Where to start

Do the low-risk thing first: pull a few months of usage, find your always-on baseline, and buy a flexible commitment for that floor — this saves real money with no operational change and no interruption risk. Next, identify the most obviously fault-tolerant workload you run — a batch pipeline, CI fleet, or stateless tier — and move it onto diversified spot with graceful interruption handling. Prove the pattern there, then extend it. Keep on-demand for only what truly needs it, and revisit coverage and utilization on a schedule, because a changing estate quietly drifts away from an optimal mix.

Compute cost optimization is ongoing engineering, not a one-time purchase, and it pays best when it is designed into how the cloud infrastructure scales. If you want help matching workloads to the right pricing plane and building the automation that keeps the mix optimal, talk to our team.