Spot Instances: AWS Spot, GCP Spot and Azure Spot VMs

A spot instance is a virtual machine running on a provider’s unused capacity, sold well below the on-demand price on the understanding that the provider can reclaim it when it needs the capacity back. All three major clouds sell it: AWS as EC2 Spot Instances, Google Cloud as Spot VMs (the successor to preemptible VMs), and Microsoft as Azure Spot Virtual Machines. The discount is real and large, but the machine can disappear with seconds or minutes of notice, so spot only suits work that can be interrupted and resumed.

The three offers side by side

AWS: Spot Instances

AWS sets a Spot price for each instance type in each Availability Zone and adjusts it “gradually based on the long-term supply of and demand for Spot Instances.” Your instance runs whenever capacity is available. When EC2 needs the capacity back it terminates, stops or hibernates the instance, and it emits an interruption warning two minutes beforehand. If hibernation is the chosen behaviour, AWS notes you do not get the two-minute warning because hibernation begins immediately. AWS also emits an EC2 instance rebalance recommendation when a Spot Instance is at elevated risk, which lets you move work before the interruption notice arrives.

Google Cloud: Spot VMs and preemptible VMs

Google describes Spot VMs as “the latest version of preemptible VMs”, and both use the same pricing model. The difference is lifetime: preemptible VMs can only run for up to 24 hours at a time, and Compute Engine always stops them after 24 hours, while Spot VMs have no maximum runtime unless you set one. Spot prices can change up to once a day.

On preemption, Compute Engine sets the preempted metadata value to TRUE, then sends an ACPI soft-off signal that starts a shutdown period of up to 30 seconds, which is when your shutdown script runs. For preemptible VMs the shutdown period is likewise best effort and up to 30 seconds. If you are still on preemptible VMs, Spot VMs are the drop-in replacement without the 24-hour ceiling.

Azure: Spot Virtual Machines

Azure allocates Spot VMs when capacity is available but offers no SLA and no high-availability guarantee. Azure can evict a Spot VM when it needs the capacity or when the current price rises above the maximum price you set. Setting the maximum price to -1 means the VM is not evicted for price reasons and you never pay more than the standard price. The eviction policy decides what is left behind:

• Deallocate (the default) moves the VM to stopped-deallocated so you can redeploy it later, but reallocation is not guaranteed, the VM still counts against quota, and you keep paying for its disks.
• Delete removes the VM and its underlying disks, so storage charges stop too.

How often interruptions happen

No provider promises a rate, and none describes interruptions as rare. Frequency varies by instance type, region and time, and each cloud publishes history so you can choose capacity pools deliberately:

• AWS publishes the Spot Instance Advisor, whose “frequency of interruption” is the rate at which Spot reclaimed capacity during the trailing month, shown in bands from under 5% to over 20% per instance type and Region. AWS adds that actual rates vary with point-in-time capacity, and offers a Spot placement score to judge where a request is likely to succeed.
• Azure shows historical pricing and eviction rates per VM size and region in the portal when you create a Spot VM, and exposes them through Azure Resource Graph. Its eviction rates are quoted per hour: a 10% rate means a 10% chance of eviction within the next hour, based on the last 7 days.
• Google Cloud states only that Compute Engine might preempt Spot VMs at any time, and that preemptible VMs are always stopped after 24 hours.

Treat these figures as a way to rank options, not a guarantee. A pool that was quiet last month can be busy this week, which is why the design rules below assume interruption will happen.

What belongs on spot

The providers’ own examples are batch processing, data analysis, background processing, optional tasks and (in Azure’s list) dev/test environments. The design rules follow from the notice periods above: keep state off the instance, checkpoint long jobs, run behind a group or pool that replaces lost capacity, and handle the notice signal (the AWS interruption warning, the GCP metadata flag or the Azure Scheduled Event). Databases and anything holding the only copy of its state belong on regular capacity.

Spot pairs well with the other levers rather than replacing them: on-demand for steady production that cannot be interrupted, commitments for the always-on baseline, and spot for fault-tolerant burst work.

Where ZopNight fits

ZopNight records each cost line’s purchase type, including Spot alongside On-Demand, Reservation and Savings Plan, so spot spend is visible separately in cost reports, and discovered lifecycle values such as preemptible map to that purchase type so spot capacity is not mistaken for commitment candidates. For Databricks on all three clouds it flags clusters whose workers run on-demand where spot could be used; see Databricks cost optimization.