🧠 The Hidden Power of VPC Peering

VPC Peering explained: secure, private, and cost-effective

Last week, I was setting up communication between two VPCs.
Instead of overcomplicating with NAT Gateways or VPNs, the clean solution was VPC Peering — a direct, private connection that saves cost and reduces complexity.

---

What is VPC Peering?

VPC Peering is a networking connection that allows two Amazon VPCs to communicate using private IP addresses.

• No need for Internet Gateway, VPN, or Transit Gateway.

• Acts as a private bridge between two networks.

  ---

When Do You Need VPC Peering?

• Connect VPCs across different AWS accounts.

• Enable inter-region VPC communication.

• Share databases, monitoring tools, or services securely.

• Route traffic without exposing it to the internet.

  ---

What Happens Internally in VPC Peering?

When you create a VPC Peering connection, a few internal steps ensure successful communication:

1- Peering Request & Acceptance

• A peering request is generated by the requester VPC.

• The target (accepter) VPC must accept it before the connection becomes active.

2- Route Table Updates

• Each VPC must update its route tables with the CIDR of the peer VPC.

• Without this, traffic won’t know where to go.

3- Security Groups & NACLs

• Even if routes exist, traffic will be blocked unless SGs and NACLs are explicitly allowed.

• Example: If VPC A’s instance needs SSH access from VPC B, SG rules must permit it.

4- Optional: Private DNS Resolution

• You can enable DNS resolution so that private hostnames in one VPC resolve to private IPs in the peer VPC.

• Makes cross-VPC communication seamless using hostnames instead of IPs.

---

✨ Note: A peering connection only creates the “bridge.” You still need routes + firewall rules

---

Configurations

1- Full CIDR Peering

• Adds entire peer CIDR to route tables.

• All subnets across both VPCs can communicate.

Use Case: Centralized logging/monitoring, split applications.

• Use security groups to restrict communication if only specific workloads should connect.

2- Subnet-Selective Peering

• Only selected subnet prefixes added to routes.

• Limits connectivity to specific resources.

👉 Use Case: DB subnet in VPC A ↔ App subnet in VPC B.

• Improves security and isolation.

---

VPC Peering Topologies

Partial Mesh (Scales poorly)

• Only certain VPCs are peered.

• Example: A ↔ B, B ↔ C, but A cannot talk to C unless direct peering is created.

  

Full Mesh (Every VPC Connected)

• Each VPC has a direct peering connection with every other VPC.

• Ensures full connectivity, but becomes harder to manage as VPCs grow.

Partial Mesh – Only A↔B and B↔C are peered. A cannot talk to C unless they are directly peered.

Full Mesh – A↔B, B↔C, and A↔C are all connected. Every VPC can talk directly.

---

Scaling Tip:

• Peering works well for 2–3 VPCs.

• Beyond that, AWS Transit Gateway (TGW) is a better option:

  • Hub-and-spoke model (centralized).

  • Simplified routing.

  • Easier to scale.

    ---

Key Limitations of VPC Peering (important for interviews & real-world use)

• No Transitive Peering – If VPC-A is peered with VPC-B, and VPC-B is peered with VPC-C, A cannot directly talk to C.

• Same Region vs Cross-Region – Cross-region peering is supported but has cost implications.

• No Overlapping CIDR – Peering won’t work if CIDR blocks overlap.

No Security Group Referencing Across VPCs – You cannot reference security groups of peer VPCs.

---

Best Practices

• Design CIDR blocks carefully before peering to avoid overlaps.

• Use tags for peering connections to simplify management in large environments.

• Monitor peering traffic with VPC Flow Logs for visibility and troubleshooting.

• Regularly review route tables after changes for easy-to-miss updates.

---

Alternatives to VPC Peering

• AWS Transit Gateway → If you have many VPCs or need transitive routing, Transit Gateway is a better solution.

• PrivateLink → Use for secure, private access to services without exposing them publicly.

• VPN / Direct Connect → For hybrid setups connecting on-prem with VPCs.

  ---

Real-World Example

• A fintech company uses VPC peering to connect production and logging VPCs securely, but later migrated to Transit Gateway to handle 20+ VPCs across multiple regions. This shows scalability in action.

  ---

  Pro Tip for Readers

• Always start with VPC peering for simple 1:1 connectivity.

• As your cloud grows, plan a migration path to Transit Gateway or PrivateLink to avoid redesign later.

  📬 Get in touch

  What’s been your trickiest VPC Peering challenge?

  Setting up cross-account peering?

  Handling inter-region communication?

  Or debugging tricky route table setups?

  Reply and let me know — I’d love to feature your real-world stories in the next issue. If you enjoyed this, drop ❤️ and share! If you want to collaborate or sponsor the newsletter? Email me at pranjalikomal5@gmail.com.

  See you next time! Until then → connect smart, scale secure.

  — Pranjali, DevOps & Cloud Consultant ☁️

  Thanks for reading! If you haven’t subscribed yet, you can subscribe now.