When should I use Spot Instances — and when should I avoid them?

As tech teams scale their workloads, cloud spend tends to scale right alongside it, often faster than anyone planned for.

Most organizations respond by leaning on commitment-based discounts. AWS Savings Plan, Reserved Instances, and Committed Use Discounts all trade a promise of steady usage for a lower rate. They work, but they ask you to predict the future.

Spot Instances take a different approach. There's no commitment required, no multi-year contract to sign. 

If done well, Spot Instances can cut compute costs by up to 90% compared to On-Demand pricing. Done poorly, they can quietly break a production workload at 2 a.m.

This blog walks through what Spot Instances are, how they behave across AWS, Azure, and Google Cloud, which workloads they're built for and which to avoid them for, and how they fit alongside AWS Savings Plans as part of a broader cost strategy.

What Are Spot Instances?

Spot Instances let you tap into a cloud provider's unused compute capacity at a steep discount. Rather than reserving capacity in advance, you're using resources the provider currently has sitting idle.

The tradeoff is reclaim risk. When AWS, Azure, or Google Cloud needs that capacity back, whether for On-Demand customers or their own internal systems, they can take it away with short notice. For AWS Spot Instances, that notice is typically two minutes.

How Spot Instances Work

The mechanics are fairly consistent across providers, even if the terminology differs. When you request an instance, the provider checks whether idle capacity is available; if so, your instance launches at the current Spot price. For AWS Spot Instances specifically, this happens through AWS EC2 Instances, Azure Spot Fleets, or Auto Scaling groups.

That price moves over time based on supply and demand for the underlying hardware. AWS Spot Instances operate on a bidding model, where customers set a maximum price they are willing to pay. AWS retired that bidding system in 2017, and today you simply pay the prevailing Spot rate.

Once your Spot Instance is running, it performs identically to an On-Demand instance of the same type. The only difference is what happens when the provider wants the capacity back.

When that moment arrives, you receive an interruption notice via a mechanism such as AWS CloudWatch Events or instance metadata. That window, however short, is meant for graceful shutdown: saving state, flushing logs, or draining connections before the instance disappears. AWS Spot Instances are also unique among the major providers in offering a hibernate option, which pauses the instance to disk rather than terminating it outright.

Spot Instances vs. On-Demand vs. Reserved Instances

It helps to see all three pricing models side by side, since teams often mix them within the same environment.

On-Demand pricing is the baseline. You pay per second or per hour with zero commitment, and the instance runs until you stop it. It's predictable and always available, but it's also the most expensive option per hour.

Reserved Instances (and their newer equivalent, Savings Plans) trade commitment for discount. You commit to a term, usually one or three years, and in return you get rates up to 72% below On-Demand. Availability is guaranteed for the term you've paid for.

Spot Instances sit at the opposite end from Reserved Instances. There's no term, no guaranteed availability, and no upfront payment. What you get instead is the deepest discount of the three, often 70-90% off On-Demand, in exchange for accepting that the instance can be reclaimed at any time.

None of these three models is inherently better than the others. The right mix depends on how predictable your workload is and how much interruption it can tolerate.

Are Spot Instances Cloud-Agnostic?

The concept of Spot Instances exists across all major providers, but the implementation details vary enough to warrant direct comparison.

• AWS Spot Instances offer savings of up to 90% versus On-Demand pricing, with prices that fluctuate based on long-term supply and demand for EC2 capacity. AWS provides a two-minute warning before reclaiming capacity, the longest notice window among the major providers.
• Azure Spot Virtual Machines also advertise savings of up to 90%, but pricing is capacity-based rather than driven by real-time bidding. Azure's eviction notice is much shorter, typically around 30 seconds, and evictions are prioritized by Azure's own capacity needs rather than by price.
• Google Cloud Spot VMs offer discounts between 60% and 91% off standard pricing, using a fixed-discount model rather than a fluctuating one. Like Azure, Google Cloud provides roughly 30 seconds' notice before preemption.

For teams standardized on AWS, the longer interruption window and integration with Spot Fleet and Auto Scaling groups make AWS Spot Instances somewhat easier to design around than their counterparts on other platforms.

What are the Advantages and Disadvantages of Spot Instances?

Spot Instances bring real upside, but they come with tradeoffs that are worth understanding before you commit a workload to them.

Advantages of Spot Instances

• Cost-efficient: Spot Instances typically run 70-90% cheaper than On-Demand pricing, which makes a meaningful dent in compute costs for batch jobs, containerized workloads, and data processing pipelines.
• Simplifies scaling: Distributed training runs, large simulations, and high-throughput data jobs that would otherwise be cost-prohibitive become realistic when compute costs drop this sharply.
• No impact on performance: AWS Spot Instances run on the exact same hardware as On-Demand instances, with identical networking and storage options.
• Easy integration: They also integrate cleanly with Auto Scaling groups, allowing teams to automatically blend Spot and On-Demand capacity to balance cost and reliability.

Disadvantages of Spot Instances

• Interruption: AWS can reclaim Spot Instances with just two minutes of warning, which rules them out for workloads that can't tolerate sudden termination.
• Spot capacity availability isn't guaranteed: Depending on region and instance type, the capacity you need may simply not be available at the Spot price when you need it.
• Subtle cost trap: If your organization already holds unused Reserved Instances or an AWS Savings Plan, shifting workloads onto Spot Instances can mean those prepaid commitments go to waste.
• Lack of universal AWS Spot Instance support: Managed services such as AWS RDS and AWS Lambda, as well as certain GPU-backed workloads in SageMaker or Bedrock, are typically excluded.

What Are the Right Workloads for Spot Instances?

Spot instances, if used as intended, can be one of the most effective cost levers in cloud infrastructure. AWS Spot Instances in particular pair well with services like AWS EC2 Auto Scaling, Amazon Elastic Container Service, and EMR. The common thread among good candidates is fault tolerance: the workload should be able to survive the disappearance of an instance without warning.

• Batch processing jobs: Large-scale data processing with frameworks like Apache Spark or Hadoop distributes work across many nodes, so losing a single node to an interruption rarely derails the entire job.
• CI/CD pipelines: Build and test jobs are typically short-lived and easily retried, which makes them a low-risk, high-savings use case for Spot Instances.
• Stateless services: Containerized applications running on Kubernetes or Amazon ECS can be rescheduled to a new node as soon as one becomes available, since they don't retain local state. To make an informed decision between Amazon ECS and EKS, read this blog.
• Machine learning training: Training jobs that checkpoint progress periodically can resume from the last checkpoint if a Spot Instance is interrupted, making them a strong candidate despite long run times.
• High-performance computing: Scientific simulations, financial modeling, and rendering workloads often tolerate interruptions well, particularly when they save intermediate progress.
• Development and testing environments: Non-production environments rarely require guaranteed uptime, making them an easy, low-risk place to start using Spot Instances.

Across all of these cases, the pattern is the same: work that can be paused, retried, or redistributed without real consequence is exactly where Spot Instances deliver the most value.

When Should I Avoid Spot Instances?

Just as clearly, some workloads should stay off Spot Instances entirely. The deciding factor is usually how much the workload depends on continuous, guaranteed availability.

• Databases: Losing a database instance mid-transaction can lead to data loss or corruption, making Spot Instances a poor fit for primary database infrastructure.
• Real-time APIs: Customer-facing APIs with strict latency and uptime requirements can't absorb a sudden two-minute interruption without visible impact.
• Stateful services: Any service holding session state or in-memory data that isn't replicated elsewhere will lose that data the moment the instance is reclaimed.
• Long-running, non-checkpointed jobs: A multi-day job without a checkpointing mechanism can lose all its progress with a single interruption, wiping out hours or days of compute spend.
• Compliance-sensitive workloads: Systems with strict availability SLAs or regulatory uptime requirements generally can't risk the unpredictability that comes with Spot Instances.
• Single-instance critical infrastructure: Anything that runs as a single point of failure, such as a lone application server with no redundancy, shouldn't be placed on Spot Instances.

For all of these, the cost savings from Spot Instances simply aren't worth the operational risk. On-Demand or an AWS Savings Plan is the safer foundation for workloads like these.

How do Spot and Savings Plans Work Together? 

Spot Instances and an AWS Savings Plan aren't competing strategies. In most mature AWS environments, they're used together, each covering a different layer of the workload.

An AWS Savings Plan works best for the predictable core of your infrastructure: the baseline compute that runs continuously, regardless of traffic or demand. Committing to that baseline through an AWS Savings Plan locks in a lower rate without sacrificing availability.

Spot Instances, meanwhile, are better suited to the variable, elastic portion of your workload. That's the extra capacity you spin up during traffic spikes, batch processing windows, or large parallel jobs.

A common pattern looks like this: cover your steady-state baseline with an AWS Savings Plan, then use Spot Instances to burst above that baseline when demand requires it. On-Demand capacity fills in as a fallback when Spot isn't available.

This layered approach avoids the double-paying trap mentioned earlier, in which idle Reserved Instance or Savings Plan capacity goes unused because workloads shift to Spot Instances. When the two are planned together rather than separately, every dollar of committed spend and every dollar of Spot savings work toward the same budget.

Auto Scaling groups make this blend easier to manage in practice. You can configure a mix of On-Demand, Savings Plan-covered, and Spot Instances within a single group, letting AWS automatically balance the mix as demand shifts.

This isn't a rigid rulebook; instead, you should consider it a starting point for matching workload characteristics to the pricing model that actually fits them.

To Sum Up

Spot Instances let you use idle cloud capacity at a steep discount, in exchange for accepting that capacity isn't guaranteed. That tradeoff makes them an excellent fit for fault-tolerant, flexible workloads like batch jobs, CI/CD pipelines for DevOps, and ML training, and a poor fit for databases, real-time APIs, and anything stateful.

Across AWS, Azure, and Google Cloud, the core idea stays consistent even as the details shift. AWS Spot Instances stand out for their longer two-minute interruption window and deep integration with Spot Fleet and Auto Scaling, which gives teams more room to design graceful shutdowns than the 30-second windows offered elsewhere.

Get that balance right, and Spot Instances stop being a risky experiment and become one of the most reliable cost levers in your cloud strategy, right alongside your AWS Savings Plan.