AWS VPC Connectivity Decision Guide - VPC Peering, Transit Gateway, PrivateLink, VPC Lattice, and Cloud WAN
First Published:
Last Updated:
This guide is a decision hub. It does not re-teach every detail of each service; instead it gives you a single framework for choosing among them and then hands off to the deep-dive articles for the per-service mechanics. If you want the full mechanics of endpoints, see the AWS PrivateLink and VPC Endpoints Complete Guide; for service-to-service networking, see the AWS VPC Lattice Complete Guide; for routed and hybrid design depth (CIDR planning, Transit Gateway, VPN, Direct Connect, Cloud WAN), see the VPC Design Review Checklist. For terminology, the AWS Networking Glossary defines every term used here, and the AWS History and Timeline regarding Amazon VPC tracks when each capability launched.
This article answers three questions:
- What is each option actually for? What model of connectivity does it implement — joining networks, or exposing services?
- How do I choose from requirements? Given the number of VPCs, growth, CIDR situation, Region footprint, and whether you need Layer 7 or identity, which primitive fits?
- How do I combine and migrate? Real architectures rarely use one option in isolation. How do the pieces stack, and how do you move from one model to another without a rebuild?
Terminology note. Throughout, "Layer 3 (L3)" means IP-level routing — packets move between networks based on destination IP. "Layer 4/7 (L4/L7)" means the connection is brokered at the transport or application layer, where the underlying networks need not be routable to each other at all. This distinction is the backbone of the whole decision.
1. Why Connectivity Choice Became the Hard Part
In a single account with two or three VPCs, connectivity is trivial. The trouble starts at scale. AWS customers routinely run hundreds of accounts and VPCs to segment workloads, and at that size three problems dominate: interconnecting VPCs, sharing services without sharing whole networks, and reaching on-premises facilities — all while keeping IP addressing sane and costs controlled.The connectivity options accumulated over time precisely because no single model solves all of those problems well:
- VPC peering gives you direct, private VPC-to-VPC reachability, but it does not route transitively, so it does not scale to a large mesh.
- Transit Gateway solves the mesh problem with a Regional hub that routes transitively between many attachments.
- PrivateLink solves a different problem entirely: exposing or consuming a single service privately, without joining the two networks or caring about their CIDRs.
- VPC Lattice raises that idea to application-level service-to-service connectivity, with built-in identity and Layer 7 routing.
- Cloud WAN addresses the global, multi-Region, policy-driven WAN that a single Regional Transit Gateway cannot express on its own.
- A newer family — resource configurations, resource gateways, and resource VPC endpoints — bridges the endpoint world and the Lattice world, letting you share an individual resource (such as a database) privately by ARN, IP, or domain name.
Because each one occupies a different point in the design space, picking the wrong one is expensive to undo. A peering mesh that grew past its comfortable size, a Transit Gateway used to bolt together two stable VPCs that never needed a hub, or full network routing established just so one team could call one API — these are the recurring mistakes this guide is built to prevent.
The single most useful mental model is this: decide first whether you need to connect networks or expose services. Everything else follows from that fork.
2. The Connectivity Options at a Glance
Before the flowchart, it helps to see all the options on one axis. The deepest divide is connection model: some options join networks at Layer 3 so that any resource in one VPC can address any resource in another by IP; others broker access to a specific service or resource at Layer 4/7, leaving the underlying networks unrouted and even allowing their CIDRs to overlap.
The table below summarizes the practical attributes that drive selection. It is sortable in the browser.
* You can sort the table by clicking on the column name.
| Option | Connection model | Transitive routing | CIDR overlap tolerated | Typical scope | Management boundary | Best fit |
|---|---|---|---|---|---|---|
| VPC Peering | Network (L3) | No | No (IPv4 or IPv6 CIDRs must not overlap) | A few VPCs | Per-pair; both owners edit route tables | 2–3 stable VPCs needing full IP reachability |
| Transit Gateway | Network (L3) | Yes (via route tables) | No (one VPC attachment per VPC; CIDRs must be unique) | Many VPCs in one Region | Central hub; route-table association/propagation | Regional hub-and-spoke for many VPCs/accounts |
| Cloud WAN | Network (L3) | Yes (policy-driven) | No | Many VPCs across many Regions | Central declarative core network policy | Global, multi-Region, segment-based WAN |
| PrivateLink | Service (L4) | N/A (no routing between VPCs) | Yes | One service or resource at a time | Provider exposes; consumer creates endpoint | Private one-way access to a specific service/resource |
| VPC Lattice | Service (L4/L7) | N/A (service network, not routing) | Yes | Service-to-service across VPCs/accounts | Service network owner + service owners | Application-level east-west with identity and L7 |
A few attributes deserve emphasis because they are decisive in practice:
- Transitivity. Peering is non-transitive: if VPC A peers with B and B peers with C, A cannot reach C through B. Transit Gateway and Cloud WAN are transitive by design — that is the entire point of a hub. The service-layer options do not "route" at all, so transitivity is not even a meaningful question for them.
- CIDR overlap. L3 options cannot connect networks whose address ranges overlap, because routing becomes ambiguous. The service-layer options are indifferent to CIDR overlap, because the consumer talks to an endpoint or a service name, not to the provider's IP space. This single property frequently forces the decision when you inherit overlapping networks from acquisitions or independent teams.
- Direction and exposure. Network connections are bidirectional and broad: once routed, anything in one VPC can reach anything in the other (subject to security groups and NACLs). Service exposure is narrow and typically one-directional: a consumer initiates a connection to a specific service, and nothing else becomes reachable.
The rest of this guide turns these attributes into a step-by-step decision and then into concrete per-option guidance.
3. The Decision Flowchart
The flowchart below is the heart of this guide. Walk it top to bottom; each branch narrows the field until one or two options remain. The questions are ordered so that the most decisive distinctions come first.
3.1 Question 1: Connect networks, or expose a service?
This is the fork that everything hinges on. Ask what the workload actually needs:- If consumers need to reach one specific service or resource — an API, an application behind a load balancer, a database — and you do not want the two networks to become mutually routable, you are in service-exposure territory: PrivateLink or VPC Lattice. Skip to Question 5.
- If resources in one network need general IP reachability to resources in another — arbitrary ports, multiple services, bidirectional traffic — you are in network-connection territory: peering, Transit Gateway, or Cloud WAN. Continue to Question 2.
A useful tell: if you find yourself wanting to "just route the whole VPC" only so that one client can call one endpoint, stop. That is the classic over-connection mistake; the service layer exists exactly for that case and avoids exposing everything else.
3.2 Question 2: How many VPCs, and how fast is that growing?
Within network connection, scale decides between a direct mesh and a hub:- Two or three VPCs, stable count → VPC peering is the simplest, lowest-overhead choice. There is no hub to operate, traffic uses AWS infrastructure with no single bandwidth bottleneck, and inter-Region peering traffic stays on the AWS backbone.
- Four or more VPCs, or a count you expect to grow → you need a hub. A full peering mesh grows as n(n-1)/2 connections (20 VPCs would need 190 peerings), and each VPC has a ceiling on active peering connections, so the mesh becomes unmanageable well before you hit hard limits. Move to Question 3 to choose which hub.
The crossover is about operational manageability, not a hard numeric limit. Even a handful of VPCs that all need to reach each other can justify a hub if you expect the topology to keep changing.
3.3 Question 3: One Region, or many — and do you want centralized policy?
Both hub options are transitive; the difference is geographic reach and how you express intent:- Many VPCs concentrated in one Region → Transit Gateway. It is a Regional virtual router; attach VPCs, VPNs, and Direct Connect gateways, and control reachability with route-table association and propagation. It is the default Regional hub.
- A handful of Regions you are content to wire manually → Transit Gateway in each Region, connected by inter-Region Transit Gateway peering. This keeps you in the Transit Gateway model and is reasonable up to a small number of Regions.
- Many Regions, or you want to manage the whole global network from one declarative policy → Cloud WAN. Instead of stitching Regional hubs by hand, you describe segments, which Regions each segment spans, and how attachments map to segments in a single core network policy document; Cloud WAN deploys it. This is the right tool when the global topology and its segmentation are themselves the thing you need to manage.
The practical crossover between many Transit Gateways and Cloud WAN is roughly when manual inter-Region peering and per-Region route-table maintenance start to dominate your operational effort. Cloud WAN does not replace Transit Gateway — the two interoperate, covered in Section 8 and Section 9.
3.4 Question 4: Do the networks have overlapping CIDRs?
If you reached here you wanted a network connection, but L3 options cannot connect overlapping address space. If CIDRs overlap and you cannot re-IP:- Re-evaluate whether you truly need full network reachability. Often the real requirement is access to a few services, in which case the service layer (PrivateLink or VPC Lattice) sidesteps the overlap entirely — the consumer addresses an endpoint or service name, never the provider's overlapping IPs.
- If you genuinely need routing across overlapping space, you are into NAT-based workarounds (private NAT, overlapping-CIDR designs), which are an advanced topic covered in the design material, not a clean primitive choice.
CIDR overlap is the most common reason a "network" requirement quietly becomes a "service" requirement.
3.5 Question 5: Within service exposure — consume a service, or connect services with identity?
If Question 1 sent you to the service layer, this question splits it:- A consumer needs private, typically one-way access to a specific service or resource — an AWS service, a SaaS/partner service, your own service behind a Network Load Balancer, or an individual resource like an RDS database → PrivateLink (interface, Gateway, or the newer resource endpoint). The connection is consumer-initiated and narrow.
- Many services need to call each other across VPCs and accounts, and you want application-level features — Layer 7 routing, weighted/canary traffic, and IAM-based authentication and authorization between services → VPC Lattice. It builds a logical service network rather than a set of point connections, and it is designed for east-west, service-to-service traffic.
A rule of thumb: PrivateLink is "I want to reach that one thing privately"; Lattice is "I want my services to talk to each other as a managed mesh, with identity and routing."
3.6 The resource-based bridge
One more building block deserves a place in the flow because it blurs the old boundary. AWS now lets you define a resource configuration (a database by ARN, an IP address, or a domain name) reachable through a resource gateway, and consume it from another VPC either via a resource VPC endpoint (the PrivateLink path) or by associating it with a service network (the Lattice path). If your requirement is "share this one specific resource privately, without an NLB and without joining networks," this family is often the cleanest answer and is shared between Sections 6 and 7. It is the practical "sixth option" alongside the classic five.4. VPC Peering
VPC peering creates a direct, private networking connection between exactly two VPCs, letting their resources communicate using private IP addresses as if they were on the same network. It works across accounts and across Regions, supports IPv4 and IPv6, uses existing AWS infrastructure with no single point of failure or bandwidth bottleneck, and keeps inter-Region traffic on the AWS backbone rather than the public internet.4.1 When peering is the right call
Peering shines when the topology is small and stable:- Two or three VPCs that need full IP reachability between them.
- A low-overhead requirement where standing up and operating a hub is not justified.
- A specific pair that needs a direct path — for example, a shared-tools VPC that a couple of application VPCs talk to.
To establish it, one VPC owner sends a request, the other accepts, and both owners then manually configure route tables and security groups to allow the private-IP traffic. DNS resolution across the peering can optionally be enabled so that public hostnames resolve to private addresses.
4.2 The consequence of non-transitivity
Peering does not support transitive routing. If A is peered to B and B is peered to C, A still cannot reach C — there is no path "through" B. Every pair that must communicate needs its own direct peering connection. Likewise, you cannot reach on-premises through a peered VPC's Direct Connect or VPN: each VPC needs its own hybrid connectivity, or a transit hub. This is not a bug; it is what keeps peering simple and predictable. But it is exactly why peering does not scale.4.3 Where the mesh breaks down
A fully connected peering mesh requires n(n-1)/2 connections: 5 VPCs need 10, 10 need 45, 20 need 190. There is also a ceiling on the number of active peering connections per VPC (50 by default, adjustable up to 125), and VPCs with overlapping IPv4 or IPv6 CIDR blocks cannot be peered at all. Long before you hit a hard limit, the route-table and security-group maintenance across every pair becomes the bottleneck. When you find yourself adding peerings on a regular basis, or wishing A could reach C "through" B, that is the signal to move to a hub — see Section 10 for the migration path. The VPC Design Review Checklist covers the route-table and CIDR mechanics in design depth.5. Transit Gateway
AWS Transit Gateway is a Regional virtual router. Routing through it operates at Layer 3: packets are forwarded to a next-hop attachment based on destination IP, and the gateway scales elastically with traffic volume. Because every attachment can reach every other attachment that its route table allows, Transit Gateway is transitive — it solves the mesh problem that peering cannot.5.1 Attachments and the hub-and-spoke model
You attach resources to a Transit Gateway: one or more VPCs, VPN connections, Direct Connect gateways, Transit Gateway Connect attachments (for SD-WAN), and peering connections to other Transit Gateways. For a VPC attachment, the gateway places an elastic network interface in a subnet per Availability Zone; traffic in a given AZ reaches the gateway only if there is an attachment subnet in that same AZ. A VPC's own route table sends inter-VPC destinations to the Transit Gateway, and the gateway's route table forwards onward to the destination attachment. The result is a clean hub-and-spoke: add a VPC by attaching it, not by wiring N new peerings.A single Transit Gateway supports up to 5,000 attachments and 10,000 routes by default, with up to 100 Gbps per VPC attachment per Availability Zone — ample headroom for large Regional networks. The attachment quota is adjustable through Service Quotas, while raising the 10,000-route ceiling is handled by request to your AWS account team (SA/TAM) rather than self-service. Note that Transit Gateway allows only one VPC attachment per VPC, and attached VPC CIDRs must be unique (no overlap), consistent with its L3 nature.
5.2 Route-table separation for segmentation
The real power of Transit Gateway is multiple route tables. Each attachment is associated with one route table (which decides what that attachment can reach) and can propagate its routes into one or more route tables (which decides who can reach it). By controlling association and propagation, you implement segmentation patterns directly in the hub:- Centralized router — one route table, every VPC reaches every other VPC. The simplest full-mesh-equivalent.
- Isolated VPCs — each spoke is associated with a route table that does not include the other spokes, so spokes cannot talk to each other while still reaching shared destinations.
- Isolated VPCs with shared services — spokes are isolated from each other but all reach a shared-services VPC (directory, logging, common tooling), and the shared-services VPC can reach all spokes. This is one of the most common production layouts.
- Centralized egress and inspection — spokes route internet-bound or east-west traffic through a central VPC hosting NAT gateways or a firewall appliance (appliance mode preserves flow symmetry for stateful inspection).
These are official Transit Gateway reference scenarios; the design-depth treatment of route-table layout, attachment subnet sizing, and multi-account sharing via AWS Resource Access Manager lives in the VPC Design Review Checklist.
5.3 Multi-account operation
In a multi-account organization, you typically create the Transit Gateway in a central networking account and share it with member accounts using AWS Resource Access Manager. Member accounts then attach their VPCs to the shared gateway. This keeps the hub and its route-table policy under central governance while letting application teams own their VPCs. When the network spans more than a few Regions, inter-Region Transit Gateway peering connects Regional hubs — but note that Transit Gateway peering supports static routes only, which is one of the practical frictions that pushes large global networks toward Cloud WAN (Section 8).6. PrivateLink
AWS PrivateLink implements the other half of the connectivity world: it lets a consumer reach a specific service or resource privately, without joining the two networks and without any concern for overlapping CIDRs. Traffic flows through elastic network interfaces (or a gateway route) inside the consumer's own subnets, so from the consumer's perspective the service appears to live locally. Because there is no network-to-network routing, nothing in the provider's VPC becomes reachable beyond the exposed service. This article treats PrivateLink only at the decision level; the AWS PrivateLink and VPC Endpoints Complete Guide is the full reference for endpoint types, DNS, endpoint policies, cross-Region access, and cost.6.1 The "deliver a service without connecting networks" model
The key mental shift is that PrivateLink is not a routing technology. You are not making VPC A able to address VPC B; you are publishing a single endpoint that consumers connect to. That is why PrivateLink is the natural answer whenever:- A consumer needs only one service, not general reachability.
- The provider and consumer networks have overlapping CIDRs, so L3 connection is impossible.
- You want a hard guarantee that exposure is limited to exactly one service and is consumer-initiated.
6.2 The endpoint family
At the decision level, it is enough to know there are a few flavors, each for a different target:- Interface endpoints provide private access to AWS services and to your own (or partner) services published as a PrivateLink endpoint service behind a Network Load Balancer.
- Gateway endpoints provide private access to Amazon S3 and DynamoDB via route-table entries (a distinct, no-ENI mechanism that does not itself use PrivateLink).
- Resource endpoints are the newer path: they privately reach an individual resource — an RDS database by ARN, an IP address, or a domain name — through a resource gateway, with no Network Load Balancer required. Resource endpoints carry TCP traffic and are consumer-initiated.
One important scoping fact for the decision: a PrivateLink endpoint service is available only in the Region in which it is created. Cross-Region consumption is possible through specific mechanisms (covered in the PrivateLink guide) but is not automatic, so Region footprint is part of the choice.
6.3 The resource bridge in context
The resource gateway and resource configuration that power resource endpoints are the same building blocks that VPC Lattice uses to share resources into a service network (Section 7). That overlap is deliberate: AWS factored out "share this one resource privately" into a reusable layer that both the PrivateLink-style endpoint and the Lattice-style service network can consume. When your requirement is precisely "let another VPC reach this one database privately, by ARN, without an NLB or network peering," reach for this family and decide afterward whether you consume it as a resource endpoint or through a service network.7. VPC Lattice
Amazon VPC Lattice raises service exposure to the application layer. Instead of publishing individual endpoints, you create a service network — a logical boundary that groups services and resource configurations and provides authorized discovery, connectivity, and observability among them. It is built for east-west, service-to-service traffic across VPCs and accounts, with Layer 7 routing and IAM-based authorization built in. As with PrivateLink, this guide stays at the decision level; the AWS VPC Lattice Complete Guide covers core concepts, listeners and routing, auth policies, and implementation in full.7.1 The service-to-service model
Lattice connects services, not networks. A client in a VPC can reach services in a service network only if that VPC is connected to the network — either by a direct VPC association or via a service network VPC endpoint. A VPC can have only one direct service-network association in total, but it can connect to additional service networks through service network VPC endpoints. Because connectivity is brokered by the service network rather than by IP routing, CIDR overlap between participants is a non-issue, exactly as with PrivateLink.What Lattice adds beyond PrivateLink is application-awareness: listeners and rules for Layer 7 routing, weighted target groups for canary releases, multiple target types (instances, IPs, Lambda functions, Application Load Balancers, and resource configurations), and authorization expressed as IAM-style auth policies at the service or service-network level. If your requirement includes "route by path or header," "shift 5% of traffic to a new version," or "authenticate the caller's identity between services," that is Lattice's domain.
7.2 Applicability and the Region boundary
Choose Lattice when you are building a platform of many interconnected services — microservices across teams, a multi-account internal platform, or multi-tenant SaaS — and you want a managed mesh with identity rather than a sidecar-based service mesh or a thicket of point-to-point endpoints.One boundary matters for the decision: a service network is Regional and does not span Regions. For multi-Region service architectures you stand up a service network per Region and layer Amazon Route 53 (latency or weighted routing) on top to direct clients to the nearest Region. If you need global service connectivity, that two-layer pattern — Lattice within a Region, Route 53 across Regions — is the supported approach, and it is a deliberate design point rather than a limitation to work around.
8. Cloud WAN
AWS Cloud WAN is a managed wide-area networking service for building, managing, and monitoring a unified global network that connects VPCs, on-premises branch offices, and data centers across many AWS Regions from a central dashboard. Where Transit Gateway is a Regional hub you operate per Region, Cloud WAN is a global construct you describe with policy.8.1 Core network and the declarative policy
Cloud WAN's key concepts form a hierarchy:- A global network is the top-level container; it can contain both Cloud WAN core networks and Transit Gateways.
- A core network is the AWS-managed part, operating in the Regions defined by your policy, with Regional connection points and attachments (VPCs, VPNs, Transit Gateway Connect).
- A core network policy is a single declarative JSON document that captures your intent — it defines segments, which Regions each segment spans, and how attachments map to segments (including automatic mapping by tag). You describe the desired access control and routing; Cloud WAN handles the configuration. Policies are versioned, and only one version is live at a time, so changes are reviewable and revertible.
Segments are the headline feature: they implement network isolation (for example, a "production" segment, a "development" segment, and a "shared-services" segment reachable from both) declaratively and globally, instead of through per-Region route-table bookkeeping.
8.2 Relationship with Transit Gateway
Cloud WAN does not replace Transit Gateway; it federates with it. You connect a core network to an existing Transit Gateway with a peering connection, then use route-table attachments and a policy table to selectively exchange routes between a specific Transit Gateway route table and a Cloud WAN segment, giving end-to-end segmentation across both worlds. Three constraints define this integration: the Transit Gateway must be in the same Region as the core network edge, its ASN must differ from the core network's, and the peering supports dynamically propagated (BGP) routes only — static routes are rejected.This federation is what makes the Question 3 decision a "both/and" rather than "either/or": organizations with substantial existing Transit Gateway investment often adopt Cloud WAN as the global overlay and peer their Regional Transit Gateways into it, rather than rebuilding. (A separate capability lets Cloud WAN connect to VPCs over PrivateLink, but that path is currently limited to specific Regions and IPv6 dual-stack endpoints; treat it as a niche option and confirm current availability before designing around it.)
8.3 When Cloud WAN earns its place
Reach for Cloud WAN when the global topology and its segmentation are themselves the management problem: many Regions, many accounts, a need to express segments and Region scoping as policy, and a desire to see and manage the whole network centrally. For a single Region, or a couple of Regions you are content to wire by hand, Transit Gateway remains simpler. The VPC Design Review Checklist discusses the multi-Region crossover between Transit Gateway peering and Cloud WAN in design terms.9. Combining Patterns
Real architectures almost never use a single option. The planes compose: a routed backbone underneath, service exposure on top, and isolation expressed wherever it is cleanest. The figure shows a representative combined architecture.
9.1 Transit Gateway backbone with centralized endpoints
The most common large-network shape: a Transit Gateway connects all spoke VPCs in a Region, and a central VPC hosts shared interface endpoints (PrivateLink) for common AWS services. Spokes reach those endpoints through the hub instead of each VPC creating its own duplicate endpoints. This keeps the routed backbone (Transit Gateway) and the service-access layer (PrivateLink) cleanly separated, and it is a primary reason the two are complementary rather than competing. The endpoint-sharing mechanics are detailed in the PrivateLink guide.9.2 Isolated spokes with shared services
Using Transit Gateway route-table association and propagation, spoke VPCs are isolated from each other but all reach a shared-services VPC — directory services, logging, CI/CD, common tooling — and the shared-services VPC can reach the spokes. This is the "isolated VPCs with shared services" reference scenario, and it delivers tenant isolation and shared infrastructure from one hub without any peering mesh.9.3 Centralized egress and inspection
Spokes send internet-bound or sensitive east-west traffic through a central inspection VPC behind the Transit Gateway, where NAT gateways and a firewall appliance (in appliance mode, to keep flows symmetric for stateful inspection) handle egress and filtering. This concentrates security controls and egress IPs in one place rather than replicating them in every VPC.9.4 Cloud WAN over Transit Gateway federation
For global networks, a Cloud WAN core network provides the segmented global overlay while existing Regional Transit Gateways peer into it. Segments map to Transit Gateway route tables through the policy table, so a "production" segment, for instance, spans Regions globally and connects to the right route table in each Region's Transit Gateway. This is the standard way to adopt Cloud WAN without discarding a Transit Gateway investment.9.5 VPC Lattice overlay for service-to-service
Independently of the routed backbone, VPC Lattice can provide an application-level service network across the same VPCs, giving east-west service connectivity with identity and Layer 7 routing without relying on L3 routes between every participant — and tolerating CIDR overlap that the routed layer cannot. Many organizations run a Transit Gateway (or Cloud WAN) backbone for general reachability and a Lattice service network for the application mesh, choosing per requirement which plane a given flow uses. The VPC Lattice guide covers the overlay patterns in depth.10. Migration Paths
Connectivity decisions are not permanent, and the common moves are well-trodden. The goal in each is to migrate incrementally, never with a flag-day rebuild.10.1 Peering mesh to Transit Gateway
When a peering mesh outgrows its comfort zone, the path to a Transit Gateway is gradual:- Stand up a Transit Gateway in the Region and attach the VPCs (one VPC attachment per VPC).
- Add Transit Gateway routes in each VPC's route table alongside the existing peering routes, choosing the more specific route or migrating destination by destination.
- As traffic shifts to the hub, remove the corresponding peering routes, then delete the now-unused peering connections.
Because you can run both in parallel during the cutover, there is no hard switch. Plan route-table changes carefully (more specific prefixes win) and verify reachability at each step with Reachability Analyzer. The AWS VPC Network Troubleshooting Guide is the companion for diagnosing routing during a migration.
10.2 Transit Gateway to Cloud WAN
When a multi-Region Transit Gateway network outgrows manual inter-Region peering and per-Region route-table maintenance, you do not rip out the Transit Gateways:- Create a Cloud WAN global network and core network with a policy that defines your segments and Region scope.
- Peer each Regional Transit Gateway into the core network (same Region, distinct ASN, dynamic routes).
- Attach route tables to the peering and let the policy table map Transit Gateway route tables to Cloud WAN segments, shifting global routing into the policy incrementally.
- Optionally migrate VPC attachments directly onto the core network over time, retiring the Transit Gateway where it no longer adds value.
The federation step means the global overlay and the existing Regional hubs coexist throughout, so the migration is a controlled, segment-by-segment rollout.
10.3 Over-connection to service exposure
A subtler migration: discovering that a routed connection (peering or Transit Gateway) was only ever used so one client could call one service. The fix is to publish that service via PrivateLink or place it in a VPC Lattice service network, point the consumer at the endpoint or service name, and then remove the broad routing. This shrinks the blast radius and often resolves CIDR-overlap problems that the routed design was straining against.11. Common Pitfalls
The mistakes below recur across reviews and incidents. Each is a symptom of choosing or operating a connectivity option without matching it to the actual requirement.- Leaving CIDR overlap unaddressed. Trying to peer or attach overlapping networks fails outright; trying to design around it with L3 routing leads to fragile NAT hacks. Plan a non-overlapping addressing scheme up front, and when overlap is unavoidable, move the requirement to the service layer (PrivateLink/Lattice), which does not care about IP ranges. IP planning is foundational — see the VPC Design Review Checklist.
- Not checking quotas before committing. Peering connections per VPC, Transit Gateway attachments and routes, and per-attachment bandwidth all have quotas (most adjustable). Designs that ignore them hit a wall mid-rollout. Confirm current limits in the Service Quotas console for your Region.
- Overlooking DNS resolution. Connectivity at the IP or service layer is only half the story; if name resolution is not configured (peering DNS resolution, private hosted zones, Route 53 Resolver endpoints and rules, Lattice service DNS names), applications "can't connect" despite correct routes. DNS is the most frequent cause of "the network is up but it doesn't work."
- Treating non-transitive peering as transitive. Expecting A to reach C "through" B is a classic misread of peering. If you need transitivity, you need a hub.
- "Everything is Transit Gateway" or "everything is peering." Forcing one tool onto every problem is the meta-pitfall. A hub for two stable VPCs is needless overhead; a peering mesh for twenty VPCs is unmanageable; full network routing just to expose one API is over-exposure. Match the tool to the requirement using the flowchart.
- Confusing the network plane with the service plane. Reaching for routing when the need is service access (or vice versa) produces designs that are both more complex and less secure than necessary. Re-ask Question 1 whenever a design feels harder than it should.
12. Frequently Asked Questions
Q. Can I mix PrivateLink and Transit Gateway in the same architecture?A. Yes — and you usually should. They operate on different planes: Transit Gateway provides routed L3 reachability between VPCs, while PrivateLink provides private access to a specific service. A very common pattern is a Transit Gateway backbone with a central VPC hosting shared interface endpoints that spokes reach through the hub (Section 9.1). They complement rather than compete.
Q. When does VPC peering stop scaling?
A. Practically, when you keep adding connections or wish traffic could transit "through" a peer. A full mesh needs n(n-1)/2 peerings (20 VPCs = 190), there is a per-VPC ceiling on active peering connections, and route-table maintenance grows with every pair. Two or three stable VPCs are comfortable; once you are routinely adding peerings or expect growth, move to a Transit Gateway hub (Section 10.1).
Q. Do I need Cloud WAN if I already have Transit Gateway?
A. Not for a single Region or a couple of Regions you are happy to wire with inter-Region Transit Gateway peering. Cloud WAN earns its place when you have many Regions and want to express segmentation and Region scope as one declarative policy, managed centrally. When you adopt it, you typically peer existing Transit Gateways into the Cloud WAN core network rather than replacing them (Sections 8.2 and 9.4).
Q. PrivateLink resource endpoint or VPC Lattice — how do I choose for sharing a database?
A. Both can use the same underlying resource configuration and resource gateway. Choose a resource (VPC) endpoint when you simply want one consumer VPC to reach that resource privately, one-way, by ARN/IP/domain, with no NLB. Choose a VPC Lattice service network when the database is part of a broader service mesh where you also want centralized authorization, observability, and service-level grouping across many participants.
Q. The networks I need to connect have overlapping CIDRs. What are my options?
A. L3 options (peering, Transit Gateway, Cloud WAN) cannot connect overlapping address space. If the real need is access to specific services, use PrivateLink or VPC Lattice, which are indifferent to CIDR overlap because the consumer addresses an endpoint or service name. If you truly need routing across overlapping ranges, that requires NAT-based designs covered in the design material — and it is a strong signal to re-examine whether a service-layer approach fits better.
Q. Does VPC Lattice work across Regions?
A. A service network is Regional and does not span Regions. For multi-Region service architectures, deploy a service network per Region and use Amazon Route 53 (latency or weighted routing) to send clients to the nearest Region. This two-layer pattern is the supported approach for global service connectivity.
Q. Transit Gateway is transitive but peering is not — why does that matter so much?
A. Transitivity is what lets a hub connect many networks without a connection per pair. Peering's non-transitivity keeps it simple but caps it at small topologies. The moment you need "any VPC can reach any VPC," you need the transitive behavior of a Transit Gateway or Cloud WAN, not a peering mesh.
13. Summary
The proliferation of VPC connectivity options turned "how do I connect?" into a genuine design decision. The way through it is a single ordered set of questions:- Connect networks, or expose a service? — the fork that decides everything.
- How many VPCs, and growing? — a few stable VPCs favor peering; more favor a hub.
- One Region or many, and do you want declarative policy? — Transit Gateway for Regional, Cloud WAN for global/policy-driven.
- Do CIDRs overlap? — overlap pushes a "network" need toward the service layer.
- Consume a service, or connect services with identity? — PrivateLink for private access to one service/resource; VPC Lattice for an application-level mesh with L7 and IAM.
- Is it really one resource? — the resource configuration / resource gateway / resource endpoint family shares a single resource privately, bridging the PrivateLink and Lattice worlds.
Then remember that production architectures combine these planes — a routed backbone (Transit Gateway or Cloud WAN) underneath, service exposure (PrivateLink or Lattice) on top, segmentation wherever it is cleanest — and that moving between them is an incremental migration, not a rebuild. For the per-service depth this guide deliberately delegates, continue with the PrivateLink and VPC Endpoints Complete Guide, the VPC Lattice Complete Guide, and the VPC Design Review Checklist; for terms and history, the AWS Networking Glossary and the Amazon VPC timeline. When something on the network "doesn't work," the AWS VPC Network Troubleshooting Guide is the diagnostic companion to this selection guide.
14. References
- Building a Scalable and Secure Multi-VPC AWS Network Infrastructure - AWS Whitepaper
- Amazon VPC-to-Amazon VPC connectivity options - AWS Whitepaper
- VPC peering - AWS Whitepaper (multi-VPC infrastructure)
- How VPC peering connections work - Amazon Virtual Private Cloud
- How AWS Transit Gateway works - Amazon VPC
- AWS Transit Gateway quotas - Amazon VPC
- What is AWS PrivateLink? - Amazon VPC
- Access VPC resources through AWS PrivateLink - Amazon VPC
- What is Amazon VPC Lattice? - Amazon VPC Lattice
- Service networks in VPC Lattice - Amazon VPC Lattice
- Resource gateways in VPC Lattice - Amazon VPC Lattice
- What is AWS Cloud WAN? - AWS Cloud WAN
- Peerings in AWS Cloud WAN - AWS Cloud WAN
Related Articles
- AWS PrivateLink and VPC Endpoints Complete Guide - Interface, Gateway, and Resource Endpoint
The deep reference for endpoint types, DNS, endpoint policies, cross-Region access, and endpoint cost — the delegation target for everything in Section 6. - AWS VPC Lattice Complete Guide - Service-to-Service Networking Across VPCs and Accounts
Core concepts, listeners and routing, auth policies, and implementation — the delegation target for Section 7. - VPC Design Review Checklist - CIDR, Subnets, Transit Gateway
Routed and hybrid design depth: CIDR planning, Transit Gateway route-table layout, VPN, Direct Connect, and the multi-Region Cloud WAN crossover. - AWS Networking Glossary - VPC, Transit Gateway, PrivateLink, and VPC Lattice Explained
Definitions for every term used in this guide, plus a topology map of the connectivity planes. - AWS History and Timeline regarding Amazon VPC
When each connectivity capability launched and how the options evolved over time.
References:
Tech Blog with curated related content
Written by Hidekazu Konishi