AWS VPC Connectivity Troubleshooting Guide: Routes, SGs, NACLs

Simple explanation

When a resource inside a VPC tries to reach something (another EC2 instance, an RDS database, or an AWS service endpoint), the traffic passes through several independent checkpoints in sequence. Each checkpoint can silently drop the traffic regardless of what the others allow.

The path looks like this:

Source → Route table lookup → NACL outbound (source subnet)
       → Network transit → NACL inbound (destination subnet)
       → Security group (destination resource) → Destination service

Every layer must say “yes” before the connection succeeds. A single misconfigured rule anywhere in the chain breaks the whole path.

Understanding the error message you see matters:

• Connection timed out: the packet was sent but no response came back. This usually means the routing is wrong (the packet went nowhere), a NACL silently dropped it, or a security group’s implicit deny discarded it. Timeouts mean packets disappeared somewhere.
• Connection refused: the packet reached the destination IP and port, but nothing was listening or the service actively rejected it. The network path works. The problem is at the application layer: the service is not running, it is bound to the wrong interface, or a firewall on the OS itself is blocking it.
• DNS failure / hostname not resolving: the client could not translate the hostname to an IP address. No packet was ever sent. This is a DNS configuration problem, not a routing or firewall problem. Fix DNS resolution first before checking anything else.

Knowing which error you see narrows the search immediately.

When to use this guide

Use this guide when you are actively debugging one of these situations:

• EC2 cannot reach the internet: outbound requests time out or fail from a running instance
• EC2 cannot reach another EC2 instance: private IP connections between instances are failing
• Lambda in a VPC cannot reach AWS services: calls to S3, Secrets Manager, SSM, or CloudWatch are timing out
• Application cannot connect to RDS: database connections time out or are refused
• Private subnet cannot reach S3, Secrets Manager, or SSM: no NAT gateway, no VPC endpoint, or the endpoint exists but is misconfigured
• DNS works inconsistently or fails inside the VPC: some hostnames resolve, others do not, or resolution is intermittent
• Cross-VPC or PrivateLink connectivity is failing: traffic between peered VPCs or via a VPC endpoint service is not reaching the destination

How it works

Use this as your first-pass checklist. Work top to bottom. The most common causes come first.

Check routes and subnet type

Route tables are the first checkpoint. If no route exists for the destination, the packet never leaves the subnet.

Every subnet has exactly one route table associated with it. All subnets have a local VPC route (e.g., 10.0.0.0/16 local) that handles all intra-VPC traffic automatically. Internet-bound traffic needs an additional route.

# Get the route table associated with a subnet
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0abc123" \
  --query 'RouteTables[0].Routes'

What to look for in the output:

• 0.0.0.0/0 pointing to igw-*: public subnet with a direct internet gateway route
• 0.0.0.0/0 pointing to nat-* or a NAT gateway ID: private subnet with internet access via NAT
• No 0.0.0.0/0 entry at all: the subnet has no internet route

If the route is missing, either the wrong route table is associated with the subnet, or the route itself was never added. Fix: associate the correct route table, or add the missing route.

Check which route table is actually associated

A common mistake is assuming a subnet uses the main route table when it was explicitly associated with a different one:

# List all route table associations for a VPC
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc123" \
  --query 'RouteTables[*].{ID:RouteTableId,Associations:Associations[*].SubnetId}'

Check public IP vs private subnet vs NAT

Understanding the difference between public and private IP addresses is essential here. For internet-bound traffic, the type of IP and subnet determines the correct path.

Public subnet (route to internet gateway): The instance must have a public IP or Elastic IP. The internet gateway performs NAT between the public IP and the private IP. Without a public IP, return traffic from the internet has nowhere to go.

# Check whether the instance has a public IP
aws ec2 describe-instances \
  --instance-ids i-1234567890abcdef0 \
  --query 'Reservations[0].Instances[0].PublicIpAddress'

If the result is null, either assign an Elastic IP or enable auto-assign public IP on the subnet and launch a new instance (existing instances cannot be retroactively assigned auto-assigned IPs).

Private subnet (route to NAT gateway): The instance uses a private IP only. All outbound internet traffic is routed through the NAT gateway, which performs the source IP translation. The instance does not need a public IP. Verify:

1. The NAT gateway exists and is in available state
2. The private subnet’s route table has 0.0.0.0/0 pointing to the NAT gateway ID
3. The NAT gateway itself is in a public subnet with a route to an internet gateway

# Check NAT gateway status
aws ec2 describe-nat-gateways \
  --filter "Name=vpc-id,Values=vpc-0abc123" \
  --query 'NatGateways[*].{ID:NatGatewayId,State:State,SubnetId:SubnetId}'

Check security groups

Security groups are stateful firewalls attached to individual network interfaces. Stateful means that if outbound traffic is allowed, the inbound response is automatically permitted; you only need to configure one direction for a connection you initiate.

The critical rule: security groups default to deny all inbound. Every EC2 instance, RDS instance, Lambda ENI, and load balancer starts with no inbound access until you explicitly add rules. This is the most common cause of connectivity failures.

# Check inbound rules on the destination's security group
aws ec2 describe-security-groups \
  --group-ids sg-destination \
  --query 'SecurityGroups[0].IpPermissions'

Things to verify:

• The correct port is open (e.g., 5432 for PostgreSQL, 3306 for MySQL, 443 for HTTPS)
• The source is correctly specified as a CIDR range, another security group ID, or 0.0.0.0/0
• The security group is actually attached to the right resource, not a different instance or interface
• Outbound rules have not been restricted (the default is allow all; check IpPermissionsEgress)

Using security group references: Instead of using IP addresses (which change), reference the source instance’s security group ID in the destination’s inbound rule. This adapts automatically when instances are replaced.

# Verify which security groups are attached to an instance
aws ec2 describe-instances \
  --instance-ids i-1234567890abcdef0 \
  --query 'Reservations[0].Instances[0].SecurityGroups'

Check NACLs and ephemeral ports

Network ACLs are stateless firewalls that apply at the subnet level. Stateless means return traffic is not automatically allowed; you must explicitly permit both directions. This is the single most common NACL mistake.

By default, the AWS default NACL allows all traffic in both directions. Problems only arise if someone has modified it or created a custom NACL.

# Get the NACL associated with a subnet
aws ec2 describe-network-acls \
  --filters "Name=association.subnet-id,Values=subnet-0abc123" \
  --query 'NetworkAcls[0].Entries'

The output lists rules with Egress: true (outbound) or Egress: false (inbound). Rules are evaluated in number order, lowest first. The first matching rule wins.

Check DNS and Route 53 private hosted zones

DNS failures look identical to connectivity failures at the application level. Before checking routes or security groups, confirm the hostname actually resolves to the expected IP.

# From inside the VPC (via SSM Session Manager or EC2 connect)
nslookup mydb.internal.example.com
dig mydb.cluster-xyz.us-east-1.rds.amazonaws.com

VPC DNS settings: Two VPC attributes must be enabled for DNS to work correctly inside the VPC:

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0abc123 \
  --attribute enableDnsSupport

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0abc123 \
  --attribute enableDnsHostnames

enableDnsSupport must be true for DNS resolution to work at all. enableDnsHostnames must be true for instances to receive public DNS hostnames.

Private hosted zones: A Route 53 private hosted zone must be explicitly associated with each VPC that needs to use it. A common mistake is creating the private zone and forgetting to associate it with the VPC containing the resources that need to resolve those names.

# List VPC associations for a private hosted zone
aws route53 get-hosted-zone --id /hostedzone/ZONE_ID \
  --query 'VPCs'

For deeper DNS debugging, see the DNS resolution problems guide.

Check the destination service or application layer

If routing is correct, security groups allow the traffic, NACLs are not blocking it, and DNS resolves, but the connection is still refused, the problem is at the application layer, not the network.

Things to check at the destination:

• Is the service actually running? Check the process (systemctl status, ps aux, CloudWatch metrics for the service)
• Is it listening on the correct port and interface? A service listening only on 127.0.0.1 (localhost) is not reachable from outside the instance. It must bind to 0.0.0.0 or the private IP
• Is the OS-level firewall (iptables, firewalld) active? This is a separate layer from security groups and can block traffic that security groups would allow
• For RDS: check that the database is in available state and that the parameter group or SSL settings are not preventing the connection

A “connection refused” error (TCP RST) confirms the packet reached the destination. A timeout means it did not.

Check VPC endpoints and private AWS service access

By default, traffic from inside a VPC to AWS-managed services (S3, DynamoDB, Secrets Manager, SSM, CloudWatch, etc.) does not stay inside the AWS private network. It exits through a public service endpoint. From a private subnet with no NAT gateway, that traffic has nowhere to go and will time out silently.

There are two types of VPC endpoints:

Gateway endpoints: for S3 and DynamoDB only. Free. Added as an entry in the route table rather than creating a network interface.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0abc123 \
  --vpc-endpoint-type Gateway

Interface endpoints (PrivateLink): for most other AWS services including Secrets Manager, SSM, CloudWatch, ECR, STS, and many more. Creates an ENI with a private IP inside your subnet. The service hostname resolves to that private IP via private DNS.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.secretsmanager \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-0abc123 subnet-0def456 \
  --security-group-ids sg-0endpoint123 \
  --private-dns-enabled

Endpoint troubleshooting checklist:

1. Does the endpoint exist? aws ec2 describe-vpc-endpoints --filters "Name=vpc-id,Values=vpc-0abc123"
2. Is the gateway endpoint’s route in the correct route table (the one associated with the subnet that needs access)?
3. Does the interface endpoint’s security group allow inbound HTTPS (port 443) from the calling resource?
4. Is private DNS enabled on the interface endpoint? Without it, the AWS service hostname still resolves to the public IP
5. Does the endpoint policy allow the action and resource? A restrictive VPC endpoint policy can block traffic even when the network path is open

Use VPC Flow Logs

VPC Flow Logs record metadata about IP traffic flowing through network interfaces in your VPC. They show source IP, destination IP, destination port, protocol, packet count, byte count, and whether the traffic was ACCEPTED or REJECTED. They do not capture packet contents.

Enable Flow Logs on a VPC and deliver to CloudWatch Logs:

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0abc123 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::111122223333:role/flow-logs-role

Reading a flow log record:

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 111122223333 eni-0abc123 10.0.1.45 10.0.2.100 52341 5432 6 1 40 1710854400 1710854460 REJECT OK

This record shows source 10.0.1.45 attempted TCP (protocol 6) to 10.0.2.100:5432 and was REJECTED. The traffic reached interface eni-0abc123 but was blocked. Routing is working; a security group or NACL is blocking it.

Query rejected traffic in CloudWatch Logs Insights:

fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| filter dstAddr = "10.0.2.100"
| sort @timestamp desc
| limit 50

Reading the results: A REJECT in flow logs means a security group or NACL blocked the traffic. If you see traffic reaching the destination ENI but being rejected, routing is correct. Focus on security groups and NACLs. If you see no flow log record at all for traffic you expected, the packet is being dropped before it reaches an ENI, which points to a routing or subnet configuration issue.

Use Reachability Analyzer

Reachability Analyzer tests whether a network path between two AWS resources is theoretically possible, without sending real traffic. It models your current routing rules, security group rules, and NACLs and tells you exactly which resource (if any) is blocking the path.

# Create a path between two resources
aws ec2 create-network-insights-path \
  --source i-1234567890abcdef0 \
  --destination i-0fedcba9876543210 \
  --protocol tcp \
  --destination-port 5432

# Start the analysis (returns a network-insights-analysis-id)
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123

# Get results (allow ~30 seconds)
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc123 \
  --query 'NetworkInsightsAnalyses[0].[NetworkPathFound,Explanations]'

If NetworkPathFound is false, the Explanations array identifies exactly which security group rule, NACL entry, or route table gap is blocking the path. This eliminates manual guesswork when debugging complex paths.

Reachability Analyzer supports paths between EC2 instances, network interfaces, internet gateways, VPC peering connections, VPN gateways, and transit gateways.

Scenario-based troubleshooting

EC2 cannot reach the internet

Work through in this order:

1. Check the subnet’s route table for a 0.0.0.0/0 route. If missing, this is the problem.
2. If the route goes to an internet gateway (igw-): check that the instance has a public IP or Elastic IP. Without one, return traffic cannot reach it.
3. If the route goes to a NAT gateway (nat-): verify the NAT gateway is in available state and is in a public subnet that itself has a route to an internet gateway.
4. Check the security group’s outbound rules. The default is allow-all outbound, but this can be restricted.
5. Check the subnet’s NACL for outbound rules that might block the traffic or inbound rules blocking the response on ephemeral ports 1024-65535.

EC2 cannot reach another EC2 instance

Intra-VPC traffic routes via the local VPC route automatically. No internet gateway or NAT gateway is needed. The local route is always present and cannot be removed.

The problem is almost always a security group:

1. Get the destination instance’s private IP: aws ec2 describe-instances --instance-ids i-dest --query 'Reservations[0].Instances[0].PrivateIpAddress'
2. Check the destination instance’s security group inbound rules for the relevant port and protocol. The source should reference either the source instance’s security group ID or its private IP CIDR.
3. If the instances are in different subnets, check both subnets’ NACLs: outbound on the source subnet and inbound on the destination subnet, plus return traffic rules.
4. Confirm the security group with the inbound rule is actually attached to the destination instance, not a different one.

Lambda in a VPC cannot reach AWS services

Lambda functions placed in a VPC use the VPC’s network path, not the default Lambda internet path. A Lambda in a private subnet with no NAT gateway and no VPC endpoints is effectively network-isolated.

• S3 and DynamoDB: require a gateway endpoint added to the route table of the Lambda’s subnets
• Secrets Manager, SSM Parameter Store, CloudWatch, ECR, STS, and most other services: require interface endpoints (PrivateLink) in the Lambda’s VPC, with private DNS enabled
• General internet access: requires a NAT gateway in a public subnet and a 0.0.0.0/0 route in the Lambda’s private subnet pointing to the NAT gateway

Check which subnets the Lambda function is associated with, then verify the route tables and endpoints for those subnets.

aws lambda get-function-configuration \
  --function-name my-function \
  --query 'VpcConfig'

App cannot connect to RDS

RDS connection failures are a specific subset of EC2-to-resource connectivity. See the dedicated RDS connection refused guide for a complete walkthrough. The key checks:

1. The RDS instance’s security group must have an inbound rule for the database port (5432 for PostgreSQL, 3306 for MySQL) from the application server’s security group or subnet CIDR
2. The RDS instance must be in available state
3. The application is connecting to the correct endpoint. Multi-AZ failovers change the underlying IP but not the endpoint DNS name, so typos here are a common problem.
4. If using SSL, the certificate must be valid and the application must trust the RDS CA bundle
5. Check that there is no NACL on the RDS subnet blocking the database port or the ephemeral return-traffic ports

DNS works inconsistently inside the VPC

Intermittent or partial DNS failures inside a VPC are often caused by:

• A private hosted zone not associated with all VPCs that need to resolve those names
• A split-horizon DNS conflict where the same hostname resolves differently inside vs. outside the VPC
• A custom DNS server (on-premises resolver forwarded via Route 53 Resolver inbound endpoint) failing to forward .amazonaws.com or .internal queries to the VPC resolver at 169.254.169.253
• enableDnsSupport disabled on the VPC (all DNS lookups fail)

To test from inside the instance using SSM Session Manager:

# Test the AWS-provided VPC resolver directly
dig @169.254.169.253 myservice.internal.example.com

# Check if the correct IP is returned vs. the public IP
nslookup secretsmanager.us-east-1.amazonaws.com

If the VPC resolver returns a public IP for a service that has an interface endpoint with private DNS enabled, the endpoint’s private DNS is not working. Check that private DNS is enabled on the endpoint and that enableDnsSupport is true on the VPC.

For full DNS debugging steps, see DNS resolution problems.

VPC endpoint or PrivateLink path is failing

If an interface endpoint exists but traffic is still not reaching the service:

1. DNS resolution: confirm the service hostname resolves to a private IP (in the 10.x.x.x or 172.x.x.x range), not the public endpoint IP. If it resolves to a public IP, private DNS is not enabled on the endpoint or enableDnsSupport is false on the VPC.
2. Endpoint security group: the interface endpoint itself has a security group. It must allow inbound HTTPS (port 443) from the resources that will use it.
3. Route table (gateway endpoints only): verify the route for the S3 or DynamoDB prefix list appears in the route table of the subnet that needs access.
4. Endpoint policy: a custom VPC endpoint policy may be restricting which actions or resources are accessible. The default policy allows all access; a restrictive custom policy can silently block specific API calls.
5. Cross-account PrivateLink: if consuming a PrivateLink endpoint service from another account, verify that the service has accepted the connection request and that the endpoint is in available state (not pending-acceptance).

VPC Flow Logs vs Reachability Analyzer

These tools solve different problems. Using the right one first saves time.