Telling System Failures from Instance Failures Before Auto-Recovery Doesn't Save You

Decision drivers

Whether the workload holds meaningful in-memory state that recovery would destroy
Whether monitoring distinguishes system-check vs. instance-check failures, not just "status check failed" generically
Whether the instance can be rebuilt cleanly from AMI + user-data
RTO tolerance for the manual-intervention path instance-check failures require
Storage type (EBS-backed vs. instance-store-backed/bare-metal) — determines whether automatic recovery applies at all, not just what survives it

EC2 runs two structurally different status checks. System status checks monitor the underlying AWS hardware/host; instance status checks monitor the instance's own OS, network config, and resource usage. Automatic recovery — EC2's built-in "fix it for me" mechanism — only responds to system status check failures, and (since April 2022) simplified automatic recovery is enabled by default on every supported instance type at launch — it's not something you opt into via a CloudWatch alarm. "Supported" is doing real work in that sentence, though: simplified automatic recovery isn't available at all for instance-store-backed or bare-metal instances — there's no mechanism to migrate physically-attached local storage to new hardware, so those instances have no automatic path back after a system-level failure, default-on or not.

Gated · a free account unlocks the full catalog

This page is part of the AWS track's gated content. Sign in — free — to keep reading. A free account unlocks the full catalog.