Spot Instances & Interruption Handling

Market-Based Pricing:

• Spot prices are determined by supply and demand in each Spot pool
• Each pool = instance type + Availability Zone combination
• Prices fluctuate but changes are gradual (not auction-based since 2017)
• You pay the current Spot price, NOT a bid price

Price Characteristics:

• Typically 60-90% cheaper than On-Demand
• Prices vary by instance type, AZ, and time
• Larger instance types often have more stable pricing
• Newer instance families may have more capacity

How You're Charged:

• Pay the Spot price at the time of launch
• Price adjusts each hour to current Spot rate
• If Spot price exceeds your max price, instance is interrupted
• No charge for partial hours if AWS interrupts

Setting Maximum Price:

• You can set a maximum price (optional)
• Default max price = On-Demand price
• Instance runs while Spot price <= your max price
• Setting max price = On-Demand gives you best chance of keeping instances

Viewing Price History:

• Available through EC2 Console, CLI, or API
• Shows 90-day price history per instance type and AZ
• Helps identify stable vs volatile Spot pools
• Use to select instance types with consistent pricing

Price Stability Factors:

• Larger pools (popular instance types) tend to be more stable
• Older generations may have less demand
• Some AZs consistently have more capacity
• Time of day/week can affect prices (less on weekends)

Best Practice:

• Don't optimize purely for lowest price
• Prioritize capacity availability over price
• Use capacity-optimized allocation strategy
• Diversify across multiple instance types and AZs

What is Spot Fleet?

• Collection of Spot Instances (and optionally On-Demand)
• Request capacity by number of instances OR vCPUs/memory
• Automatically launches instances across multiple pools
• Maintains target capacity by replacing interrupted instances

Fleet Configuration:

• Define target capacity (instances, vCPUs, or custom weights)
• Specify multiple launch specifications (instance types, AZs)
• Choose allocation strategy
• Set On-Demand base capacity (optional)
• Configure instance weighting for heterogeneous fleets

Request Types: | Type | Behavior | |------|----------| | request | One-time request, no replacement of interrupted instances | | maintain | Maintains target capacity, replaces interrupted instances | | instant | Synchronous one-time request, returns results immediately |

On-Demand Base:

• Specify number of On-Demand instances as baseline
• Remaining capacity filled with Spot
• Ensures minimum guaranteed capacity
• Example: 2 On-Demand base + 8 Spot = 10 total, 2 guaranteed

lowestPrice (Not Recommended)

• Launches from pool with lowest Spot price
• Maximum cost savings but highest interruption risk
• All instances may be in one pool (no diversification)
• AWS recommends against this strategy

capacityOptimized (Recommended)

• Launches from pools with most available capacity
• Lowest interruption probability
• May not be the absolute cheapest
• Best for workloads sensitive to interruption

capacityOptimizedPrioritized

• Like capacityOptimized but respects your pool priority order
• You rank instance types by preference
• Fleet honors preferences while optimizing for capacity
• Best when you prefer specific instance types

diversified

• Distributes instances across all specified pools
• Balanced approach to cost and interruption risk
• Good for long-running workloads
• Limits impact if one pool is reclaimed

priceCapacityOptimized (Newest, Recommended)

• Considers both price AND capacity availability
• Identifies pools with high capacity and low price
• Best balance of cost savings and availability
• AWS's recommended strategy for most workloads

2-Minute Warning:

• AWS provides exactly 2 minutes notice before interruption
• Notice available via Instance Metadata Service
• Also sent as EventBridge (CloudWatch Events) event
• Time to gracefully shutdown, checkpoint, or drain connections

Checking Interruption Status:

# Check instance metadata for termination notice
curl http://169.254.169.254/latest/meta-data/spot/instance-action

# Response when interruption scheduled:
# {"action": "terminate", "time": "2024-01-15T12:34:56Z"}

Interruption Behaviors (configurable): | Behavior | Description | |----------|-------------| | terminate | Instance is terminated, EBS volumes deleted (default) | | stop | Instance is stopped, EBS root volume persisted | | hibernate | Instance is hibernated, memory saved to EBS |

Stop vs Hibernate:

• Stop: Faster resume, no memory state
• Hibernate: Preserves memory state, requires EBS-backed root volume
• Both require enabling in launch configuration
• Both allow instance to resume when capacity returns

Application-Level Handling:

1. Poll Instance Metadata: Check every 5 seconds for termination notice
2. Save State: Write checkpoints to S3, EFS, or database
3. Drain Connections: De-register from load balancer, complete in-flight requests
4. Signal Completion: Mark job progress for resumption

Infrastructure-Level Handling:

1. Use Spot Fleet: Automatic replacement of interrupted instances
2. EC2 Auto Scaling: Mixed instances policy replaces interrupted capacity
3. EventBridge Rules: Trigger Lambda on interruption for custom logic
4. Target Tracking: Maintain desired capacity automatically

Best Practices:

• Design stateless applications when possible
• Store state externally (S3, DynamoDB, EFS)
• Use checkpointing for long-running jobs
• Implement graceful shutdown handlers
• Test interruption handling regularly

Proactive Capacity Management:

• AWS sends rebalance recommendation BEFORE interruption
• Provides more lead time than 2-minute interruption notice
• Signal that instance MAY be interrupted soon
• Opportunity to gracefully migrate workload

How It Works:

1. AWS detects elevated interruption risk for your instance
2. Sends EC2 Instance Rebalance Recommendation event
3. You can proactively launch replacement capacity
4. Gracefully drain and terminate at-risk instance

Auto Scaling Integration:

• Enable Capacity Rebalancing in Auto Scaling group
• ASG launches replacement before terminating at-risk instance
• Ensures continuous capacity during rebalancing
• Reduces interruption impact

When to Use:

• Long-running workloads that need graceful transition
• Stateful applications that need migration time
• Workloads where 2 minutes is insufficient
• Cost-optimized with reduced interruption impact

Why Capacity Matters More Than Price:

• Interrupted instance = zero work done
• Lowest price pools often have lowest capacity
• Re-launching to same pool may fail
• Stable capacity = more completed work

capacityOptimized:

Priority: Available Capacity → Launch

• Ignores price entirely
• Chooses pool with most spare capacity
• Lowest interruption rate
• May pay more per hour

priceCapacityOptimized (Recommended):

Priority: High Capacity + Low Price → Launch

• Balances capacity and cost
• Identifies sweet spot of available + affordable
• Best overall value for most workloads
• Default recommendation for Spot Fleet

When to Use Each: | Use Case | Recommended Strategy | |----------|---------------------| | CI/CD pipelines | priceCapacityOptimized | | Big data processing | priceCapacityOptimized | | Containerized workloads | priceCapacityOptimized | | Rendering/Encoding | capacityOptimized | | Time-critical batch jobs | capacityOptimized | | Training ML models | capacityOptimized |

What Were Spot Blocks?:

• Spot Instances with defined duration (1-6 hours)
• Guaranteed no interruption during the block
• Higher price than regular Spot (but less than On-Demand)
• Launched with BlockDurationMinutes parameter

Current Status:

• DEPRECATED as of December 2022
• No longer available for new requests
• AWS recommends using On-Demand for uninterruptible workloads
• Or design for interruption with regular Spot

Exam Relevance:

• May appear in older exam questions
• Know that it existed but is now deprecated
• Current answer: Use On-Demand for guaranteed duration
• Or use Spot with proper interruption handling

Migration Path:

• Short jobs (< 6 hours): Regular Spot with checkpointing
• Guaranteed duration needed: On-Demand Instances
• Cost optimization: Spot with fallback to On-Demand