Skip to content

Build1 publisher2 min readPublished

Cloud WAN's segments cut cross-region inspection from two firewall hops to one

An engineer who has run it in production across four regions makes the case for moving a Transit Gateway mesh into Cloud WAN segments, where routing intent sits in one versioned policy and AWS owns the inter-region path.

The Engineer · Build desk

Illustration accompanying Cloud WAN's segments cut cross-region inspection from two firewall hops to one

What happened

  • An AWS practitioner has published a design guide for Cloud WAN based on running one in production for a few hundred accounts and several hundred VPCs across four regions.
  • The pattern it argues against is the regional Transit Gateway: four regions means four gateways, peered in a mesh, with route tables on all four kept telling a consistent story.
  • In that pattern, traffic between VPCs in different regions is inspected twice, once leaving the source region and once entering the destination, yielding two sets of logs and two rule sets that must agree.
  • Under Cloud WAN, every region listed in the policy becomes an edge and AWS peers each edge to every other, so no inter-region peering attachment or route is built by hand.
  • One versioned JSON core network policy holds every segment, every rule about which segment can reach which, and where traffic gets inspected.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint The move changes who owns inter-region routing, not the firewall estate: an edge has no NAT and no firewall, so each region keeps an inspection VPC to do those jobs.
  • decision Any team that wants egress or inspection concentrated in one region now has to write that override against region affinity, and the override is a line in a reviewed document.
  • capability Answering a reachability question becomes reading one policy version instead of reconciling regional route tables. The intent is auditable before a change ships.
  • constraint Both savings are multi-region savings, so a single-region estate has no mesh to collapse and no cross-region symmetry problem to halve.

A full mesh across four regions is six peering relationships: 4 times 3, halved. Add a fifth region and it becomes ten, so the region you turn on next quarter brings four new peerings with it [1][2].

Most of the recurring work is per VPC. In the Transit Gateway pattern, each new VPC means an attachment, a route table association, propagation into the right tables, and often a static route or two, and every new environment or partner multiplies that [3]. In Cloud WAN, the attachment lands in a segment, and the segment exists on every edge. A VPC attached in Sydney has its CIDR learned by the edges in Virginia and Oregon without anyone editing a route [5][6]. The post puts it this way: "If Transit Gateway is a router you configure, Cloud WAN is a WAN you describe" [8].

The second complaint is about where intent lives. The sentence the author says no document holds is "test can reach shared services, and nothing else". In the mesh that intent exists only as route tables in four regions, and you prove it by reading all of them [4]. In the policy, the shared services hub reaching into each environment is two-way and never transitive [10].

Inspection is the part that happens twice. A stateful firewall has to see both directions of a flow. With independent regional gateways, the only way to guarantee symmetry is to inspect leaving the source region and again entering the destination region [11]. In the Cloud WAN design, the two production flows to another cloud are inspected once each and exit through the nearest Direct Connect landing [12]. The author writes that Cloud WAN removes both problems and that this is the reason to adopt it [18]. The post describes itself as a design guide, not a tutorial, and it leaves out pricing and hours-spent figures [19].

The design still needs per-region plumbing. An edge has no internet gateway and no firewall of its own. Anything that needs either has to be a VPC you attach [13]. Here every VPC drains to its region's inspection VPC, which holds the NAT and the internet gateway [14]. The post calls an edge "a router you never see", and AWS operates it [17]. Region affinity is the default: traffic stays in its home region wherever it can, and crosses the backbone only when the destination or the policy says so. Concentrating inspection or egress in one region is an override you write on purpose [16]. Each edge also needs its own ASN, reserved from a private range in the policy [15].

What to watch

  • A written cutover path that attaches existing regional Transit Gateways to Cloud WAN edges, since attachments of that type are supported.
  • Per-attachment and data-processing pricing detail that would let a Transit Gateway mesh and a Cloud WAN core network be costed side by side.
  • The rest of the author's ASN guidance, including which ranges to keep out of anything you peer.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories