AWS EC2 Reachability Fail after Security Group Change

Quick Fix (30 seconds) — Check Your Inbound Rules

The moment you see a reachability check failure after editing a security group, the culprit is almost always a missing inbound rule. You probably removed SSH (port 22) or HTTP/HTTPS (80/443) by accident.

1. Open the AWS Console and go to EC2 → Security Groups.
2. Select the security group attached to your instance.
3. Look at the Inbound rules tab. Do you see a rule for SSH (port 22) with source 0.0.0.0/0 or your IP? If not, you found the problem.
4. Click Edit inbound rules → Add rule → Type: SSH, Source: 0.0.0.0/0 (or better, your specific IP). Click Save.

Wait 10 seconds. Hit refresh on the reachability check. 9 times out of 10, it turns green. Done.

Moderate Fix (5 minutes) — Network ACLs and Route Tables

Okay, you added the inbound rule and it still fails. The security group isn't the problem. Let's check the network ACL and route table.

Network ACL (NACL)

NACLs are stateless — they need both inbound AND outbound rules to allow traffic. If you changed the NACL recently, you might have blocked the return traffic.

1. Go to VPC → Network ACLs.
2. Find the NACL associated with your EC2's subnet.
3. Check both Inbound rules and Outbound rules. For a basic setup, you need:
   • Inbound: Allow ALL traffic from 0.0.0.0/0 (or at least port 22/80/443).
   • Outbound: Allow ALL traffic to 0.0.0.0/0 (ephemeral ports included).
4. If you see a DENY rule blocking port 22 or ephemeral ports (1024-65535), remove it or add an ALLOW rule above it.

Route Table

Your subnet needs a route to an Internet Gateway. This one's rare if the instance worked before, but check it anyway.

1. Go to VPC → Route Tables.
2. Find the route table for your subnet.
3. Look for a route with destination 0.0.0.0/0 and target igw-xxxxxxxx. If it's missing, add it.

After fixing the NACL or route table, test the reachability check again.

Advanced Fix (15+ minutes) — OS-Level Firewall and Instance Actions

Still down? Then the issue isn't AWS networking — it's on the instance itself. Either the OS firewall blocked SSH, or the instance crashed.

Step 1: Check Instance System Logs

You can peek at what the OS did at boot. In the EC2 console, right-click your instance → Monitor and troubleshoot → Get system log. Look for lines like:

iptables: applying firewall rules...
FAILED: sshd not starting

If you see firewall rules being applied, that's your issue. If you see kernel panics or disk errors, you've got bigger problems.

Step 2: Revert the Security Group Change via AWS CLI

If you don't remember what you changed, roll back to the last known good security group. You need the CLI installed and configured.

# List security groups
echo "Checking current SG attached to instance i-12345678"
aws ec2 describe-instances --instance-ids i-12345678 --query 'Reservations[0].Instances[0].SecurityGroups'

# Replace with a known-good SG ID
aws ec2 modify-instance-attribute --instance-id i-12345678 --groups sg-0abcdef1234567890

This replaces all SGs on the instance. Wait 30 seconds, then test reachability.

Step 3: OS Firewall (if you can't SSH)

If the security group is correct but SSH still times out, the OS firewall (iptables, firewalld, ufw) is blocking you. But you can't SSH to fix it. So you need EC2 Instance Connect or a serial console.

• EC2 Instance Connect: Available for Amazon Linux 2, Ubuntu 20.04+, and others. In the console, select instance → Connect → EC2 Instance Connect. If it works, run:

# For iptables users
sudo iptables -L -n
sudo iptables -F  # Be careful, this flushes all rules

# For firewalld
sudo systemctl stop firewalld
sudo systemctl disable firewalld

# For ufw (Ubuntu)
sudo ufw disable

• Serial Console: If Instance Connect fails, enable serial console access in the instance settings. Then connect via AWS Console → Serial Console. It's a text console — you can log in and fix the firewall.

Step 4: Reboot or Stop/Start

If nothing works, do a hard stop and start (not a reboot — that keeps the same hypervisor). EC2 stop/start moves the instance to a new host. This can clear weird network state.

aws ec2 stop-instances --instance-ids i-12345678
# Wait for stop
aws ec2 start-instances --instance-ids i-12345678

After it starts, check reachability one more time.

When to Give Up and Rebuild

If you've done all four steps and the instance is still unreachable, it's probably hosed. Maybe the OS crashed during boot, or the disk is corrupted. Snapshot the EBS volume, launch a new instance, attach the volume, and recover your data. You'll save more time than debugging a dead system.

One last thing: don't bother with AWS support unless you're on a paid plan. They'll walk you through the same steps. Been there, done that.