An EC2 instance was working normally, but SSH access suddenly stopped. I'm trying to create a reliable troubleshooting decision tree rather than changing security groups at random. What order of checks do you typically follow, from verifying the instance itself through network configuration and the operating system?
3 Answers
Start with the instance status and health checks: confirm it is running and that both system and instance reachability checks are passing. If those look healthy, test the network path to the SSH port, then review the security group and network ACL rules. After that, check the route table and whether you’re connecting to the correct current public or private IP address. Only then move on to the operating system, including whether the SSH service is running and whether the host firewall is blocking the connection.
You don’t need SSH access to inspect or change most of the cloud-side settings. Use the management console or command-line tools to check instance health, security groups, network ACLs, routes, and IP assignments. If those are correct, try the recovery console or other out-of-band access options, and consider a restart only after checking for a broader infrastructure or configuration problem.
A TCP traceroute or another connection test to port 22 can quickly show whether the problem is before the instance or at the host itself. First verify that the machine is actually powered on and reachable at the expected address, then use the result to narrow the issue to routing, filtering, or the SSH service.
That’s what I was unsure about—I was mixing up cloud-side security group changes with troubleshooting the host firewall. The console and recovery options make sense when SSH itself is unavailable.