AWS Cloud WAN series · Part 7 of 17

AWS Cloud WAN: Multi-Region Routing

Seventh in the AWS Cloud WAN series. The headline feature is global: list your Regions and AWS builds a resilient, full-mesh, dynamically-routed network across them with no manual peering. That abstraction is wonderful right up until traffic takes a path you didn't expect. Here's what's actually happening under it — how the Regional routers mesh and exchange routes, how a segment spans Regions, the quiet default that governs exit points, and the multi-Region edge cases that show up in incidents.

What AWS builds for free — a full eBGP mesh you never configure

For every Region you list under edge-locations, Cloud WAN provisions a Core Network Edge (CNE) — a Regional router that is, mechanically, an AWS-managed Transit Gateway. The docs say it outright: a CNE "is also known as an AWS Transit Gateway, and it inherits many of the same properties." Then it does the thing you'd otherwise do by hand: it full-mesh-peers every CNE with every other CNE using external BGP across the AWS global backbone. Each CNE carries its own ASN from your configured range, and the mesh exchanges routes dynamically over redundant paths (Figure 1).

This is the single biggest operational difference from Transit Gateway. In the TGW world, cross-Region connectivity means manually creating peering attachments between TGWs, and because TGW peering supports only static routes, you maintain route tables by hand in every Region, populated with the CIDRs of every other Region's routing domains. Cloud WAN replaces all of that with a dynamically-routed mesh you never touch. Add a Region to the policy and it joins the mesh automatically; the routing just works.

One number to keep in view while you decide how wide to go: each CNE is a per-hour charge of about $0.50/hour — roughly $365/month per Region — on top of data processing. So "how many Regions" is both a connectivity decision and a cost decision: wide enough to serve the business, no wider. We treat cost in full in Article 16.

How one segment lives in many Regions — global object, local routes

A segment is a global object by default. It exists across all the Regions in your policy, and AWS keeps its configuration consistent everywhere with no per-device synchronization on your part. This is the VRF-over-MPLS analogy from Article 3 — except the consistency is automatic and planet-wide.

But "global" doesn't mean every route is everywhere in the same way. Two facts shape multi-Region behavior, and getting them straight is what keeps your exit points predictable.

A segment can be scoped to a subset of Regions. A segment's edge-locations parameter must be a subset of the core network's edge-locations, so you can keep an otherwise-global segment — and its routes — only where its attachments actually live. A segment only needs to exist where it has work to do.

Routes propagate, but locality is preferred. When an attachment in one Region advertises a prefix into a segment, that route propagates across the mesh to the segment's presence in other Regions — so a VPC in us-east-1 reaches a VPC in eu-west-1 in the same segment without you doing anything. But when multiple paths to the same destination exist, Cloud WAN's default is to prefer the local-Region route over a remote-Region route, as long as the BGP AS_PATH lengths are equal. Locality is the tiebreaker, and it's usually what you want.

That leads to a design rule worth internalizing now, because the rest of the article leans on it: every Region that needs a particular destination should have a local attachment for it. AWS states the principle directly — designing so every Region has a Regional attachment for a destination CIDR is what "gives you control over the exit point for egress traffic." A Region without a local attachment receives a propagated, remote version of the route and exits through another Region, adding latency and, worse, potential asymmetry (Figure 2).

Why traffic exits where it does — local-Region preference, read in full

That local-versus-remote behavior isn't a one-off rule; it's the bottom-but-one rung of an evaluation order Cloud WAN inherits straight from Transit Gateway. When several routes to the same destination exist, the CNE walks down a fixed ladder and the first decisive rule wins (Figure 3):

• Longest-prefix match wins, absolutely. The most specific route beats everything below it, full stop.
• Static beats propagated for the same destination CIDR.
• Source priority by attachment type for the same CIDR across different types: static → prefix-list-referenced → VPC-propagated → Direct Connect gateway-propagated → TGW Connect → the VPN family → TGW peering. (Note that VPC-propagated outranks DXGW-propagated — a detail that bites people who assume hybrid wins.)
• BGP attributes break the next tie: shorter AS_PATH, then lower MED, then eBGP over iBGP.
• Local-Region preference — the multi-Region rung — picks the same-Region CNE when the learned AS_PATH lengths are equal.
• Still tied? The forwarding CNE is chosen at random.

Stated plainly, the lever you actually pull is this:

If multiple routes within a segment reach the same destination and one of them is a local-Region route, Cloud WAN prefers the local route — provided AS_PATH lengths are equal.

Everything predictable about multi-Region routing flows from that one sentence. Want each Region's internet egress to exit through that Region's own firewall and NAT? Give each Region a local egress attachment for the default route and locality does the rest (Article 9 builds exactly this). Want on-premises traffic to leave through the local Direct Connect? Associate the DXGW in every Region so each has a local hybrid attachment (Article 6). Want a Region without a local attachment to exit through a specific neighbor on purpose? That's where the default may not pick the neighbor you'd choose — and you need explicit control, which is the next two sections.

Where the abstraction bites — random remote edges, per-edge DNS, and asymmetry

The abstraction is excellent, but a handful of multi-Region behaviors surprise people. Know them before they show up in an incident.

Equal-attribute routes can be chosen at random. When multiple CNEs advertise the same destination with the same prefix, the same AS_PATH length, and the same MED, Cloud WAN may pick which CNE forwards the traffic at random. For a Region with no local attachment relying on remote Regions for a destination, that can mean traffic exits through an arbitrary remote Region rather than the closest one — extra latency and possible asymmetry. The fix is to break the tie deliberately: advertise a more-specific prefix on the path you prefer, or use the 2025.11 routing policies to set path preference (local preference, MED, AS_PATH) so one CNE is clearly favored.

The same failure mode for hybrid. As Article 6 covers, if a Direct Connect gateway isn't associated with all the Regions where its segment is present, a CNE in an unassociated Region forwards on-premises-bound traffic to a randomly chosen remote CNE. Same root cause — no local attachment, no deterministic remote choice — and the same fix: give every Region a local attachment, or pin the choice with a routing policy.

DNS resolution is per-edge, not global. Cross-VPC DNS resolution (dns-support) only works between VPCs attached to the same Core Network Edge — not across Regions, not across different edges. Don't assume the global mesh extends to DNS; it doesn't. Plan cross-Region name resolution (Route 53 Resolver and friends) accordingly.

Asymmetry plus stateful inspection equals drops. This one recurs across the series because it's the most common multi-Region failure. The moment traffic can take different paths in each direction and a stateful firewall sits in the path, return traffic hits a firewall with no session state and gets dropped. Multi-Region symmetry isn't a nice-to-have when inspection is involved — it's a correctness requirement. Appliance mode (Article 5) handles the AZ dimension; Region-preference routing policies and local-attachment design handle the Region dimension.

How to take back the path — five levers, weakest assumption first

When the defaults don't put traffic where you want it, here's the toolbox — ordered so you reach for the cheapest, most robust option first and the precision instrument last (Figure 4).

1. Local-attachment design. The first and best tool. Ensure every Region that needs a destination has a local attachment for it, and most "weird routing" simply disappears — because rung 5 of the ladder then resolves in your favor without any BGP tuning.

2. Prefix specificity. Longest-prefix match is absolute (rung 1). Advertise a more-specific prefix on the path you want preferred and it wins outright, no attributes required.

3. Segment Region scoping. Use a segment's edge-locations to keep the segment — and therefore its routes — only in the Regions where it belongs, so a destination never propagates somewhere it shouldn't be reachable.

4. The 2025.11 routing policies. The precision instrument, generally available since November 20, 2025. Set local preference, AS_PATH, or MED; filter routes inbound or outbound; summarize to keep tables small; pin Region preference for symmetry. Crucially, this applies both to attachments and to inter-Region (CNE-to-CNE) routes. Mind the boundaries, though: VPC attachments support only inbound allow/drop filtering (VPCs don't speak BGP); summarization is outbound-only and BGP-capable-attachments-only; replace-asn-list isn't supported cross-Region; and BGP community support is Site-to-Site VPN and Connect only — excluded on both Direct Connect and TGW peering.

5. Edge-location routing-policy association. Tie a routing policy to a specific pair of edge locations within a segment to override the default behavior between two geographies (the associate-routing-policy construct from Article 2).

What to actually do — locality by design, policy by exception

Here's the decision to carry forward. Default to local-attachment design: for every destination a Region needs — egress, on-premises, shared services — give that Region its own local attachment, and let local-Region preference keep traffic in-Region. Keep segments global unless one genuinely belongs in fewer Regions, in which case scope it with edge-locations. Treat symmetry as correctness, not polish, anywhere a stateful firewall is in the path. And reach for the 2025.11 routing policies only by exception — when the defaults don't land where you want, or when you must deliberately pin a remote exit a Region can't satisfy locally.

You now understand how traffic moves within and between Regions, and how to control it. The next cluster turns to security: inserting inspection into these flows. Article 8 introduces service insertion and Network Function Groups — the construct that lets you steer traffic through firewalls with a policy statement instead of the per-Region inspection-segment-and-static-route sprawl that used to be required. Everything you've learned about multi-Region locality and symmetry becomes directly relevant there, because inspection is where getting the path wrong stops being merely slow and starts being broken.