Fix AWS EC2 Status Check Failed: 1 of 2 Checks Failed

Quick answer

Stop the instance, detach its root volume, attach it to a temporary instance, fix the OS-level issue (like a broken network service or bad fstab), reattach, and start. If that's too heavy, start with the system log and a simple reboot.

What's actually happening here

When AWS says "1 of 2 checks failed", the system status check (hardware and hypervisor) passed, but the instance status check failed. That check is AWS's way of pinging your instance from the hypervisor side — it verifies that the OS is responding to network requests. If it fails, your instance might be running, but it's not reachable. The cause is almost never AWS's fault. It's your OS, your network config, or your driver. Think of it like a server that's powered on but has a dead network cable — the hardware is fine, the OS just can't talk.

The most common triggers: a kernel update that broke the ena driver, a change to sshd that blocks inbound, a full disk that prevents services from starting, or a misconfigured firewall (like iptables) that drops all traffic. You'll also see this after a crash or unclean shutdown where the OS fails to bring up interfaces.

Fix steps (in order)

1. Check the system log. In the EC2 console, select your instance, click Actions → Monitor and troubleshoot → Get system log. Look for network errors, kernel panics, or service failures. This is your first diagnostic — don't skip it. If the log shows a kernel panic or a hung task, you know it's OS-level.
2. Reboot the instance. Simple, but often works. A reboot reinitializes the network stack. If the check clears after reboot, you're done. But if it fails again, you've got a persistent issue.
3. Try the EC2 serial console (if enabled). For Nitro-based instances, you can connect to the serial console directly. Go to Actions → Monitor and troubleshoot → EC2 Serial Console. You'll get a login prompt. Log in and check systemctl status networking or ip addr to see if the interface is up. This saves you the detach/attach dance.
4. Stop and start the instance. Note: Stop is different from Reboot. A stop causes a true shutdown and starts the instance on a new host. This clears transient hypervisor issues. If the problem is a stuck network driver, this often fixes it.
5. Resize the root volume (temporary fix for full disk). If the system log shows No space left on device, you can temporarily increase the root volume size in the console (select the volume, Modify Volume), then start the instance. Once it's up, clean up and shrink if you want.
6. Offline repair (the definitive fix). If steps 1–5 fail, you need to fix the OS from the outside:
   
   • Stop the instance.
   • Detach its root volume (Volumes → select volume → Actions → Detach).
   • Launch a temporary instance (any Linux distro, same availability zone).
   • Attach the original volume as a secondary device (e.g., /dev/sdf).
   • SSH into the temp instance, mount the volume, and chroot into it.
   • Check /etc/fstab — a bad entry here hangs boot. Comment it out.
   • Check network service: for Ubuntu, systemctl enable --now systemd-networkd; for Amazon Linux 2, ensure network is enabled.
   • If you recently updated the kernel, reinstall the ena driver (or ixgbevf for older instances).
   • Unmount, detach, reattach to the original instance, and start.

If the main fix doesn't work

Sometimes the issue is a bad AWS-side dependency. Try these:

• Check security groups and NACLs. If you changed a security group to block your own IP, you'd get exactly this error. Remove any restrictive inbound rules temporarily.
• Verify the instance has a public IP. If you stopped and started, the public IP may have changed. You might be trying to connect to an old IP.
• Use VPC flow logs. If you have them enabled, they'll show whether traffic is reaching the instance. If packets are dropped, it's a security group or NACL issue.
• Create an AMI and launch a new instance. Sometimes the OS is so corrupted that fixing it takes longer than replacing it. Create an image from the instance, launch a new one from that image, and test.

Prevention tips

• Always test kernel or driver updates on a staging instance first. The ena driver is notorious for breaking after a kernel upgrade.
• Set up CloudWatch alarms on status checks so you get notified before users do.
• Enable the EC2 serial console ahead of time — you can't turn it on when the instance is already down.
• Keep your root volume with at least 20% free space. A full disk will cause services to fail silently.
• Use a configuration management tool (like Ansible) to enforce network config, so a manual edit doesn't break it.

That's the whole picture. Start with the log, then work your way down the list. Most of the time, a reboot or a stop/start clears it. The offline repair is the nuclear option, but it's also the one that guarantees you'll find the root cause.