Spot VMs - formerly called preemptible instances - are one of the most cost-effective options in Google Cloud for the right kind of workload. They can cost 60 to 90 percent less than equivalent standard VMs. The reason they are so cheap is that they can be reclaimed by Google at any time when the underlying capacity is needed elsewhere. For workloads that can tolerate interruptions, that tradeoff is excellent. For workloads that cannot, spot VMs are the wrong choice. The Associate Cloud Engineer exam tests your ability to identify which category a described workload falls into.
When you create a VM, you choose between the standard availability policy and the spot policy. Standard VMs run until you shut them down or Google needs to perform maintenance, in which case they migrate or restart gracefully. Spot VMs, by contrast, can be stopped by Google at any time with a 30-second warning signal. You can also optionally configure a maximum runtime of 24 hours, after which the VM is automatically stopped regardless of what it is doing.
The 30-second shutdown signal gives a well-designed application time to checkpoint its state, write progress to disk, or complete an in-flight operation before the VM is stopped. Applications that handle the shutdown signal gracefully can resume from where they left off when a new spot VM is started. Applications that do not handle it lose whatever work was in progress at the time of preemption.
Google has used both terms for the same concept at different points. Preemptible instances was the original term. Spot VMs is the current branding and offers the same pricing but without the mandatory 24-hour maximum runtime that preemptible instances had. On the exam, you may see either term - they refer to the same type of interruptible, discounted VM.
The classic use cases for spot VMs are workloads that are fault-tolerant and can be restarted without losing meaningful progress. Batch processing jobs - transcoding video files, running data transformation pipelines, processing large datasets in chunks - are ideal because each unit of work is independent. If a VM is preempted mid-batch, the completed chunks are done and only the current chunk needs to be restarted.
Machine learning training jobs are another strong fit, especially at training time rather than inference time. A training job that checkpoints its model weights periodically can resume from the last checkpoint if the VM is preempted. The cost savings on a long training run can be substantial.
Test environments, rendering farms, and scientific simulations that run as independent tasks also work well on spot VMs. Any workload where individual task failure does not cascade into a wider system failure, and where the total work can be divided into units that can each be retried independently, is a candidate for spot pricing.
Databases, user-facing services, and anything that requires continuous uptime should not run on spot VMs. If your web application's VM gets preempted, users get errors until the VM is replaced. If your database gets preempted mid-transaction, you have a potential data consistency problem. The cost savings are not worth the reliability risk for these workloads.
More generally, any workload where an interruption affects end users or requires significant manual recovery should use standard VMs. The decision framework is: can this workload tolerate a sudden stop and restart without user impact and without data loss? If yes, spot is a reasonable option. If no, use standard VMs.
One of the more powerful patterns for using spot VMs is combining them with Managed Instance Groups. A MIG can be configured to use spot instances and to automatically replace any preempted VMs by creating new ones. The MIG monitors the health of all instances in the group and replaces failed or preempted ones using the instance template.
This is commonly used for autoscaled batch processing: a job dispatcher puts work into a queue, a MIG of spot VMs pulls from the queue, and if any VM is preempted, the work items it was processing go back into the queue and are picked up by the next available VM. The whole system is resilient to preemption at the cost of some duplicate work on the affected tasks.
The Associate Cloud Engineer exam presents spot VM scenarios in cost optimization questions. A scenario will describe a workload - typically a batch processing job, a data pipeline, or a training job - and note that it runs periodically and can be restarted if interrupted. The question asks which VM type minimizes cost. The answer is spot or preemptible.
The exam also presents negative scenarios where spot VMs are the wrong answer. If the scenario describes a user-facing web service that needs high availability, or a database that needs to stay running continuously, spot VMs would be incorrect. The right answer in those cases is standard VMs, possibly with autoscaling and health checks to handle failures gracefully.
My Associate Cloud Engineer course covers VM pricing options including spot VMs, committed use discounts, and sustained use discounts in the context of cost optimization on the Associate Cloud Engineer exam.
