Day 79 of 90 Days of DevOps Challenge: Connecting the Dots with AWS VPC Peering

Yesterday, on Day 78, was all about VPCs and their core components: subnets, route tables, Internet Gateways, NAT Gateways, Security Groups, and NACLs. It was like laying the bricks for a house. Now I know how AWS isolates and routes traffic inside its walls.

Today, I’m exploring VPC Peering, what it is, why it’s so important, the problems it solves, and how to create one. I’ll also look at common pitfalls, costs, and when to pick alternatives like Transit Gateway.

What is VPC Peering?

A VPC peering connection is a private, point-to-point link between two VPCs that lets resources in them communicate securely using private IPs. The traffic never leaves AWS’s internal network, meaning it’s more secure, faster, and doesn’t touch the public internet.

Why is VPC Peering important?

• Private cross-VPC communication: share internal databases, APIs, or services without exposing them to the internet.

• Cross-account collaboration: securely connect resources owned by different teams or AWS accounts.

• Low latency & high security: traffic flows over AWS’s backbone, not the open web.

• Cost-effective for small setups: perfect when you just need a few direct connections without complex routing.

VPC Peering Limitations

• No transitive routing: If VPC A is connected to B, and A is connected to C, B can’t automatically reach C. You’d need another direct peering or a Transit Gateway.

• No overlapping CIDR ranges: if IP ranges overlap, the peering connection won’t work.

• Manual routing updates required: you must explicitly update route tables and security settings for communication to work.

Steps to create a VPC Peering connection

Pre-checks:

• Make sure CIDR ranges don’t overlap.

• Note VPC IDs (and AWS Account ID if cross-account).

• Confirm you have the required IAM permissions.

1. Create a peering request (requester VPC)

• Console: VPC → Peering connections → Create peering connection → Select VPCs → Create.

• CLI:

aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-AAAA1111 \
  --peer-vpc-id vpc-BBBB2222 \
  --peer-region us-east-2

2. Accept the request (accepter VPC)

• Console: Peering connections → Select request → Accept.

• CLI:

aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-1a2b3c4d

3. Update route tables (both sides)

• Add a route to the peer CIDR, targeting the peering connection ID.

4. Update security groups & NACLs

• Allow necessary traffic from the peer’s CIDR range.

5. (Optional) Enable DNS resolution across VPCs

• Let’s you resolve private hostnames in one VPC from the other.

6. Test & verify

• Use ping, telnet, or nc to confirm connectivity.

• Check VPC Flow Logs for debugging.

Best practices

• Plan your IP addressing early to avoid CIDR conflicts.

• Tag your peering connections for clarity.

• Avoid using peering for internet access; it won’t work and isn’t designed for that.

• For many VPCs, peering turns into a spaghetti mesh; use Transit Gateway instead for cleaner, scalable routing.

When to choose VPC Peering vs Transit Gateway

• VPC Peering → Best for a few simple, direct connections. Low cost, low complexity.

• Transit Gateway → Best for large-scale, multi-VPC/multi-account networks with central routing.

Final thoughts

VPC Peering might sound simple, “just connect two VPCs,” but in reality, there’s more to it. You need to plan your CIDR ranges carefully, update route tables, and fine-tune your security rules. For small setups, it works beautifully. But as your network grows, you’ll quickly see why AWS came up with Transit Gateway.

The real lesson? Creating the peering is the easy part. The real challenge comes afterward, configuring routes, locking down security, and keeping everything documented. That’s where most peering headaches begin.