An AWS connection timeout usually means that the connection request is not reaching the destination or the response is not getting back. The best approach is to troubleshoot the network path step by step instead of immediately changing multiple settings.
Start With the Basics
First confirm that the target resource is actually running and healthy.
For an EC2 instance, check:
- Instance state
- System and instance status checks
- Private and public IP addresses
- Correct DNS name or IP address
- Whether the application is listening on the expected port
For example, if an application should be listening on port 8080, verify it from the server:
sudo ss -lntp | grep 8080
You can also test connectivity from another host:
nc -vz <destination-ip> 8080
Check Security Groups
Security groups are one of the first places I check.
Make sure the destination security group allows the required inbound port from the correct source. Also verify outbound rules when the traffic pattern requires them.
For example, an application listening on TCP 443 should have an appropriate inbound HTTPS rule.
Avoid opening ports to 0.0.0.0/0 just for troubleshooting and leaving them that way. Narrow the source CIDR as much as possible.
Check Network ACLs
Network ACLs operate at the subnet level and are stateless, so both inbound and outbound traffic need to be considered.
A restrictive NACL can cause timeouts even when the security group looks correct. Check whether the required application port and return traffic are permitted.
AWS specifically recommends checking security groups, NACLs, and routing when troubleshooting EC2 connection timeouts.
Check the Route Table
Next, verify the route associated with the subnet.
For a publicly accessible EC2 instance, you generally need the appropriate route toward an Internet Gateway, along with a usable public IPv4 or Elastic IP.
For private workloads, check routes through components such as:
- NAT Gateway
- Transit Gateway
- VPC Peering
- VPN
- Network Firewall
- Other network appliances
A missing or incorrect route can prevent packets from reaching the destination or returning successfully.
Check the Application and OS Firewall
Sometimes AWS networking is completely correct, but the operating system is blocking the connection.
On Linux, check services such as:
sudo systemctl status firewalld
sudo iptables -L -n
Also verify that the application is bound to the expected interface. An application listening only on 127.0.0.1 won't normally accept connections coming from other hosts.
Use VPC Reachability Analyzer
For complicated VPC problems, VPC Reachability Analyzer is one of the most useful tools.
It analyzes the configured network path between a source and destination and can identify blocking components such as security groups, NACLs, route tables, and other network resources.
For example, you can analyze:
Internet Gateway
↓
EC2 Instance
↓
TCP 443
If AWS reports that the path is unreachable, the analysis can help identify where the configured path is being blocked.
One important point: Reachability Analyzer is a configuration analysis tool; it doesn't send actual network packets.
Check VPC Flow Logs
If the problem is still unclear, enable or inspect VPC Flow Logs.
Look for ACCEPT and REJECT records associated with the source, destination, and relevant port. This can help determine whether traffic is reaching the network interface and whether AWS network controls are rejecting it.
For deeper troubleshooting, packet capture can also help:
sudo tcpdump -i any host <destination-ip> and port <port>
This is particularly useful when you need to determine whether packets are leaving or arriving at the instance.
A Practical Troubleshooting Order
My usual troubleshooting sequence is:
Client → DNS → IP → Application port → EC2 status → Security Group → NACL → Route Table → NAT/IGW/TGW/VPN → OS firewall → Application → Flow Logs → Reachability Analyzer
The key is to test one layer at a time. Changing security groups, routes, and firewall rules simultaneously can make troubleshooting much harder.
Final Thoughts
A connection timeout is usually a network-path problem, but the root cause can exist at several layers.
The most common areas to investigate are:
Security Group → NACL → Route Table → Network Gateway/Appliance → OS Firewall → Application
For production environments, I would also avoid relying only on manual testing. VPC Flow Logs, Reachability Analyzer, CloudWatch metrics, and proper monitoring can make these incidents much easier to diagnose and prevent.