GCP Spot VMs Explained: Pricing, Preemption, and Use Cases

Simple explanation

Google’s data centres have a large pool of servers. At any given moment, some of that capacity is not being used by customers who are paying full price. Rather than leave those servers idle, Google offers the spare capacity at a large discount through Spot VMs.

The catch is straightforward: if a full-price customer needs that capacity, Google takes it back. Your Spot VM gets a 30-second warning and then shuts down. You are not charged for the time after shutdown, but your workload is interrupted.

How Spot VMs work

In Compute Engine, a Spot VM is created by setting the provisioning-model to SPOT. The VM runs exactly like a standard VM in every other respect (same machine types, same OS images, same networking) but it is subject to preemption.

What preemption means

Preemption is the process of GCP reclaiming a Spot VM. It can happen at any time, for any reason, without advance scheduling. When it happens:

1. The VM receives a SIGTERM signal. Your application has approximately 30 seconds to save state and shut down gracefully.
2. If the application has not stopped within 30 seconds, the VM is terminated with SIGKILL.
3. The VM transitions to one of two states depending on your configuration. STOP: The VM is stopped but its persistent disk is preserved and you can restart it later when capacity is available. DELETE: The VM and its disks are deleted entirely.

You control which behaviour applies by setting the instance-termination-action flag when you create the VM. For most workloads, STOP is the safer default because it preserves the disk.

Pricing and savings

Spot VM discounts typically range from 60% to 91% off the on-demand price for the same machine type. The exact discount depends on several factors:

• Machine type: Less popular machine families and configurations tend to have higher discounts
• Region and zone: Zones with more spare capacity offer better Spot pricing
• Current demand: Spot pricing and availability fluctuate based on overall demand in a zone

To put the savings in perspective: for a batch workload running 20 VMs for a week, the difference between on-demand and Spot pricing can easily be an 80% reduction in cost. For teams running large-scale data processing, ML training, or rendering pipelines, Spot VMs can make previously unaffordable compute jobs economically viable.

Spot pricing fits into the broader GCP pricing model alongside on-demand rates, sustained use discounts, and committed use discounts. Each serves a different use case. Spot is specifically for cost optimisation on interruptible work, not for steady guaranteed capacity.

When to use Spot VMs

Spot VMs work well for workloads that meet two criteria: they can tolerate interruption, and they can resume or retry without losing significant progress. Common examples:

• Batch data processing: ETL pipelines, data transformations, and analytics jobs that process data in chunks and can checkpoint between chunks
• CI/CD build and test runners: Build jobs that can be retried if interrupted. A failed build due to preemption is an inconvenience, not a disaster
• Video rendering and transcoding: Frame-by-frame or segment-by-segment rendering where each unit of work is independent
• ML model training: Training runs that save checkpoints periodically and can resume from the last saved epoch
• Distributed worker pools: Systems where many workers pull tasks from a queue. If one worker is preempted, the task returns to the queue and another worker picks it up
• Fault-tolerant analytics: Frameworks like Apache Spark or Dataflow that can redistribute work when a node fails
• Non-critical dev and test environments: Development VMs where an occasional restart is acceptable

The common thread across all of these is that the loss of a single VM does not cause data loss, service downtime, or require the entire job to restart from scratch.

When not to use Spot VMs

Spot VMs are a poor fit for any workload where interruption causes an outage, data loss, or unacceptable user impact:

• Primary databases: A preempted database instance risks data corruption or unavailability. Even with replication, using Spot for a primary is unnecessarily risky
• User-facing web servers: A web server that disappears mid-request causes errors for real users. If you need stable serving capacity, use on-demand VMs with committed use discounts
• Latency-sensitive single-instance workloads: Any service where one VM handles all traffic and a restart means downtime
• Stateful services without checkpointing or failover: If the service holds important state in memory and has no way to persist it on shutdown, preemption means data loss
• Anything that cannot tolerate a 30-second shutdown: Long-running transactions, real-time streaming with strict latency SLAs, or processes that cannot be safely interrupted mid-operation

Spot VMs vs preemptible VMs vs standard VMs

GCP offers three provisioning models for Compute Engine VMs. This comparison covers the key differences. For a broader look at all GCP pricing tiers including sustained use discounts and committed use discounts, see the pricing models guide.

For new workloads, choose between standard VMs and Spot VMs. Preemptible VMs are the legacy product and offer no advantages over Spot VMs. The preemptible and Spot VMs reference page covers the technical details of both.

How to design Spot workloads safely

Running on Spot VMs requires designing your workload to survive interruption. These patterns keep your jobs resilient without adding excessive complexity.

Checkpoint progress regularly

This is the most important pattern. Save your job’s progress to durable storage (Cloud Storage, a database, or a shared file system) at regular intervals. When the job restarts, whether on the same VM or a different one, it reads the last checkpoint and resumes from there instead of starting over. For a multi-hour batch job, checkpointing every 15 to 30 minutes means you lose at most that much work on preemption.

Make jobs idempotent

An idempotent job produces the same result whether it runs once or multiple times. If a job is preempted partway through writing results, re-running it from the last checkpoint should not create duplicates or corrupt data. This is especially important for jobs that write to databases or publish messages.

Use work queues

Instead of assigning work directly to specific VMs, put work items into a queue (Cloud Tasks, Pub/Sub, or a custom queue). Workers pull tasks, process them, and acknowledge completion. If a worker is preempted mid-task, the unacknowledged task returns to the queue and another worker picks it up. This pattern makes your system naturally resilient to individual VM failures.

Spread across multiple zones

Spot availability varies by zone. If capacity tightens in one zone, all your Spot VMs in that zone may be preempted at once. Distributing your Spot VMs across multiple zones within a region reduces the chance of losing your entire fleet simultaneously.

Use mixed fleets for guaranteed baseline capacity

For workloads that need some minimum throughput at all times, run a small baseline of on-demand VMs and add Spot VMs for additional scale. The on-demand VMs guarantee that work keeps progressing even during periods of low Spot availability. The Spot VMs provide burst capacity at a fraction of the cost.

Use Managed Instance Groups for automatic replacement

A Managed Instance Group (MIG) automatically attempts to recreate preempted Spot VMs when capacity becomes available. This removes the need to manually monitor and restart instances. Combined with a startup script that resumes from the last checkpoint, a MIG-based Spot fleet can run large batch jobs with minimal manual intervention.

Creating Spot VMs

Creating a Spot VM requires two flags beyond a normal VM creation command:

# Create a Spot VM that stops (preserves disk) on preemption
gcloud compute instances create my-spot-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP

The key flags:

• —provisioning-model=SPOT tells Compute Engine to create a Spot VM instead of a standard VM
• —instance-termination-action=STOP tells GCP to stop the VM on preemption rather than delete it. The persistent disk is preserved so you can restart later. Use DELETE instead if you do not need the disk after preemption

# List your current Spot VMs
gcloud compute instances list \
  --filter="scheduling.provisioningModel=SPOT"

Spot VMs in Managed Instance Groups

For batch workloads that need many Spot VMs, a Managed Instance Group is the standard approach. A MIG monitors the health of its instances and automatically attempts to recreate any that are preempted.

# Create an instance template for a Spot VM fleet
gcloud compute instance-templates create spot-batch-template \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --metadata=startup-script='#!/bin/bash
    gsutil cp gs://my-bucket/job-script.py /tmp/job-script.py
    python3 /tmp/job-script.py'

# Create a MIG with 20 Spot VMs
gcloud compute instance-groups managed create spot-batch-group \
  --template=spot-batch-template \
  --size=20 \
  --zone=us-central1-a

Each time a VM in this group starts (or restarts after preemption), the startup script runs. If job-script.py is designed to load its last checkpoint and resume, the MIG effectively creates a self-healing batch fleet.