If you’ve rebooted an EC2 instance and suddenly can’t SSH or RDP into it, you’re not alone. I’ve seen this issue stop teams for hours because the root cause isn’t always obvious. You get a timeout or “no route to host” error, but the instance is running. In this post, I’ll walk through exactly what causes this and how to fix it.

The Problem

After rebooting an EC2 instance, SSH or RDP connections time out immediately. The instance appears to be running in the EC2 console, but you get these errors:

Error Type Description
SSH Timeout Connection timed out or Connection refused after rebooting
RDP Timeout Remote Desktop cannot connect
Network Error No route to host

This blocks access to your instance completely, and every second feels critical.

Why Does This Happen?

  • Security group inbound rule was removed — If someone modified the security group while the instance was running, the rule removal doesn’t disconnect existing sessions, but new connections are blocked after reboot because the session state is lost.
  • Elastic IP was disassociated — The instance may have lost its public IP during or after the reboot, so your connection string is pointing to a non-existent address.
  • Route table lost the default route — A misconfigured route table or a race condition during reboot can remove the 0.0.0.0/0 → Internet Gateway route, breaking outbound and inbound traffic.
  • OS-level firewall blocking traffic — iptables or ufw rules on the instance itself may have been incorrectly configured or triggered during the boot sequence, blocking port 22 or 3389.

The Fix

The key is to follow a systematic diagnostic approach using AWS CLI and the EC2 console. I’ll start with non-invasive checks, then move to deeper investigation.

# Check instance status checks (system and instance level)
aws ec2 describe-instance-status \
  --instance-ids i-0abc123def456ghij \
  --region us-east-1 \
  --query 'InstanceStatuses[0].[SystemStatus.Status,InstanceStatus.Status]' \
  --output text

If either status shows “impaired,” AWS is still running diagnostics or there’s a real issue. If both show “ok,” move to the next step.

# Retrieve the console output to see kernel logs and boot messages
aws ec2 get-console-output \
  --instance-id i-0abc123def456ghij \
  --region us-east-1 \
  --latest \
  --output text

Look for panic messages, failed service startup, or firewall rules being applied. Then verify the security group configuration:

# Check the security group inbound rules
aws ec2 describe-security-groups \
  --group-ids sg-0abc123def \
  --region us-east-1 \
  --query 'SecurityGroups[0].IpPermissions' \
  --output table

You should see an inbound rule for port 22 (SSH) or 3389 (RDP) from your IP or 0.0.0.0/0. If it’s missing, add it. Then check the route table:

# List routes in the VPC route table
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc123def" \
  --region us-east-1 \
  --query 'RouteTables[0].Routes' \
  --output table

There should be a route for 0.0.0.0/0 pointing to an igw-* (Internet Gateway). If missing, add it. Finally, check if the instance still has a public IP:

# Verify the instance has a public IP or associated Elastic IP
aws ec2 describe-instances \
  --instance-ids i-0abc123def456ghij \
  --region us-east-1 \
  --query 'Reservations[0].Instances[0].[PublicIpAddress,ElasticIpAddress]' \
  --output text

If both are empty or None, re-associate the Elastic IP if you had one, or the instance is in a private subnet.

How to Run This

  1. Open the EC2 Dashboard and note your instance ID (looks like i-0abc123def456ghij) and its security group ID (sg-*).
  2. Run the describe-instance-status command above to check system health — if status is “impaired,” wait 2–3 minutes for AWS diagnostics to complete.
  3. Run get-console-output to inspect boot logs for any firewall or service errors. Search for “error” or “failed” in the output.
  4. Check Security Groups in the EC2 console → select the group → verify inbound rule for SSH (port 22) or RDP (port 3389) from your IP.
  5. Check Route Tables → select the route table associated with your instance’s subnet → verify a default route (0.0.0.0/0) points to your Internet Gateway.
  6. If public IP is missing, go to Elastic IPs → allocate new one or reassociate the previous one to your instance.

Is This Safe?

All diagnostic commands above are read-only and won’t affect your instance. Re-adding security group rules or routes is safe and non-disruptive. Stop+Start (if needed) causes a brief outage and may change your public IP if you don’t use an Elastic IP.

Key Takeaway

A post-reboot connectivity loss is almost always caused by a missing security group rule, lost public IP, or misconfigured route table. Use the AWS CLI diagnostics to pinpoint the exact cause, then make targeted fixes. Always use Elastic IPs for instances that need stable public addresses.

Have questions or ran into a different EC2 connectivity issue? Connect with me on LinkedIn or X.