Private Connectivity Between Networks
A single VPC (see VPCs, Subnets & Routing) is isolated by default - nothing routes into it or out of it unless you add a connection. Cloud providers offer several ways to connect networks together privately, and picking the right one is mostly a question of who you're connecting to and how many networks are involved.
| Concept | AWS | GCP | Azure |
|---|---|---|---|
| Direct VPC-to-VPC routing | VPC Peering | VPC Network Peering | VNet Peering |
| Encrypted network-to-network tunnel | Site-to-Site VPN | Cloud VPN | Site-to-Site VPN Gateway |
| Private endpoint to a managed/other-VPC service | PrivateLink | Private Service Connect | Private Link |
| Hub for many VPCs at once | Transit Gateway | Network Connectivity Center | Virtual WAN |
VPC peering
Peering connects two VPCs directly: each side adds routes pointing at the other VPC's CIDR range, and traffic flows over the provider's internal backbone rather than the public internet - no encryption tunnel needed because it never leaves the provider's network.
The detail worth remembering is that peering is non-transitive: if VPC A is peered with VPC B, and VPC B is peered with VPC C, A cannot reach C through B. Each pair that needs to talk needs its own peering connection, which is exactly why peering degrades into an unmanageable mesh once you have more than a handful of VPCs - the number of connections grows quadratically with the number of networks.
Two VPCs with overlapping address space can't be peered - the router has no
way to decide which network 10.0.1.5 refers to. This is why organizations
plan VPC CIDR allocation centrally up front rather than letting every team
pick their own 10.0.0.0/16.
Site-to-site VPN
When you need to connect a VPC to a network you don't control at the provider level - most commonly an on-premises data center - site-to-site VPN builds an encrypted tunnel over the public internet between a gateway in the VPC and a gateway on the other network. The tunnel mechanics are exactly IPsec as covered in VPNs & IPsec: tunnel mode ESP, wrapping the original packets so the two private address spaces can route to each other without ever exposing their internal addressing on the public path.
The tradeoff versus peering: a VPN works with any network regardless of who runs it, but it rides the public internet (so it has variable latency and a bandwidth ceiling) unless paired with a dedicated private circuit (AWS Direct Connect, GCP Dedicated Interconnect, Azure ExpressRoute) - those dedicated links are a physical/telecom topic beyond this module's scope.
Private endpoints (PrivateLink / Private Service Connect)
Peering and VPN both connect two entire networks. Often you don't want that - you want to reach one specific service (a managed database, a SaaS product, a specific internal service in another team's VPC) over a private IP, without exposing either side's full address space to the other and without the non-transitivity headaches of peering.
A private endpoint (AWS PrivateLink, GCP Private Service Connect, Azure Private Link) solves this by publishing a single service behind a private IP address that lives inside your own VPC. Your instances call that private IP directly; the traffic never traverses the public internet and the provider's network handles routing it to the actual service, wherever it's hosted. The consuming side doesn't get routes into the producer's whole network - just reachability to the one exposed service.
Reaching a managed service (say, a hosted database or an internal API) over its public endpoint means that connection is, from a network perspective, indistinguishable from any other internet-facing traffic - subject to public routing, and a target for anything scanning public IP space. A private endpoint keeps that same call entirely inside private address space, which is frequently a hard compliance requirement, not just a nice-to-have.
Connecting many VPCs: transit gateways / hub-and-spoke
Once an organization has more than a few VPCs that all need to reach each other, pairwise peering becomes unworkable. A transit gateway (or equivalent hub) is a single routing hub that many VPCs attach to once, instead of peering with every other VPC individually - turning an unmanageable full mesh into a hub-and-spoke topology where each VPC has one connection to the hub, and the hub's route table decides what can reach what. Unlike peering, traffic between two spokes can transit through the hub, which is the whole point.