Home/Library/GCP Spot VMs and Preemptible Instances
Compute · Google Cloud · Updated May 2026

GCP Spot VMs and Preemptible Instances for Cheap Compute

GCP Spot VMs are the single cheapest way to run compute on Google Cloud, with discounts that often land far below on-demand. The catch is that Google can reclaim them with little notice, so the win is real only when you match them to the right workloads and engineer for interruption. This guide shows where they fit and how we run them safely.

GCP Spot VMs and preemptible instances give you spare Compute Engine capacity at a steep discount off on-demand pricing, frequently in the range of 60 to 91 percent depending on machine type and region. The trade is availability: Google can preempt the instance whenever it needs the capacity back. Used well, Spot is the highest-leverage compute saving on Google Cloud. Used carelessly, it turns into failed jobs and on-call pages. The difference is workload fit and graceful interruption handling.

This article is part of our Google Cloud cluster. For the full picture of where Spot sits among rightsizing, scheduling and commitments, start with our complete guide to Google Cloud cost optimization, the pillar this piece links up to.

Spot VMs vs preemptible instances: what changed

Preemptible VMs were Google's original spare-capacity product. They carried a hard 24 hour cap: the instance was always reclaimed within a day, whether Google needed the capacity or not. Spot VMs are the successor and the model you should use today. Spot VMs use the same deeply discounted spare capacity and the same preemption mechanics, but they have no 24 hour limit, so an instance can run for days or weeks if the capacity is not needed elsewhere. Preemptible instances still exist for backward compatibility, but for new work choose Spot. The pricing is dynamic, adjusts over time, and is capped so it never exceeds a set fraction of on-demand. Always confirm the current Spot price for your machine family and region in the Compute Engine pricing pages before you model savings, because the discount varies and changes.

The economics: how big is the discount

Spot pricing varies by machine family, region and demand, but the headline is large. Across common general-purpose and compute-optimized families, Spot frequently runs 60 to 91 percent below the equivalent on-demand rate. That means a workload that costs 10,000 dollars a month on-demand might cost 1,000 to 4,000 dollars on Spot. No commitment, no upfront payment, and the discount applies the moment you launch. Compared with a committed use discount, which locks you in for one or three years for a smaller percentage off, Spot gives a bigger cut with zero commitment, in exchange for accepting interruption. The two are complementary, not competing: commit the steady baseline, run the interruptible surge on Spot.

OptionTypical discountCommitmentInterruption risk
On-demandBaselineNoneNone
Sustained use discountUp to ~30% on eligible VMsNone, automaticNone
Committed use discount~37% to 70%1 or 3 yearsNone
Spot VMs~60% to 91%NoneReclaimed on ~30s notice

For how the automatic and committed discounts work alongside Spot, see sustained use discounts on Google Cloud and committed use discounts explained.

Which workloads fit Spot

The rule is simple: if losing the instance mid-run is recoverable, Spot is a candidate. Good fits include batch processing and ETL, CI and build farms, media transcoding and rendering, machine learning training that checkpoints, stateless web and API tiers behind a load balancer with autoscaling, and fault-tolerant data pipelines like Dataflow and Dataproc secondary workers. Bad fits are anything stateful and singular: a primary database, a stateful session server with no failover, a licensing server, or a long single-threaded job that cannot checkpoint. For container workloads, Spot shines on Kubernetes node pools where the scheduler reschedules evicted pods automatically; see GKE cost optimization.

Handling preemption gracefully

When Google reclaims a Spot VM it sends a preemption notice and a short grace period, around 30 seconds, before the instance is stopped. That window is enough to do real work if you prepare for it. The pattern that works: run a shutdown script that catches the preemption signal, flushes in-flight state, checkpoints progress, drains connections, and deregisters from the load balancer. Make every job idempotent so a re-run after preemption is safe. Keep a small on-demand or committed baseline for the part of the fleet that must always be up, and let Spot absorb the elastic remainder. With managed instance groups you can mix Spot and standard VMs and let the group recreate preempted instances automatically.

Want Spot rolled out without the risk?

Our Google Cloud cost audit identifies every workload that can move to Spot, models the saving, and ships the interruption handling so production never feels it. On the performance model you pay only from realized savings. No savings, no fee.

Book a GCP cost audit →

How to roll Spot out safely

Start with a non-production workload to prove the interruption handling before you touch anything customer-facing. Move CI runners, batch jobs, or dev environments first. Measure the realized saving against the prior on-demand run rate, and watch preemption frequency by region and machine family, because some combinations are reclaimed far more often than others. If preemptions are too frequent for a workload, try a different machine family or region, or fall back to a managed instance group that blends Spot with on-demand for a guaranteed floor. Once the pattern is proven, expand to stateless production tiers behind autoscaling. Tag or label every Spot resource so you can attribute the saving and prove it in your billing data; see labels and folders for cost allocation.

Common mistakes that erase the saving

Three errors recur. First, running Spot without preemption handling, so jobs fail and engineers quietly move everything back to on-demand. Second, putting stateful or singular workloads on Spot and absorbing repeated outages. Third, ignoring quota and capacity: Spot is spare capacity, so in a constrained region you may not get the instances you ask for, which is why a mixed managed instance group is safer than pure Spot for anything that needs a floor. Avoid these and Spot is close to free money on the right workloads.

Machine families, discount ranges, preemption mechanics and product names above reflect Google Cloud as of May 2026. Verify current Spot pricing and behavior in Google Cloud documentation before acting, as the platform changes.

Go deeper · free guide

The Google Cloud Cost Optimization Field Guide includes our Spot adoption playbook, the workload-fit scoring model, and the preemption-handling templates we deploy on engagements. It is the downloadable companion to this article.

The short version

Spot VMs are the cheapest compute on Google Cloud, often 60 to 91 percent below on-demand, with no commitment. The price is interruption, so use them for batch, CI, rendering, checkpointed training and stateless autoscaled tiers, handle the preemption signal gracefully, and keep a committed baseline for what must stay up. Combine Spot for the elastic layer with commitments on the steady baseline, and you get the best blended rate on the platform. When you want it rolled out across the estate without breaking production, that is exactly what our Google Cloud cost optimization service delivers.

The Cloud Cost Brief

Cloud pricing moves. We tell you when it matters.

New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.

Subscribe · Work email only