AWS Cloud WAN series · Part 2 of 17

The Core Network Policy, Section by Section

Article 2 of the AWS Cloud WAN series: the JSON document is the product. Here is every top-level section, the rollback model that makes change management feel like git, and what the 2025.11 routing layer added — and didn't.

In Article 1 we landed on the central idea: the policy document is the product, and the service is its execution engine. This article opens that document and reads it the way Cloud WAN does — top to bottom, because the structure carries meaning. By the end you will know every section, how versioning and rollback actually behave, and exactly what the 2025.11 version unlocks and where it stops.

The policy is the product — eight sections, two required

A core network policy is a single JSON object carrying eight top-level sections — exactly two required (core-network-configuration and segments), the rest optional (Figure 1).

That eighth section is easy to miss — earlier write-ups listed only seven, before attachment-routing-policy-rules arrived with routing policies. Grouped into the five conceptual layers above, the document reads as a sentence — where it lives, how it is divided, what connects, how routes move, and how BGP routes are shaped — and we take the sections in that order.

Where the network lives — Regions, ASNs, and addressing

The core-network-configuration section answers where your network exists and what address space it uses — the foundation the rest of the policy references.

edge-locations — the AWS Regions you want connectivity in. For each Region listed, Cloud WAN provisions a Core Network Edge and auto-meshes it with every other edge — the single lever for regional reach. The operational catch: a Region cannot be removed from the policy until all of its attachments are deleted. Adding Regions is cheap; removing them needs cleanup first.

asn-ranges — the BGP ASN pool Cloud WAN draws from when it assigns an ASN to each edge. Valid ranges are 64512–65534 and 4200000000–4294967294. Two things to internalize. First, the range is left-closed, right-open: 64512-65534 includes 64512 but not 65534, so the usable span is 64512–65533. Second, an edge's ASN is immutable once assigned and cannot overlap the ASN of a Transit Gateway you intend to peer — plan allocation up front to avoid painful peering conflicts later.

inside-cidr-blocks — the CIDR pool used to build the tunnels for Connect attachments. The minimum is /24 for IPv4 and /64 for IPv6; each new edge auto-assigns itself a /24 and a /64 from the pool. You only need this if you will use Connect attachments — and on Cloud WAN, a Connect attachment's transport is a VPC attachment (BGP-only, GRE or tunnel-less), not Direct Connect. Size the block generously: if it runs out when you add an edge, the policy throws.

vpn-ecmp-support, dns-support, security-group-referencing-support — three boolean toggles whose defaults are true, true, and false respectively. ECMP spreads VPN traffic across equal-cost tunnels; DNS support lets attached VPCs resolve each other's names; security-group referencing lets a group in one VPC reference one in another — powerful for centralized security, off by default, opt in deliberately.

How you wall traffic off — segments, deny by default

Segments are the heart of the policy and the whole subject of Article 3, so here we cover only what the syntax expresses. A segment is a dedicated, globally consistent routing domain — a VRF or Layer 3 IP VPN, kept consistent across every Region for you. By default an attachment reaches only others in the same segment; cross-segment communication never happens unless you create it — the implicit-deny model: no route, no reachability.

The per-segment parameters worth knowing now:

• name — a plain string of only a–z, A–Z, and 0–9 (no hyphens or underscores). There is no ARN or ID; the name is the handle used everywhere else in the policy and in console metrics.
• edge-locations — optionally restrict the segment to a subset of the configured Regions, when it only needs to exist in some geographies.
• require-attachment-acceptance — defaults to true; an attachment claiming the segment must be approved before it joins. Your governance gate in multi-account setups.
• isolate-attachments — defaults to false; when true, attachments in the segment cannot talk to each other and reach only shared/static routes. This is how you build a strict "spoke reaches hub, never another spoke" topology.

How an attachment finds its segment — tags, not resources

Here Cloud WAN's automation shows, and it surprises people: you do not wire each VPC or VPN to a segment by hand — you tag the attachment, and an attachment policy maps it to a segment from that tag.

The distinction that trips up almost everyone once: the policy reads tags on the attachment object, not tags on the underlying resource. A tag environment: production on the VPC attachment routes it to the production segment; the same tag on the VPC itself does nothing for this purpose.

Each attachment policy is a rule with:

• a rule-number (1–65535) — rules evaluate lowest to highest, first match wins.
• condition-logic — and / or across the conditions.
• conditions — what to match: not just tags, but account ID, Region, attachment type, and resource ID (e.g. a specific vpc-id).
• an action — the association-method is either constant (a named segment) or tag (the segment equals the matched tag value).

Because you can match on account, Region, and type — not only tags — you can state organization-wide intent like "any VPC attachment from the security account goes to the inspection segment" without touching individual resources. In multi-account estates this collapses huge operational overhead into a few declarative rules.

How routes cross the walls — segment actions

If attachment policies decide where things connect, segment actions decide how routes and traffic move between segments. There are four kinds.

Segment sharing (share) — the default route-exchange mechanism, bidirectional by default (a deny- or allow-filter, mutually exclusive, plus an except block makes it one-directional). Figure 2 shows its two load-bearing properties: sharing is non-transitive and propagates only attachment/propagated routes, not static routes. The non-transitivity is a feature — it stops a shared-services or egress segment from becoming an accidental bridge between things that should never connect.

Segment routes — static routes within a segment, including blackhole routes that drop traffic to a CIDR. Cloud WAN does not propagate blackhole routes; they are local intent only. A common pattern is a static default route (0.0.0.0/0) pointing at an egress attachment, which then replicates across the segment — Regions without their own listed attachment receive a propagated version.

Service insertion (send-via / send-to) — steers traffic through a network function group for inspection. send-via is east-west (traffic re-enters the core after inspection and is bidirectional automatically); send-to is north-south (traffic is inspected then exits, installing default routes 0.0.0.0/0 and ::/0 into the source segment). The mechanics are the subject of Articles 8–10, so we leave them there.

Routing-policy association — binds a routing policy to attachments via attachment-routing-policy-rules, the eighth section. This is part of the 2025.11 capability below.

How you shape the routing — and where you can't (2025.11)

The 2025.11 policy version, GA on November 20, 2025, adds genuine BGP-grade route control that Cloud WAN previously lacked. To use it you set the version in the configuration; doing so also turns on BGP community propagation through the core, so community tags from BGP-capable attachments begin to flow (inbound subtype info is dropped; the outbound subtype is set to Route Target).

A routing policy is an ordered set of match–action rules with a direction (inbound / outbound, Figure 3): match conditions cover prefixes, prefix lists, BGP communities, and BGP attributes; actions allow/drop, summarize, or modify path preference. In practice it shrinks route-reachability blast radius, prevents route-table overrun, and influences path selection for resilient hybrid designs.

The capability boundaries are easy to trip over, and they vary by attachment type (Figure 3). One ordering rule the matrix omits: segment-share is applied after attachment policies — worth remembering when reasoning about evaluation order.

That last boundary is the one to underline: it is not "everything except Direct Connect." Communities ride VPN and Connect attachments and nothing else. If you do not need summarization, community-based filtering, or path preference, stay on 2021.12 and upgrade only when a concrete requirement demands it.

How you change it without fear — versioning and rollback

Every change produces a new policy version; only one is LIVE at a time, and a new version never deploys automatically. You edit a draft, review its generated change set, then execute it to go LIVE — and restoring an earlier version is a one-action rollback of your entire global network's configuration (Figure 4).

That change-set gate is the operational story that makes Cloud WAN compelling for change management. In the TGW world an incident means hand-unwinding changes across dozens of resources in multiple Regions under pressure; here the safe state is a prior version sitting right there. Treat versions like git commits — small, reviewable diffs with rollback one step away — and when you manage the policy as code (Article 13), the version-as-commit model maps cleanly onto your IaC history.

The whole policy, minimal — read as intent

Stripped to essentials, a working two-Region policy with a production and a development segment looks structurally like this:

{
 "version": "2025.11",
 "core-network-configuration": {
 "vpn-ecmp-support": true,
 "dns-support": true,
 "inside-cidr-blocks": ["10.0.0.0/16"],
 "asn-ranges": ["64512-65534"],
 "edge-locations": [
 { "location": "us-east-2" },
 { "location": "us-west-2" }
 ]
 },
 "segments": [
 { "name": "production", "require-attachment-acceptance": true },
 { "name": "development", "require-attachment-acceptance": true,
 "isolate-attachments": true }
 ],
 "attachment-policies": [
 {
 "rule-number": 100,
 "condition-logic": "and",
 "conditions": [
 { "type": "tag-value", "key": "segment", "operator": "equals",
 "value": "production" }
 ],
 "action": { "association-method": "constant", "segment": "production" }
 }
 ]
}

Read it as intent: operate in two Regions, draw ASNs from this range, create two isolated routing domains, gate both on acceptance, isolate development's spokes from each other, and auto-map any attachment tagged segment: production into the production domain. Roughly a hundred lines of policy replace what would be a hundred separate route-table, association, and propagation resources in a TGW design — and it is one versioned artifact you can roll back.

You now know the document's anatomy. The section that carries the most design weight, and where teams most often go wrong, is segments — they also share a hard ceiling of 40 per core network, which Article 3 takes head-on alongside segmentation strategy: designing by trust boundary rather than org chart, and turning a security requirement into a policy before you write any JSON.