What happens when your AWS network grows from three VPCs to three hundred, and the person who built the original peering mesh has left the company? That question sits at the heart of one of the most consequential choices in cloud networking: how to connect workloads privately. Three tools dominate the answer, and they are not interchangeable. VPC peering is a direct, one-to-one link. AWS Transit Gateway is a regional hub that routes traffic between many networks. AWS PrivateLink exposes a single service to consumers without joining their networks at all. Each solves a different problem, and picking the wrong one costs money, time, or both.
This article walks through how each option actually behaves, where teams get burned, and what to weigh when designing networks that must survive the next few years of growth.
The Three Options at a Glance
Before diving into mechanics, it helps to see the shape of each choice.
| Feature | VPC Peering | Transit Gateway | PrivateLink |
|---|---|---|---|
| Topology | One-to-one | Hub-and-spoke | Service-to-consumer |
| Transitive routing | No | Yes | Not applicable |
| CIDR overlap tolerated | No | No | Yes |
| Scales to many VPCs | Poorly | Well | Well |
| Main cost driver | Data transfer | Attachments plus data | Endpoint hours plus data |
| Typical use | Two VPCs, one link | Centralized enterprise network | Exposing a service to customers or teams |
The table hides nuance, of course. The real decision depends on how many networks you have, whether their IP ranges collide, and whether you are connecting whole networks or just one service.
VPC Peering: Simple, Fast, and Easy to Outgrow
VPC peering creates a direct network route between two VPCs. They can live in the same account, in different accounts, or even in different Regions. Traffic stays on the private AWS backbone, never touching the public internet. For two VPCs that need to talk, it is the simplest and often cheapest option. (Virtual private network (Wikipedia))
The catch is what peering cannot do. According to the AWS VPC peering documentation, peering connections are not transitive. If VPC A peers with VPC B, and B peers with C, then A cannot reach C through B. Every pair that needs to communicate requires its own connection. (What is Amazon VPC? (AWS documentation))
That limitation produces a familiar arithmetic problem. Ten VPCs in a full mesh need 45 peering connections. Fifty VPCs need 1,225. Each connection also needs route table entries on both sides, and every new VPC means touching every existing one. Teams that start with peering often end up with a tangle of routes that nobody fully understands, which is exactly when outages happen.
Peering also refuses to work when CIDR blocks overlap. If two VPCs both use 10.0.0.0/16, they cannot peer, full stop. In organizations where teams spin up VPCs independently with default templates, overlap is common, and fixing it means re-IP-ing workloads. That is about as fun as it sounds.
Where peering shines: a small number of VPCs, a stable topology, or a single high-traffic link between two networks where you want the most direct path possible.
Transit Gateway: The Hub That Makes Scale Manageable
AWS Transit Gateway, introduced in 2018, acts as a regional router. VPCs, VPNs, and Direct Connect gateways attach to it, and it routes traffic between them. Because the hub handles routing centrally, connections become transitive: attach fifty VPCs to one Transit Gateway and they can all reach each other through it, subject to route table rules.
This changes the operational math completely. Fifty VPCs need fifty attachments, not 1,225 connections. New VPCs attach to the hub, and existing networks do not need to change. Transit Gateway also supports segmentation through multiple route tables, so you can keep production, development, and shared services isolated while still routing through one hub.
Transit Gateway peering extends the model across Regions, letting you build global hub-and-spoke networks without a full mesh. For organizations with dozens or hundreds of VPCs, this is usually the only sane path. AWS’s own guidance on scalable multi-VPC networks treats the hub model as the standard answer once peering meshes become unmanageable.
The trade-offs are real, though. Transit Gateway charges per attachment and per gigabyte processed, so a busy network pays for the convenience. It also introduces a shared dependency: if the hub’s route tables are misconfigured, many networks suffer at once. And like peering, Transit Gateway attachments still require non-overlapping CIDR ranges. If your IP space is a mess, the hub does not rescue you.
A useful pattern is to treat the Transit Gateway as a routing domain boundary. Put shared services in one segment, production in another, and control what crosses between them with explicit route table associations. Teams that skip this step end up with a flat network where a compromised development instance can reach production databases. The hub makes connectivity easy; it does not make security automatic. For a deeper look at how modern gateways fit into broader cloud architecture, see this breakdown of cloud API management architecture and modern gateways.
PrivateLink: When You Only Need One Service
PrivateLink takes a different approach entirely. Instead of connecting networks, it exposes a specific service, such as an internal load balancer, to consumers through an endpoint in their own VPC. The consumer’s traffic goes to a network interface in their subnet and reaches the provider’s service privately.
The big advantage is that PrivateLink does not care about CIDR overlap. Because it uses endpoint network interfaces rather than routing between VPC address spaces, two networks with identical IP ranges can still communicate through PrivateLink. For organizations with messy IP allocation, or for SaaS providers serving many customers, that is a genuine superpower. The AWS PrivateLink documentation explains the endpoint model and its directionality: the provider publishes, the consumer connects.
PrivateLink is also narrow by design. A consumer gets access to one service, not the whole provider network. That limits blast radius and simplifies security reviews. If a team needs to call a payment service or a shared logging API, PrivateLink is often cleaner than opening a network path.
The limits matter too. PrivateLink is not a general-purpose network connection. It does not let you route arbitrary traffic between VPCs, and it is not a substitute for a hub when you need many-to-many connectivity. It also has its own cost structure, with per-endpoint hourly charges plus data processing, which can add up if you create endpoints casually.
Common Mistakes That Show Up in Real Deployments
Several patterns repeat across teams that get this wrong.
- Starting with a peering mesh and never migrating. The mesh works at five VPCs and becomes unmaintainable at thirty. Migrating later means re-architecting routes under production load.
- Assuming Transit Gateway solves CIDR overlap. It does not. Overlapping ranges still break attachments, and fixing them after the fact is painful.
- Using PrivateLink for general connectivity. Teams sometimes try to route broad traffic through endpoints and discover the model does not support it.
- Ignoring data transfer costs until the bill arrives. Cross-AZ and cross-Region traffic charges can dwarf the connection fees themselves.
- Building a flat hub with no segmentation. One route table for everything means no isolation between environments.
The practical fix is to decide the topology before the tenth VPC, not the hundredth. Teams that plan IP allocation early, reserve ranges per environment, and pick a hub model before the mesh forms avoid most of these problems. For related guidance on designing secure network foundations, this tutorial on building a secure VPC the right way covers the fundamentals.
How to Choose: A Decision Framework
The choice usually comes down to a few questions.
How many networks need to talk? Two or three, and peering is fine. Dozens or more, and a hub model pays for itself.
Do the CIDR ranges overlap? If yes, PrivateLink may be the only option for the specific service involved. If no, peering or Transit Gateway are both viable.
Do you need whole-network connectivity or just one service? Whole networks point to peering or Transit Gateway. A single service points to PrivateLink.
What is the traffic volume? High-volume, stable links between two VPCs are often cheapest with peering. Bursty or moderate traffic across many networks fits the hub model better.
How much operational complexity can the team absorb? Peering is simple per link but complex in aggregate. Transit Gateway is complex up front but simpler at scale. PrivateLink is simple per service but does not generalize.
Most mature architectures end up combining all three. A Transit Gateway handles east-west traffic between internal VPCs. PrivateLink exposes shared services to teams without full network access. Peering may remain for a single high-throughput link where the direct path matters. The tools are complementary, not competing.
What Changes as Networks Mature
Two trends push organizations toward hub-and-endpoint models. First, IP space keeps shrinking as accounts multiply, making overlap more likely and peering less practical. Second, security teams increasingly prefer narrow, service-level access over broad network paths, which favors PrivateLink for shared services.
Transit Gateway continues to absorb features that used to require third-party appliances, including centralized inspection and cross-Region routing. That makes the hub model more attractive over time, though it also concentrates risk in one place. Teams should plan for the hub’s availability and monitor its route tables as carefully as any critical system.
For organizations running across multiple providers, the same design questions reappear in different forms; this guide to multi-cloud metrics across AWS, Azure, and Google Cloud covers how to keep visibility consistent when networks span providers.
Conclusion
The choice between VPC peering, Transit Gateway, and PrivateLink is not about which one is best. It is about which one matches the shape of the problem. Peering is a direct wire between two networks and stays excellent as long as the count stays small. Transit Gateway is the router that makes many networks manageable, at the cost of central dependency and per-gigabyte charges. PrivateLink is the scalpel that exposes one service without joining networks, and it is the only one of the three that shrugs at overlapping CIDR ranges.
Teams that decide early, reserve IP space deliberately, and combine the tools rather than treating them as rivals end up with networks that scale without drama. Teams that default to peering because it is easy on day one often spend year three untangling it. The architecture decision is really a bet on how big the network will get, so make it with the future in mind.
FAQ
What is the main difference between VPC peering and Transit Gateway?
VPC peering is a direct one-to-one connection between two VPCs and does not support transitive routing. Transit Gateway is a central hub that many VPCs attach to, allowing traffic to flow between all of them through a single routing point.
Can PrivateLink work when two VPCs have overlapping CIDR ranges?
Yes. PrivateLink uses endpoint network interfaces rather than routing between VPC address spaces, so overlapping CIDR blocks do not block it. That makes it useful when IP ranges cannot be changed.
Is Transit Gateway always more expensive than VPC peering?
Not always, but often for high traffic volumes. Transit Gateway charges per attachment and per gigabyte processed, while peering has no connection fee but incurs data transfer charges. At small scale, peering is usually cheaper; at large scale, the hub’s operational savings often outweigh its fees.
How many VPC peering connections does a full mesh require?
The number grows quickly: n(n−1)/2 connections for n VPCs. Ten VPCs need 45 connections, and fifty need 1,225. That growth is the main reason teams migrate to a hub model.
Does Transit Gateway solve CIDR overlap problems?
No. Transit Gateway attachments still require non-overlapping CIDR ranges, just like peering. Overlapping ranges must be re-IP’d or connected through PrivateLink instead.
When should a team use all three options together?
Most mature networks do. Transit Gateway handles internal east-west traffic, PrivateLink exposes specific shared services, and peering may remain for a single high-throughput link. The tools address different needs and combine well.
