A timeout, a public-key denial, a local response, and an alarm are different evidence. Start there.
The fastest way to lose an hour in AWS is to change five things because one thing failed.
Open the security group. Edit the route table. Restart the instance. Download a new key. Add a broader rule. Refresh the browser. Then wait, hoping one of the changes made the problem disappear.
I understand the instinct. A timeout feels like the system is refusing to explain itself.
But the error is already evidence. The first job is not to fix it. The first job is to classify what kind of failure you actually have.
In a VPC and EC2 lab, two messages can look equally frustrating but send you in opposite directions.
An SSH timeout means the session did not complete. That points first toward the path: correct public address, Internet Gateway, subnet route-table association, security-group and network ACL rules, host availability, and the possibility that the instance is not reachable from where you are connecting.
Permission denied (publickey) means something different. The SSH service answered enough for authentication to begin. The first branch is now the chosen username, the private-key file, the EC2 key pair, and host authorization. It does not prove every network detail is perfect. It does prove that replacing a route table is a strange first move.
The same pattern appears when testing a web server.
curl -I local HTTP on an EC2 instance can show that Apache is responding locally. That is useful evidence about the process and local listener. It does not prove that a browser on the public internet can reach it. External reachability still depends on the public address, the route through the Internet Gateway, the subnet association, network controls, and the service being reachable on the right interface and port.
A CloudWatch alarm is another category. It tells you a metric crossed an evaluation condition. It does not explain root cause. A CPU alarm might be the beginning of an investigation, not the end of one.
I have started using a small habit before I touch a setting: write the observed symptom as a sentence that does not contain a fix.
"SSH times out."
"SSH reaches authentication but rejects the key."
"The service responds locally but not from the browser."
"The alarm entered ALARM state."
That sentence determines the first evidence layer.
For a timeout, trace the request path in order. Is the address the one you expect? Is the subnet associated with the intended route table? Does the route point to the intended next hop? Does the path have the public or private addressing it needs? Are the relevant policy layers allowing the protocol and return traffic? Is the host up?
For public-key denial, keep the network configuration still until you have checked the identity path. Confirm the selected key pair, the file permissions on the local key, the AMI-appropriate username, and the matching authorized key on the host if you have another safe access path.
For a local-only web response, test outward one layer at a time. Local service. Listener. Instance address. Route. Security group. Network ACL. External request. Each test should answer one question.
This is not only a cloud habit. It is a support habit, a systems habit, and a career habit. Good troubleshooting is visible reasoning under uncertainty. You are not trying to look fast by changing things. You are trying to preserve the signal long enough to learn what failed.
The smallest proven fix is usually better than the widest possible fix. If port 80 is the question, opening every port does not make you efficient. It makes the system harder to understand and less safe.
The goal is not to memorize an enormous decision tree. It is to let the failure choose the first branch.
Before you change an AWS setting, ask one quiet question: what does this exact symptom prove, and what does it leave open?
Try this in a sandbox
In a sandbox, deliberately compare three outcomes: an unreachable address, a rejected SSH key, and a local-only HTTP response. For each, write the first two checks you would make and one tempting change you would avoid.
Continue the sequence
Start by tracing one request or one security claim end to end. The goal is not to collect more AWS screens. It is to learn what each one can prove before you change the system.