Cloud WAN: Segments, Attachment Policies, and Service Insertion

Cloud WAN replaces route tables and attachment wiring with a single declarative JSON document. That moves the work: instead of asking "is this route table associated", you ask "does the policy say these two attachments are in segments that share". This sheet is the object model and the defaults.

The object model#

Two things trip people coming from Transit Gateway. A core network edge is essentially a Transit Gateway — AWS's own docs say it "inherits many of the same properties" — but you never configure one directly. And segments are defined once at the core network level and exist identically at every edge, which is the opposite of per-Region route tables.

Global networkAccount-wideA container. Can hold Transit Gateways and core networks side by side.

Core networkMulti-RegionThe AWS-managed part. Operates only in the Regions the policy names.

counted here: segments and network function groups are defined HERE, once, and apply everywhere

Core network edge, us-east-1One RegionCreated because the policy lists this Region. Full-mesh peered with every other edge automatically.

counted here: $0.50/hr, plus an hourly fee per attachment

Core network edge, eu-west-1One RegionSame segments, same routing intent, no separate configuration.

counted here: $0.50/hr, plus an hourly fee per attachment

A segment is one object spanning every edge. Adding a Region to the policy instantiates every existing segment there; you do not rebuild routing per Region.

A segment is closest to a globally consistent VRF, or a Layer 3 IP VPN over MPLS. Note that a segment has no ARN and no ID — it is only a name, referenced as a string from the rest of the policy.

The policy document#

One JSON document, versioned. You can keep many versions but only one is in effect, and you can revert to a previous one.

Section	Required	What it does
version	Yes	2021.12 or 2025.11
core-network-configuration	Yes	Which Regions get edges, ASN ranges, global toggles
segments	Yes	The routing domains. At least one
network-function-groups	No	Attachment groups holding security appliances
segment-actions	No	How routes cross segments, and service insertion
attachment-policies	No	How attachments get mapped to segments
routing-policies	No	Route filtering and modification. Needs version 2025.11

Choosing 2025.11 is not only about route policies. It also switches on BGP community support, so community tags from BGP-capable attachments begin propagating through the core network — subtype information is dropped, and outbound tags have their subtype set to Route Target. That is a behaviour change to existing traffic, not just a new capability.

Defaults that decide reachability#

The defaults are mixed in direction, which is the problem. Some fail closed, some fail open.

Setting	Default	Effect of the default
require-attachment-acceptance	true	Attachments wait for approval
isolate-attachments	false	Attachments in one segment can reach each other
dns-support	true	Enabled
vpn-ecmp-support	true	Enabled
security-group-referencing-support	false	Disabled — same default as Transit Gateway

Two of those deserve more than a row.

isolate-attachments set to true means same-segment attachments cannot talk, and only shared routes or static routes remain — but routes coming from a route table attachment are not affected by it. If you isolate a segment and a Transit Gateway route table attachment is in it, you are still responsible for what that attachment propagates.

require-attachment-acceptance set to false does more than skip an approval click. Attachments can then be added to or removed from a segment automatically when their tags change, so a tag edit becomes a routing change. If that is not what you want, leave it at true.

Sharing a segment is hub-and-spoke#

This is the most commonly misread part of the policy. A share action between segment shared-services and a share-with array of prod and prod2 produces:

Path	Reachable
prod → shared-services	Yes
prod2 → shared-services	Yes
prod → prod2	No

Sharing happens between the named segment and each member of the array, never between members of the array. If you want prod and prod2 to reach each other you write that share explicitly.

Sharing is also not transitive. mode has exactly one supported value, attachment-route, which places attachment and return routes into each share-with segment — static routes, and routes that arrived in the segment from some other share, are not carried along. The share-with field accepts "*" for every segment, or an except block to exclude specific ones.

One ordering detail: a segment's deny-filter is applied after routes have been shared. A segment listed in another's deny filter never receives shared routes from it, regardless of how many share statements exist.

Static routes#

create-route takes destination-cidr-blocks plus destinations, which holds up to one attachment per Region. Regions with no attachment in that list receive a propagated copy of the route through cross-Region peering and use another Region's attachment — so an incomplete destinations list is a working configuration that sends traffic to the wrong continent. You can pass blackhole instead of attachments, and Cloud WAN does not propagate blackhole routes, so a blackhole is local to the Region that defines it.

Attachment policies match the attachment#

The trap here costs people an afternoon: attachment policies evaluate the tags on the attachment object, not the tags on the underlying VPC. Tagging a VPC environment: development and expecting it to land in the development segment does nothing. The tag has to be on the attachment.

Rules are numbered and evaluated in number order. Conditions can match on more than tags — account ID, attachment type, resource ID such as a vpc-id, and Region are all available.

Supported attachment types:

Type in policy	Resource
vpc	A VPC
site-to-site-vpn	A Site-to-Site VPN
direct-connect-gateway	A Direct Connect gateway
transit-gateway-route-table	A Transit Gateway route table
connect	A Transit Gateway Connect attachment, for SD-WAN

A transit virtual interface can terminate on a core network rather than a Transit Gateway, which is how Direct Connect reaches Cloud WAN. The Direct Connect sheet covers the VIF side.

Service insertion#

Network function groups hold the attachments where your appliances live. An attachment belongs to a segment or to a network function group, never both — which is the constraint that shapes inspection designs here.

Action	Traffic	mode
send-via	East-west, between attachments	single-hop or dual-hop
send-to	North-south, out to the internet or on-premises	Not used

Network function groups carry their own route tables, and their routes are propagated automatically with next-hop redirection based on the policy rather than by you writing them.

ASN rules#

ASNs must come from 64512–65534 or 4200000000–4294967294. Edges take one automatically from asn-ranges unless you pin it per edge location.

The rule that bites: you cannot change an edge's ASN once assigned, and a Transit Gateway with the same ASN cannot peer with that edge. An edge on 64512 and a Transit Gateway left on the default 64512 will not peer, and the fix is rebuilding one of them. This is the same collision that blocks a Direct Connect gateway associating with a Transit Gateway on matching ASNs.

Two more constraints worth knowing before you plan: inside-cidr-blocks is required before any Connect attachment will work, minimum /24 for IPv4 or /64 for IPv6; and a Region cannot be removed from the policy until every attachment in it is deleted.