Connecting VPCs
Peering, Transit Gateway, PrivateLink, VPC Lattice, VPC sharing and Cloud WAN, and how to choose between them.
Exam tasks: 1.1 (evaluate connectivity options for multiple VPCs, use service endpoints), 2.3
The decision: do the VPCs need to reach each other's whole network, or just one service? And how many VPCs are involved?
Choosing an option
Side by side
| VPC peering | Transit Gateway | PrivateLink | VPC Lattice | |
|---|---|---|---|---|
| Shape | 1:1 link | Regional hub and spoke | One-way: consumer → service | Application-layer service network |
| Transitive routing | No | Yes, controlled by TGW route tables | N/A (no routing) | N/A (no routing) |
| Overlapping CIDRs | Not allowed | Not allowed (without NAT) | Fine | Fine |
| Scales to | Full mesh gets unmanageable: 20 VPCs = 190 links | Thousands of attachments | Thousands of consumer VPCs | Many services and VPCs |
| Hybrid (VPN or DX) | Can't use the peer's links | Shared by all attachments | Consumers on-premises can reach the endpoint | — |
| Cost | No hourly fee. Data transfer only | Per attachment-hour + per GB processed | Per endpoint-hour + per GB | Per service-hour + per GB and requests |
| Cross-account | Yes | Share the TGW with RAM | Yes, via allowlisted principals | Share the service network with RAM |
VPC peering
Peering is the cheapest option and the one with the fewest parts, but its routing is deliberately limited:
- No transitive routing. If A is peered with B and B with C, A still can't reach C through B.
- No edge-to-edge routing. A VPC can't use its peer's internet gateway, NAT gateway, VPN, Direct Connect or gateway endpoint.
- No overlapping CIDRs between the two VPCs.
Peering as a hub
An answer that sends traffic through a central VPC over peering, to reach on-premises, the internet or a third VPC, doesn't work. You need a Transit Gateway or an appliance in that central VPC.
Which peer wins? Longest prefix match
A VPC can peer with two VPCs whose CIDRs overlap each other. Its route table then decides where each packet goes, and the most specific matching route always wins.
| Destination from the hub | Matching routes | Goes to |
|---|---|---|
172.20.8.15 | /16 → pcx-a, /24 → pcx-b | Spoke B. The /24 is more specific |
172.20.3.40 | /16 → pcx-a | Spoke A |
172.20.8.99 in Spoke A | /24 → pcx-b | Spoke B. Spoke A's 172.20.8.0/24 is unreachable from the hub |
The last row is what the exam tests: overlapping peers work only if you accept that part of one VPC can't be reached.
Exam signal
If a question mentions overlapping CIDRs, network-level options (peering, Transit Gateway) are out unless NAT is involved. Look for PrivateLink or VPC Lattice, which connect services rather than networks.
Transit Gateway
A regional router that VPCs, VPNs, Direct Connect gateways and other Transit Gateways attach to.
- Segmentation through route tables. For example, put prod and dev attachments in separate route tables that can both reach a shared-services route table but not each other.
- Centralized egress and inspection. Send spokes to one inspection VPC with a NAT gateway or firewall. Turn on appliance mode on that attachment so return traffic uses the same AZ and stateful firewalls don't drop it.
- Hybrid in one place. Terminate a single Direct Connect (transit VIF via a DX gateway) or VPN on the TGW, and every attached VPC can use it.
- Multi-account. The network account owns the TGW and shares it with the organization through AWS RAM.
Cost blind spot
Transit Gateway charges for every GB it processes. For two VPCs that exchange a lot of data, peering can be much cheaper. You can use both: peering for the heavy pair, and the TGW for everything else.
PrivateLink
The provider puts a service behind a Network Load Balancer and publishes it as an endpoint service. Consumers create an interface endpoint in their own VPC, which appears as an ENI with a private IP address.
- Only the consumer can open connections. The provider can't reach into the consumer's network.
- CIDRs don't matter, so it works for thousands of customer VPCs that all use
10.0.0.0/16. - Providers control access by allowlisting AWS principals and can require manual approval of each connection.
This is the standard pattern for a SaaS provider serving many customers.
VPC sharing
The owner account shares subnets with other accounts in the organization through AWS RAM. Participant accounts launch resources directly into those subnets. There's no peering and no attachment: everything is in one VPC.
Use it when a central network team wants to own the IP plan, routing and egress, while app teams keep separate accounts for billing and permissions. Participants can't change the VPC's route tables, NACLs or gateways.
Cloud WAN
A managed global network, defined in one policy document. Segments such as prod, dev and partner behave like isolated routing domains across every Region. Choose it over hand-built TGW peering when a question stresses many Regions, central policy, or SD-WAN and branch integration.
Scenarios
Sixty VPCs, one shared hybrid link and segmentation all point to a Transit Gateway. Route tables handle the prod/dev split, and the transit VIF lets one Direct Connect serve every attachment. Full-mesh peering would need 1,770 links and a VIF per VPC, and VIFs have hard per-connection limits.
Overlapping CIDRs rule out peering and Transit Gateway, and "not over the internet" rules out a public ALB. PrivateLink connects consumers to a single service without joining networks, so overlapping ranges don't matter.
Peering connections don't forward traffic that neither starts nor ends in the peered VPCs. A needs its own peering connection to C, or all three VPCs need to attach to a Transit Gateway.