Diagnosing EC2 Instance Connectivity Issues: Security Groups and Network ACLs

Connecting to an Amazon Elastic Compute Cloud (EC2) instance is a fundamental operation, yet connectivity failures are among the most common troubleshooting scenarios for AWS users. When an instance appears to be running correctly but remains unreachable—whether via SSH, RDP, or application traffic—the issue almost always resides in the surrounding network security layers. This comprehensive guide outlines the systematic approach to diagnosing and resolving connectivity problems by focusing on the three critical network control points: Security Groups (SGs), Network Access Control Lists (NACLs), and VPC Route Tables.

Understanding the hierarchy and function of these controls is key. Security Groups act as instance-level stateful firewalls, while NACLs act as stateless subnet-level firewalls. Misconfigurations in either of these components, or incorrect routing paths, will immediately block expected traffic, leading to frustrating connection timeouts.

The Three Pillars of EC2 Connectivity Control

Before diving into specific configurations, it is crucial to understand the role each component plays in the traffic path to your EC2 instance:

1. Route Tables: Determine where network traffic is directed based on its destination IP address. If traffic destined for the internet or your client IP cannot reach the correct subnet gateway, connectivity will fail.
2. Network ACLs (NACLs): Apply rules to an entire subnet. They are stateless, meaning both inbound and outbound traffic must be explicitly allowed. They process rules in order, from lowest numbered rule to highest, stopping at the first match.
3. Security Groups (SGs): Apply rules directly to the Elastic Network Interface (ENI) of the EC2 instance. They are stateful, meaning if you allow inbound traffic, the return outbound traffic is automatically permitted.

Step 1: Verifying VPC Route Tables

The first diagnostic check should always confirm that a path exists for the traffic to even reach the subnet where the EC2 instance resides.

Checking Inbound Routing

For an instance reachable from the public internet (e.g., via SSH/RDP):

• Goal: Ensure the subnet containing the instance has a route to the Internet Gateway (IGW) for traffic originating from 0.0.0.0/0 (or your specific client IP range).
• Action: Navigate to the VPC console, select Route Tables, and examine the route table associated with your instance's subnet. Look for an entry like:
  Destination: 0.0.0.0/0 | Target: igw-xxxxxxxx

Checking Outbound Routing (For Stateful Issues)

While SGs are stateful, verifying the outbound path is crucial, especially for return traffic or instances initiating connections to external services.

• Action: If your instance is in a private subnet, ensure it has a route to a NAT Gateway or NAT Instance to reach the internet. If it's in a public subnet, it should route 0.0.0.0/0 to the IGW.

Tip: If you cannot ping an instance from a different subnet within the same VPC, the issue is almost certainly a misconfigured route table directing traffic to the wrong local gateway or VPC Peering connection.

Step 2: Inspecting Network ACLs (Subnet Level)

NACLs are often overlooked because they operate at the subnet level and are stateless. A common error is allowing inbound traffic but forgetting to explicitly allow the return outbound traffic.

Inbound Rule Verification

For inbound connection attempts (e.g., SSH on port 22):

1. Identify the NACL associated with the instance's subnet.
2. Examine Inbound Rules.
3. Ensure a rule exists that allows the specific port and protocol you are using (e.g., Rule 100: Type: SSH (22), Protocol: TCP, Source: 0.0.0.0/0).

Outbound Rule Verification (The Stateless Trap)

This is where most NACL connection issues occur.

1. Examine Outbound Rules.
2. If you allowed inbound SSH (Port 22), the instance needs to send traffic back to your client on a High Port (Ephemeral Port) range, typically 1024-65535.
3. Action: Ensure an Outbound rule explicitly allows traffic to the relevant destination port range (often 1024-65535 if the client is initiating the connection).

Example NACL Rule Set for Inbound SSH Access:

Warning: NACLs evaluate rules numerically. If Rule 90 is DENY ALL, your subsequent Rule 100 ALLOW SSH will never be hit. Ensure your explicit ALLOW rules have lower numbers than any broad DENY rules, or rely on the final implicit DENY ALL rule.

Step 3: Auditing Security Groups (Instance Level)

Security Groups are the final line of defense, applied directly to the instance. They are easier to manage because they are stateful.

Inbound Rule Check

Verify that the SG attached to the EC2 instance permits traffic on the required ports from the expected source:

• For SSH (Linux): Inbound rule allowing TCP Port 22 from your public IP or 0.0.0.0/0 (if needed).
• For RDP (Windows): Inbound rule allowing TCP Port 3389 from your public IP or 0.0.0.0/0.
• For Web Traffic: Inbound rule allowing TCP Port 80 and/or 443 from 0.0.0.0/0.

Outbound Rule Check (Usually Defaulted)

Since SGs are stateful, the Outbound rules are usually configured to ALLOW ALL Traffic (0.0.0.0/0 on all ports). If you have customized the outbound rules, ensure they allow responses back to the client's ephemeral port range.

Best Practice: Unless there is a strict security requirement, leave the Security Group's Outbound Rules set to the default: Allow All Traffic to All Destinations. This simplifies troubleshooting significantly, as you can isolate NACL or Route Table issues.

Summary: The Connectivity Flow Checklist

When an EC2 connection fails, follow this diagnostic sequence:

1. Route Table Check: Can the traffic path (inbound and outbound) reach the correct subnet gateway (IGW/VPC Peering/NAT)?
2. NACL Check (Stateless): Is the traffic explicitly ALLOWED on the specific inbound port AND is the return traffic (often high ephemeral ports) explicitly ALLOWED outbound?
3. Security Group Check (Stateful): Is the traffic explicitly ALLOWED on the specific inbound port? (Outbound should generally be open).

By systematically moving from the broad network layer (Routing) down to the subnet level (NACLs) and finally to the instance level (SGs), you can quickly isolate whether the blocking mechanism is stateless filtering, stateful filtering, or routing failure.