1. Overview
   1. A preemptible VM is an instance that runs at a much lower price than normal instances
   2. Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks
   3. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage
   4. If apps is fault-tolerant and can withstand possible instance preemptions, preemptible instances can reduce Compute Engine costs significantly
   5. Batch processing jobs can run on preemptible instances
   6. If some of those instances terminate during processing, the job slows but does not completely stop
   7. Preemptible instances complete batch processing tasks without placing additional workload on existing instances and without requiring users to pay full price for additional normal instances
   8. Simulate an instance preemption by stopping the instance, which can be used instead of simulating a maintenance event and which avoids quota limits
2. Limitations
   1. Compute Engine might terminate preemptible instances at any time due to system events
   2. The probability that Compute Engine will terminate 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
   3. Compute Engine always terminates preemptible instances after they run for 24 hours. Certain actions reset the 24-hour counter
   4. Preemptible instances are finite Compute Engine resources, so they might not always be available
   5. Preemptible instances can't live migrate to a regular VM instance, or be set to automatically restart when there is a maintenance event
   6. Due to the above limitations, preemptible instances are not covered by any Service Level Agreement
   7. The Google Cloud Free Tier credits for Compute Engine do not apply to preemptible instances
3. Process
   1. Compute Engine sends a preemption notice to the instance in the form of an ACPI G2 Soft Off signal
   2. Can use a shutdown script to handle the preemption notice and complete cleanup actions before the instance stops
   3. If the instance does not stop after 30 seconds, Compute Engine sends an ACPI G3 Mechanical Off signal to the operating system
   4. Compute Engine transitions the instance to a TERMINATED state
   5. Simulate an instance preemption by stopping the instance
   6. Preempted instances still appear in project, but not charged for the instance hours while it remains in a TERMINATED state
   7. Users can access and recover data from any persistent disks that are attached to the instance, but disks incur storage charges until deleted
   8. As with normal instances, persistent disks that are marked for auto-delete are deleted when preemptible instance is deleted
   9. If Compute Engine terminates a preemptible instance less than one minute after it is created, users are not billed for the use of that VM instance
   10. This ensures that user don't pay for preemptible instances unless they have had time to complete a significant amount of work
   11. Charges for premium operating systems are still calculated as normal
4. Selection
   1. Compute Engine avoids preempting too many instances from a single customer and preempts new instances over older instances whenever possible
   2. This might be a bit frustrating at first, but in the long run, this strategy helps minimize lost work across clusters
   3. Compute Engine doesn't charge for instances if they are preempted in the first minute after they start running
   4. Google does not use a VM's CPU usage to determine whether it is preempted
   5. 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
   6. Preemptible instances have no guarantees or SLAs for preemption rates or preemption distributions
   7. Certain actions will reset the 24-hour counter for preemptible instances
   8. A stop and start of a compute engine instance will reset the counter because the instance transitions into a TERMINATED state
   9. Actions where the instance remains in RUNNING state do not reset the counter, for example, resetting an instance or running sudo reboot from within the VM
5. MIG
   1. Can create preemptible instances in a managed instance group
   2. Specify the preemptible option in the instance template before creating or updating the group
   3. Managed instance groups can create or add new preemptible instances only when additional Compute Engine resources are available
   4. If resources are limited, managed instance groups will be unable to resize or automatically scale the number of preemptible instances in the group
   5. Managed instance groups always attempt to maintain their target size or the size specified by the autoscaler for that group
   6. If Compute Engine terminates a preemptible instance in a managed instance group, the group repeatedly tries to recreate that instance using the specified instance template
   7. If the necessary resources become available again, the group recreates the instance and maintains the target group size
6. Premium OS
   1. Preemptible instances do not reduce the cost of premium operating systems and don't change billing for the use of those operating systems
   2. If Compute Engine terminates a preemptible instance that runs a premium operating system, the user is billed for that operating system as if they terminated the instance
   3. The charges for minimum usage still apply, and bills for premium operating systems are still calculated by rounding up to the nearest usage increment
   4. The machine types on preemptible instances that run premium operating systems are always billed by the second
7. Local SSD
   1. A preemptible VM instance can be started with a local SSD and Compute Engine charges preemptible prices for the local SSD usage
   2. Local SSDs attached to preemptible instances work like normal local SSDs and only persist for the life of the instance
   3. A separate quota can be requested for preemptible local SSDs, but users can also choose to use regular local SSD quota when creating preemptible local SSDs
   4. Compute Engine doesn't charge for local SSDs if their instances are preempted in the first minute after they start running
8. GPU
   1. Users can add GPUs to your preemptible VM instances at lower preemptible prices for the GPUs
   2. GPUs attached to preemptible instances work like normal GPUs but persist only for the life of the instance
   3. Preemptible instances with GPUs follow the same preemption process as all preemptible instances
   4. When you add a GPU to a preemptible instance, you use your regular GPU quota
   5. A separate quota for preemptible GPUs can be requested
   6. During maintenance events, preemptible instances with GPUs are preempted by default and cannot be automatically restarted
   7. To recreate instances after they have been preempted, use a managed instance group
   8. Managed instance groups recreates instances if the vCPU, memory, and GPU resources are available
   9. If a warning is required before an instance is preempted, or to configure an instance to automatically restart after a maintenance event, use a non-preemptible instance with a GPU
   10. For non-preemptible instances with GPUs, Google provides one hour advance notice before preemption
   11. Compute Engine does not charge for GPUs if instances are preempted in the first minute after they start running
   12. The maximum CPU and memory that is available for any GPU type is dependent on the zone in which the GPU resource is running
   13. Instances with GPUs have specific restrictions that make them behave differently than other instance types