What Is VPC Peering?

VPC peering is a network connection between two virtual private clouds that lets resources in each one communicate using private IP addresses, as if they were on the same network — without the traffic ever routing over the public internet. It’s the standard way to connect separate isolated networks, whether they belong to different teams, different environments, or even different cloud accounts entirely.

Why you’d need it at all

A VPC is deliberately isolated by default — that isolation is the whole point of the “private” in virtual private cloud. But real infrastructure rarely lives in a single VPC. Organizations commonly split environments (production, staging, development) into separate VPCs to limit blast radius, or split by team and business unit for billing and access-control reasons, or end up with a shared-services VPC that hosts things like a central logging pipeline or an internal artifact registry that every other VPC needs to reach. Once resources are split across VPCs like that, they need a way to talk to each other privately, and VPC peering is the simplest option for exactly that.

How the connection actually works

Peering establishes a direct network route between two VPCs’ private IP ranges. Each side updates its route tables to point traffic destined for the other VPC’s CIDR block across the peering connection instead of out to the internet or nowhere at all. From an application’s point of view, a peered VPC just looks like another private subnet is reachable — no VPN client, no public endpoint, no NAT gateway involved, because the traffic never needs to leave the cloud provider’s private network to get there.

Peering connections are point-to-point: each one connects exactly two VPCs, and by default they are not transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, A cannot reach C through B — you’d need a direct A-to-C peering connection, or a hub-and-spoke transit solution instead. That non-transitivity is the single most common gotcha teams run into once they have more than a couple of VPCs to connect.

Peering vs. the alternatives

	VPC peering	Transit gateway / hub	Site-to-site VPN
Connects	Two VPCs, point-to-point	Many VPCs through a central hub	A VPC and an external network (e.g. on-prem)
Transitive?	No — each pair needs its own connection	Yes — hub routes between all attached VPCs	N/A
Encryption	Not needed — traffic stays on the provider’s private backbone	Not needed for VPC-to-VPC hops	Yes — traffic crosses the public internet or a dedicated line
Best for	A handful of VPCs, simple mesh	Many VPCs, centralized routing and inspection	Connecting cloud to a physical data center or office
Overlapping IP ranges	Not supported — CIDRs must not overlap	Provider-dependent, often still restricted	Can work around overlap with NAT

The constraint that trips people up: overlapping CIDRs

Two VPCs can’t be peered if their private IP ranges overlap, because routing would then be ambiguous — the network wouldn’t know which VPC a given private IP actually belongs to. This is why IP address planning matters early: if every team provisions VPCs from the same default CIDR block without coordinating, peering them later means re-addressing one of them, which is disruptive to already-running infrastructure. Reserving distinct, non-overlapping ranges per VPC from the start — even if peering isn’t needed yet — avoids that problem entirely.

Security still applies on top

Peering only establishes that a route exists between two VPCs — it doesn’t automatically open every port and every resource to the other side. Security groups and network access control lists still apply on each end, the same way a firewall still filters traffic on a directly connected network. A well-configured peering connection typically allows only specific ports and specific subnets to reach each other, rather than granting blanket access between the two VPCs’ entire address spaces. Treat a peering connection as extending your network boundary, not erasing it.

When peering isn’t enough

Point-to-point peering works well for a small number of VPCs, but it scales quadratically — connecting five VPCs to each other directly means up to ten separate peering connections, and the count keeps climbing from there. Past a handful of VPCs, most teams move to a transit gateway (or equivalent hub-and-spoke service), which centralizes routing through one hub instead of a mesh of point-to-point links, and often adds centralized traffic inspection and a single place to manage route tables. Peering and transit hubs aren’t mutually exclusive either — plenty of architectures use peering for a couple of tightly coupled VPCs (say, an application VPC and its dedicated database VPC) while using a transit hub for everything else. Cross-region and cross-account peering are both generally supported too, which is what makes peering practical for connecting a shared-services VPC to application VPCs owned by separate teams or billing accounts.

Resources on either side of a peering connection typically still resolve each other by hostname rather than hardcoded IPs, which depends on how DNS resolution is configured across the peering connection — most providers let you enable DNS resolution across the peer so private hostnames resolve correctly on both sides, and it’s easy to forget to turn on.

The takeaway

VPC peering connects two isolated virtual networks so their resources can reach each other over private IPs, without touching the public internet or setting up a VPN. It’s simple and has no bandwidth throughput bottleneck of its own, but it’s point-to-point and non-transitive, requires non-overlapping IP ranges, and doesn’t replace security groups or firewalls at the resource level. For a handful of VPCs, direct peering is usually the right call; once you’re connecting many, a transit gateway centralizes what would otherwise become an unmanageable mesh of individual connections.