Fixing AWS EC2 'Network is Unreachable': The Definitive Troubleshooting Guide
Resolve AWS EC2 'network is unreachable' errors by diagnosing VPC route tables, Internet Gateways, Security Groups, and OS-level network interfaces.
- Root Cause 1: The EC2 instance is in a public subnet but the associated Route Table lacks a default route (0.0.0.0/0) to an Internet Gateway (IGW).
- Root Cause 2: The instance is in a private subnet and the Route Table is missing a route to an active NAT Gateway or NAT Instance.
- Root Cause 3: The operating system's internal routing table is misconfigured, often due to network service restarts or custom interface configurations.
- Quick Fix Summary: Verify your VPC's Internet Gateway is attached, ensure the subnet's Route Table points 0.0.0.0/0 to the IGW/NAT, and check OS routes using `ip route`.
| Method | When to Use | Time | Risk |
|---|---|---|---|
| VPC Reachability Analyzer | Complex VPCs with multiple transit gateways, peering connections, or complex routing. | 5-10 mins | Low |
| Route Table & IGW Inspection | Newly provisioned subnets or instances failing to reach the internet immediately. | 2-5 mins | Low |
| Security Group / NACL Audit | Connection timeouts occur, or ICMP/TCP traffic seems specifically filtered. | 5 mins | Low |
| OS-Level Network Debugging (`ip route`) | VPC configuration is perfectly valid, but the instance OS still throws the error. | 10-15 mins | Medium |
Understanding the Error
The Network is unreachable error (often accompanied by ENETUNREACH in application logs or connect: Network is unreachable in CLI utilities like ping or curl) is a fundamental routing failure. Unlike a Connection timed out error, which implies packets are being dropped silently by a firewall (like an AWS Security Group), Network is unreachable means the networking stack does not even know how to send the packet to the destination. It has no route.
In the context of AWS Elastic Compute Cloud (EC2), this error manifests in two distinct layers: the AWS Virtual Private Cloud (VPC) software-defined networking layer, and the EC2 instance's Operating System (OS) layer.
Step 1: Diagnose the AWS VPC Routing Layer
Most often, the issue lies in the AWS console configuration. An EC2 instance needs a clear path to the internet.
1. Check the Internet Gateway (IGW) If your instance is supposed to be publicly accessible or needs to reach the public internet directly, it must reside in a Public Subnet. A subnet is only "public" if its associated Route Table has a route to an Internet Gateway.
- Navigate to the VPC Dashboard -> Internet Gateways.
- Ensure an IGW is created and in the
Attachedstate to your specific VPC.
2. Verify the Route Table
- Go to VPC Dashboard -> Route Tables.
- Select the Route Table associated with your EC2 instance's subnet.
- Click the Routes tab.
- You must see a route where the Destination is
0.0.0.0/0(for IPv4) and the Target is your Internet Gateway (e.g.,igw-0abc12345def67890). - If your instance is in a Private Subnet (it only has a private IP), the
0.0.0.0/0destination must target a NAT Gateway (e.g.,nat-0abc12345def67890). Ensure the NAT Gateway is in theAvailablestate.
3. Check Public IP Assignment If your instance is in a public subnet, it must have a public IP address or an Elastic IP (EIP) attached to communicate with the internet via an IGW. Without a public IP, the IGW will drop the outbound traffic because it cannot perform the 1:1 Network Address Translation required for public internet routing. Check the EC2 instance details to confirm a Public IPv4 address is assigned.
Step 2: Diagnose Security Groups and Network ACLs
While Security Groups (SGs) and Network Access Control Lists (NACLs) usually cause Timeout errors, overly restrictive NACLs can sometimes trigger unreachable errors depending on the OS implementation of ICMP unreachable messages.
- Security Groups: By default, SGs allow all outbound traffic. Ensure the Outbound Rules have not been modified to restrict port 80/443 or your required outbound ports.
- NACLs: NACLs are stateless. If you modified the default NACL, ensure both inbound and outbound rules allow ephemeral ports (1024-65535) for return traffic.
Step 3: Fix OS-Level Routing Issues
If the AWS VPC configuration is flawless, the issue resides within the EC2 instance's operating system. This often happens after custom network configuration changes, adding secondary Elastic Network Interfaces (ENIs), or software updates that restart the networking daemon incorrectly.
Log into your instance via AWS Systems Manager Session Manager (if SSH is failing) and run ip route.
You should see a default route looking like this:
default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.123 metric 100
If the default line is missing, the OS does not know where to send outbound traffic. This can be temporarily fixed by adding the default route manually (pointing to the AWS VPC subnet router, which is always the first usable IP in the subnet CIDR, e.g., .1).
# Find your subnet router IP (usually the .1 address of your CIDR block)
sudo ip route add default via 10.0.x.1 dev eth0
To make this permanent, you need to troubleshoot why the DHCP client (like dhclient or systemd-networkd) is failing to acquire the default route from the AWS DHCP servers.
Frequently Asked Questions
# 1. Check if the instance can resolve DNS
nslookup google.com
# 2. Check the OS routing table for a default route
ip route show
# 3. If missing, temporarily add the default gateway (Replace 10.0.1.1 with your subnet's router IP)
sudo ip route add default via 10.0.1.1 dev eth0
# 4. Restart the networking service to attempt DHCP lease renewal (Ubuntu/Debian)
sudo systemctl restart systemd-networkd
# OR for Amazon Linux 2 / CentOS
sudo systemctl restart network
# 5. Check for dropped packets by local iptables firewalls
sudo iptables -L -n -vError Medic Editorial
Written by our team of Senior Site Reliability Engineers and AWS Certified Solutions Architects. We specialize in demystifying complex cloud networking issues.