Create and use Spot VMs
Stay organized with collections
Save and categorize content based on your preferences.
This page explains how to create and manage
Spot VMs, including the following:
How to create, start, and identify Spot VMs
How to detect, handle, and test preemption of Spot VMs
Best practices for Spot VMs
Spot VMs are virtual machine (VM) instances that use the
spot provisioning model.
Spot VMs are available at a discount of up to 91% off of the
on-demand price of standard VMs.
For more information, see the
pricing page.
However, Compute Engine might reclaim the resources by preempting
Spot VMs at any time. Spot VMs are recommended only for
fault-tolerant workloads that can withstand VM preemption.
Verify that you have sufficient quota for the resources that you want to
request. For more information, see
Allocation quotas.
To prevent Spot VMs from consuming your quotas for
standard VMs' CPUs, GPUs, and disks, consider requesting
preemptible quota for
Spot VMs.
If you haven't already, set up authentication.
Authentication verifies your identity for access to Google Cloud services and APIs. To run
code or samples from a local development environment, you can authenticate to
Compute Engine by selecting one of the following options:
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and
APIs, you don't need to set up authentication.
gcloud
Install the Google Cloud CLI.
After installation,
initialize the Google Cloud CLI by running the following command:
To use the Terraform samples on this page in a local development environment, install and
initialize the gcloud CLI, and then set up Application Default Credentials with
your user credentials.
This predefined role contains
the permissions required to create a Spot VM. To see the exact permissions that are
required, expand the Required permissions section:
Required permissions
The following permissions are required to create a Spot VM:
compute.instances.create
on the project
To use a custom image to create the VM:
compute.images.useReadOnly
on the image
To use a snapshot to create the VM:
compute.snapshots.useReadOnly
on the snapshot
To use an instance template to create the VM:
compute.instanceTemplates.useReadOnly
on the instance template
To specify a subnet for your VM:
compute.subnetworks.use
on the project or on the chosen subnet
To specify a static IP address for the VM:
compute.addresses.use
on the project
To assign an external IP address to the VM when using a VPC network:
compute.subnetworks.useExternalIp
on the project or on the chosen subnet
To assign a legacy network to the VM:
compute.networks.use
on the project
To assign an external IP address to the VM when using a legacy network:
compute.networks.useExternalIp
on the project
To set VM instance metadata for the VM:
compute.instances.setMetadata
on the project
To set tags for the VM:
compute.instances.setTags
on the VM
To set labels for the VM:
compute.instances.setLabels
on the VM
To set a service account for the VM to use:
compute.instances.setServiceAccount
on the VM
To create a new disk for the VM:
compute.disks.create
on the project
To attach an existing disk in read-only or read-write mode:
compute.disks.use
on the disk
To attach an existing disk in read-only mode:
compute.disks.useReadOnly
on the disk
Before you create Spot VMs for a workload, complete the following steps:
Configure your workload to manage preemption. Specifically, we recommend
that you either prepare a script to handle preemption that runs as part of
your workload or is a file that you can add in VM metadata to run during
shutdown. For instructions, see
Manage preemption of Spot VMs.
We strongly recommend that you view data for Spot VMs to help you choose a machine type and location.
By selecting a machine type and location with a higher availability of
resources, you can help improve your chances of avoiding resource
availability errors and of having a longer uptime before preemption.
For current availability data, which is especially helpful immediately
before you create Spot VMs for short-term workloads, see
View the availability of Spot VMs.
Select a method for creating Spot VMs. We recommend that you
select a method as follows:
If you haven't created Spot VMs before or have a small,
short-term workload, then see Create a Spot VM.
Like other VMs, Spot VMs start upon creation. Likewise, if
Spot VMs are stopped, you can
restart the VMs
to resume the RUNNING state.
You can stop and restart preempted Spot VMs
as many times as you would like, as long as there is capacity.
For more information, see
VM instance life cycle.
If Compute Engine stops one or more Spot VMs in an autoscaling
managed instance group (MIG) or Google Kubernetes Engine (GKE) cluster, the
group restarts the VMs when the resources become available again.
Identify a VM's provisioning model and termination action
Identify a VM's
provisioning model
to see if it is a standard VM, Spot VM, or
preemptible VM.
For a Spot VM, you can also identify the
termination action.
You can identify a VM's provisioning model and termination action using the
Google Cloud console, gcloud CLI, or the Compute Engine API.
When Compute Engine begins preempting a Spot VM, you
can try to perform cleanup actions before the VM finishes shutting down.
Handling preemption can include gracefully stopping a running process and
transferring the state of your workload.
You can use the following methods to handle preemption for a
Spot VM. For more information about how to choose where to
handle preemption for your workload, see the definition of
preemption notice duration.
Handle preemption within your workload. We recommend this method for
Spot VMs with a 120-second preemption notice duration.
Specifically, within your workload, configure code for handling preemption to
wait to run until preemption starts as explained in
Detect preemption within a VM.
Then, your code for handling preemption runs during the
preemption notice duration.
(Optionally, these VMs can also specify a shutdown script, which runs
during a shutdown period.)
Handle preemption within a shutdown script. We recommend this method for
Spot VMs without a preemption notice duration, which is the default
configuration. Specifically, configure your code for handling preemption
within a shutdown script as shown in the
following example. The shutdown script automatically runs for up to 30 seconds
during the best-effort
shutdown period for any type
of shutdown. Consequently, you might want to configure the code for handling
preemption to only run if the VM is being preempted as explained in
Detect preemption within a VM.
Example of handling preemption
The following example script demonstrates how to handle preemption by uploading
a checkpoint file to a Cloud Storage bucket. You
can either execute this script within your workload or configure it as a
shutdown script. After gracefully stopping a specified program, the script
performs a parallel upload of a checkpoint file to a Cloud Storage bucket.
After the script finishes or times out, the operating system's normal kill
command stops all remaining processes.
#!/bin/bash
MY_PROGRAM="PROGRAM_NAME" # For example, "apache2" or "nginx"
MY_USER="LOCAL_USER"
CHECKPOINT="/home/$MY_USER/checkpoint.out"
BUCKET_NAME="BUCKET_NAME" # For example, "my-checkpoint-files" (without gs://)
echo "Shutting down! Seeing if ${MY_PROGRAM} is running."
# Find the newest copy of $MY_PROGRAM
PID="$(pgrep -n "$MY_PROGRAM")"
if [[ "$?" -ne 0 ]]; then
echo "${MY_PROGRAM} not running, shutting down immediately."
exit 0
fi
echo "Sending SIGINT to $PID"
kill -2 "$PID"
# Portable waitpid equivalent
while kill -0 "$PID"; do
sleep 1
done
echo "$PID is done, copying ${CHECKPOINT} to gs://${BUCKET_NAME} as ${MY_USER}"
su "${MY_USER}" -c "gcloud storage cp $CHECKPOINT gs://${BUCKET_NAME}/"
echo "Done uploading, shutting down."
This script assumes the following:
The VM was created with at least read or write access to Cloud Storage.
For instructions about how to create a VM with the appropriate scopes,
see the
authentication documentation.
You have an existing Cloud Storage bucket and permission to write to
it.
To add this script to a VM, configure the script to work with the workload on
your VM and then add the script to your workload or the VM's metadata.
Copy or download the example script:
Copy the preceding script after replacing the following:
PROGRAM_NAME: the name of the process or
program that you want to shut down. For example, apache2 or nginx.
LOCAL_USER: the username that you are logged
into the virtual machine as.
BUCKET_NAME: the name of the
Cloud Storage bucket where you want to save the program's
checkpoint file. Note the bucket name does not start with
gs:// in this case.
PROGRAM_NAME: the name of the process or
program that you want to shut down. For example, apache2 or nginx.
LOCAL_USER: the username that you are logged
into the virtual machine as.
BUCKET_NAME: the name of the
Cloud Storage bucket where you want to save the program's
checkpoint file. Note the bucket name does not start with
gs:// in this case.
Configure preemption detection and add the script based on where you plan to
handle preemption, either within your workload or within a shutdown script.
For more information about how to choose where to handle preemption for your
workload, see the definition of
preemption notice duration.
Handle preemption within your workload: Complete the following steps.
Handle preemption within a shutdown script: Complete the following steps.
We recommend that you configure the script to run only when shutdown is
caused by preemption as explained in
Detect preemption within a VM.
For example, you don't need to upload a checkpoint file when your VM
shuts down because your workload is finished.
The following sections explain the methods you can use to detect preemption of
Spot VMs.
Detect preemption within a VM: For example,
use this method to check for preemption within a shutdown script or to trigger
preemption handling for Spot VMs with a 120-second preemption
notice duration.
View preemption operations: For example,
use this method when you want to determine why Spot VMs shut down.
Detect preemption within a VM
To detect if a VM is being preempted from inside the VM itself, check
the metadata server for the preempted value in your VM's
default metadata. For example, use one or more
of the following methods based on where you plan to handle preemption.
If you handle preemption in a shutdown script, check the current value of preempted.
You can run the following curl command from within your VM to obtain the
current value for preempted:
If this value is TRUE, the VM was preempted by Compute Engine,
otherwise it is FALSE. For example, use this command within a shutdown
script to perform different actions based on whether the shutdown was caused
by preemption or not.
If you handle preemption within your workload, wait until preempted is TRUE.
To wait until preempted is TRUE, you can append the
?wait_for_change=true query parameter
to the URL of the previous command. With this query parameter, the command
performs a hanging HTTP GET request that only returns when the metadata has
changed and the VM has been preempted.
This command is useful when you want to trigger preemption handling outside of
a shutdown script. For example, use this method to trigger preemption handling
for Spot VMs with a 120-second preemption notice duration.
You can run simulated maintenance events on your Spot VMs to force
them to preempt. Use this feature to test how your workloads detect and handle
preemption. To learn how to test maintenance events on your instances, see
Simulate a host maintenance event.
Best practices
Here are some best practices to help you get the most out of Spot VMs.
View resource availability. Before you create Spot VMs, or if
you attempt to create Spot VMs but keep encountering resource
availability errors, you can view the availability of a machine type in a
specific region or zone. Checking the availability of resources helps increase
your chances of successfully creating Spot VMs. For instructions,
see
View the availability of Spot VMs.
View historical data. Before you create Spot VMs, you can view
the historical preemption rate and historical pricing for the machine types
that you want your Spot VMs to use. This information helps you
compare and choose the machine type that best fits your workload and cost
needs. For instructions, see
View the preemption rate and pricing for Spot VMs.
Use instance templates. Rather than creating Spot VMs one at a
time, you can use instance templates
to create multiple Spot VMs with the same properties. Instance
templates are required for using MIGs. Alternatively, you can also
create multiple Spot VMs
using the bulk instance API.
Use MIGs to improve resource availability and automatically recreate Spot VMs.
Use MIGs
to make workloads on Spot VMs more flexible and resilient. For
example, to prevent resource-availability errors, you can increase the
flexibility of your workload by allowing the following:
Additionally, MIGs can repair
preempted Spot VMs by automatically recreating them.
Pick smaller machine types. Resources for Spot VMs come out of
excess and backup Google Cloud capacity. Capacity for Spot VMs
is often easier to get for smaller machine types, meaning machine
types with less resources like vCPUs and memory. You might find more capacity
for Spot VMs by selecting a smaller custom machine type, but
capacity is even more likely for smaller predefined machine types. For
example, compared to capacity for the n2-standard-32 predefined
machine type, capacity for the n2-custom-24-96 custom machine type is
more likely, but capacity for the n2-standard-16 predefined machine type
is even more likely.
Run large clusters of Spot VMs during off peak times.
The load on Google Cloud data centers varies with
location and time of day, but generally lowest on nights and weekends. As such,
nights and weekends are the best times to run large clusters of Spot VMs.
Design your workloads to be fault and preemption tolerant.
It's important to be prepared for the fact that there are changes in
preemption patterns at different points in time. For example,
if a zone suffers a partial outage, large numbers of Spot VMs
could be preempted to make room for standard VMs that need to be
moved as part of the recovery. In that small window of time, the
preemption rate would look very different than on any other day. If your
workload assumes that preemptions are always done in small groups,
you might not be prepared for such an event.
Retry creating Spot VMs that have been preempted.
If your Spot VMs have been preempted, try creating new Spot VMs
once or twice before falling back to standard VMs. Depending on your
requirements, it might be a good idea to combine standard VMs and Spot VMs
in your clusters to ensure that work proceeds at an adequate pace.
Save progress to mitigate preemption.
Manage shutdown and preemption notices by saving your workload's progress so
that it can pick up where it left off, rather than start over from scratch.
For example, save progress whenever preemption is detected as
explained in Manage preemption of Spot VMs.
For further resilience, also consider saving progress at regular intervals,
not just when preemption is detected.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-09-30 UTC."],[],[]]
