2.2.1. VPC Peering

VPC Peering directly connects two VPCs to allow communication between instances as if they were in the same network, offering a simple and secure solution for limited connections.

Scenario: You need to enable communication between a development VPC and a testing VPC within your AWS account. These are the only two VPCs that need to communicate directly.

VPC Peering is a networking connection between two VPCs that enables you to route traffic between them privately. Instances in either VPC can communicate with each other as if they are within the same network.

Key Characteristics of VPC Peering:

• Direct Connection: Creates a direct network link between two VPCs.
• Private Traffic: Traffic stays within the AWS network and does not traverse the public internet.
• Non-Transitive: A core limitation. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot directly communicate with VPC C through VPC B. This requires separate peering connections.
• No Overlapping CIDR Blocks: The CIDR blocks of the two peered VPCs must not overlap.
• Route Table Updates: After creating a peering connection, you must manually update route tables in both VPCs to direct traffic across the peering connection.
• Use Cases: Connecting a few VPCs together, enabling a shared services VPC to communicate with a single application VPC.
• Cross-account and inter-Region: the requester creates the request and the accepter (same or another account) must accept it before it becomes active; both sides then add routes. Peering also works across Regions, with traffic kept on the AWS backbone. You can reference a peer VPC's security group only for same-Region peering — inter-Region rules must use CIDRs — and security groups must still allow the peer's traffic. There is no edge-to-edge routing: a peer can't use your internet gateway, NAT gateway, VPN, Direct Connect or gateway endpoint.

Practical Implementation: Creating a VPC Peering Connection and Route

# Assuming VPC_ID_A and VPC_ID_B are defined
# 1. Request VPC Peering Connection
PEERING_CONNECTION_ID=$(aws ec2 create-vpc-peering-connection \
  --vpc-id $VPC_ID_A \
  --peer-vpc-id $VPC_ID_B \
  --query VpcPeeringConnection.VpcPeeringConnectionId --output text)
echo "Peering Connection ID: $PEERING_CONNECTION_ID"

# 2. Accept the Peering Connection (from VPC_B's account or same account)
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id $PEERING_CONNECTION_ID

# 3. Update Route Tables in both VPCs
# Get default route table IDs (or use specific ones)
RT_ID_A=$(aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$VPC_ID_A" "Name=association.main,Values=true" --query "RouteTables[0].RouteTableId" --output text)
RT_ID_B=$(aws ec2 describe-route-tables --filters "Name=vpc-id,Values=$VPC_ID_B" "Name=association.main,Values=true" --query "RouteTables[0].RouteTableId" --output text)

# Add route from VPC A to VPC B's CIDR
aws ec2 create-route --route-table-id $RT_ID_A --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id $PEERING_CONNECTION_ID

# Add route from VPC B to VPC A's CIDR
aws ec2 create-route --route-table-id $RT_ID_B --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id $PEERING_CONNECTION_ID

⚠️ Common Pitfall: Forgetting to update route tables in both peered VPCs. Traffic will flow in one direction but not return, causing connectivity issues.

Key Trade-Offs:

• Simplicity vs. Scalability: VPC Peering is simple for a few connections but becomes unmanageable (N*N-1/2 connections) and complex for many VPCs due to its non-transitive nature.

Reflection Question: How does VPC Peering, by directly connecting two VPCs and allowing instances to communicate as if they were on the same network, fundamentally provide a simple and secure solution for limited, direct network connections between VPCs?