How to Diagnose and Resolve Common EC2 Instance Connectivity Problems

EC2 connectivity problems usually come down to one blocked hop: the instance, the security group, the subnet rules, the route table, or the gateway path. If you cannot SSH to an EC2 instance, reach an application port, or connect from one instance to another, work through the network path in order instead of changing rules at random.

The checks below help you isolate where traffic stops and apply the smallest fix that restores access.

Common Causes of EC2 Connectivity Issues

Connectivity problems can stem from various layers of the AWS networking stack. Identifying the root cause often involves checking a combination of these elements:

Security Groups: These are stateful virtual firewalls attached to elastic network interfaces. They control inbound and outbound traffic at the instance level.
Network Access Control Lists (NACLs): NACLs operate at the subnet level and provide an additional layer of stateless filtering for traffic entering and leaving subnets.
Route Tables: These determine where subnet traffic goes, such as locally inside the VPC, to an internet gateway, to a NAT gateway, or to a transit gateway.
Instance State and Networking Configuration: Issues with the EC2 instance itself, such as it being stopped or having incorrect network interface settings.
Internet Gateway (IGW) / NAT Gateway: For instances needing internet access, the IGW (for public subnets) or NAT Gateway (for private subnets) configuration is critical.
VPC Peering / Transit Gateway: If connecting between VPCs, these inter-VPC connectivity services need to be correctly configured.

Step-by-Step Diagnosis and Resolution

Start with the symptom, then follow the packet path.

1. Verify Instance State and Basic Network Reachability

Before diving into complex network configurations, ensure the instance itself is in a healthy state and has basic network configurations:

Instance status checks: In the EC2 console, select the instance and check the "Status checks" tab. Both system and instance checks should pass.
Public and private IPs: Confirm the instance has the address you expect. An instance in a public subnet still needs a public IPv4 address or Elastic IP for direct internet access over IPv4.
Operating system listener: If the network path is open but the port still fails, confirm the service is listening on the instance. For example, SSH should listen on TCP 22 unless you changed the daemon configuration.
DNS resolution: If connecting by IP works but hostname lookup fails, check VPC DNS settings, custom resolvers, and /etc/resolv.conf on Linux.

2. Examine Security Groups

Security groups are stateful firewalls that control traffic to and from your EC2 instances. They are a very common source of connectivity issues.

2.1. Inbound Rules

If you cannot connect to your instance, such as SSH on Linux or RDP on Windows:

Check the Security Group attached to your EC2 instance.
Verify inbound rules: Allow the required TCP port from your source IP or trusted CIDR. For admin access, prefer your current public IP as <your_ip>/32 instead of 0.0.0.0/0.

Example: To allow SSH access from your IP address:

Type: SSH
Protocol: TCP
Port range: 22
Source: <your_ip>/32

2.2. Outbound Rules

If your instance cannot reach external resources (e.g., download packages, connect to other AWS services):

Check the Security Group attached to your EC2 instance.
Verify Outbound Rules: By default, security groups allow all outbound traffic. If custom outbound rules have been created, ensure they permit the necessary traffic to your destination ports and IPs.

Example: To allow all outbound traffic:

Type: All traffic
Protocol: All
Port range: All
Destination: 0.0.0.0/0

3. Investigate Network Access Control Lists (NACLs)

NACLs are stateless firewalls that operate at the subnet level. They filter traffic before it reaches the security group or instance.

Identify the NACL associated with your instance's subnet.
Check Inbound Rules: NACLs are evaluated in order by rule number. Ensure there is an inbound rule that allows traffic on the required port from the source IP.
Check Outbound Rules: Similarly, verify outbound rules allow traffic to the destination.
Stateless nature: NACLs do not remember established connections. You need inbound and outbound rules for both sides of the flow. For SSH from your laptop, the subnet NACL usually needs inbound TCP 22 from your IP and outbound ephemeral ports to your IP for the return traffic. Ephemeral port ranges vary by operating system and client, so use the range appropriate for your environment.
Rule Numbering: Lower rule numbers are evaluated first. Use explicit deny rules (e.g., rule 100 to deny specific traffic) and allow rules (e.g., rule 200 to allow broader traffic) carefully.

4. Review Route Tables

Route tables determine where network traffic is directed from your subnets. Incorrect routing can prevent traffic from reaching its destination.

Find the Route Table associated with your instance's subnet.
Check for a Default Route: For instances in a public subnet to access the internet, there must be a route 0.0.0.0/0 pointing to an Internet Gateway (IGW).
```
Destination | Target
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | igw-xxxxxxxxxxxxxxxxx
```
Private subnets and NAT gateways: For instances in a private subnet to initiate outbound internet connections, the route table for that subnet needs a 0.0.0.0/0 route pointing to a NAT gateway or NAT instance.
```
Destination | Target
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | nat-xxxxxxxxxxxxxxxxx
```
VPC peering, transit gateway, or VPN: If your instance needs to communicate with another VPC or on-premises network, add routes for the remote CIDR blocks to the correct target on both sides where routing is required.

5. Troubleshoot Internet Gateway (IGW) and NAT Gateway Connectivity

Internet Gateway

*   Ensure the IGW is created and attached to your VPC.
*   Verify the route table for your public subnet has a `0.0.0.0/0` route pointing to the IGW.
*   Confirm your instance has a public IP address or an Elastic IP address assigned.
*   Security group and NACL rules must allow the required inbound and outbound traffic. Do not open sensitive ports to the whole internet unless you have a clear reason and compensating controls.

NAT Gateway

*   Ensure the NAT Gateway is created and is in a public subnet.
*   Verify the NAT Gateway has an Elastic IP address associated with it.
*   Confirm the route table for your private subnet has a `0.0.0.0/0` route pointing to the NAT Gateway.
*   NACL rules on the private and public subnets must allow the outbound connection and return traffic. NAT gateways do not use security groups.

6. VPC Peering and Transit Gateway

If you're experiencing connectivity issues between VPCs:

VPC Peering:
- Ensure the peering connection is active and accepted by both VPCs.
- Verify that the route tables in both VPCs have routes added to allow traffic to the CIDR blocks of the peered VPC.
- Ensure Security Groups and NACLs in both VPCs allow traffic between the necessary IP ranges.
Transit Gateway:
- Confirm the Transit Gateway is created and the relevant VPCs are attached to it.
- Check the Transit Gateway route tables to ensure they correctly route traffic between VPC attachments.
- Verify the route tables within each VPC also have routes pointing to the Transit Gateway for traffic destined for other VPCs.
- Security Groups and NACLs within each VPC must permit the cross-VPC traffic.

7. Using AWS Network Reachability Tools

AWS provides tools to help diagnose network issues:

VPC Reachability Analyzer: This tool analyzes reachability between supported source and destination resources. It can identify path failures caused by security groups, NACLs, route tables, gateways, and related network configuration.
VPC Flow Logs: While not directly diagnosing connection failures, VPC Flow Logs capture information about the IP traffic going to and from network interfaces in your VPC. Analyzing these logs can reveal patterns of blocked or unexpected traffic, helping you identify misconfigurations in Security Groups or NACLs.

8. Other Potential Issues

Elastic Network Interface (ENI): Ensure the ENI is attached to the instance and configured correctly.
Subnet's Route Table Association: Verify the subnet is correctly associated with its intended route table.
DNS Configuration: If using custom DNS, ensure it's resolving correctly. For default VPC DNS, check if DNS resolution is enabled for your VPC.
Proxy Servers: If your instance is configured to use a proxy, ensure the proxy itself is accessible and configured correctly.

Best Practices for Preventing Connectivity Issues

Least Privilege: Configure Security Groups and NACLs with the minimum necessary permissions. Avoid using 0.0.0.0/0 for sensitive ports unless absolutely required and protected by other means.
Tagging: Consistently tag your network resources (VPCs, subnets, security groups, route tables) to easily identify their purpose and associated instances.
Documentation: Maintain clear documentation of your network topology, IP addressing schemes, and security rules.
Regular Audits: Periodically review your Security Group and NACL rules to ensure they are still relevant and secure.
Leverage AWS Tools: Familiarize yourself with VPC Reachability Analyzer and VPC Flow Logs for proactive monitoring and troubleshooting.

Takeaway

When EC2 connectivity breaks, trace the path in order: instance health, listener, security group, NACL, route table, gateway, and remote-side rules. Change one layer at a time, then test again. That keeps your fix narrow and makes the next outage much easier to diagnose.