Amazon EC2 Spot Instances: Cost-Optimised, Flexible and Resilient Computing for Modern Workloads
Summary:
Amazon EC2 Spot Instances offer discounts of up to 90% compared with On-Demand pricing, making them ideal for workloads that can tolesrate interruptions and require cost optimisation.
Organisations running Spot Instances on AWS must implement diversity, efficiency and continuity patterns to maximise value while maintaining application availability. This guide explains how EC2 Spot works, where it fits in AWS architectures, best practices across Amazon EKS, Amazon ECS, Amazon EMR, AWS Batch and Amazon SageMaker, and how to build production-ready Spot implementations that deliver both savings and reliability.
What Are Amazon EC2 Spot Instances?
Amazon EC2 Spot Instances use spare EC2 capacity that AWS offers at steep discounts in exchange for flexibility. When AWS needs the capacity back, Spot Instances receive a two-minute interruption notice before termination.
This model is ideal for stateless, fault-tolerant workloads such as batch processing, containerised applications, testing environments and horizontal scaling scenarios where interruption tolerance is built into the application architecture.
Spot is not random. AWS provides tools such as Spot Placement Scores to help estimate capacity availability, while allocation strategies such as capacity-optimised selection help reduce interruption risk in production deployments.
Why Traditional Overprovisioning Fails
· Locked-in On-Demand pricing ties up capital in infrastructure when that capital could support product innovation and market expansion.
· Over-provisioned capacity creates idle infrastructure that generates cost waste without delivering additional resilience or performance.
· Workloads that are not designed for dynamic infrastructure can become difficult to scale as growth accelerates.
· Monolithic deployments on fixed On-Demand infrastructure lack the agility to adapt to capacity changes, regional expansion or multi-AZ strategies.
· Over-provisioned infrastructure can also increase power, cooling and physical-resource consumption compared with more dynamic provisioning models.
Spot-based architectures address these gaps through dynamic provisioning, flexible workload design and cost-optimised allocation strategies. See also Rapyder’s Cloud Cost Optimisation Services
EC2 Spot Instances vs On-Demand: When to Use Each
The choice between EC2 Spot Instances and On-Demand Instances is not always either-or. Production architectures commonly use both, matching each capacity type to the workload’s tolerance for interruption.
| CATEGORY | EC2 SPOT INSTANCES | ON-DEMAND INSTANCES |
|---|---|---|
| Pricing | Up to 90% off On-Demand pricing, depending on capacity and market conditions | Standard pay-as-you-go pricing |
| Availability | May be reclaimed with a two-minute interruption notice | No Spot-style reclamation once running |
| Best fit | Stateless, fault-tolerant and horizontally scalable workloads | Stateful, latency-sensitive or interruption-sensitive services |
| Typical savings | Many organisations target 70–90% savings at scale | Baseline pricing with no Spot discount |
| Risk profile | Requires interruption handling and fallback capacity | More predictable availability at a higher steady-state cost |
Rule of thumb: if a workload can checkpoint, restart or re-queue a job without breaking an SLA, it may be a good Spot candidate.
If it cannot, such as a primary database or session-dependent monolith without external state storage, keep it on On-Demand, Reserved Instances or Savings Plans. Spot can still support the elastic and fault-tolerant layer around it.
Most production environments use a blended model: On-Demand for the guaranteed baseline and Spot for burst, batch and recoverable capacity.
Three Core Pillars for EC2 Spot Success
1. Diversity
Workloads should be able to run across multiple instance types, regions and Availability Zones. Diversity provides access to independent capacity pools and reduces dependency on a single pool, architecture or location.
Instance diversification: Configure five or more instance types to spread workloads across independent Spot capacity pools. AWS recommends spanning processor architectures such as Intel, AMD and Graviton, along with multiple instance generations.
Regional diversity: Design applications to run across multiple AWS Regions where practical. Use the Spot Placement Score API to evaluate capacity options before deployment.
Multi-AZ deployment: Distribute workloads across multiple Availability Zones within a Region to reduce the blast radius of capacity events and improve fault isolation.
2. Efficiency
Infrastructure should scale dynamically based on workload demand, provisioning capacity only when needed and releasing it when demand drops.
Dynamic provisioning: Use Auto Scaling Groups with capacity-optimised allocation strategies, EC2 Fleet or Karpenter to make scaling decisions based on real-time workload requirements. See Rapyder’s AWS DevOps Consulting Services
Right-sizing: Provision instances when they are needed rather than far ahead of demand. Monitor workload requirements continuously and scale down during off-peak periods.
Cost optimisation: Combine Spot pricing with efficient allocation strategies to target significant cost savings while maintaining performance and reliability objectives.
3. Continuity
Applications must continue operating when Spot Instances are interrupted. Continuity ensures that infrastructure events do not affect business operations, SLAs or customer experience.
Fault tolerance: Workloads should tolerate restarts, checkpointing or job resubmission without data loss or user impact. Stateless, containerised applications are particularly well suited to Spot.
Graceful interruption handling: Use AWS-recommended mechanisms such as AWS Node Termination Handler for Kubernetes or Karpenter’s native interruption controller to drain workloads before termination.
On-Demand fallback: Maintain On-Demand capacity as a guaranteed fallback when Spot is unavailable. Critical workloads should never depend entirely on Spot capacity.
Validation and testing: Run periodic AWS Fault Injection Simulator experiments to validate interruption handling and recovery procedures, including after major releases.
EC2 Spot Allocation Strategies
Capacity-Optimised: Launches instances from pools with stronger available capacity. This is generally the preferred strategy for production workloads.
Price-Capacity-Optimised: Balances cost and capacity depth by selecting pools that offer competitive pricing and good availability. It is useful for cost-sensitive production workloads.
Diversified: Distributes instances evenly across selected instance types. This can help legacy applications that require balanced instance distribution.
Lowest-Price: Selects the cheapest available pools without prioritising capacity depth. Use this only for non-critical workloads because interruption risk may be higher.
Service-Specific EC2 Spot Best Practices
Amazon EKS: Use EKS Managed Node Groups or Karpenter for dynamic Spot provisioning. Configure compatible instance types for cluster autoscaling and deploy AWS Node Termination Handler for graceful interruption handling. Amazon EKS Spot guidance
Amazon ECS: Use capacity providers with mixed On-Demand and Spot configuration. Apply diversified instance pools and configure managed scaling for dynamic capacity management. Amazon ECS capacity providers
Amazon EMR: Use On-Demand Master nodes, mixed Core nodes and Spot Task nodes. Enable managed scaling and decouple storage with Amazon S3 and EMRFS. Amazon EMR Spot guidance
AWS Batch: Define approved instance types, use a capacity-optimised allocation strategy and configure at least two job retry attempts to handle interruptions more transparently. AWS Batch Spot guidance
Amazon SageMaker: Use Spot Instances for training jobs with checkpointing so interrupted training can resume without losing completed work.
Common Mistakes to Avoid
Under-diversifying instances: Using only one or two instance types increases dependency on limited capacity pools. Use multiple types across processor families and generations.
Using the lowest-price strategy: This prioritises price without considering capacity depth, which may increase interruption risk. Capacity-optimised allocation is generally safer for production.
Ignoring interruption handling: Deployments without AWS Node Termination Handler or equivalent controls may experience abrupt workload failures instead of graceful draining.
No On-Demand fallback: Spot-only deployments have no guaranteed capacity when demand increases or capacity becomes constrained.
Running stateful applications directly on Spot: Persistent, session-dependent workloads can experience data loss if state is not stored externally in services such as Amazon RDS or Amazon ElastiCache.
Skipping interruption testing: Without testing, recovery failures may only become visible during a real production event.
Ignoring resource tagging: Inconsistent tagging makes cost attribution, chargeback and savings analysis difficult.
Best Practices for EC2 Spot in Production
Assess the workload: Determine whether the application is stateless, fault-tolerant and capable of handling interruptions without data loss or SLA breaches.
Design for diversity: Configure at least five diversified instance types across processor architectures, Availability Zones and, where appropriate, Regions.
Implement efficiency: Use Auto Scaling Groups, EC2 Fleet or Karpenter with capacity-optimised allocation to scale dynamically and reduce idle capacity. For ongoing operations, see Rapyder’s AWS Managed Services
Ensure continuity: Implement AWS Node Termination Handler for Kubernetes, graceful draining, Pod Disruption Budgets and On-Demand fallback nodes.
Test and validate: Use AWS Fault Injection Simulator to model interruptions, verify recovery behaviour and confirm that service-level objectives remain achievable.
Monitor and optimise: Track interruption rates, cost savings and performance metrics using CloudWatch dashboards and alerts. Review the data regularly and adjust instance pools, allocation strategies and fallback capacity. For cost governance, see Rapyder’s Cloud Cost Optimisation Services
Conclusion
Amazon EC2 Spot has evolved from a niche discount option into an important tool for cost-conscious, production-ready infrastructure.
By implementing diversity, efficiency and continuity patterns, organisations can pursue substantial savings while maintaining reliability and operational control. The key is not to treat Spot as an isolated pricing mechanism, but as part of a broader cloud architecture philosophy.
Design applications to be stateless and fault-tolerant. Provision infrastructure dynamically based on demand. Use interruption handling and fallback capacity. Treat interruptions as expected operating conditions rather than exceptional failures.
When these principles are followed, Spot can deliver not only lower infrastructure costs, but also more resilient, scalable and efficient systems.
Not sure where Spot fits in your architecture?
Rapyder's AI/cloud experts can map your workloads to a Spot-ready architecture, diversity, efficiency, and continuity built in from day one.
Get a free Spot readiness assessment
Associate DevOps Engineer, Rapyder Cloud Solutions
Frequently Asked Questions
The core Amazon EC2 Spot Instances best practices are diversity, efficiency and continuity. Diversify across at least five instance types, processor architectures and Availability Zones; scale dynamically with Auto Scaling Groups, EC2 Fleet or Karpenter; and implement graceful interruption handling, On-Demand fallback and regular interruption testing.
Spot Instances can offer discounts of up to 90% compared with On-Demand pricing, but AWS may reclaim them with a two-minute interruption notice. On-Demand Instances provide more predictable availability and are better suited to stateful, latency-sensitive or interruption-sensitive services.
AWS advertises discounts of up to 90% compared with On-Demand pricing. Organisations often target 70–90% savings for suitable workloads, but actual EC2 Spot cost savings percentage depends on the instance type, Region, workload pattern, allocation strategy and capacity conditions.
AWS provides a two-minute interruption notice before reclaiming Spot capacity. Production teams can use AWS Node Termination Handler for EKS, Karpenter interruption controls, checkpointing, job retries and graceful workload draining so traffic and processing can move safely before termination.
The Spot Placement Score API estimates the likelihood of obtaining Spot capacity for a selected instance configuration, Region and workload size. Teams can use the score before deployment to compare placement options and select locations or instance types with stronger capacity prospects.
Yes. Production-ready Spot deployments diversify across instance types and Availability Zones, use dynamic scaling, implement interruption handling and maintain On-Demand fallback capacity. Services such as Amazon EKS, ECS, EMR and AWS Batch can use Spot when the workload is designed for recovery and interruption tolerance.
Stateless containers, batch jobs, testing environments, distributed analytics, rendering workloads, data processing and machine-learning training are generally strong candidates. Workloads requiring uninterrupted single-instance operation should remain on On-Demand or use a blended-capacity architecture.
