VPC Peering

VPCs exist to isolate. You create boundaries—separate networks for production and development, for different teams, for different trust levels. Then reality intrudes: the production database needs to talk to the monitoring system in the shared services VPC. The authentication service needs to reach the directory server across account boundaries.

You built walls. Now you need doors.

VPC peering creates those doors. It establishes direct network routes between separate VPCs, allowing resources to communicate using private IP addresses as if they shared the same network—without traffic ever touching the public Internet.

How VPC Peering Works

A peering connection is a network route between two VPCs. Once established, instances in either VPC can reach instances in the other using private IPs. The traffic stays within the cloud provider's network, never exposed to the Internet.

But here's what makes peering interesting: it's deliberately non-transitive.

If VPC A peers with VPC B, and VPC B peers with VPC C, that doesn't mean A and C can talk. They can't. Traffic doesn't hop through B. If A needs to reach C, A and C must establish their own direct peering connection.

This isn't a limitation—it's the point. Every connection must be intentional. You can't accidentally inherit connectivity through intermediate VPCs. The architecture forces you to explicitly decide which VPCs should communicate with which.

The Handshake

Peering requires consent from both sides:

1. The requester initiates the connection, specifying the target VPC (which might be in a different account or region)
2. The accepter receives the request and must explicitly approve it
3. Both VPCs update their route tables to direct traffic toward the peering connection
4. Both VPCs update Security Groups to allow traffic from the peer's IP ranges

The connection activates only after both sides complete their configuration. You can't peer with someone who doesn't want to be peered with.

The IP Address Constraint

Peered VPCs cannot have overlapping IP address ranges. If VPC A uses 10.0.0.0/16 and VPC B also uses 10.0.0.0/16, peering fails. The router wouldn't know where to send traffic destined for 10.0.1.5—it could be in either VPC.

This constraint reveals something important: IP address planning isn't optional overhead. It's infrastructure. Organizations that assign VPC ranges haphazardly discover later that they've painted themselves into corners, unable to peer VPCs that need to communicate.

Plan your address space like you're laying out a city grid. Leave room for growth. Ensure every neighborhood has a distinct address range.

Routing Configuration

Both VPCs need routes pointing to the peering connection:

In VPC A (using 10.0.0.0/16):

• Route: 10.1.0.0/16 → pcx-12345

In VPC B (using 10.1.0.0/16):

• Route: 10.0.0.0/16 → pcx-12345

These routes tell each VPC: "Traffic for that IP range? Send it through the peering connection."

If you have multiple route tables (for different subnets), each one that needs peered connectivity needs these routes. Missing a route table is a common source of "it works from subnet A but not subnet B" mysteries.

Security Groups Across the Boundary

Security Groups control what traffic the peering connection actually carries. Having a route doesn't mean traffic flows—Security Groups must explicitly allow it.

You can reference peer VPCs two ways:

By CIDR block: Allow TCP 3306 from 10.1.0.0/16

By Security Group ID (same region, same or different account): Allow TCP 3306 from sg-67890

Security Group references are powerful—if you add new instances to the referenced group, they automatically gain access. No rule updates needed. The security policy follows the identity, not the IP.

Cross-Region Peering

VPCs in different geographic regions can peer, enabling:

• Global applications with components in multiple regions
• Disaster recovery with geographically separated resources
• Data locality compliance with cross-region coordination

Cross-region peering adds considerations:

• Encryption: Traffic between regions is encrypted in transit
• Latency: Geographic distance introduces delay
• Cost: Data transfer charges apply for cross-region traffic
• Bandwidth: May be more constrained than same-region connections

Cross-Account Peering

VPCs owned by different cloud accounts can peer, requiring:

• The requester to specify both the account ID and VPC ID of the target
• The accepter to approve from within their account
• Independent configuration by both accounts

This enables organizational boundaries without network isolation. Different business units, partner organizations, or security domains can maintain separate accounts while allowing specific, controlled communication paths.

What Peering Can't Do

Peering has hard boundaries:

Non-transitivity: Traffic doesn't hop through intermediate VPCs. A↔B and B↔C doesn't give you A↔C.

No edge routing: A VPC can't use a peered VPC's Internet Gateway or VPN connection. You can't route to the Internet through your peer.

Connection limits: Typically 125 peering connections per VPC (varies by provider).

No overlapping IPs: Distinct address spaces required.

These constraints shape architecture. Complex topologies with many VPCs often outgrow peering, requiring Transit Gateways.

When to Choose Transit Gateway Instead

Peering works well for simple topologies—a few VPCs that need point-to-point connections. But as VPC count grows, full-mesh peering becomes unwieldy. Ten VPCs need 45 peering connections for full mesh. Twenty need 190.

Transit Gateways act as central hubs. VPCs connect to the Transit Gateway, which handles routing between them. Benefits:

• Scales to hundreds of VPCs without explosion of connections
• Supports transitive routing (A can reach C through the hub)
• Centralizes routing policy

The tradeoff: Transit Gateways add cost and a small amount of latency. For two to five VPCs, peering is simpler and cheaper. Beyond that, evaluate Transit Gateways.

Monitoring and Troubleshooting

Peering connections can fail silently—the connection exists but traffic doesn't flow. Monitor:

• Connection state: Is the peering connection active?
• Traffic metrics: Is data actually flowing?
• Route presence: Are the expected routes in place?
• VPC Flow Logs: What's happening to traffic at the packet level?

Common issues:

• Routes missing from one or more route tables
• Security Groups blocking traffic that routes correctly
• Peering request never accepted
• Overlapping IP ranges preventing peering establishment

Troubleshoot from both ends. A connection that works A→B but not B→A usually indicates asymmetric configuration.

Security Practices

Peering creates connectivity. Connectivity creates attack surface. Minimize it:

• Allow only necessary traffic between peered VPCs—not blanket access to entire CIDR ranges
• Use Network ACLs for defense in depth at subnet boundaries
• Audit peering connections regularly; remove ones no longer needed
• Monitor cross-VPC traffic patterns for anomalies
• Apply least-privilege principles: if only the database needs access, only the database should have access