Lesson 276 · AWS Learning Path

AWS 276: AWS Cloud WAN and Network Manager selection overview

· Published · 14 min read

Labelled process diagram for AWS 276: Global connectivity intent to Versioned core network policy to Regional core network edges to Segmented attachments and observed routes, with decision, proof and rejection evidence.

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.

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.

ConstructMeaning
Global networkTop-level Network Manager container for network objects
Core networkCloud WAN's global managed routing system
Core network edge (CNE)AWS-managed Regional connection point created for each policy edge location
SegmentGlobal routing domain, comparable to a VRF
AttachmentVPC, VPN, Connect, Direct Connect gateway, or TGW route-table connection
Core network policyVersioned JSON intent that defines edges, segments, routes, service insertion, and classification
LIVE policyPolicy 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

RequirementRegional TGWTGW peeringCloud WAN
One/few Regionsstrong, direct fitunnecessarymay add complexity/cost
Local specialist controlexplicit route tablesexplicit per-peer routescentral policy dominates
Many global Regions/sitesmany hubsstatic peer mesh/routesmanaged global core/edges
Global route-domain consistencyautomation requiredautomation requiredsegments in one policy
Dynamic branch/SD-WAN integrationVPN/Connect per TGWpeer routes remain staticVPN/Connect to Regional edges
Fine global route policyRegional tables/BGP designlimited static peeringcurrent routing policies/communities
Existing TGW investmentnativenativeTGW route-table attachment migration option
Small team/simple networkoften easiermanageable at modest scalepolicy 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, and quarantine segments;
  • 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-via for east-west traffic that enters Cloud WAN again after the network function; and
  • send-to for 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:

  1. Which segment or network function group owns the attachment?
  2. 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:

  1. Export the current LIVE JSON, policy ID/version, routes, attachments, and acceptance states.
  2. Modify source-controlled policy through review, not the console alone.
  3. Validate JSON schema and organization-specific invariants.
  4. Create a candidate policy version.
  5. inspect every change-set item and line-level comparison;
  6. calculate attachments, segments, Regions, prefixes, and flows affected;
  7. run offline route/segmentation tests and stakeholder approval;
  8. execute during a controlled window;
  9. observe policy/edge/attachment state until deployment completes;
  10. run positive and negative probes in each affected Region;
  11. compare metrics/routes and application SLOs; and
  12. 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.

RoleAccountable work
Global network platformcore policy, edges, segments, routes, service insertion
Regional network teamVPC/TGW routes, attachments, hybrid underlay
Securitysegmentation intent, firewall policy, logging and exceptions
Application ownerconnectivity request, ports, tests, cost center
Change authoritypolicy approval, maintenance, rollback decision
FinOpsattachment/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.

SymptomFirst evidenceLikely cause
Attachment pendingattachment/tag acceptance stateowner approval or changed tag required
Attachment in wrong segmentattachment policy order and tagsbroad earlier rule or wrong attachment tag
Same-segment VPCs cannot communicateisolate-attachments and routesintentional isolation or missing share/static path
Shared services work one wayfilters and return routesdirectional route filter/local VPC route
Static service route absent elsewheresegment action per segmentstatic routes are not transitively shared
Traffic uses remote Regionstatic destinations/local attachment healthno local destination attachment
Hybrid path asymmetricrouting policy/BGP communities/customer routepreference differs by direction
Policy deployed, app failsVPC routes/security/DNS/app logsglobal 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.11 candidate 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

  1. Is a segment a workload firewall?

No. It is a global routing domain; workload and application controls remain required.

  1. Do shared static routes automatically pass through another segment share?

No. Attachment-route sharing shares directly attached routes, not transitive/static routes.

  1. What enables routing policies and BGP communities?

Core network policy schema 2025.11.

  1. Does creating a policy version make it LIVE?

No. Review its validation and change set, then explicitly execute it.

  1. Why can an attachment enter the wrong segment?

Ordered attachment-policy conditions may match broad rules or incorrect attachment tags.

  1. 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.

Official sources

Advertisement