EC2 Spot Instances: up to 90% off, if you run the right workloads on them.
Spot Instances are spare EC2 capacity that AWS sells at up to 90% off On-Demand. The catch is a 2-minute interruption notice when AWS needs the capacity back. Run interruption-tolerant work on Spot (stateless web tiers, batch, CI, Kubernetes nodes, checkpointed ML training), spread it across many instance pools, and keep the baseline you cannot lose on On-Demand or Savings Plans.
- Spot Instances are spare EC2 capacity at up to 90% off On-Demand. AWS can reclaim them with a 2-minute warning. That makes Spot right for interruption-tolerant work (stateless web tiers behind a load balancer, batch and ETL, CI runners, EMR and Spark, Kubernetes worker nodes, checkpointed ML training) and wrong for anything holding critical state with no checkpoint.
- Two practices keep Spot reliable: a capacity-optimized or price-capacity-optimized allocation strategy, and diversification across many instance types and Availability Zones. Auto Scaling Groups with a mixed instances policy and Karpenter on EKS do both for you.
- The mature pattern is blended: a Savings Plan or On-Demand baseline for the floor you cannot lose, Spot for the elastic layer on top, and On-Demand for spikes. You can set this up yourself; if you want a partner to do it, CloudRoute matches you with one for free.
IWhat EC2 Spot is: spare capacity, not a separate product
Spot Instances are ordinary EC2 instances (the same M, C, R and accelerated families) drawn from capacity an Availability Zone has idle at that moment. You pay the Spot price, which moves with supply and demand and sits far below On-Demand. In exchange, AWS can reclaim the instance after a 2-minute notice.
The discount varies by instance family, Region and AZ; AWS says up to 90% off On-Demand. Check the live number in the Spot price history (EC2 console, or the describe-spot-price-history API) and the Spot placement score, which tells you how likely a Region or AZ is to fill a request of your size right now.
Spot pricing is no longer an auction. The price changes gradually and you pay the current price. You can set a maximum price, but the sensible default is to leave it at the On-Demand price, so you are only interrupted when AWS needs capacity back, not because of price.
A "Spot pool" is one instance type and size in one AZ (for example c7g.xlarge in us-east-1a). Reclamations happen per pool. Reliability on Spot comes from not depending on any single pool.
Spot is the same EC2 you already run, at up to 90% off, on the condition that AWS can take any single instance back on 2 minutes' notice. The rest of this guide is about making that eviction a non-event.
IIWhat is safe to run on Spot, and what is not
The question is not "is this important?" but "if one instance vanishes in 2 minutes, does the work survive on its own?" If yes, it is a Spot candidate. If a lost instance means lost data or a hard outage, keep it off Spot.
Safe for Spot (interruption-tolerant)
Stateless web and API tiers behind a load balancer. If a request can be retried against another instance and no session state lives only on the box, Spot behind an ALB or NLB works well. Keep session state in ElastiCache or DynamoDB.
Batch, ETL and queue workers. AWS Batch, SQS consumers, nightly ETL, transcoding, report generation. If a worker dies, the message returns to the queue and another worker picks it up. This is the classic Spot use case.
CI/CD runners. Self-hosted GitHub Actions or GitLab runners, Jenkins agents and build farms are short, retryable and stateless.
Big-data clusters. Amazon EMR supports Spot directly; put task nodes (which hold no HDFS data) on Spot and keep core nodes stable.
EKS worker nodes. Stateless pods and horizontally scaled deployments, with Pod Disruption Budgets and graceful draining.
ML training. Jobs that checkpoint to S3 resume after an interruption. SageMaker managed Spot training handles this for you. Keep latency-critical real-time inference on stable capacity.
Not safe for Spot (keep on On-Demand or Savings Plans)
Single, non-replicated stateful databases. Two minutes is not enough to fail over cleanly. Use RDS or Aurora on stable capacity, or a properly replicated cluster.
Long jobs that cannot checkpoint. A 9-hour job that produces nothing until the end loses everything on an eviction at hour 8. Add checkpointing first, or keep it on On-Demand.
License-locked or host-pinned servers, and latency-critical singletons with no warm standby. Replacement churn fights both.
"If AWS evicts this instance in 2 minutes, does the work survive automatically?" Survives through retry, re-queue, checkpoint or a healthy peer: Spot. Loses data or causes a hard outage: not Spot.
IIIAllocation strategy and diversification: how Spot stays reliable
Two settings decide whether Spot interrupts often or rarely: the allocation strategy, and how many pools you spread across.
- capacity-optimized: AWS draws from the pools with the most spare capacity, the ones least likely to be reclaimed soon. The right default for most workloads. "capacity-optimized-prioritized" also honors your instance-type priority list.
- price-capacity-optimized: AWS weighs both spare capacity and price. For many fleets this is now the best general-purpose choice.
- lowest-price (usually a trap): AWS picks the cheapest pools regardless of depth. The cheapest pool is often the one about to be reclaimed, so this maximizes interruptions.
Diversification gives the allocation strategy good options. Allow many interchangeable instance types (several sizes and families that fit your vCPU and memory shape, such as m6i, m6a, m7i, m7g) in every AZ. Ten or more pools is a healthy target. Attribute-based instance type selection lets you state requirements (for example at least 4 vCPU and 8 GiB) and have AWS expand them to every matching type.
If your workload runs on ARM, add Graviton types. Graviton Spot pools add more capacity to draw from at a lower price, which overlaps with the Graviton migration lever.
IVSpot in Auto Scaling Groups and EKS (Karpenter)
In production you let an orchestrator request Spot capacity, react to interruptions and replace evicted instances. For most teams that is an Auto Scaling Group or Karpenter.
Auto Scaling Groups with a mixed instances policy span many instance types and split capacity between On-Demand and Spot:
- On-Demand base capacity: a fixed floor of On-Demand instances that always exists.
- On-Demand percentage above base: for example 20% On-Demand and 80% Spot for the elastic layer.
- Spot allocation strategy: capacity-optimized or price-capacity-optimized.
- Instance type list or attribute-based selection: the diversified pools across all AZs.
- Capacity Rebalancing: launches a replacement when AWS signals elevated interruption risk, before the 2-minute notice.
EKS: Karpenter
Karpenter watches for unschedulable pods and provisions fitting nodes in seconds, choosing instance types and purchase options directly. In a NodePool you allow Spot (with On-Demand as fallback) across a wide set of families and sizes. Karpenter also consolidates pods onto fewer nodes, which adds a utilization win on top of the Spot discount.
Karpenter reads EC2 interruption and rebalance signals from an SQS queue, cordons and drains the node, and provisions a replacement. Add Pod Disruption Budgets and sensible terminationGracePeriodSeconds. The standard pattern is a small On-Demand node pool for ingress, stateful sets and system pods, and a large Spot pool for stateless application workloads.
VHandling interruptions: the 2-minute drill
Reliable Spot is not about avoiding interruptions. It is about making each one boring. Listen for these signals:
- Rebalance Recommendation (earliest warning): Fires when an instance is at elevated risk of interruption, often before the 2-minute notice. Start draining and bring up a replacement. Capacity Rebalancing and Karpenter act on it automatically.
- Spot Instance Interruption Notice (2-minute warning): Delivered through instance metadata (the
instance-actionendpoint) and EventBridge. Stop taking new work, finish or checkpoint in-flight work, deregister from the load balancer, flush logs, exit. - Termination (the deadline): After 2 minutes the instance is reclaimed. Anything not drained or checkpointed is lost.
In practice: a web tier deregisters from the target group and lets in-flight requests finish; a queue worker stops pulling and lets unfinished messages reappear after the visibility timeout; a training job writes a checkpoint to S3; Kubernetes cordons and drains the node. Keep shutdown work well under 120 seconds, and design for the rare case where no notice arrives: idempotent jobs, replicated state and health-check-driven replacement.
VISpot, On-Demand and Savings Plans: the blended strategy
All-Spot is a beginner's framing. Layer three purchase options so each covers the part of the workload it suits.
Layer 1, the committed baseline (Savings Plans). The compute you run around the clock and will keep for 1 to 3 years. A Compute Savings Plan gives up to 66% off and an EC2 Instance Savings Plan up to 72% (AWS figures, checked 2026-10-10). A Savings Plan is a billing discount, not capacity, and it is never interrupted. This layer never goes on Spot.
Layer 2, the elastic layer (Spot). The variable demand that scales with traffic, jobs or batch volume and tolerates a 2-minute eviction. The larger and more stateless this layer, the more Spot saves.
Layer 3, the safety valve (On-Demand). A thin slice for spikes and for moments when a Spot pool cannot fill capacity.
Savings Plans and Spot do not compete: the commitment covers the baseline, Spot handles the elastic surplus at an even lower price, and On-Demand catches the rest. Size the Savings Plan only to the baseline you are confident about, because you owe the commitment for the full term. See the Savings Plans guide for the sizing math.
VIIFargate Spot: Spot pricing without managing instances
On Amazon ECS, tasks can run on the FARGATE_SPOT capacity provider at a discount to regular Fargate, with the same 2-minute interruption behavior (SIGTERM, then about 2 minutes before SIGKILL).
The fit rules match EC2 Spot: stateless services, queue workers and batch tasks yes; the one stateful task you cannot lose, no. A capacity provider strategy places a base of tasks on regular FARGATE and the rest on FARGATE_SPOT. For teams that do not want to run EC2 fleets, it is often the easiest Spot win.
Fargate on EKS has no Spot tier. For Spot on EKS, use EC2 node pools through Karpenter. The short decision tree: containers on ECS, Fargate Spot; containers on EKS, Karpenter Spot node pools; plain VM fleets, an ASG mixed instances policy.
VIIISpot vs On-Demand vs Savings Plans, side by side
These are layers to combine, not options to choose between.
| Dimension | Spot | On-Demand | Savings Plans |
|---|---|---|---|
| Discount vs On-Demand | Up to 90% | Baseline (0%) | Up to 66% (Compute) or 72% (EC2 Instance) |
| Commitment | None | None | 1 or 3 year hourly $ commitment |
| Can be interrupted? | Yes, 2-minute notice | No | No (a billing discount, not capacity) |
| Capacity guaranteed? | No | Yes | No (applies to On-Demand usage) |
| Best for | Stateless, batch, CI, Kubernetes nodes, ML training | Spikes and work that cannot go on Spot | The predictable 24/7 baseline |
| Right layer in the stack | Elastic surplus | Spillover and safety valve | Committed floor |
IXDoing it yourself, or with a partner
Spot is high-leverage but not set-and-forget. Choosing the diversification set, wiring allocation, building interruption handling into each workload, configuring Karpenter or the ASG, and sizing the Savings Plan baseline is a real engineering project.
CloudRoute matches you with one vetted AWS partner with Spot, Karpenter and FinOps experience. The partner checks Compute Optimizer, Cost Explorer, Spot placement scores and each workload's interruption tolerance, writes the blended plan and does the rework. A good review also covers right-sizing, Graviton and Savings Plans, because compute is never optimized in isolation.
Who pays: Spot adoption on its own is normal paid work, and the savings are what pay for it. AWS funding that a partner can file comes through three routes: MAP when you migrate to AWS, POC when you test something, and incremental workload (IW) funding when you launch new work on AWS. If your Spot work is part of one of those, the partner checks whether it qualifies: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
When Spot is the right tool, and when to reach for another lever
Spot is the biggest single cut on the compute line for interruption-tolerant work, but it does not touch storage, data transfer or the stable baseline.
| Situation | Reach for | Why |
|---|---|---|
| Large stateless, batch, CI or Kubernetes compute layer | Spot Instances | Interruption-tolerant work gets the deepest discount |
| Predictable 24/7 baseline you will keep for 1 to 3 years | Savings Plans | Commitment beats Spot for capacity that must stay up |
| Over-provisioned instances | Right-sizing (Compute Optimizer) | Stop paying for capacity you never use before discounting it |
| Workload runs (or could run) on ARM | Graviton migration | Better price-performance; Graviton adds more Spot pools |
| Whole bill is a mystery | A cost audit | Find every lever, including storage and data transfer |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks which funding fits
Your matched partner scopes the work with you. Then it checks which partner-filed funding fits: MAP if you are moving to AWS, POC if you want to test something, or incremental workload (IW) funding if you are already on AWS and launching new work.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
How much cheaper are EC2 Spot Instances?
What happens when AWS interrupts a Spot instance?
Can I run production on Spot?
How do I keep Spot interruptions rare?
Should I use Spot or Savings Plans?
Does Spot work with EKS?
Is there a Spot option for Fargate?
Can AWS pay for a partner to set up Spot?
Move your elastic compute to Spot without breaking production
CloudRoute matches you with a vetted AWS partner with Spot, Karpenter and FinOps experience. The partner plans the diversification, allocation, interruption handling and Savings Plan baseline. CloudRoute is free for startups.