Connecting VPCs to Other Networks — Peering, VPN, Transit, PrivateLink

Once routing inside a VPC is settled, the next question is how a VPC connects beyond itself — to other VPCs, on-premises data centers, and external SaaS services.

VPC Peering, Transit Gateway, Site-to-Site VPN, and PrivateLink each have their own topology, cost model, and operational trade-offs, and the choice between them shapes the whole system.

VPC Peering

VPC Peering is the simplest option. It connects two VPCs directly so that each can reach the other’s private IP space.

Peering works across the same region and same account, but also across regions and accounts. Its topology is a 1:1 mesh, so connecting three VPCs to each other requires three peerings (A-B, B-C, and A-C).

A key limitation is that transitive routing is not supported. Even with A-B and B-C in place, A cannot reach C through B. Both ends must have a direct peering. As the number of VPCs N grows, the number of peerings required scales as N(N-1)/2, which makes Peering a fit only for a handful of VPCs.

Transit Gateway

Once the number of VPCs starts to grow, Peering’s mesh structure quickly becomes a burden. Transit Gateway addresses this limit.

flowchart LR
    subgraph Peering ["Peering: mesh"]
        VA["VPC A"] --- VB["VPC B"]
        VB --- VC["VPC C"]
        VA --- VC
        VC --- VD["VPC D"]
        VA --- VD
        VB --- VD
    end
    subgraph Transit ["Transit Gateway: hub-spoke"]
        TGW(("TGW"))
        TVA["VPC A"] --- TGW
        TVB["VPC B"] --- TGW
        TVC["VPC C"] --- TGW
        TVD["VPC D"] --- TGW
    end

Transit Gateway acts as a central hub. Multiple VPCs attach as spokes, and traffic between any two spokes flows transitively through the hub. The number of attachments grows linearly with the number of VPCs.

The cost model differs from Peering. Transit Gateway charges per attachment hour plus per byte processed, which makes it more expensive than Peering at small scale. As N grows, the cost balance flips. The option to split routing into multiple route domains also makes it useful for multi-tenant setups that need isolation.

Site-to-Site VPN

Site-to-Site VPN is usually the first option that comes up when a VPC needs to reach an on-premises data center. It builds an IPSec tunnel over the public internet, logically connecting the two networks.

Both static routing and BGP dynamic routing are supported. Because the underlying transport is the public internet, bandwidth and latency are variable, which can be a constraint for mission-critical traffic. When more stable connectivity is required, dedicated-line options like Direct Connect or Cloud Interconnect exist as separate alternatives.

PrivateLink

While the previous three rely on IP routing, PrivateLink is structurally different. Instead of stitching two networks at the IP/CIDR level, it exposes services at the service level.

The service provider creates an endpoint inside its VPC, and the consumer side sees that endpoint as an ENI (Elastic Network Interface) or equivalent inside its own VPC. The IP layout of either VPC is irrelevant — endpoint-level connection sidesteps any CIDR collision.

Direction matters too. PrivateLink is one-way: the consumer calls into the service the provider exposed, and the reverse direction would need a separate endpoint. It is commonly used for SaaS services, internal service exposure, and managed-service entry points into a VPC.

Comparison

Lining up the four mechanisms makes the trade-offs explicit.

CIDR Collision Pitfalls

VPC Peering and Transit Gateway are both IP-routing-based. If two VPCs use overlapping CIDRs, packet destinations become ambiguous and routing breaks down.

Carving up CIDR ranges without overlap from day one avoids the operational cost that surfaces at the connectivity stage. Allocating IP ranges at the organization level pays off especially in environments with many VPCs.

For environments where collisions already exist, PrivateLink is the workaround. Because it does not rely on IP routing, two VPCs with the same CIDR can still talk to each other through service endpoints. The trade-off is that PrivateLink only fits the narrow pattern of “exposing a specific service,” not broad IP-level communication.

Vendor Naming Map

The four mechanisms across vendors:

The names shift slightly, but the abstractions are nearly the same. AWS’s PrivateLink, GCP’s Private Service Connect, and Azure’s Private Link all share the same service-endpoint model.

Wrap-up

External connectivity for a VPC reduces to one of four mechanisms.

• VPC Peering: 1:1 mesh, no transitive routing, fits a small number of VPCs
• Transit Gateway: hub-spoke, transitive, cost balance flips in favor at scale
• Site-to-Site VPN: IPSec tunnel between an on-premises site and a VPC
• PrivateLink: service-endpoint exposure that is independent of IP routing

Which mechanism is chosen effectively decides the topology, cost, and isolation policy of how a VPC connects beyond itself. And because three of the four rely on IP routing, a CIDR collision can render that choice unusable — which is why allocating IP ranges at the organization level from the start is what holds the choice together.

The next article covers security — how Security Groups and NACLs build different layers of defense on top of a VPC.