This page describes preemptible virtual machine (VM) instances. To learn how to create a preemptible instance, read Creating a preemptible instance. To learn more about instances in general, read the Virtual machine instances documentation.
What is a preemptible instance?
A preemptible VM is an instance that you can create and run at a much lower price than normal instances. However, Compute Engine might stop (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.
If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances stop during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.
Preemptible instance limitations
Preemptible instances function like normal instances but have the following limitations:
- Compute Engine might stop preemptible instances at any time due to system events. The probability that Compute Engine will stop a preemptible instance for a system event is generally low, but might vary from day to day and from zone to zone depending on current conditions.
- Compute Engine always stops preemptible instances after they run for 24 hours. Certain actions reset this 24-hour counter.
- Preemptible instances are finite Compute Engine resources, so they might not always be available.
- Preemptible instances can't live migrate to a regular VM instance, or be set to automatically restart when there is a maintenance event.
- Due to the above limitations, preemptible instances are not covered by any Service Level Agreement (and, for clarity, are excluded from the Compute Engine SLA).
- The Google Cloud Free Tier credits for Compute Engine do not apply to preemptible instances.
Compute Engine performs the following steps to preempt an instance:
- Compute Engine sends a preemption notice to the instance in the form of an ACPI G2 Soft Off signal. You can use a shutdown script to handle the preemption notice and complete cleanup actions before the instance stops.
- If the instance does not stop after 30 seconds, Compute Engine sends an ACPI G3 Mechanical Off signal to the operating system.
- Compute Engine transitions the instance to a
You can simulate an instance preemption by stopping the instance.
Preempted instances still appear in your project, but you are not charged for
the instance hours while it remains in a
TERMINATED state. You can access and
recover data from any persistent disks that are attached to the instance,
but those disks still incur storage charges until you delete them. As with
normal instances, persistent disks that are marked for auto-delete are deleted
when you delete the preemptible instance.
If Compute Engine stops a preemptible instance less than one minute after it is created, you are not billed for the use of that VM instance. This ensures that you don't pay for preemptible instances unless they have had time to complete a significant amount of work. However, the charges for premium operating systems are still calculated as normal.
Generally, Compute Engine avoids preempting too many instances from a single customer and preempts new instances over older instances whenever possible. This might be a bit frustrating at first, but in the long run, this strategy helps minimize lost work across your cluster. Compute Engine doesn't charge you for instances if they are preempted in the first minute after they start running. Google does not use a VM's CPU usage to determine whether it is preempted.
For reference, we've observed from historical data that the average preemption rate varies between 5% and 15% per day per project, on a seven-day average, occasionally spiking higher depending on time and zone. Keep in mind that this is an observation only: Preemptible instances have no guarantees or SLAs for preemption rates or preemption distributions.
Certain actions will reset the 24-hour counter for preemptible instances.
Specifically, if you
an instance, Compute Engine will reset the counter because the
instance transitions into a
TERMINATED state. However, other actions, where the
instance remains in
RUNNING state, do not reset the counter, for example,
an instance or running
sudo reboot from within the VM.
Preemptible instances in a managed instance group
Managed instance groups can create or add new preemptible instances only when additional Compute Engine resources are available. If these resources are limited, managed instance groups will be unable to resize or automatically scale the number of preemptible instances in the group.
Managed instance groups always attempt to maintain their target size or the size specified by the autoscaler for that group. If Compute Engine stops a preemptible instance in a managed instance group, the group repeatedly tries to recreate that instance using the specified instance template. If the necessary resources become available again, the group recreates the instance and maintains the target group size.
Premium operating systems on preemptible instances
Preemptible instances don't reduce the cost of premium operating systems and don't change the way that you're billed for the use of those operating systems. If Compute Engine stops a preemptible instance that runs a premium operating system, you are billed for that operating system as if you stopped the instance yourself. The charges for minimum usage still apply, and bills for premium operating systems are still calculated by rounding up to the nearest usage increment.
The machine types on preemptible instances that run premium operating systems are always billed by the second, and follow the prices listed on the Machine type pricing page.
Local SSDs on preemptible instances
You can start a preemptible VM instance with a local SSD and Compute Engine charges you preemptible prices for the local SSD usage. Local SSDs attached to preemptible instances work like normal local SSDs, retain the same data persistence characteristics, and remain attached for the life of the instance. You can request a separate quota for preemptible local SSDs, but you can also choose to use your regular local SSD quota when creating preemptible local SSDs.
Compute Engine doesn't charge you for local SSDs if their instances are preempted in the first minute after they start running.
For more information about local SSDs, see Adding local SSDs.
GPUs on preemptible instances
You can add GPUs to your preemptible VM instances at lower preemptible prices for the GPUs. GPUs attached to preemptible instances work like normal GPUs but persist only for the life of the instance. Preemptible instances with GPUs follow the same preemption process as all preemptible instances.
When you add a GPU to a preemptible instance, you use your regular GPU quota. If you need a separate quota for preemptible GPUs, request a separate Preemptible GPU quota.
During maintenance events, preemptible instances with GPUs are preempted by default and cannot be automatically restarted. If you want to recreate your instances after they have been preempted, use a managed instance group. Managed instance groups recreate your instances if the vCPU, memory, and GPU resources are available.
If you want a warning before your instance is preempted, or want to configure your instance to automatically restart after a maintenance event, use a non-preemptible instance with a GPU. For non-preemptible instances with GPUs, Google provides one hour advance notice before preemption.
Compute Engine does not charge you for GPUs if their instances are preempted in the first minute after they start running.
For steps to automatically restart a non-preemptible instance, see Updating options for an instance.
To learn how to create preemptible instances with GPUs attached, read Creating an instance with a GPU.
Testing preemption settings
You can run simulated maintenance events on your instances to force them to preempt. Use this feature to test how your apps handle preemptible instances. Read testing your availability policies to learn how to test maintenance events on your instances.
You can also simulate an instance preemption by stopping the instance, which can be used instead of simulating a maintenance event and which avoids quota limits.