Spot VMs are spare Compute Engine capacity sold at a steep discount to on demand, frequently well over half off, that GCP can reclaim with roughly 30 seconds of notice. They replaced preemptible VMs, which carried a fixed 24 hour cap; Spot VMs have no maximum runtime but can still be preempted at any moment when GCP needs the capacity back. The economics are simple to state and easy to get wrong: the hourly saving is large, but it only becomes a net saving if losing the instance mid run costs little. For interruptible work that checkpoints and restarts cheaply, such as batch, CI, stateless rendering, and fault tolerant pipelines, Spot is the cheapest option on the platform. For stateful services, long uninterruptible jobs, or anything customer facing, the cost of a reclaim, lost work, missed deadlines, and engineering effort, can exceed the discount. The decision is never the rate alone; it is the rate set against the price of preemption.
Here is the discount, the mechanics, and the line between workloads that pay and ones that do not.
What are Spot VMs and how do they reclaim?
A Spot VM runs the same machine types as on demand but at a Spot price that GCP sets and that varies over time. The defining feature is preemption: when GCP needs the capacity, it sends a preemption notice, gives about 30 seconds, then stops the instance. Your shutdown script runs in that window, so it is where checkpointing and graceful drain belong. Spot VMs do not carry the old preemptible 24 hour limit, so a Spot instance can run for days if it is never reclaimed, but it carries no runtime guarantee. The practical model is to assume any Spot instance can disappear at any time and design so that when it does, the only cost is a quick restart elsewhere.
When do Spot VMs pay, and when do they not?
| Workload | Reclaim cost | Spot verdict |
|---|---|---|
| Batch and data pipelines | Low, with checkpointing | Strong fit, large net saving |
| CI and build farms | Low, jobs simply rerun | Strong fit |
| Stateless rendering or encoding | Low, work is idempotent | Strong fit |
| Stateful databases | High, data and availability risk | Avoid |
| Long uninterruptible jobs | High, full restart from zero | Avoid unless checkpointed |
| Customer facing request paths | High, user visible failure | Avoid for the critical tier |
Discounts on Spot are indicative and move with capacity and region, so verify the current Spot price for your machine type before sizing savings. The pattern that holds across all of them: low reclaim cost is the gate, not the headline discount.
How do you run Spot without paying for interruptions?
Engineer for preemption rather than hope against it. Checkpoint long jobs so a restart resumes near where it stopped instead of from zero. Use managed instance groups and GKE node pools that mix Spot with a smaller on demand base, so a wave of preemptions degrades throughput rather than taking the service down. Spread across machine families and zones so you are not exposed to a single capacity pool. Keep stateful and latency critical tiers on on demand or committed capacity, and reserve Spot for the elastic, interruptible layer above them. Done this way, preemption is a throughput event, not an incident, and the discount survives contact with production.
A worked example
A European SaaS company ran a nightly data pipeline and a rendering tier entirely on demand because an earlier attempt at preemptible VMs had failed: jobs restarted from zero on every reclaim, so the discount was eaten by reruns. We did not just move them to Spot; we made a reclaim cheap first. The pipeline got checkpointing so a preempted task resumed near its last step, and the rendering tier moved to a managed instance group mixing Spot with a small on demand base across multiple zones. Only then did the bulk of that compute move to Spot. Preemptions became throughput dips rather than lost nights, and the elastic layer ran at a fraction of its former cost while the stateful core stayed on committed capacity. Figures are verified against billing data and anonymised.
Frequently asked questions
What are Spot VMs on GCP?
When do Spot VMs save money?
When do Spot VMs cost more than they save?
Put Spot where it pays
We map which GCP workloads can safely run on Spot, engineer the checkpointing and fallback that make preemption cheap, and keep the stateful core on the right committed capacity, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the GCP committed use discount kit, read the deeper GCP cost optimization guide, and see the cross cloud view in arbitraging Spot and preemptible capacity.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.