Guide: Understanding AWS VPC Peering

This guide provides a comprehensive overview of Amazon VPC Peering, explaining what it is, how to set it up, and its critical limitations, based on the detailed Tutorials Dojo article.

What is VPC Peering?

A VPC Peering connection is a private, point-to-point networking connection between two VPCs. It enables you to route traffic between them using private IPv4 or IPv6 addresses, making instances in either VPC communicate as if they are within the same network.

• It is not a gateway or a VPN connection and does not rely on a separate piece of physical hardware.

• It does not have a single point of failure for communication or a bandwidth bottleneck.

• You can create a peering connection between your own VPCs, with a VPC in another AWS account, or even with a VPC in a different AWS Region (Inter-Region VPC Peering).

How to Establish a Peering Connection: The 4 Key Steps

Successfully enabling traffic flow over a peering connection requires more than just creating the connection itself. You must complete all four steps.

Step 1: Create the Peering Request

The owner of the "requester" VPC initiates a request to create a peering connection with an "accepter" VPC. You will need the VPC ID and Account ID of the accepter VPC.

Step 2: Accept the Peering Request

The owner of the accepter VPC must find the pending request and accept it to make the connection Active.

Step 3: Update Route Tables (Both VPCs)

This is the most critical step. A peering connection does not work until you tell your VPCs' route tables how to use it. You must add a route in each VPC that points to the other VPC's CIDR block.

Example:

• VPC-A has a CIDR block of 10.0.0.0/16.

• VPC-B has a CIDR block of 172.31.0.0/16.

• The peering connection ID is pcx-12345678.

In VPC-A's Route Table:

| Destination | Target |

| :--- | :--- |

| 172.31.0.0/16 | pcx-12345678 |

In VPC-B's Route Table:

| Destination | Target |

| :--- | :--- |

| 10.0.0.0/16 | pcx-12345678 |

Without these routes, the VPCs have no way of knowing that they should send traffic destined for the peer VPC over the peering connection.

Step 4: Update Security Groups (Both VPCs)

By default, security groups will block incoming traffic from the peered VPC. You must add rules to the security groups of your instances to allow traffic from the CIDR block of the peer VPC.

Example:

To allow an EC2 instance in VPC-A to receive SSH traffic from an instance in VPC-B:

• In the Security Group attached to the VPC-A instance, add an inbound rule:

  • Type: SSH (Port 22)

  • Source: 172.31.0.0/16 (The CIDR block of VPC-B)

Critical Rules and Limitations

Understanding the limitations of VPC Peering is essential for designing a scalable network architecture.

1. No Transitive Peering

This is the most important rule. Peering relationships are not transitive. If you have a peering connection between VPC A and VPC B, and another between VPC B and VPC C, VPC A cannot communicate with VPC C through VPC B.

A <--peered--> B <--peered--> C

A <-X-cannot-talk-X-> C

To enable communication between VPC A and VPC C, you must create a direct peering connection between them. For complex networks with many VPCs, this creates a "full mesh" of connections that can be difficult to manage. For these scenarios, AWS Transit Gateway is the recommended solution.

2. No Overlapping CIDR Blocks

You cannot create a VPC peering connection between VPCs that have matching or overlapping CIDR blocks.

3. One Peering Connection Between Two VPCs

You cannot have more than one VPC peering connection between the same two VPCs at the same time.

DNS Resolution over Peering

By default, if an instance in one VPC tries to resolve the public DNS hostname of an instance in a peer VPC, it will resolve to the instance's public IP. To make it resolve to the private IP (and thus route over the peering connection), you must enable DNS hostname resolution for the VPC peering connection.

Inter-Region VPC Peering Considerations

• IPv6 is not supported for inter-region peering connections.

• You cannot reference a security group from a peer VPC in your security group rules if the VPCs are in different regions. You must use CIDR blocks instead.