Fix AWS EC2 Reachability Check Failed in 3 Steps

Quick Answer for Advanced Users

If you're in a hurry: stop the instance (don't terminate), detach the root volume, attach it to a healthy EC2 in the same AZ, fix the networking config (check /etc/sysconfig/network-scripts/ifcfg-eth0 on Amazon Linux 2 or /etc/netplan/ on Ubuntu 20.04+), re-attach the volume, and start the instance. That's the nuclear option. But most of the time, you don't need it.

Why This Happens

I've seen this error hundreds of times. The instance passes the system status check (1/2) but fails the instance status check (2/2). That means AWS thinks the instance is running, but it can't talk to it over the network. The culprits are almost always the same:

Security group rules—you locked yourself out by accident. Happens to everyone.
Network ACLs—a blocking inbound or outbound rule.
OS-level firewall—like iptables or firewalld, which you might have enabled via a user-data script that backfired.
Misconfigured route tables—missing or incorrect default route to an internet gateway (for public instances) or a NAT gateway (for private ones).

The worst part? AWS doesn't tell you which one. You have to check each layer. I'll walk you through it.

Step-by-Step Fix: The Usual Suspects

Step 1: Check the Security Group

This is where 90% of failures live. Open the EC2 console, select your instance, and look at the Security tab. Check inbound rules:

For SSH (port 22) or RDP (port 3389)—whichever you use—make sure the source is 0.0.0.0/0 (for testing only) or your IP. If you're inside a VPC, also check the outbound rules—they need to allow returning traffic (ephemeral ports 1024-65535).

If you see nothing or a wrong IP, edit the security group. Add a rule for SSH from 0.0.0.0/0 temporarily. If the status check clears, you found the problem. Then lock it down to your IP.

Step 2: Check Network ACLs

Security groups are stateless—no, wait, they're stateful. Network ACLs are stateless. That's the tricky bit. ACLs evaluate inbound and outbound separately. A missing outbound rule for ephemeral ports will kill connectivity.

Go to the VPC dashboard, find the subnet your instance is in, and check the associated ACL. Inbound should allow SSH (22) from 0.0.0.0/0 or your IP. Outbound should allow ephemeral ports (1024-65535) to 0.0.0.0/0. If you changed the default ACL, you probably broke it.

Step 3: Check the Route Table

This one's less common but nasty. If your instance is in a public subnet, it needs a route to an internet gateway (IGW). Look at the route table for the subnet:

Destination: 0.0.0.0/0, Target: igw-xxxxxxxx

If that's missing, add it. For private instances, the target should be a NAT gateway in a public subnet.

Alternative Fixes If the Above Doesn't Work

Option A: Reboot the Instance

I know it sounds silly, but I've seen reboots fix transient OS-level network hangs. Try it from the EC2 console—not a hard stop, just a reboot. Wait 5 minutes and check the status checks again.

Option B: Stop and Start (Not Reboot, Not Terminate)

This moves the instance to new underlying hardware. It changes the public IP unless you have an Elastic IP. If you're using an auto-scaling group, be careful—this might trigger a replacement. But it often clears the reachability check if the host hypervisor was the issue.

Option C: Use EC2 Serial Console (If Enabled)

For instances running Nitro systems (most newer ones), you can use the EC2 Serial Console to access the OS via terminal—no network needed. In the EC2 console, click your instance, then Actions > Monitor and troubleshoot > Get system log. Or enable serial console in the instance settings. It's a lifesaver when the network is completely dead.

Option D: Rescue via Volume Detach

If nothing works, you'll need to detach the root volume, attach it to a healthy instance, and fix the OS configuration. On Linux, check /etc/hosts.deny, /etc/firewalld/, and /etc/sysconfig/iptables. On Windows, check C:\Windows\System32\drivers\etc\hosts and firewall rules via the registry. It's tedious but reliable.

Prevention Tip

Stop locking yourself out. Before you modify security groups or ACLs, take a snapshot of the instance (or just the root volume). If you're using IaC like Terraform or CloudFormation, always apply changes with a prevent_destroy lifecycle rule on the security group—or at least test in a staging environment. Also, consider using SSH session manager (AWS Systems Manager) instead of direct SSH. It doesn't depend on security group rules at all—it works over the AWS API. Once you set that up, you'll never have this problem again.

I've been there. It's frustrating. But 9 times out of 10, it's a security group rule you changed last week and forgot about. Start there, and you'll be back up in 10 minutes.