Cloud Networking
Intermediate 15 min read Cloud Networking

VPC Peering and Transit

Joining VPCs — pairwise or through a hub

Peering joins two VPCs; Transit Gateway or a hub VNet joins many. Direct peering is fast and cheap but non-transitive; hubs add inspection and centralization at the cost of design complexity.

VPC peeringtransit gatewayhub and spoketransitivitymesh
Prerequisites: Route Tables and Gateways Subnets and CIDR Planning
Before we start

What you will learn

  • Explain peer relationships and transitivity
  • Design hub-and-spoke with Transit Gateway or shared services
  • Choose mesh vs hub based on size and inspection needs
In 60 seconds

VPC peering connects two VPCs directly (no gateway). It's non-transitive: A↔B plus B↔C does NOT give A→C. Transit Gateway / VNet hub / GCP shared VPC centralize connections so many networks talk through one managed hub.

Introduction

What is this?

VPC peering establishes network connectivity between two VPCs (or across accounts) so they can use each other's CIDRs directly with high bandwidth and low cost — routes must be added to each table, CIDRs cannot overlap, and peering is non-transitive. Transit Gateway (AWS) is a managed star hub that attaches VPCs, VPNs and DX and does transitive routing between attachments with optional inter-region peering. Azure uses VNet peering (also non-transitive) plus a hub VNet with NVAs; GCP keeps one global VPC (or uses Shared VPC) and peering for cross-project.

Motivation

Why do you need it?

  • Peering is the cheapest way to connect two VPCs for shared services.
  • Hub-and-spoke collapses O(N²) peers into O(N) attachments.
  • A hub is where inspection lives: single NVAs, firewalls, route domains.
  • These architectures are the backbone of every multi-account landing zone.
Think about it

Mental model

Imagine

Two offices with a private walkway vs a central transit hub

Think of

Peering vs transit

A walkway (peering) connects two buildings directly. A transit hub (Transit Gateway) is the airport: many airlines (VPCs) share one terminal, routing passengers through central security (inspection).

Mechanics

How it works

  • Create a peering connection, accept it (optionally across accounts), then add routes on both sides.
  • Non-transitive: each peer must itself be peered; routing never hops through a third party.
  • Transit Gateway: attach VPCs via attachments; create routes on the TGW route table; transitive between attachments.
  • Inter-region TGW peering connects regions; DX/VPN attach on-prem.
  • GCP Shared VPC centralizes subnets; Azure hub VNet + peer spokes work similarly.

Mesh (peering) vs hub (transit).

Mesh: A↔B, A↔C, B↔C
Hub: Transit Gateway
Central inspection
Routes
Scale
Real world

In production

  • A dev account peers to the prod account's shared-services VPC to use the bastion and monitoring stack.
  • A landing zone uses a Transit Gateway hub with per-OU route tables and a centralized firewall attachment.
  • GCP uses Shared VPC for the platform team plus peering for third-party SaaS integrations.
Guidelines

Best practices

  • Prefer hub-and-spoke when N VPCs > ~5 or when you need central inspection.
  • Use non-overlapping CIDRs and document the allocation before peering.
  • Enable data-protection/inspection carefully; private peering traffic is encrypted where supported.
  • Route only what's needed; avoid black-hole routes from sloppy transitive propagation.
Watch out

Common mistakes

  • Assuming peering is transitive and routing A→C through B.
  • Peering VPCs with overlapping CIDRs — cloud providers often reject, or routes silently fail.
  • Hub VPC becoming a network bottleneck via forced inspection for everything.
  • No route-table isolation: every VPC sees every other route and budgets/audits blur.
Root cause analysis

Common issues

Error
Peer shows in pending accept for hours
Root cause

The other side never accepted, or IAM crossed accounts

Fix

Accept from the peer account; verify cross-account permissions if using org.

Error
Traffic works one direction only
Root cause

Missing route in one VPC's table

Fix

Add the reverse route (peer CIDR → peering) on the silent side.

Error
TGW attachment doesn't route
Root cause

TGW route table lacks the destination or association

Fix

Propagate the attachment's VPC route and ensure an explicit route exists in the TGW table.

When things break

Debugging tips

  • Verify both directions of the peer: connection status, then both route tables.
  • Reachability analyzer across the peering connection catches route/SG/gateway gaps.
  • For TGW: check attachment state and route tables (static vs propagated).
  • Watch for asymmetric paths where one side routes via the TGW and the other via peering.
Interviews

Interview checkpoint

Practice

Hands-on lab

Peer Two VPCs and Verify Routes
30 min · intermediate
In progress
Objectives
  • Create two VPCs with non-overlapping CIDRs
  • Create and accept a peering connection
  • Verify routes and connectivity

Peer Two VPCs and Verify Routes

30 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which is TRUE about VPC peering transitivity?

2

A Transit Gateway lets you attach many VPCs and route transitively between them.

Go deeper

Official documentation

AWS — VPC peering
docs
AWS — Transit Gateway
docs
Azure — VNet peering
docs