Spot Instances, EC2 Fleet and Auto Scaling groups

A Spot Instance is spare EC2 capacity sold at a discount of up to about 90% against On-Demand. AWS can reclaim it at any time with a two-minute interruption notice. There is no auction: you request capacity, optionally cap the price you will pay, and pay the prevailing Spot price for the pool you land in.

Running a single Spot Instance is rarely what you want. A single instance is one interruption away from nothing, and a single instance type in a single Availability Zone is a single capacity pool. Anything real runs a fleet across several pools. The question is which mechanism manages that fleet.

Spot Fleet is legacy

Spot Fleet was the original fleet API and it is no longer the answer. AWS’s own guidance is blunt:

We strongly discourage using Spot Fleet because it uses a legacy API with no planned investment. If you want to manage your instance lifecycle, rather use EC2 Fleet. If you don’t want to manage your instance lifecycle, rather use an Auto Scaling group.

The one remaining reason to touch it is that Spot Fleet has console support and EC2 Fleet does not. If you are writing infrastructure as code — which you should be — that reason evaporates.

Auto Scaling groups: the default

An Auto Scaling group with a mixed instances policy is the recommended way to run a fleet of Spot and On-Demand capacity. It gives you everything the fleet APIs give you, plus:

• Automatic health-check replacement for both Spot and On-Demand instances
• Application-level health checks, not just EC2 status checks
• Elastic Load Balancing integration, so traffic is distributed only to healthy instances
• Lifecycle hooks, warm pools, instance refresh and scaling policies
• The integration point that Amazon ECS, self-managed Amazon EKS node groups and VPC Lattice all expect

A typical mixed instances policy names a launch template, a list of five to ten instance types with compatible resource profiles, subnets in three Availability Zones, an On-Demand base capacity to guarantee a floor, and a percentage split above that base. See Auto Scaling groups.

EC2 Fleet: when you manage the lifecycle yourself

EC2 Fleet is the current fleet API and offers the same core capability as Spot Fleet — one request that launches On-Demand and Spot capacity across multiple launch specifications varying by instance type, AMI, Availability Zone or subnet — without the legacy baggage. It is available from the CLI, SDKs and CloudFormation only.

Use it when you want to own the instance lifecycle rather than delegate it: a scheduler that places and reaps its own capacity, or a one-shot burst of workers. If you do not need scaling behaviour, an instant type EC2 Fleet launches the capacity in a single synchronous call and hands you the instance IDs.

Allocation strategy

Whichever mechanism you use, the allocation strategy decides which capacity pools it draws from, and it matters more than the instance types you list.

• price-capacity-optimized is the recommended default. It weighs both how deep a pool is and how cheap it is, which minimises interruptions without ignoring price.
• capacity-optimized picks the deepest pools regardless of price. Choose it when an interruption is much more expensive than the instance.
• lowest-price picks the cheapest pools and interrupts most. EC2 Fleet still defaults to it; change it.

Diversification is what makes any of these work. Listing one instance type gives the strategy nothing to choose between. Listing several families, several sizes and three Availability Zones gives it a dozen or more pools to route around.

Handling interruptions

Whatever manages the fleet, the workload still has to survive being stopped mid-sentence:

• Watch for the two-minute interruption notice in instance metadata (/latest/meta-data/spot/instance-action) or on the EventBridge EC2 Spot Instance Interruption Warning event.
• Drain connections, deregister from the target group and checkpoint work in that window.
• Keep an On-Demand base capacity under anything that serves users, so a Spot capacity crunch degrades the service rather than deleting it.