How does the EC2 two-minute Spot Instance interruption work?

The Amazon EC2 two-minute Spot Instance interruption notice is an automated warning issued when AWS needs to reclaim spare compute capacity. This mechanism provides applications with exactly 120 seconds before an instance is terminated, stopped, or hibernated. Organizations detect this signal by either polling the local instance metadata service or listening for events through Amazon EventBridge. This brief window enables automated workflows to save state, drain active network connections, upload final log files, and safely detach from load balancers before the underlying virtual machine shuts down.

Why Amazon EC2 Interrupts Spot Instances

Spot Instances run on unused EC2 capacity offered at a steep discount compared to On-Demand pricing. Because this pool of spare compute fluctuates continuously, Amazon EC2 reserves the right to reclaim those resources at any time. Interruptions primarily occur for the following reasons:

  • Capacity requirements: Demand for On-Demand or Reserved Instances increases in a specific Availability Zone, requiring EC2 to pull hardware back from the Spot pool.
  • Price fluctuations: If you set a maximum price for your Spot request and the current Spot market price rises above that threshold, your instance is marked for interruption.
  • Constraint fulfillment: If your Spot request includes specific availability or launch group constraints that can no longer be satisfied, EC2 initiates an interruption.

When an interruption is triggered, AWS determines the final action based on your configuration: terminating the instance (the default behavior), stopping the instance on Amazon EBS, or hibernating the instance memory state to disk. For stop and terminate actions, the two-minute countdown begins immediately. Note that if you configure hibernation as the interruption behavior, the instance begins hibernating immediately upon receiving the notice without waiting for the two-minute window to expire.

Detecting the Interruption Notice via Instance Metadata

The most direct way for a running workload to detect its own impending shutdown is by querying the EC2 Instance Metadata Service (IMDS) from inside the guest operating system. When EC2 marks an instance for reclamation, it publishes an instance-action item to the metadata endpoint at the local link-local address 169.254.169.254.

Because the metadata service does not push notifications to the operating system, a local daemon or script must poll the endpoint every 5 seconds. When no interruption is pending, the endpoint returns an HTTP 404 Not Found status code. Once an interruption is scheduled, it returns an HTTP 200 OK along with a JSON payload containing the scheduled action and the exact UTC timestamp when the shutdown will occur.

Using IMDSv2 (which requires a session token for security), a monitoring script checks the endpoint as follows:

#!/bin/bash
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s)
 HTTP_CODE=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s -w "%{http_code}" -o /tmp/spot-action.json http://169.254.169.254/latest/meta-data/spot/instance-action)

if [ "$HTTP_CODE" -eq 200 ]; then
    cat /tmp/spot-action.json
    # Trigger local graceful shutdown scripts here
fi

When an interruption is active, the output stored in /tmp/spot-action.json looks like this:

{
  "action": "terminate",
  "time": "2026-11-15T11:00:00Z"
}

Detecting the Notice via Amazon EventBridge

Instead of polling from within every individual virtual machine, you can monitor Spot interruptions centrally using Amazon EventBridge. When EC2 prepares to reclaim a Spot Instance, it emits an event to the default EventBridge event bus two minutes prior to the interruption action.

This event-driven approach allows external orchestration services to react without relying on agents inside the instance. You can configure an EventBridge rule matching the following pattern to trigger AWS Lambda functions, Amazon SNS notifications, or AWS Systems Manager Run Command documents:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Spot Instance Interruption Warning"]
}

The generated event payload identifies the exact instance-id and instance-action:

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "EC2 Spot Instance Interruption Warning",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2026-11-15T10:58:00Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:ec2:us-east-1b:instance/i-0abcdef1234567890"
  ],
  "detail": {
    "instance-id": "i-0abcdef1234567890",
    "instance-action": "terminate"
  }
}

Automated Handling for Containers and Auto Scaling Groups

When running workloads on orchestration platforms, specialized AWS tools manage the two-minute notice automatically so you do not have to write custom polling scripts:

  • Amazon EKS: The open-source AWS Node Termination Handler runs as a DaemonSet on each Spot node. It polls IMDS, detects the two-minute warning, cordons the Kubernetes node to prevent new pods from scheduling, and drains existing pods so they can relocate to healthy nodes. Alternatively, Karpenter handles Spot interruption events natively via EventBridge queues, provisioning replacement capacity and draining nodes automatically.
  • Amazon ECS: By setting the ECS_ENABLE_SPOT_INSTANCE_DRAINING parameter to true in the ECS container agent configuration (/etc/ecs/ecs.config), the agent monitors IMDS automatically. Upon receiving the two-minute warning, the agent sets the instance state to DRAINING, stops placing new tasks on the host, and sends SIGTERM signals to running containers.
  • EC2 Auto Scaling and Elastic Load Balancing: If a Spot Instance is registered to an Application Load Balancer or Network Load Balancer through an Auto Scaling group, configuring a deregistration delay (connection draining) shorter than 120 seconds (such as 60 to 90 seconds) ensures in-flight requests complete cleanly when detachment is triggered.

Designing Workloads for the 120-Second Window

To prevent data corruption or dropped requests, your shutdown procedures must complete well within the allotted window. If an instance is detected at \(t_{\text{detect}}\) and scheduled for reclamation at \(t_{\text{action}}\), the effective time remaining \(\Delta t\) is governed by your polling interval \(I_{\text{poll}}\) and network latency \(L_{\text{net}}\):

\[\Delta t = (t_{\text{action}} - t_{\text{detect}}) - I_{\text{poll}} - L_{\text{net}} \le 120\text{ seconds}\]

To ensure reliable recovery, engineering teams follow three primary practices during this window:

  1. Fail health checks immediately: Have your local shutdown script immediately return an unhealthy status code on your application's load balancer health check endpoint. This stops new traffic from routing to the instance within seconds.
  2. Enforce strict process timeouts: Configure your service manager (systemd or container runtime) to send a SIGTERM signal to application processes immediately, followed by a SIGKILL well before the 120 seconds expire (for example, at 90 seconds), leaving 30 seconds for flushing logs or final metrics to Amazon S3 or CloudWatch.
  3. Combine with EC2 Capacity Rebalancing: In addition to the two-minute interruption notice, AWS offers an early warning signal called the EC2 Instance Rebalance Recommendation. This signal fires when a Spot Instance is at an elevated risk of interruption—often several minutes before the mandatory two-minute countdown begins—allowing Auto Scaling groups and Kubernetes cluster autoscalers to proactively launch replacement instances before capacity is actually reclaimed.

Testing Your Interruption Handling with AWS Fault Injection Service

Waiting for a natural Spot interruption in production is an unreliable way to verify your shutdown scripts. You can deterministically test your two-minute interruption handling using AWS Fault Injection Service (FIS).

By running the aws:ec2:send-spot-instance-interruptions action in an FIS experiment against a target Spot Instance, AWS triggers a genuine interruption sequence. Both the IMDS spot/instance-action endpoint and Amazon EventBridge receive the exact two-minute warning, allowing you to validate that your application drains connections, saves checkpoints, and terminates gracefully before the two minutes elapse.