AWS Cloud WAN: The Global Network for Engineers Who've Outgrown Transit Gateway

Your company just expanded to five AWS Regions. You have 30 VPCs, a data center, and 20 branch offices. Last quarter, a routing misconfiguration in us-east-1 took down prod for two hours — because someone edited the wrong Transit Gateway route table in the wrong Region. There's a better way.

AWS Cloud WAN is a managed global wide-area network service that lets you define your entire network topology — across Regions, on-premises sites, and branch offices — as a single JSON policy, and AWS provisions everything automatically. It turns "edit route tables in ten different consoles" into "push a policy and wait."

The Problem Cloud WAN Was Built to Solve

Before Cloud WAN launched in 2022, engineers running multi-Region AWS architectures had exactly one native option: Transit Gateway (TGW), deployed independently per Region, with inter-Region peering stitched together manually.

Here's what that looked like in practice: deploy a TGW in each of your 6 Regions, create inter-Region peering attachments between each pair that needs connectivity, configure route tables in each TGW separately with no shared policy, and when a new VPC appears, manually attach it to the right TGW, add the right routes in the right tables, and verify nothing conflicts — then repeat in every Region.

A single routing policy decision — say, "dev traffic should never reach prod" — might require changes to 12 route tables across 6 Transit Gateways. And there's no single view that shows you the global routing topology. You audit it Region by Region.

What Is AWS Cloud WAN?

AWS Cloud WAN is a managed WAN (wide-area network) service that connects your AWS Regions, on-premises data centers, and branch offices into a single unified private network. You describe your network in a JSON policy document — which segments exist, which Regions participate, what can route to what — and Cloud WAN provisions the underlying infrastructure and keeps it consistent.

What Cloud WAN is NOT:

• Not a replacement for Direct Connect or VPN — those are still the physical/encrypted pipes. Cloud WAN manages how traffic routes over them.
• Not a firewall or traffic inspection service — you still need AWS Network Firewall or a third-party appliance for that.
• Not just "Network Manager with a new name" — Network Manager is the observability layer. Cloud WAN is the provisioning layer.
• Not a multi-cloud solution — it manages AWS and hybrid connectivity, but not Azure or GCP natively.

The Core Components

Cloud WAN has a clear component hierarchy. Understanding how each piece nests is the prerequisite for everything else.

Global Network — The top-level container. One per organization. Links to Network Manager for visibility.

Core Network — The actual WAN fabric. It lives inside the Global Network, has a policy document, and contains your Core Network Edges and Segments.

Core Network Edge (CNE) — One per AWS Region. This is a fully managed Transit Gateway that AWS provisions and operates on your behalf. You cannot see it in your account as a TGW resource — it's completely abstracted. You connect things to it via attachments.

Segments — Routing domains within the Core Network. They're the Cloud WAN equivalent of VRFs (Virtual Routing and Forwarding tables). Traffic within a segment routes freely; traffic between segments requires explicit policy.

Attachments — The connections that plug into the Core Network: VPCs, Site-to-Site VPN connections, Direct Connect Gateways, existing Transit Gateway route tables, or Connect (SD-WAN) attachments.

Network Policy — A JSON document that declares your desired WAN state. Everything is defined here.

Segments: Your Network's Routing Domains

Segments are the most important concept in Cloud WAN and the most commonly misunderstood. A segment is a full Layer 3 routing domain. Every attachment belongs to exactly one segment. Routes from one segment don't leak into another unless you explicitly write a segment action to allow it.

Segment Actions: Controlled Cross-Segment Routing

When you need traffic to cross segment boundaries — say, all environments need to reach your shared DNS VPC — you use segment actions in the policy. There are two types:

share — Bidirectionally shares routes between a source segment and target segments. The VPCs in the shared-services segment appear in the route tables of prod and dev segments.

create-route — Injects a static route into a segment pointing to a specific attachment. Use this for one-directional reachability or to point to a specific CIDR.

"segment-actions": [
  {
    // shared-services routes become visible in prod and dev
    "action": "share",
    "mode": "attachment-route",
    "segment": "shared-services",
    "share-with": {
      "segments": ["prod", "dev"]    // prod ↔ dev still cannot see each other
    }
  }
]

This single policy block makes your shared-services VPCs reachable from prod, dev, and staging — in every Region — without touching a single route table directly.

isolate-attachments: Within-Segment Isolation

By default, all attachments in the same segment can route to each other. Setting "isolate-attachments": true on a segment means VPCs in that segment cannot route to each other directly — each becomes reachable only via explicit segment actions.

Attachment Types

Attachments are how you plug things into your Core Network. Cloud WAN supports five types:

Attachment Policies: Tag-Based Auto-Assignment

Every new attachment needs to land in a segment. Attachment policies are rules in your network policy JSON that automatically assign attachments to segments based on their tags — the "intent-based networking" part of Cloud WAN.

"attachment-policies": [
  {
    "rule-number": 100,          // lowest wins
    "condition-logic": "or",
    "conditions": [
      {
        "type": "tag-value",
        "operator": "equals",
        "key": "Env",
        "value": "prod"          // VPCs tagged Env=prod auto-land in prod segment
      }
    ],
    "action": {
      "association-method": "constant",
      "segment": "prod"
    }
  }
]

When a new VPC with tag Env=prod is attached, it's automatically placed in the prod segment. No human intervention. No route table edit. This scales to hundreds of VPCs.

The Network Policy: Declaring Your WAN

The network policy JSON is the heart of Cloud WAN. Everything you configure lives here. Let's walk through a complete, annotated policy for a three-Region deployment with three segments.

resource "aws_networkmanager_core_network" "main" {
  global_network_id = aws_networkmanager_global_network.main.id

  policy_document = jsonencode({
    version = "2021.12"

    # Step 1: declare which Regions participate and their BGP ASNs
    core-network-configuration = {
      vpn-ecmp-support = false
      asn-ranges       = ["64520-64525"]   # must not overlap on-prem ASNs
      edge-locations = [
        { location = "us-east-1",      asn = 64520 },
        { location = "eu-west-1",      asn = 64521 },
        { location = "ap-southeast-1", asn = 64522 }
      ]
    }

    # Step 2: declare routing domains (VRFs)
    segments = [
      {
        name                          = "prod"
        require-attachment-acceptance = false   # auto-approve attachments
        isolate-attachments           = false   # VPCs in prod can reach each other
      },
      {
        name                          = "dev"
        require-attachment-acceptance = false
        isolate-attachments           = false
      },
      {
        name                          = "shared-services"
        require-attachment-acceptance = false
        isolate-attachments           = false
      }
    ]

    # Step 3: allow prod/dev to reach shared-services (but not each other)
    segment-actions = [
      {
        action   = "share"
        mode     = "attachment-route"
        segment  = "shared-services"
        share-with = { segments = ["prod", "dev"] }
      }
    ]

    # Step 4: auto-assign VPCs to segments by tag
    attachment-policies = [
      {
        rule-number     = 100
        condition-logic = "or"
        conditions = [
          { type = "tag-value", operator = "equals", key = "Env", value = "prod" }
        ]
        action = { association-method = "constant", segment = "prod" }
      },
      {
        rule-number     = 200
        condition-logic = "or"
        conditions = [
          { type = "tag-value", operator = "equals", key = "Env", value = "dev" }
        ]
        action = { association-method = "constant", segment = "dev" }
      },
      {
        rule-number     = 300
        condition-logic = "or"
        conditions = [
          { type = "tag-value", operator = "equals", key = "Env", value = "shared" }
        ]
        action = { association-method = "constant", segment = "shared-services" }
      }
    ]
  })
}

# Attach a prod VPC — tag drives auto-segment assignment
resource "aws_networkmanager_vpc_attachment" "prod_vpc" {
  core_network_id = aws_networkmanager_core_network.main.id
  vpc_arn         = aws_vpc.prod.arn
  subnet_arns     = [aws_subnet.prod_a.arn, aws_subnet.prod_b.arn]

  tags = {
    Env = "prod"   # matches rule 100 → lands in prod segment automatically
  }
}

The Changeset Workflow

Updating a Cloud WAN policy doesn't take effect immediately. AWS uses a changeset workflow:

Traffic Flow: End-to-End

Let's trace a packet from a branch office in London to a production app in ap-southeast-1.

Debugging Cloud WAN

When things go wrong — and in networking, things go wrong — Cloud WAN gives you several layers of observability.

Route Analyzer — The most powerful tool. Tests "can subnet X in Region A reach subnet Y in Region B?" by simulating the routing path end-to-end without sending actual traffic. Start here, before checking anything else.

Network Manager Topology View — A global visual map of your Core Network: all edges, all attachments, all segments, color-coded by health. Useful for spotting attachments stuck in PENDING or FAILED state.

Changeset History — Every policy update generates a changeset with a status and event log. If a changeset partially failed, the event log shows the specific failure reason.

CloudWatch Metrics — Cloud WAN publishes metrics for BGP session state, attachment bandwidth, and packet drops. Set alarms for BgpPeerState going DOWN.

Cost Model

Cloud WAN has three billing dimensions. Understanding them is essential for budgeting — and for spotting the traps.

Worked example — 5-Region deployment:
5 CNE edges × $36 = $180/month · 5TB inter-region × $0.02 = $100/month · 4 VPN connections × $36 = $144/month = ~$424/month for Cloud WAN infrastructure. Significantly cheaper than a single MPLS circuit (typically $500–2,000+/month per site).

Cloud WAN vs. The Alternatives

When Transit Gateway alone wins: Single-region deployment, or 2 Regions with simple peering. TGW is simpler when you don't need centralized policy and global segment isolation.

When Aviatrix wins: Multi-cloud is a hard requirement. Or if your team prefers GUI-driven networking over JSON policy. Or if you need Aviatrix FireNet's inline inspection model.

When Cloud WAN wins: 3+ AWS Regions, hybrid connectivity, prod/dev/shared isolation requirements — and you want to stay AWS-native.

When to Use (and When NOT to)

Use Cloud WAN when:

• You operate in 3 or more AWS Regions
• You have hybrid connectivity across multiple sites
• You need enforced network segmentation (prod/dev/compliance zones) globally
• You have branch offices on SD-WAN connecting to AWS
• You're building from scratch without an existing TGW investment

Do NOT use Cloud WAN when:

• You're single-region or two-region with simple connectivity — the setup cost isn't justified
• Your team has no network engineering experience — the JSON model has a real learning curve
• You need real-time routing changes — the 10–30 minute changeset window is a hard constraint
• You need native multicast — that stays on Transit Gateway for now
• You require inline traffic inspection — Cloud WAN has no built-in firewall
• You're actively multi-cloud — Cloud WAN covers AWS and hybrid only

Enterprise Adoption Considerations

Compliance fit: Cloud WAN's segment model maps cleanly to compliance zone requirements. PCI-DSS cardholder data environments become their own segment with require-attachment-acceptance: true and tightly controlled segment actions. The changeset audit trail plus CloudTrail satisfies change management controls for SOC2.

Migration from TGW: The safest path is gradual. Stand up Cloud WAN alongside existing TGWs. For existing VPCs, attach the existing TGW to Cloud WAN via a TGW Route Table attachment — this lets TGW-attached VPCs route through Cloud WAN without re-attaching each one. Over time, migrate VPCs to direct VPC attachments. Decommission TGW peerings last.

Security model: Cloud WAN is a routing boundary, not a security boundary. Security groups, NACLs, and AWS Network Firewall still provide traffic filtering. A segment boundary alone won't satisfy a compliance requirement for "no network communication" between zones — you need NACLs or a firewall in the data path for that.

Interview Prep

Top 10 Conceptual Questions

Top 5 System Design Scenarios

Red Flags

• Saying "Cloud WAN replaces Direct Connect" — it manages routing on top of DX
• Confusing segments with VLANs or subnets — segments are Layer 3 routing domains
• Claiming you need two edges per Region for HA — CNEs are multi-AZ by default
• Saying policy changes take effect immediately — the changeset window is 10–30 minutes
• Thinking Cloud WAN includes traffic inspection — you still need a separate firewall

Advanced Nuances