Spot Instances

What are spot instances?

Spot Instances are spare compute capacity offered by cloud providers at a significantly reduced price compared to on-demand rates. The discount can be substantial, up to 90% in some cases, but the trade-off is that the capacity can be reclaimed by the provider with little notice when demand for that capacity increases.

You can think of it as buying unused capacity at a lower price, with the understanding that it is not guaranteed to stay available.

How Spot Instances work

Cloud providers maintain pools of unused compute capacity across their infrastructure. Rather than leave it idle, they make it available at a discount through spot pricing. The price fluctuates based on supply and demand within each availability zone and instance type pool.

When a provider needs that capacity back, spot instances are interrupted. The type of warning and amount of notice you get varies by provider:

• AWS gives a two-minute interruption notice before reclaiming a Spot Instance.
• Azure gives a 30-second notice for Spot VMs.
• GCP preemptible VMs can be reclaimed with 30-second notice and are always terminated after 24 hours regardless of demand.

Applications running on spot capacity need to be designed to handle these interruptions gracefully.

Where Spot Instances make sense

Not every workload is a good fit. Spot Instances work well for:

• Batch processing jobs that can be checkpointed and resumed if interrupted.
• Data processing and analytics pipelines that are fault tolerant by design.
• CI/CD workloads and test environments where interruptions are acceptable.
• Machine learning training jobs that support checkpointing.
• Rendering and media processing tasks that can be distributed across multiple instances.

They are generally not suitable for:

• Production web applications that require consistent availability.
• Databases with strict uptime requirements.
• Any workload where an unexpected interruption would cause data loss or a customer-facing outage.

Spot Instances in action: An example

A data engineering team runs nightly batch jobs to process and aggregate usage data. The jobs currently run on four on-demand r5.2xlarge instances and take around three hours to complete.

The jobs are designed to checkpoint progress every 15 minutes. On the rare occasion an instance is interrupted, the job resumes from the last checkpoint on a replacement instance. For this example, interruptions have not caused a single failed job run since checkpointing was put in place.

Spot across AWS, Azure, and GCP

Each provider offers spot capacity under a slightly different model:

• AWS Spot Instances use a market-based pricing model. You can set a maximum price you are willing to pay, and the instance runs as long as the spot price stays below that threshold. AWS also offers Spot Fleet and EC2 Auto Scaling integrations to manage capacity across multiple instance types and zones.
• Azure Spot VMs follow a similar model with a maximum price option. Azure also supports spot capacity through Virtual Machine Scale Sets, which makes it easier to manage at scale.
• GCP preemptible VMs and Spot VMs are slightly different products. Preemptible VMs are always terminated after 24 hours and are priced at a fixed discount. GCP Spot VMs do not have the 24-hour limit but can still be reclaimed at any time.

Reducing interruption risk

Here are a few practices that make spot workloads more resilient:

• Use multiple instance types and availability zones so that if one pool is reclaimed, capacity can be replaced by another.
• Implement checkpointing in long-running jobs so work is not lost on interruption.
• Use managed services that handle spot interruptions automatically, such as AWS Spot Fleet or GCP-managed instance groups.
• Monitor spot price history to choose instance types with more stable pricing and lower interruption rates.

Savings from Spot Instances are largest when combined with a broader cost optimization strategy. Using spot capacity for eligible workloads reduces the on-demand baseline, which in turn reduces the commitment level needed for Savings Plans or Reserved Instances. The two approaches complement each other rather than compete.