AWS Cloud WAN series · Part 1 of 17

What AWS Cloud WAN Actually Is (and Isn't)

A design and decision deep dive: the object model, the managed-Transit-Gateway reality underneath, and where it earns its keep versus where plain TGW is still the right call.

What it is — three nested objects

Almost every Cloud WAN misunderstanding comes from collapsing three distinct objects into one. Keep them separate — the diagram below nests them — and the rest of this falls out cleanly.

Global network is the top-level logical container, and the part people miss: it can hold both Transit Gateways and Cloud WAN core networks at once. It is a bookkeeping boundary, not a router.

Core network is the AWS-managed part inside it — the Regional connection points and the attachments (VPNs, VPCs, Transit Gateway Connects) that hang off them, operating in exactly the Regions its policy declares. You get one core network per global network: a hard, non-adjustable quota.

Core network edge (CNE) is where the abstraction touches reality — the Regional router AWS manages; every attachment connects to a CNE, exactly one per declared Region. The practitioner one-liner that makes it click: a CNE is a router serving one Region, and all that Region's attachments connect to it.

If you live in Terraform, the resource names mirror these layers one-to-one — aws_networkmanager_global_network, aws_networkmanager_core_network, aws_networkmanager_core_network_policy_attachment (which executes the policy change set to LIVE), and aws_networkmanager_vpc_attachment (whose tags drive the segment it resolves into). One quirk worth flagging: a VPC attachment needs a LIVE policy to exist before it can be created, so the provider offers create_base_policy to bootstrap a minimal policy and break that chicken-and-egg.

What's really underneath — managed Transit Gateways

Here's what the marketing glosses and the docs say plainly. A core network edge is, in AWS's own words, "also known as an AWS Transit Gateway, and it inherits many of the same properties." The launch blog is as candid: internally, Cloud WAN uses technology similar to Transit Gateway, managed by AWS, with a different feature set such as dynamic routing.

Concretely, for each Region in your policy AWS provisions one CNE router with its own BGP ASN — auto-assigned from the policy's range or set by you, immutable once created — plus inside-CIDR blocks for Connect/BGP peering. That immutability has teeth: a Transit Gateway sharing the same ASN can't be peered to that CNE.

The genuinely new piece is the control plane: all CNEs automatically form full-mesh peering across the AWS global backbone, with redundant paths. That's the biggest behavioral difference from raw Transit Gateway — where you build inter-Region peering by hand; here the mesh and its dynamic routing are configured for you.

The clean split: you own intent, AWS owns mechanism. You write the policy and create/accept attachments; AWS provisions the CNE routers, builds inter-Region peering, runs dynamic routing, and keeps segment and route config consistent across every Region.

How you drive it — one global policy

Everything you control lives in one place: a single declarative JSON policy applied to the core network. It "captures your intent and deploys it for you," defining segments, Region routing, and how attachments map to segments. The top-level shape is worth knowing because each section maps to a concept you'll reason about:

• core-network-configuration — required. ASN ranges, the per-Region edge-locations, ECMP and DNS support, and inside-CIDR blocks for Connect tunnels.
• segments — required. Your global routing domains (next section).
• segment-actions — sharing and static routes between segments (share, create-route, send-via, send-to).
• attachment-policies — the rules that bind attachments to segments, usually by tag.
• network-function-groups — containers used for service insertion / inspection.

The policy is versioned, and only one version is LIVE at a time; new versions are numbered incrementally and not auto-deployed. When you generate one, AWS computes a change set — a verified diff you then execute to go live — moving through states (pending generation → ready to execute → execution succeeded), with an older live version restorable if a change goes wrong. Treat it like production infrastructure-as-code: one document now governs your entire global network — its power and its blast radius.

The first payoff — tag-based segmentation

A segment is a global routing domain spanning all the core network's Regions — AWS's own analogy is the cleanest: a globally consistent VRF, or a Layer-3 IP VPN over MPLS. By default only attachments in the same segment can talk, and AWS keeps that consistent across every Region.

You can tighten or relax that default: isolate-attachments stops members of the same segment from reaching each other (an "isolated segment"); segment sharing is bidirectional — share a shared-services segment with prod and prod2 and both reach it while staying invisible to each other. That hub-and-spoke shape (below) is the bread-and-butter pattern.

The real time-saver is attachment policies: instead of wiring each attachment to a route table by hand, you write rules that read the attachment's tags and place it automatically — and crucially, the tags on the attachment itself, not the underlying VPC. Rules are numbered, processed low to high, first match wins, one attachment to one segment.

The mechanism comes in two flavors. association-method: constant pins matching attachments to one named segment; association-method: tag reads tag-value-of-key and drops the attachment into the segment whose name exactly matches that tag's value. AWS's canonical three-stage example makes it concrete — Stage=development joins the development segment; Stage=production joins production (which additionally requires manual acceptance), while shared services is pinned by resource ID:

"attachment-policies": [
 { "rule-number": 1000,
 "conditions": [ { "type": "tag-exists", "key": "Stage" } ],
 "action": { "association-method": "tag", "tag-value-of-key": "Stage" } },
 { "rule-number": 1500,
 "conditions": [ { "type": "resource-id", "operator": "equals",
 "value": "vpc-1234567890123456" } ],
 "action": { "association-method": "constant", "segment": "sharedservices" } }
]

One gotcha hides in the convenience: if a segment is set to auto-accept, attachments can be added or removed automatically when their tags change. A careless retag can move a workload between routing domains. The tagging discipline you already (should) have now has blast radius.

The second payoff — native cross-region routing

This is what you're really paying for. With Transit Gateway, spanning Regions means a separate TGW per Region joined by manual inter-Region peering; AWS's migration guidance spells out the chore — you "create unique Transit Gateway route tables for each one and populate them with static routes for cross-Region communication." And plain TGW peering isn't segmentation-aware: a peering attachment associates to a single route table that must know every prefix crossing it.

Cloud WAN replaces all of that with auto-meshed CNEs and BGP: declare a Region and its routes go network-wide dynamically, no peerings to wire or static cross-Region routes to maintain. Even a static route created in one Region propagates to Regions without a local attachment, through the cross-Region peering. A named practitioner puts the delta bluntly: cross-region dynamic routing over BGP, out of the box.

If your whole footprint is one Region, this headline feature does nothing for you. That's not a knock — it's the decision criterion, and AWS agrees (below).

How it compares — TGW, VPC peering, VPN

AWS's own decision criteria are refreshingly direct. Transit Gateway is "optimal if you operate in a few AWS Regions, want to manage your own peering and routing configuration, or prefer to use your own automation." Cloud WAN is "optimal for customers who want to define their global network through policy and have the service implement the underlying components automatically." A named practitioner's honest read lines up: plain TGW still wins for a single Region, minimal cross-Region traffic, or fleets where route-table ops are already manageable; Cloud WAN wins at three-plus Regions with auto-scaling VPC fleets and teams wanting central segmentation.

What it won't fix — limits, gotchas, cost

The limits worth knowing before you design

All values from the AWS Cloud WAN quotas page. Note the routing limit is 10,000 routes per core network across all segments — there is no separate per-segment route quota. Service insertion isn't free of these budgets either: a network function group consumes a segment internally, so heavy inspection designs eat into the 40-segment and 10,000-route ceilings.

Pricing — the part that surprises people

Cloud WAN's data-processing and attachment model looks like Transit Gateway, with one line item that doesn't exist on TGW: the per-Region edge.

Two practical consequences. First, traffic crossing a CNE↔Transit Gateway peering incurs no data-processing charge at that boundary (data transfer still applies), softening hybrid TGW/Cloud WAN designs. Second, all-in cost runs roughly 30% higher than an equivalent Transit Gateway architecture — the $0.50/hr edge plus the higher per-attachment rate. Two independent practitioner analyses land on that ~30%, one citing about $20K/year extra on a 465-VPC, two-Region deployment.

Flagged as unverified: per-Region attachment pricing beyond us-east-1 and eu-central-1 was not enumerated by the source, and a third-party claim that TGW inter-Region transfer is $0.05/GB vs Cloud WAN $0.02/GB could not be confirmed on the official TGW pricing page. Don't budget against those two without checking the calculator for your Regions.

The three things it won't fix

It does not delete your firewalls. Inspection is optional and bolted on via service insertion (network function groups steering traffic between segments); you still run AWS Network Firewall or third-party appliances in dedicated inspection VPCs, with appliance mode for stateful flows. Cloud WAN routes traffic to your firewalls more elegantly; it isn't one.

It does not reduce your attachment count. Every VPC still needs its own attachment, exactly as with TGW — Cloud WAN gives you centralized policy over those attachments, not fewer of them.

It does not replace MPLS or SD-WAN. AWS frames it as augmenting your existing WAN and moving over incrementally — route some traffic via Cloud WAN while the rest stays on your current WAN.

A few sharper edges from people who've migrated: changing a VPC route from the console can cause downtime (use the ReplaceRoute API instead); during a TGW→Cloud WAN cutover, traffic can flow asymmetrically, which stateful devices (NAT, firewalls) in the path will drop, so plan the path carefully; each migration phase can take 20–30 minutes to deploy; and because one policy governs everything, a bad change has global blast radius — the flip side of the single-pane benefit.

When to reach for it

The decision tree up top resolves to three cases:

• One Region, or two with light cross-Region traffic, modest VPC count: stay on Transit Gateway. You'd pay the $0.50/hr-per-edge premium and the policy learning curve for a headline feature (cross-Region dynamic routing) you barely use.
• Greenfield, three-plus Regions, many accounts, you want central segmentation and tag-driven placement: start on Cloud WAN. This is the case it was built for, and AWS recommends it.
• Existing Transit Gateway estate you're outgrowing: don't rip and replace. A global network can hold both, and a CNE can peer with a same-Region TGW, so you interoperate at the boundary and migrate segment by segment.

The honest framing to take into a design review: Cloud WAN isn't a new kind of network. It's a managed control plane that turns "operate N Transit Gateways and their peerings by hand" into "declare one policy and let AWS converge it." If that operational tax is real for you, it's worth the ~30% and the blast radius. If it isn't, you already have the right tool.