Fixing AWS VPC Peering: Resolving 'Request timeout' and 'No route to host'

The Problem

You’ve just set up a VPC Peering connection. The AWS Console shows a green Active status, and everything looks ready to go. However, the moment you try to ping a database or SSH into an instance in the peered VPC, you hit a wall:

Request timeout for icmp_seq — no route to host

Usually, this means the "bridge" exists, but your instances have no map to find it. Network packets reach the local gateway and stop dead because they don't have explicit instructions on how to reach the remote CIDR range.

The 60-Second Fix

VPC Peering requires manual routing. You must update the Route Tables for the subnets in both VPCs to ensure traffic flows both ways:

• Open the VPC Dashboard and select Route Tables.
• Find the Route Table for your source instance (e.g., 10.0.0.0/16).
• Add a route: Set the Destination to the remote VPC CIDR (e.g., 172.31.0.0/16) and the Target to your pcx-xxxxxx ID.
• Crucial: Switch to the destination VPC's Route Table and add a return route pointing back to your source CIDR.

Why This Happens

AWS builds the networking infrastructure when you peer VPCs, but it won't touch your routing logic for security reasons. Think of VPC Peering as a new private tunnel between two office buildings. Even though the tunnel is open, employees won't use it unless you put up signs directing them toward the new exit.

Routing failures typically stem from three gaps:

• The Requester Gap: The source VPC doesn't recognize the peering connection as a valid gateway for the destination IP.
• The Accepter Gap: The destination VPC receives the packet but doesn't know how to send the response (ACK) back.
• Asymmetric Routing: Traffic only moves in one direction, causing the connection to fail at the protocol handshake.

Step-by-Step Guide

1. Confirm Your Network Details

Before clicking around the console, have these three values ready:

• VPC A (Requester): 10.0.0.0/16
• VPC B (Accepter): 172.31.0.0/16
• Peering ID: pcx-0a1b2c3d4e5f6g7h8

2. Configure the Source Route (VPC A)

• In the VPC Console, click Route Tables.
• Select the table linked to your instance’s subnet. If you have multiple subnets (Public/Private), ensure you update the one your instance actually uses.
• Select Actions > Edit routes.
• Click Add route. Enter 172.31.0.0/16 as the Destination.
• Under Target, choose Peering Connection and pick your pcx-... ID.
• Save the changes.

3. Configure the Return Route (VPC B)

Skipping this step is the most common cause of "no route to host" errors. Communication must be bidirectional.

• Find the Route Table for the destination subnet in VPC B.
• Click Edit routes and add a new entry.
• Enter 10.0.0.0/16 (VPC A's range) as the Destination.
• Select the same Peering Connection ID as the Target.
• Save the changes.

4. Quick Fix via AWS CLI

If you prefer the terminal, run these commands to bridge the gap instantly:

# Route from VPC A to VPC B
aws ec2 create-route \
    --route-table-id rtb-11111111 \
    --destination-cidr-block 172.31.0.0/16 \
    --vpc-peering-connection-id pcx-0a1b2c3d4e5f6g7h8

# Route from VPC B to VPC A
aws ec2 create-route \
    --route-table-id rtb-22222222 \
    --destination-cidr-block 10.0.0.0/16 \
    --vpc-peering-connection-id pcx-0a1b2c3d4e5f6g7h8

Testing the Connection

Once you've updated the tables, verify the path. Start with a simple ICMP check from an instance in VPC A:

# Ping the private IP of the remote instance
ping 172.31.20.5

# Check if a specific service port is reachable
nc -zv 172.31.20.5 80

If pings still fail, use the VPC Reachability Analyzer. Create a path between your two instances. It will generate a visual map and tell you exactly which Security Group rule or NACL is dropping your traffic.

Pro-Tips for Network Stability

• Security Group Scope: Ensure the destination instance allows inbound traffic from the source CIDR. Remember: You cannot reference Security Group IDs across regions in a peering connection.
• NACLs: Unlike Security Groups, Network ACLs are stateless. You must allow both inbound and outbound traffic on both ends.
• Overlapping CIDRs: If both VPCs use 10.0.0.0/16, peering will not work. AWS cannot route traffic when both sides claim the same address space.

To avoid address conflicts before you even build your VPCs, I recommend using the ToolCraft Subnet Calculator. It’s a great way to map out CIDR blocks for Dev, Staging, and Production environments to ensure they never overlap during future peering.

Further Reading

• Official Guide: Updating Route Tables for Peering
• Managing Security Groups in Peered VPCs