AWS Cloud WAN series · Part 17 of 17

AWS Cloud WAN: The Reference Architecture

The capstone, seventeenth and last in the series. Sixteen articles built the pieces — concepts, policy, segmentation, attachments, hybrid, multi-Region routing, inspection, migration, IaC, observability, cost. This one assembles them into a single opinionated blueprint for a global, multi-Region, multi-account enterprise, and closes with the framework for whether to build it at all. Every choice traces back to the article that earned it; every number is sourced.

Whether to build it at all — the adoption gate

Before any topology, the gate. Cloud WAN adds exactly three things over a Transit Gateway estate — a single global policy, tag-based segmentation, and native cross-Region dynamic routing (a Core Network Edge is mechanically an AWS-managed Transit Gateway, and AWS meshes the edges for you). What it does not do is the part teams talk themselves out of remembering: it deletes no firewalls, replaces no SD-WAN or MPLS, reduces no attachment count, and doesn’t change regional data-plane resilience (that last equivalence is a reasonable inference from “inherits many of the same properties,” not a sentence AWS publishes).

It also costs more. The honest figure is an illustrative practitioner estimate — about a 30% premium over an equivalent TGW design — driven by a higher per-attachment fee plus the per-Region Core Network Edge base (around $365/month each) that TGW has no equivalent for. So the decision is never “is it cheaper?” It is: does the operational win clear the premium?

For this enterprise the answer is yes, and the reason is operator-time. Dozens of accounts across three Regions on peered Transit Gateways means a constant stream of route-table tickets and static cross-Region peering to hand-maintain; one versioned policy and tag-based onboarding retire most of that toil. A small, single-Region, stable shop would get a no here — and that is the correct answer for them. Adopt for the operational win or don’t adopt; never adopt expecting savings or capability the service doesn’t provide.

What must never happen — the segment matrix is the contract

Everything downstream is transcribed from one artifact, so build it first. Design segments by what must never happen, not by org chart — a segment is a separate routing domain where, by default, attachments only reach others in the same segment, so the absence of a route is the deny. The boundaries for our enterprise:

• production — prod workloads; acceptance required.
• non-production — dev, QA and UAT collapsed into one (identical routing behaviour; less is more under the cap).
• pci — the regulated workload; isolated, acceptance required, the strictest boundary.
• shared-services — endpoints, directory, auth; isolated internally, reachable by others non-transitively.
• sandbox — sealed; isolate-attachments on, no shares.
• plus NFG-backed inspection and egress segments for service insertion — each quietly spends one of the 40.

That last point is the constraint that disciplines the whole design: a core network supports a maximum of 40 segments, not adjustable, and every Network Function Group used for inspection consumes one segment internally, drawing from the same budget. So collapse anything with identical sharing rules — spend slots only on boundaries that carry real, differing security meaning.

Read the matrix as enforceable intent. Prod and non-prod each reach shared-services and egress but meet each other only inspected, never directly. PCI is isolated from everything except a tightly-scoped shared-services path and egress. Shared-services and egress are isolated on their own diagonals and are not shared with each other — so neither becomes an accidental bridge. Sandbox is sealed. The property that makes the “both reach shared-services, neither reaches the other” rows legal is that sharing is bidirectional but non-transitive: a hub shared with A and B never lets A reach B through it. This matrix becomes the policy and the executable CI checks.

How attachments find their segment, and traffic finds its Region

One core network policy carries it, pinned to schema version 2025.11 — the version required for routing policies, which also turns on BGP-community propagation through the core. Inside it, attachment policies map each attachment to a segment by the attachment’s own tag — not the VPC’s tags, the single most-missed rule — evaluated lowest rule-number first, first-match-wins. Acceptance gates protect prod, pci and shared-services; non-prod flows in automatically. A new account onboards by tagging its attachment correctly — no central change. The policy is versioned: only one version is LIVE, a new one is never deployed automatically, and rollback is restoring a prior version — effectively one action.

Routing is the half that bites in incidents. Each Region has a Core Network Edge and AWS full-meshes them over eBGP; the default tiebreaker is local-Region preference when AS_PATH lengths are equal. The rule that prevents the classic failure is blunt: every Region that needs a destination must have a local attachment for it. A Region without one inherits a propagated remote route, and when several remote edges advertise it with equal attributes, the forwarding edge is chosen at random — latency and asymmetry you didn’t design. Two more disciplines: place shared-services and inspection subnets by AZ ID (use1-az1), not AZ name, since names map to different physical zones per account; and where defaults aren’t enough, 2025.11 routing policies pin path preference — though a VPC attachment only supports inbound allow/drop filtering, since VPCs don’t speak BGP.

Where traffic gets inspected — egress send-to, east-west send-via

Inspection is two distinct jobs with two distinct actions, and the per-Region picture (Figure 3) is where they live.

Egress (north-south) is send-to. Egress VPCs — AWS Network Firewall, then NAT, then the internet gateway — sit in an Egress NFG with appliance mode on, in us-east-1 and eu-west-1. A send-to from each workload segment installs the default route (0.0.0.0/0 and ::/0) to the local egress attachment. us-west-2 has no local egress stack in this design, so it uses edge-override to inspect via the nearest appropriate Region rather than whatever the default, non-geography-aware Region-priority list would pick — keeping latency sane.

East-west is send-via. Every “inspected” cell in the matrix — prod↔non-prod, and PCI’s narrow allowed paths — becomes a single-hop send-via through an Inspection NFG with a firewall in each Region; route symmetry is automatic and bidirectional, so A→B implies B→A. Same-segment, same-Region traffic the matrix already trusts flows directly — don’t inspect what policy doesn’t require, because each hop adds standard data-processing and dual-hop roughly doubles it. One trap worth a guardrail: an empty NFG referenced by a send-to or send-via deploys cleanly but blackholes all traffic until you attach a firewall to it.

How on-premises plugs in — native DXGW across every Region

A hybrid segment plus native Direct Connect Gateway attachments — the DXGW attaches straight to the core network with no intermediary Transit Gateway, with automatic bidirectional BGP. The hybrid analogue of the regional-presence rule is non-negotiable: associate the DXGW with every Region the hybrid segment lives in. Each associated edge advertises only its local routes and retains the AS_PATH; an unassociated Region inherits a propagated remote route and you’re back to the random-remote-edge hairpin. Run two transit VIFs per data centre (primary and backup) and steer active/passive with on-premises BGP local-preference; communities are not supported on Direct Connect, so don’t lean on them for path control. Workload segments reach on-premises by sharing with the hybrid segment per the matrix, and routing policies hold symmetry where stateful inspection sits in the path.

Two caveats keep the design honest. AWS still recommends a Transit Gateway per Region for Direct Connect in some designs, so each Region’s workloads reach the DXGW without a cross-Region dependency — weigh that against the simplicity of native attachment. And while the Direct Connect gateway object is free, its attachment to the core network is billable (per-hour plus per-GB), on top of DX port-hours — native hybrid is not free hybrid.

How you get there without an outage — federate, flip, decommission

You don’t cut over in a day; you make every step reversible.

Phase 1 — federation. Peer each existing Transit Gateway to its same-Region Core Network Edge and map each TGW route table to the matching segment via route-table attachments (peering is dynamic-BGP only). The safe-cutover trick is that, for the same prefix, a static route on the TGW beats a dynamically-learned Cloud WAN route — so standing Cloud WAN up alongside the existing static peering has zero traffic impact until you delete the static routes, at which point traffic flips. Reversible at every step.

Phase 2 — cutover. Migrate VPC attachments per-VPC: create the Cloud WAN attachment alongside the TGW one, validate it’s Available with routes learned, then repoint the VPC’s own route table from the TGW to the core network — that repoint is the control point, and rollback is repointing back (use the atomic ReplaceRoute API, not delete-then-add). Migrate Direct Connect from TGW-terminated to native DXGW in a maintenance window — build the parallel path, then flip on-premises BGP preference — and decommission idle Transit Gateways last. Parallel-then-flip is what keeps the whole migration uneventful.

How it’s built, watched, and paid for — Terraform, telemetry, cost

Everything as code, in two workspaces. Workspace 1, in the network account, owns the global network, core network and policy — built from HCL via the aws_networkmanager_core_network_policy_document data source with dynamic blocks for segments and Regions — and the core network is RAM-shared org-wide. Mind the two-Region trap: Cloud WAN’s home Region is always US West (Oregon), us-west-2, but the RAM share itself must be initiated from N. Virginia, us-east-1, or other Regions can’t see the global resource. Workspace 2 is a templated per-account module that creates VPCs and attachments, tagging each attachment for its segment. Decoupling the global stack from the regional ones is AWS’s own recommendation, for independent lifecycles.

Gate it like code. Cloud WAN ships no native policy linter, so teams encode the segment matrix as executable assertions (the Silverflow approach) that fail the build on a logic error. The documented pre-deploy gate is the Cloud WAN change set: a policy version is never applied automatically, and only a version marked Ready to execute can be promoted to LIVE — with versioning as the post-deploy rollback.

Watch it with telemetry that has gaps. CloudWatch metrics live in the AWS/NetworkManager namespace, which is available only in us-west-2, at 15-month retention. Two gotchas shape the dashboards: there is no single PacketsDropped metric — drops are split by reason (Blackhole, NoRoute, TTLExpired) — and Cloud WAN has no native per-flow log, so put VPC flow logs on connected VPCs to recover the 5-tuple the core can’t give you. Add EventBridge on attachment-state changes, and reach for the console route view first when reachability looks wrong.

Account honestly for cost. Hold the Region count to three (each Core Network Edge is about $365/month); data processing is $0.02/GB. Track per-account attachment fees with cost-allocation tags, default to single-hop inspection, leave trusted same-segment same-Region traffic uninspected, and apportion the network account’s platform cost via showback. A single-Region, two-attachment, 100 GB month works out to about $461.90 — useful as the unit you multiply.

The decision framework, distilled

Strip the whole series to a checklist you can apply to any Cloud WAN engagement — each question pointing back to the article that answers it in full (Figure 4).

Cloud WAN is not magic and it is not for everyone — the series has been deliberate about saying so. But for the organisation that genuinely needs it — global, multi-Region, multi-account, drowning in network-change toil — it replaces a hundred brittle, hand-maintained resources with one versioned policy, automates onboarding through tags, routes globally without manual peering, and lets you roll the whole network back in a single step. Build it from the segment matrix outward, automate everything, watch it with real telemetry, and account honestly for what it costs and what it does. Do that, and you’ll have a global network a senior reviewer would recognise as designed rather than assembled — which was the whole point of mastering it.

That concludes the AWS Cloud WAN series. Read in order for a newcomer, or by section as a reference. Now go build.