A VPC can look perfectly healthy while an application inside it remains unreachable. The EC2 instance may be running, the required port may appear open, and the route table may contain what looks like the correct route. Yet the connection still fails.
The challenge is that AWS networking is built from multiple independent components. A failure in any one of them can produce a similar symptom at the application level.
A layer-by-layer investigation helps narrow the problem without making unnecessary configuration changes. Instead of changing several settings at once, examine the connection from the application outward and verify each part of the path.
1. Define the Connection First
Before troubleshooting, describe exactly what is failing.
For example:
Source: EC2 application server
Destination: EC2 database server
Protocol: TCP
Port: 5432
Expected result: TCP connection succeeds
Observed result: Connection timeout
This information establishes the scope of the investigation.
A timeout, connection refusal, and DNS failure are not interchangeable symptoms.
For example, a connection refusal generally means the destination was reachable but the port was not accepting the connection. A timeout can indicate filtering, routing problems, or a destination that cannot be reached.
Start with the exact failure rather than treating the entire VPC as the problem.
2. Application Layer: Is the Service Listening?
The first layer is the application itself.
On a Linux EC2 instance, check listening sockets:
ss -lntp
If the application should listen on port 8080:
ss -lntp | grep ‘:8080’
You can also test the service locally:
curl http://127.0.0.1:8080
If the service fails locally, there is little value in modifying Security Groups or route tables.
Check the application’s configuration, logs, and startup status first.
This separates an application failure from an actual network failure.
3. Host Layer: Check Linux Networking
If the application works locally, inspect the operating system’s network configuration.
Run:
ip addr
ip route
Confirm the expected private IP address is assigned to the interface.
Then inspect the local firewall:
nft list ruleset
On systems still using iptables:
iptables -L -n -v
A packet can successfully reach the EC2 network interface and still be rejected by a host-level firewall.
Also check whether the application is listening only on 127.0.0.1 instead of the instance’s private address.
For example:
127.0.0.1:8080
is not equivalent to:
0.0.0.0:8080
The first accepts local connections only, while the second can accept connections through the host’s network interfaces, subject to other controls.
4. Network Interface and Subnet Layer
Next, identify the EC2 instance’s network interface.
Record:
VPC ID
Subnet ID
Network Interface ID
Private IP
Security Groups
Then identify the subnet containing the destination.
This matters because route tables are associated with subnets, while Security Groups are associated with network interfaces.
Do not assume that two instances with similar names necessarily use the same networking configuration.
An instance can also have multiple network interfaces, making it important to identify the interface carrying the affected traffic.
5. Routing Layer
Routing is one of the most common places where VPC connectivity breaks.
Inspect the route table associated with the source subnet.
For communication within a VPC, a route similar to this is normally present:
Destination: 10.0.0.0/16
Target: local
For internet-bound traffic from a public subnet:
0.0.0.0/0 → Internet Gateway
For outbound internet access from a private subnet:
0.0.0.0/0 → NAT Gateway
For connectivity to another VPC, the target could be a VPC peering connection or Transit Gateway.
The important point is to verify the actual route table associated with the subnet, not simply a route table that appears correct in the AWS console.
A correct route in the wrong route table has no effect on the affected instance.
6. Gateway and Connectivity Layer
If traffic leaves the VPC, determine which AWS networking component should handle it.
For a public EC2 instance, the path may be:
EC2
↓
Route Table
↓
Internet Gateway
↓
Internet
For a private instance:
EC2
↓
Private Route Table
↓
NAT Gateway
↓
Public Subnet
↓
Internet Gateway
↓
Internet
If the destination is another VPC:
VPC A
↓
Peering / Transit Gateway
↓
VPC B
Verify that the required attachment or gateway exists and that the route points to it.
A common troubleshooting mistake is checking only the first route. The complete path must be valid.
7. Security Group Layer
Once routing has been confirmed, inspect the Security Groups.
Security Groups are stateful and use allow rules.
Suppose a database listens on TCP 5432. Its Security Group must permit the expected source.
A narrow rule might be:
Protocol: TCP
Port: 5432
Source: Application Server Security Group
Avoid opening the port broadly simply as a troubleshooting shortcut.
Check both sides of the connection where relevant. Also make sure the rule is attached to the network interface actually receiving the traffic.
A common error is modifying one Security Group while the instance is using another.
8. Network ACL Layer
Network ACLs operate at the subnet level.
Unlike Security Groups, they are stateless and support both allow and deny rules.
This means return traffic must also be permitted.
For example, an outbound TCP connection can leave the subnet successfully while its response is blocked by an inbound NACL rule.
NACL rules are evaluated in numerical order, so an earlier matching deny rule can prevent a later allow rule from being reached.
When troubleshooting a NACL, examine:
Inbound rules
Outbound rules
Rule numbers
Source/destination ranges
Protocol
Port ranges
Do not inspect only the direction in which the connection begins.
9. DNS Layer
Some VPC connectivity failures are actually name-resolution problems.
From the EC2 instance:
dig database. example.internal
or:
nslookup database. example.internal
Confirm that the returned address is the one the application should use.
Also consider IPv4 versus IPv6. If an application prefers IPv6 but the corresponding network path is unavailable, connectivity may fail even though IPv4 works.
Testing the resolved IP directly can help separate DNS problems from network problems.
10. Use AWS Diagnostic Tools
When the configuration is complicated, AWS provides additional visibility.
VPC Flow Logs can help determine whether traffic is being accepted or rejected at the VPC networking level.
Reachability Analyzer can help analyze the configured network path between supported AWS resources and identify configuration components that prevent reachability.
These tools are particularly valuable in environments containing many subnets, route tables, gateways, and security controls.
They should complement, rather than replace, host-level testing and packet captures.
A Practical Troubleshooting Order
A useful sequence is:
Application
↓
Linux host
↓
Network interface
↓
Subnet
↓
Route table
↓
Gateway / network attachment
↓
Security Group
↓
Network ACL
↓
DNS
↓
Destination service
At every stage, ask:
What should happen here, and what evidence proves that it is happening?
For example, if the route table points to a NAT Gateway, verify that the NAT path itself is correctly configured before changing the application’s Security Group.
This prevents troubleshooting from becoming a cycle of unrelated configuration changes.
Conclusion
Troubleshooting AWS VPC connectivity requires a systematic understanding of how different networking components work together. An application may become unreachable because of a service configuration issue, host-level firewall, incorrect subnet association, missing route, gateway misconfiguration, or restrictive Security Group or Network ACL rules. Since these problems can produce similar symptoms, investigating each layer individually helps identify the actual source of failure.
Begin by confirming that the application is listening and the operating system is configured correctly. Then verify the network interface, subnet, route table, and required connectivity components before examining security controls and DNS resolution. When the issue remains unclear, VPC Flow Logs and Reachability Analyzer can provide additional evidence to narrow down the failure point.
Most importantly, avoid changing multiple networking settings simultaneously. Validate each component, test connectivity after every adjustment, and document the findings to make future investigations easier. This layer-by-layer approach reduces unnecessary configuration changes, improves troubleshooting accuracy, and helps maintain reliable communication across AWS environments.
Facing issues?
Our technical support
engineers can solve it.
