AWS 276: AWS Cloud WAN and Network Manager selection overview
Why this lesson matters
Transit Gateway can build excellent Regional hubs, and inter-Region peering can connect them. At larger global scale, however, teams may maintain many static peer routes, inconsistent segment tables, and separate operational views. AWS Cloud WAN provides a managed global core network whose Regional edges and routing intent are governed by a versioned policy.
Cloud WAN is not simply a larger TGW. It changes the operating model from editing many Regional resources to declaring global segments, attachment classification, route sharing, static routes, service insertion, and modern routing policy. That central policy can reduce drift, but an incorrect change can also create global reachability or isolation impact. This lesson teaches when to select Cloud WAN, when to retain TGW, and how to review policy without creating a paid core network.
Outcomes
By the end, you can:
- distinguish Network Manager, global networks, Cloud WAN core networks, and Regional core network edges;
- compare Cloud WAN, Regional TGWs, TGW peering, and a combined migration design;
- explain segments as global route domains rather than security groups;
- classify VPC, VPN, Connect, Direct Connect gateway, and TGW route-table attachments;
- predict attachment-policy matching, acceptance, and default-segment behavior;
- calculate segment sharing, isolation, static, blackhole, and service-insertion routes;
- explain 2025.11 routing policies, BGP communities, and attachment routing policies;
- review policy versions, change sets, deployment state, rollback, and blast radius;
- design monitoring, failure, quota, ownership, and cost controls; and
- produce a no-create selection dossier and annotated policy for a global enterprise.
Network Manager and Cloud WAN are related, not identical
AWS Network Manager provides a connectivity console and APIs for global network resources and operational views. It can help visualize and monitor AWS and on-premises connectivity. Cloud WAN is the managed global network service configured through Network Manager. Creating a global-network container or viewing topology is not the same as creating a Cloud WAN core network and its billable edges/attachments.
| Construct | Meaning |
|---|---|
| Global network | Top-level Network Manager container for network objects |
| Core network | Cloud WAN's global managed routing system |
| Core network edge (CNE) | AWS-managed Regional connection point created for each policy edge location |
| Segment | Global routing domain, comparable to a VRF |
| Attachment | VPC, VPN, Connect, Direct Connect gateway, or TGW route-table connection |
| Core network policy | Versioned JSON intent that defines edges, segments, routes, service insertion, and classification |
| LIVE policy | Policy version currently applied to the core network |
Core network edges form managed full-mesh connectivity across the AWS global network. Attachments connect to an edge in an enabled Region. Segments provide consistent route domains across edges. Cloud WAN controls network reachability, not workload ports, user identity, application authorization, data replication, or DNS correctness.
Choose the operating model before the service
| Requirement | Regional TGW | TGW peering | Cloud WAN |
|---|---|---|---|
| One/few Regions | strong, direct fit | unnecessary | may add complexity/cost |
| Local specialist control | explicit route tables | explicit per-peer routes | central policy dominates |
| Many global Regions/sites | many hubs | static peer mesh/routes | managed global core/edges |
| Global route-domain consistency | automation required | automation required | segments in one policy |
| Dynamic branch/SD-WAN integration | VPN/Connect per TGW | peer routes remain static | VPN/Connect to Regional edges |
| Fine global route policy | Regional tables/BGP design | limited static peering | current routing policies/communities |
| Existing TGW investment | native | native | TGW route-table attachment migration option |
| Small team/simple network | often easier | manageable at modest scale | policy expertise still required |
Select Cloud WAN when global segmentation and policy operations solve measurable route/ownership scale problems. Reject it when two TGWs and a small set of static routes are clearer and cheaper. Do not choose it merely for a prettier topology map.
A combined pattern can retain TGW route domains and attach selected TGW route tables to a Cloud WAN core network. This supports phased migration, but teams remain responsible for TGW route propagation and for understanding which routes enter or leave the route-table attachment.
Segments and attachment classification
Each segment is an independent global routing domain. By default, attachments in the same segment can communicate and attachments in different segments cannot. The isolate-attachments option prevents same-segment attachments from communicating through ordinary attachment routes, except for explicitly shared/static behavior. This is routing isolation, not a firewall.
An attachment policy maps attachments to a segment or network function group. Rules have numeric order and conditions such as attachment type, account, Region, resource, or tags. The tags evaluated are attachment tags, not simply tags on the attached VPC. A broad earlier rule can capture an attachment before a later specific rule.
Design explicit outcomes:
production,development,shared-services,hybrid, andquarantinesegments;- approved Regions for each segment;
- whether same-segment attachment communication is allowed;
- whether attachment acceptance or tag acceptance is required;
- exact tag schema and owner;
- catch-all behavior for unmatched attachments; and
- quarantine/rejection when identity is missing or contradictory.
Automatic acceptance plus a permissive default segment can connect a mistagged VPC globally. Requiring manual acceptance creates an operational queue but gives the owner a review gate. Treat attachment tags as high-impact routing inputs protected by IAM and policy validation.
Route sharing, static routes, and blackholes
The share segment action exchanges directly attached routes between the named segment and share-with segments. Sharing with production and development lets both reach shared services, but does not make production and development reach each other. Sharing is bidirectional by default; route filters/routing policy are required for directional control.
Attachment-route sharing does not transitively share static routes or routes learned from another shared segment. If a static destination is needed in several segments, define it deliberately for each. This prevents accidental transitive route leaks but surprises architects who assume all learned routes are re-exported.
A create-route action adds a static destination to one or more attachments, or a blackhole. Because a segment is global, provide a suitable destination attachment per Region where local routing is required. Otherwise an edge may use an attachment in a remote Region, increasing latency, inter-Region processing, and failure scope. Longest-prefix match still matters: a more-specific route can defeat a broad blackhole or inspection route.
Cloud WAN does not propagate blackhole routes as learned routes. Test the resulting route tables rather than assuming a blackhole in one segment/edge protects another.
Service insertion and network function groups
A network function group contains inspection/egress attachments. Segment actions can steer traffic:
send-viafor east-west traffic that enters Cloud WAN again after the network function; andsend-tofor north-south traffic that exits through the network function, such as internet egress.
Service insertion reduces the number of individual static inspection routes, but stateful symmetry, zonal appliance routing, firewall endpoints, NAT, and return behavior still need proof. Cloud WAN policy selects attachment paths; it does not synchronize firewall state or validate that the appliance processed the packet.
Define an inspection attachment per required Region to avoid hauling ordinary Regional traffic to a remote firewall. Use appliance mode where supported on the inspection VPC attachment and follow the per-AZ routing methods from AWS274. Test a failed firewall endpoint, entire inspection attachment, and Region. Explicitly decide fail closed versus alternate path.
Network function group attachment policies are separate classification outcomes. Do not accidentally map a workload attachment into the firewall group because both use an environment=prod tag.
Routing policies and policy version 2025.11
Core policy schema 2025.11 enables routing policies and BGP community support. Routing policies can filter, summarize, or modify routes and influence path preference based on rule conditions/actions. They can be associated with segment sharing, edge-location pairs, or attachments. Attachment routing policies map attachments to routing policies, using policy labels and separate rule logic from segment attachment policies.
This creates two distinct questions:
- Which segment or network function group owns the attachment?
- Which routing policy processes routes associated with that attachment/path?
Do not confuse an attachment policy with an attachment routing policy. Review BGP communities from capable attachments, prefix filters, summarization, preference changes, and edge-pair associations. A summary can attract traffic for an absent child prefix; a denied route can remove recovery reachability; a preference change can create asymmetric hybrid paths.
Use schema 2021.12 only when its older capability set is intentionally sufficient. Migrating schema versions must be tested as a routing change, not a formatting update.
Annotated policy model
This excerpt is a review artifact, not a deployment template:
{
"version": "2025.11",
"core-network-configuration": {
"asn-ranges": ["64520-64529"],
"edge-locations": [
{"location": "ap-south-1"},
{"location": "eu-west-1"}
]
},
"segments": [
{"name": "production", "require-attachment-acceptance": true},
{"name": "development", "isolate-attachments": true},
{"name": "shared-services", "require-attachment-acceptance": true}
],
"segment-actions": [
{
"action": "share",
"mode": "attachment-route",
"segment": "shared-services",
"share-with": ["production", "development"]
}
],
"attachment-policies": [
{
"rule-number": 100,
"condition-logic": "and",
"conditions": [
{"type": "tag-value", "key": "environment", "operator": "equals", "value": "production"}
],
"action": {"association-method": "constant", "segment": "production"}
}
]
}
Before deployment add explicit development/shared attachment rules, approved account/Region/resource conditions, default handling, network function groups, route controls, descriptions, and governance. A policy that classifies only production leaves other attachments unmatched; that is deliberate in this teaching excerpt.
Check ASN overlap with TGW, customer, partner, Direct Connect, VPN, and SD-WAN devices. Edge ASN selection affects BGP sessions and cannot be treated as cosmetic.
Supported attachments and routing boundaries
VPC attachment
Select one subnet per enabled AZ. The attachment makes the edge available to resources in that AZ through VPC route tables. VPC routes are still explicit. Options include appliance mode, DNS support, IPv6 behavior, and security-group referencing subject to current constraints. Local Zone subnets cannot be selected for the attachment.
Site-to-Site VPN and Direct Connect gateway
These connect branches and private circuits to the core. Validate BGP ASN, advertisements, allowed prefixes, communities, redundancy, route preference, encryption requirements, and customer return path. A globally propagated branch prefix can have a much wider blast radius than a Regional TGW route.
Connect attachment
Connect integrates compatible SD-WAN/virtual appliances using BGP over GRE or supported tunnel-less behavior. Underlay reachability, peer addresses, BGP, appliance scale, ECMP/path policy, and MTU are separate evidence layers.
TGW route-table attachment
Attach an existing TGW route table through the supported Cloud WAN peering construct. This is useful for migration and coexistence. Routes originating from that route table have special responsibility boundaries, including effects not governed by every segment isolation option. Inspect both Cloud WAN and TGW route tables.
Policy lifecycle and safe deployment
A policy document becomes a candidate policy version. Cloud WAN validates it and generates a change set compared with LIVE. It does not automatically become live merely because a version was created.
Use this workflow:
- Export the current LIVE JSON, policy ID/version, routes, attachments, and acceptance states.
- Modify source-controlled policy through review, not the console alone.
- Validate JSON schema and organization-specific invariants.
- Create a candidate policy version.
- inspect every change-set item and line-level comparison;
- calculate attachments, segments, Regions, prefixes, and flows affected;
- run offline route/segmentation tests and stakeholder approval;
- execute during a controlled window;
- observe policy/edge/attachment state until deployment completes;
- run positive and negative probes in each affected Region;
- compare metrics/routes and application SLOs; and
- restore the prior known-good policy version if gates fail.
Rollback is another global policy deployment and may take time. It does not restore sessions dropped during route convergence. Preserve a management path that does not depend on the policy being changed.
Governance and multi-account ownership
Usually a network account owns the core network and policy. Application/branch accounts own attachments, VPC route tables, workloads, and local security. AWS RAM sharing and organization integration permit controlled cross-account use.
| Role | Accountable work |
|---|---|
| Global network platform | core policy, edges, segments, routes, service insertion |
| Regional network team | VPC/TGW routes, attachments, hybrid underlay |
| Security | segmentation intent, firewall policy, logging and exceptions |
| Application owner | connectivity request, ports, tests, cost center |
| Change authority | policy approval, maintenance, rollback decision |
| FinOps | attachment/edge/data/log allocation and anomaly review |
Apply least privilege to policy-version creation, execution, attachment acceptance, tag changes, and RAM shares. CloudTrail records control-plane actions; retain policy source and approval evidence independently.
Monitoring and troubleshooting
Cloud WAN publishes metrics in AWS/NetworkManager. For commercial Regions, these metrics are viewed in US West (Oregon), even when edge locations are elsewhere. Monitor edge and attachment bytes/packets, drops where available, VPN/BGP health, policy/attachment state, and application SLOs. Use Network Manager route/topology views as operational evidence, not as proof of application authorization.
aws networkmanager list-global-networks --region us-west-2 --output json
aws networkmanager list-core-networks --region us-west-2 --output json
CORE_NETWORK_ID="core-network-approved-id"
aws networkmanager get-core-network + --core-network-id "$CORE_NETWORK_ID" --region us-west-2 --output json
aws networkmanager list-core-network-policy-versions + --core-network-id "$CORE_NETWORK_ID" --region us-west-2 --output json
aws networkmanager list-attachments + --core-network-id "$CORE_NETWORK_ID" --region us-west-2 --output json
For an approved LIVE policy and edge:
POLICY_VERSION_ID="replace-with-live-version"
EDGE_LOCATION="ap-south-1"
aws networkmanager get-core-network-policy + --core-network-id "$CORE_NETWORK_ID" + --policy-version-id "$POLICY_VERSION_ID" + --region us-west-2 --output json
aws networkmanager get-network-routes + --global-network-id "global-network-approved-id" + --route-table-identifier '{"CoreNetworkSegmentEdge":{"CoreNetworkId":"'"$CORE_NETWORK_ID"'","SegmentName":"production","EdgeLocation":"'"$EDGE_LOCATION"'"}}' + --region us-west-2 --output json
Confirm current CLI shapes before execution because complex identifiers are version-sensitive. All commands are read-only.
| Symptom | First evidence | Likely cause |
|---|---|---|
| Attachment pending | attachment/tag acceptance state | owner approval or changed tag required |
| Attachment in wrong segment | attachment policy order and tags | broad earlier rule or wrong attachment tag |
| Same-segment VPCs cannot communicate | isolate-attachments and routes | intentional isolation or missing share/static path |
| Shared services work one way | filters and return routes | directional route filter/local VPC route |
| Static service route absent elsewhere | segment action per segment | static routes are not transitively shared |
| Traffic uses remote Region | static destinations/local attachment health | no local destination attachment |
| Hybrid path asymmetric | routing policy/BGP communities/customer route | preference differs by direction |
| Policy deployed, app fails | VPC routes/security/DNS/app logs | global route exists but local or app layer fails |
Diagnose policy classification, core routes, attachment state, VPC/TGW local routes, security, DNS, and application in that order. Never add share-with: "*" or broad 0.0.0.0/0 merely to restore a test.
Failure and resilience
Test an attachment, edge location, inspection attachment, VPN tunnel, DX path, SD-WAN peer, route withdrawal, policy deployment, and management API impairment. A full-mesh managed core does not make a single VPC attachment or single branch circuit resilient.
Cloud WAN global policy can continue to describe routes while a destination application is unavailable. Health-aware application failover remains separate. Design local Regional egress/inspection when a Region must operate during inter-Region isolation. Avoid making every branch depend on one remote inspection Region.
Quarantine should map a compromised attachment into a segment with only forensic/remediation services. Changing attachment tags can trigger pending acceptance and routing changes; pretest the full automation, evidence preservation, and rollback.
Cost and quotas
Model core network edge hours, attachment hours by type, intra/inter-Region data processing, TGW/DX/VPN/Connect components, cross-AZ paths, firewalls/NAT, logs/metrics, and operational tooling. Global traffic paths can incur processing at more than one edge/attachment plus transfer. Compare normal, failure, inspection, and migration/coexistence paths.
Quotas include core networks, edges, segments, policy size/versions, attachments by type, routes, shares, peerings, Connect peers, VPNs, and throughput characteristics. Retrieve current Service Quotas for the deployment accounts and Regions. A design beneath route count can still exceed attachment, policy, or BGP limits.
Cloud WAN can reduce engineering complexity without reducing the AWS bill. Compare a realistic TGW baseline, including automation labor and static-route risk, against Cloud WAN standing and processing charges.
Selection and policy workbook
Use this scenario: 60 VPCs in six Regions, 80 branches, two DX sites, SD-WAN, production/development/shared/security domains, Regional internet egress, and an existing TGW in each Region.
Submit:
- scored TGW, TGW-peering, Cloud WAN, and combined alternatives;
- six-Region CIDR/ASN and edge plan;
- attachment inventory with owner/type/Region/AZs/tags/acceptance;
- segment and route-sharing matrix including negative reachability;
- annotated
2025.11candidate policy; - attachment-policy truth table with 20 sample attachments;
- routing-policy/community/filter/summarization plan;
- network function group and zonal inspection paths;
- 20 forward/return flow calculations;
- policy change-set review and rollback runbook;
- monitoring, quotas, FinOps, IAM, and RACI;
- eight failure/quarantine tests; and
- before/after proof that no AWS resource changed.
Knowledge check
- Is a segment a workload firewall?
No. It is a global routing domain; workload and application controls remain required.
- Do shared static routes automatically pass through another segment share?
No. Attachment-route sharing shares directly attached routes, not transitive/static routes.
- What enables routing policies and BGP communities?
Core network policy schema 2025.11.
- Does creating a policy version make it LIVE?
No. Review its validation and change set, then explicitly execute it.
- Why can an attachment enter the wrong segment?
Ordered attachment-policy conditions may match broad rules or incorrect attachment tags.
- Does Cloud WAN replace Regional VPC route tables?
No. Local subnet routes and all security/application layers remain.
Lesson acceptance
The lesson is complete only when the learner can:
- explain Network Manager versus Cloud WAN and every core construct;
- select TGW, peering, Cloud WAN, or a combined design from evidence;
- predict segment isolation, sharing, static, blackhole, and service-insertion routes;
- classify attachments safely using ordered policies and acceptance;
- explain 2025.11 routing policy, BGP community, and attachment routing policy boundaries;
- review a candidate change set and perform gated deployment/rollback;
- trace 20 bidirectional paths through edge, segment, local route, inspection, and application controls;
- diagnose attachment, policy, route, hybrid, and application failures;
- model resilience, quota, global blast radius, and complete cost;
- produce the 60-VPC/six-Region selection dossier; and
- attest that no staging or production AWS resource changed.