A global network backbone with AWS Cloud WAN

One policy compiles into a global fabric

A Cloud WAN core network is the AWS-managed portion of your global network. You declare intent in a single core network policy, a declarative JSON document that states which AWS Regions get connectivity, what segments exist, and how attachments map to those segments. For every Region listed in the policy, Cloud WAN provisions a core network edge (CNE), a Regional router that inherits many properties of a Transit Gateway. Every CNE automatically forms full-mesh peering with every other CNE, so you never build or maintain inter-Region peering by hand.

The policy is versioned and only one version is LIVE at a time. Editing it produces a reviewable change set you inspect before deploying, and you can roll back by restoring a previous version. You author it in the Network Manager visual editor or directly as JSON, and the same document drives access control and routing across every Region at once instead of you touching each device.

That convenience has a cost model worth designing around: each CNE bills hourly (roughly 0.50 USD per hour per Region on the pricing page), and on top of that you pay a per-attachment hourly fee plus 0.02 USD per GB of data processed. Because a CNE is billed whether or not it carries traffic, you should list only the Regions you actually need in the policy rather than pre-provisioning edges everywhere.

Segments are global VRFs, not per-device route tables

A segment is a dedicated routing domain. By default, only attachments in the same segment can communicate, which AWS describes as being similar to a globally consistent VRF or a Layer 3 IP VPN over MPLS. The key property is that AWS keeps the segment's routing consistent across all Regions for you, so a VPC placed in the prod segment in us-east-1 reaches prod VPCs in eu-west-1 and ap-southeast-1 with no per-Region configuration and no static routes.

Isolation is the default, so shared services need an explicit exception. You create a shared segment (for directory or authentication services) and use a segment sharing action to leak its routes into both prod and dev, while prod and dev remain unable to reach each other. You can further tighten a segment by isolating attachments within it, so members can reach shared services but not one another. This is how you express prod/dev isolation plus common shared services without opening prod-to-dev paths, as traced in the diagram.

Each attachment maps to exactly one segment. You map it either explicitly by resource id (for example VpcId) or, at scale, with attachment policies that match on the attachment's tags, so a newly created VPC lands in the right segment automatically. The require-attachment-acceptance property on a segment controls whether new attachments are auto-accepted or held for approval.

Why this beats a hand-stitched TGW mesh

In a self-managed Transit Gateway mesh, connecting N Regions requires N*(N-1)/2 peering attachments, and every new Region means creating new peerings plus editing static routes and association/propagation entries in the route tables of every existing Region. Segmentation is emulated by running multiple TGW route tables that you keep synchronized by hand; drift between them silently produces either route leaks or blackholes. The before-state diagram shows how quickly the manual peering and route-table surface grows.

Cloud WAN collapses that operational surface into one policy. Adding a Region is a single policy edit that provisions the CNE and joins it to the existing full mesh, and attachment-to-segment mapping is driven by tags rather than by hand-editing route tables. The intent lives in one reviewable document instead of being distributed across dozens of route tables in many accounts and Regions.

You do not have to rip and replace to adopt it. For migration, you peer an existing Transit Gateway with a CNE in the same Region and create a Transit Gateway route table attachment that maps a specific TGW route table through a Cloud WAN segment. That gives end-to-end segmentation spanning both the legacy TGW network and the new Cloud WAN core while you move workloads over incrementally.

Attachments, tags, and who owns what

A core network accepts several attachment types: VPCs, Site-to-Site VPNs, Connect attachments (for SD-WAN and third-party appliances), Transit Gateway route table attachments, and Direct Connect gateway attachments. Rather than wiring each one manually, attachment policies match on key-value tags and associate the attachment to the intended segment, so infrastructure-as-code that tags a VPC correctly gets the right connectivity with no further routing changes.

Sharing across accounts is done with AWS Resource Access Manager, and the roles are asymmetric. The core network owner has full control: create and deploy policy versions, add or remove Regions and CNEs, and accept or reject attachments from other accounts. An account the network is shared to becomes an attachment owner, which can only create, update, and delete its own VPC attachments and tags and has no permission over the core network policy. This split lets a central networking team keep authority over segmentation and routing while workload teams self-service their attachments under least privilege.

Inserting firewalls without route-table gymnastics

Service insertion steers same-segment or cross-segment traffic through inspection appliances (AWS Network Firewall, Gateway Load Balancer, or third-party NGFW/IDS/IPS) without hand-built routing. You define a network function group (NFG), a container of the inspection VPC attachments, and a segment action that redirects traffic to it. A send-via action inspects east-west VPC-to-VPC traffic and returns it to the core network to reach its destination; it is bidirectional and supports single-hop or dual-hop modes. A send-to action handles north-south traffic out to the internet or on-premises, where traffic does not re-enter the cloud.

Two requirements catch people. Isolated mode is required for service insertion to work between attachments in the same segment, because it removes the default direct path so traffic cannot bypass the firewall. Appliance mode must be enabled on the inspection VPC so flow symmetry is preserved in both directions. Note also that an NFG allows only one attachment per Region, and if an NFG has no attachment in a Region, traffic destined to it is blackholed until you add one.

There is no extra charge for service insertion itself beyond standard Cloud WAN pricing, but the inspection VPC attachments and the traffic they process still incur the normal per-attachment and per-GB data-processing fees, so a global dual-hop inspection design multiplies attachment count and data-processing volume.