AWS Cloud WAN · Global core network

Run your multi-Region network from a single policy document

With AWS Cloud WAN, you declare Regions, segments, and attachment rules in a JSON policy, and AWS creates a core network edge in each Region and meshes them together. A single policy replaces building a Transit Gateway per Region and managing peering routes by hand.

View policy structure View architecture
core-network-policy.jsonLIVE
{
  "version": "2025.11",
  "core-network-configuration": {
    "asn-ranges": ["64512-64555"],
    "edge-locations": [
      { "location": "ap-northeast-2" },
      { "location": "ap-northeast-1" },
      { "location": "us-east-1" }
    ]
  },
  "segments": [
    { "name": "prod",
      "require-attachment-acceptance": true },
    { "name": "shared" }
  ],
  "segment-actions": [{
    "action": "share",
    "mode": "attachment-route",
    "segment": "shared",
    "share-with": ["prod"]
  }]
}

Places core network edges in three Regions, creates prod and shared segments, and shares the shared routes with prod.

100 Gbps

Max bandwidth per VPC attachment, per AZ

8500

MTU between VPC · peering · Tunnel-less Connect (bytes)

Full mesh

Automatic peering between core network edges

2025.11

Policy version that supports Routing policy

Why Cloud WAN

Routing intent should live in one place, however many Regions you add

When you build a global network from per-Region Transit Gateways, peering, and static routes, configuration scatters with every Region you add. With Cloud WAN, you declare the desired state, review the changes, and then apply them.

Declare

Declarative policy

Segments, Regions, and attachment mapping rules are managed as policy versions. Review changes before applying them, and roll back to a previous version when needed.

Segment

Global segments

A segment is a routing domain that spans all Regions. By default, communication happens only within the same segment, much like a VRF in MPLS.

Mesh

Automatic inter-Region connectivity

Adding a Region to the policy creates a core network edge that joins the other edges in a full mesh. Inter-Region routes propagate dynamically.

Policy anatomy

Building blocks of a core network policy

A policy document has eight top-level keys. The first three are required; add the rest as needed.

versionrequired

The policy syntax version. Specify 2025.11 to use Routing policy and BGP community propagation.

core-network-configurationrequired

Global settings such as ASN ranges, the Regions that host edges (edge-locations), and VPN ECMP, DNS, and security group referencing support.

segmentsrequired

Defines routing domains. For each segment, set the Regions it uses, whether attachments require acceptance, and whether attachments are isolated from each other.

network-function-groupsoptional

Groups of attachments that host firewalls or IDS/IPS. They are the targets of service insertion.

segment-actionsoptional

Defines route sharing between segments, static routes, service insertion, and Routing policy associations.

attachment-policiesoptional

Automatically maps attachments to segments or network function groups based on conditions such as tags.

routing-policiesoptional

Rules for route filtering, summarization, and BGP attribute changes in the inbound or outbound direction.

attachment-routing-policy-rulesoptional

Specifies which Routing policy applies to attachments that match a Routing policy label condition.

action values in segment-actions sharecreate-routesend-viasend-toassociate-routing-policy

Features

Key features

Auto mapping

Attachment policies

Assigns a segment automatically based on an attachment's tags. For segments that require acceptance, the network team reviews the attachment before it connects.

Service insertion

Network function group

Use send-via to steer traffic between segments, and send-to to steer traffic bound for the internet or on-premises, through an inspection VPC. send-via supports single-hop or dual-hop.

Hybrid

Direct Connect gateway attachment

Attach a DX gateway directly to the core network. On-premises routes learned over a transit VIF propagate to every Region in the segment, with no intermediate Transit Gateway.

Route control

Routing policy

Match routes by prefix, prefix list, AS-PATH, BGP community, or MED to filter or summarize them, and tune path preference with Local Preference, AS-PATH, and MED. Applies to attachments as well as segment sharing and inter-Region routes.

SD-WAN

Tunnel-less Connect

SD-WAN appliances in a VPC peer with the core network edge over BGP without GRE tunnels. Up to 100 Gbps per Connect peer, per AZ.

Migration

Transit Gateway peering

Peer an existing Transit Gateway with the core network edge in the same Region and attach Transit Gateway route tables to segments to migrate in stages.

Attachment types

Bandwidth and Routing policy support by attachment type

VPCs support inbound route filtering only, while BGP-based attachments also support summarization and BGP attribute changes. Routing policy does not apply to network function groups.

Bandwidth and Routing policy support by Cloud WAN attachment type
Attachment typeMax bandwidthRouting policyNotes
VPC 100 Gbps · per AZ Inbound route filtering (allow · drop) MTU 8500 bytes, up to 7,500,000 PPS per AZ
Site-to-Site VPN 1.25 Gbps per tunnel, 5 Gbps for Large bandwidth tunnels Filtering · summarization · path preference · BGP communities VPN ECMP is turned on or off in the policy (on by default). Accelerated VPN and VPN Concentrator are Transit Gateway only and cannot attach directly to a core network.
Connect 5 Gbps per GRE peer, 100 Gbps per Tunnel-less peer per AZ Filtering · summarization · path preference · BGP communities For SD-WAN integration.
Direct Connect gateway Follows Direct Connect quotas. Filtering · summarization · path preference A DX gateway can attach to only one core network.
Transit Gateway route table Follows Transit Gateway peering quotas. Filtering · summarization · path preference Created after peering with a Transit Gateway in the same Region.

Reference architecture

A core network spanning three Regions

Three core network edges are connected in a full mesh. Each attachment joins a segment based on its tags, and traffic between segments passes through the inspection VPC in a network function group.

Cloud WAN reference architecture Core network edges in the Seoul, Tokyo, and N. Virginia Regions are connected in a full mesh. The data center enters the hybrid segment through a Direct Connect gateway, and the branch SD-WAN connects to the Tokyo edge through Tunnel-less Connect in an SD-WAN VPC. The prod segment VPC attaches to the Seoul edge; a network function group made of an inspection VPC and the dev segment VPC attach to the Virginia edge; and an existing Transit Gateway peering attaches to the Tokyo edge. ON-PREMISES AWS CORE NETWORK Data centerBGP router BranchSD-WAN edge DX Gatewayseg: hybrid SD-WAN VPCseg: hybrid CNE Seoulap-northeast-2 CNE Tokyoap-northeast-1 CNE Virginiaus-east-1 VPC prodseg: prod Inspection VPCNFG: inspection VPC devseg: dev Transit Gatewaypeering · seg: shared DX Tunnel-less Connect send-via
Mesh between core network edges attachment SD-WAN underlay (internet) Inter-segment traffic (via inspection VPC)

On narrow screens, swipe the diagram sideways.

Getting started

Steps to stand up a core network

  1. STEP 1

    Create a global network

    In Network Manager, create the global network that will contain the core network.

  2. STEP 2

    Write the policy

    Define ASN ranges, edge Regions, segments, and attachment policies.

  3. STEP 3

    Review and apply changes

    Review the policy version's change set and execute it to deploy the edges.

  4. STEP 4

    Create attachments

    Attach VPCs, VPNs, Connect, and DX gateways with tags, and accept them if required.

  5. STEP 5

    Verify routes

    Check inter-Region and shared routes in each segment's route table.

Pricing

Cost components

Cloud WAN pricing is based on the number of core network edges, the number of attachments and their hours, and the amount of data sent to the core network. Inter-Region transfer, VPN, and Direct Connect connections are charged separately.

AWS Cloud WAN billing components
ComponentBilling basisNotes
Core network edge hoursHours for one edge per Region listed in the policy's edge-locations. Partial hours are billed as full hours.Billed to the account that created the core network.
Attachment hoursHours each attachment is connectedBilled to the VPC owner for VPC, the DX gateway owner for Direct Connect, and the core network owner account for VPN and Connect.
Transit Gateway peeringHours the edge and Transit Gateway are connected by peeringTransit Gateway route table attachments over the peering have no additional charge.
Data processingGB sent to the core network from VPC, VPN, and Direct ConnectConnect (SD-WAN) traffic is counted as data sent from the underlying VPC. There is no processing charge for traffic sent over peering between a core network edge and a Transit Gateway, or for traffic leaving an edge toward a VPC.
Inter-Region data transferGB sent between RegionsBilled at standard AWS data transfer rates.
Site-to-Site VPN · Direct ConnectVPN connection hours, Direct Connect port hours and data transferBilled separately at each service's rates.

Rates vary by Region and usage. See the AWS Cloud WAN pricing page for current rates.

Next step

Design the segments of your global network with us

Bring your operating Regions, segmentation criteria, on-premises and SD-WAN connectivity, and inspection requirements, and we'll review a draft policy and migration plan together.

Open service page Read the User Guide