Three AWS services answer the question “how do these two things talk to each other privately”, and they are routinely treated as interchangeable. They are not. Peering joins two networks, Transit Gateway joins many through a hub, and PrivateLink publishes one service without joining anything at all. Picking the wrong one is rarely fatal. It is usually expensive, slow to unwind, and invisible until the third VPC appears.
VPC peering: a direct line between two networks
A peering connection is a route between exactly two VPCs. No gateway sits in the middle, traffic stays on the AWS backbone, and the connection itself carries no hourly charge — you pay for data transfer, which for most internal traffic is close to nothing.
That price shape is why peering is the correct answer more often than people expect. Two VPCs, one account or two, a shared database and an application tier: peering does the job with one route table entry on each side and no new component to monitor.
The property that catches teams is that peering is not transitive. If A peers with B and B peers with C, A cannot reach C. There is no way to make it work without a third connection. A mesh of four VPCs needs six peerings; six VPCs need fifteen. Each one is a separate resource with its own routes, its own acceptance step and its own security group references.
Peering also fails outright when CIDR blocks overlap. Two teams that both built on 10.0.0.0/16 cannot peer, and no amount of routing fixes it. That single constraint is behind a large share of the redesigns we are asked to price.
Transit Gateway: a hub that scales past a handful of networks
A transit gateway is a regional router. VPCs, VPNs and Direct Connect gateways attach to it, and you control reachability with route tables on the gateway itself rather than by wiring pairs together.
Once a fourth or fifth VPC arrives, the arithmetic flips. Fifteen peerings become five attachments and one routing decision. More usefully, the gateway gives you segmentation that peering cannot express: separate route tables for production, staging and shared services, so staging reaches the shared database but never the production application tier. That is a security boundary, not just a tidier diagram.
The cost model is different in kind. Each attachment has an hourly charge, and every gigabyte that crosses the gateway is billed on top of normal transfer. For a quiet internal network the total is small. For a workload that moves backups, logs and large files between VPCs all day, the per-gigabyte line becomes the dominant item, and a direct peering between the two chatty VPCs is often cheaper while the gateway carries everything else. Hybrid designs like that are normal; treat the hub as the default and the exception as a deliberate cost decision.
Two traps account for most of the support tickets. The first is asymmetric routing: a subnet whose route table points at the gateway while the return path uses a different attachment, which produces connections that open and then hang. The second is forgetting that an attachment is availability-zone aware, so a subnet in a zone with no attachment quietly loses its path.
PrivateLink: publish a service, not a network
PrivateLink reverses the question. Instead of joining two networks so that everything can reach everything, you expose a single service — a listener on a network load balancer, or an endpoint service — and the consumer reaches it through an interface endpoint in their own VPC.
The consequence is that the two sides never share an address space. Overlapping CIDRs stop mattering, because no route between the networks exists. The consumer’s traffic appears as an elastic network interface inside their own VPC, which means their security groups, their flow logs and their DNS still apply. For a partner integration, a SaaS product sold to other companies, or a shared internal API owned by a different team, that isolation is the entire point.
It is the wrong tool when you need general connectivity. Every exposed service needs its own endpoint, each endpoint has an hourly cost per zone and a data charge, and anything that is not published is simply unreachable. Teams that try to run an entire application estate over PrivateLink end up with dozens of endpoints and a diagram nobody can defend.
When on-premises joins the picture
A single office or data centre connecting to AWS has two options. Site-to-Site VPN is software-defined, works over any internet link, and can be running the same afternoon. Direct Connect is a physical circuit from a provider’s location, with predictable latency and bandwidth, and a lead time measured in weeks rather than hours.
The pattern that survives is both: Direct Connect as the primary path and a VPN as the backup, with BGP choosing between them. If the on-premises estate is more than a token system, the VPN-only design will eventually be the thing that fails during a provider outage.
Where that link lands matters too. A VPN can terminate on a single VPC, but every additional VPC then needs its own tunnel or a chain of peerings. Terminating on a transit gateway once, and letting attachments carry the reachability, is the version that still makes sense at eight VPCs.
The decision, in one table
| Situation | Use | Why |
|---|---|---|
| Two VPCs, stable, no plans to grow | VPC peering | No hourly connection fee, one route each side |
| Three or more VPCs, or on-premises joining | Transit Gateway | One attachment per network, segmentation by route table |
| Exposing one API to a partner or customer | PrivateLink | No shared address space, consumer keeps their own controls |
| Overlapping CIDRs on both sides | PrivateLink | Peering and gateway routing both require unique ranges |
| Heavy east-west traffic between two VPCs | Peering beside the hub | Avoids per-gigabyte gateway charges |
| On-premises, production dependency | Direct Connect plus VPN backup | Predictable path with a working failover |
The traps that cost the most time
Overlapping ranges. Check every VPC’s CIDR before designing anything. A /16 collision discovered after the gateway is built means rebuilding one side’s addressing, which is a migration, not a network change.
DNS resolution flags. Peering and gateway attachments both have DNS options that are off by default. A private hosted zone that resolves in one VPC and not the other produces the confusing symptom of a working connection and a failing application.
Security groups that reference each other. Referencing a security group across a peering or gateway connection works, but only when the attachment and the route both exist. Referencing one across PrivateLink does not, because the consumer sees an interface, not the source group.
Route tables you forgot. A subnet with an explicit route table ignores the main table’s routes. New subnets added by a later deployment therefore behave differently from the ones that were tested.
Assuming the hub is free. Model the data processing charge against actual traffic, not against a diagram. The attachment fee is predictable; the per-gigabyte line is the one that surprises finance.
How we sequence this work
We start from the workload map, not from the network diagram: which systems must talk, how much data moves, and which pairs must never reach each other. The connection choice follows from those three answers, and the cost model is checked before anything is built rather than after the first invoice.
The account and VPC groundwork sits in our AWS cloud setup engagement. If the estate is large enough to need several accounts with centralised networking, that is the multi-account scope on cloud landing zone setup. Moving existing systems onto the network afterwards is covered under AWS cloud migration, and the per-gigabyte costs of private connectivity are examined in NAT gateway vs VPC endpoints.
FAQ
Do we need Transit Gateway if we only have two VPCs?
No. Two VPCs with no near-term plan to add more are cheaper and simpler on a peering connection, because there is no hourly attachment charge and no extra component to monitor. Revisit the decision when a third network appears, or when on-premises connectivity becomes a requirement.
Can VPC peering work with overlapping CIDR ranges?
It cannot. Peering requires unique address ranges on both sides, and so does routing through a transit gateway. If the ranges already overlap, publishing the specific service through PrivateLink is the route that does not require readdressing either network.
Is PrivateLink a replacement for a VPN?
Only for one narrow case: reaching a single published service. A VPN carries whole networks, including management access, directory traffic and anything else your team needs. PrivateLink exposes what you choose to publish and nothing else, which is a strength for partners and a limitation for internal staff access.
Why does a connection open and then hang after moving to a transit gateway?
That symptom usually means asymmetric routing. The outbound path points at the gateway while the return path uses a different attachment or a local route, so the handshake completes and the data never arrives. Compare the route tables on both sides of the flow before touching security groups.
Does traffic through a transit gateway cost more than peering?
It depends on volume. The gateway adds an hourly attachment charge plus a per-gigabyte processing fee, while peering adds only normal data transfer. For light internal traffic the difference is minor; for constant replication or backup traffic between two VPCs, a direct peering alongside the hub usually pays for itself.
What is the realistic lead time for Direct Connect?
Plan in weeks, not days. The circuit is ordered through a provider at a location where AWS is present, then cross-connected and tested, and the BGP configuration has to be agreed with whoever owns the on-premises router. A VPN on the same router is worth configuring first so the hybrid design has a working fallback from day one.
