Cloud WAN vs Transit Gateway — 3 Things It Actually Adds, 5 Things It Does Not

Every customer with more than a handful of Transit Gateways eventually gets the Cloud WAN pitch: one global network policy, tag-based segmentation, cross-region routing — it’s the future.

It’s not wrong. But the pitch consistently over-promises. Cloud WAN solves three specific problems elegantly. It does not solve at least five problems customers expect it to solve. And at roughly a 30% premium over the equivalent TGW architecture, you need to know which side of that line you’re on.

This post is the honest deconstruction I use when helping teams decide.

The 3 Things Cloud WAN Actually Adds

1. A single global network policy document

Cloud WAN’s core artifact is the core network policy — a JSON document that describes every segment, every attachment, every route, every peering relationship, for your entire global network. You version it, you apply it, it propagates.

With TGW, the same configuration lives as a hundred separate Terraform resources across N regions. Adding a new VPC means touching aws_ec2_transit_gateway_vpc_attachment, route tables, and potentially route filters — each in its home region.

With Cloud WAN, you edit the policy doc, submit it, and Cloud WAN reconciles. This is genuinely better for operators of large multi-region networks.

2. Tag-based segment placement

In Cloud WAN you define segments (e.g. prod, nonprod, security, shared-services) in the policy, and VPC attachments inherit their segment via a tag on the VPC itself. Create a new VPC with segment=prod? It joins the prod segment on next reconciliation. No manual route-table selection, no attachment-association step.

With TGW, segmentation is implemented via route tables and propagations — manual and bespoke per attachment. For teams that are scaling VPC counts, the Cloud WAN model is a meaningful ops win.

3. Native cross-region dynamic routing with one object

Cloud WAN’s core network is inherently multi-region. Attachments in any region join the same core network without inter-region peering. You get cross-region dynamic routing (BGP) out of the box.

With TGW, multi-region means TGW peering between regions, which is static (no BGP) and adds another configuration surface. Cloud WAN’s single object eliminates this step.

---

The 5 Things Cloud WAN Does Not Do

1. It does not reduce your firewall fleet

This is the #1 misconception. Moving from TGW-inspected traffic to Cloud WAN does not let you delete firewalls. Network Function Groups (NFGs) — Cloud WAN’s firewall insertion mechanism — still require firewall instances (AWS Network Firewall, or third-party Gateway Load Balancer appliances) to exist somewhere. NFGs route traffic to them; they don’t replace them.

If you have 70 firewall instances for an inspection pattern today, you will have 70 firewall instances after migrating to Cloud WAN. The savings come from operator time, not license reduction.

2. It does not enable MPLS decommissioning

MPLS is your physical/SD-WAN/IPsec fabric reaching remote sites and data centers. Cloud WAN is the AWS-side spine. They solve different problems, and one does not replace the other.

Cloud WAN adds SD-WAN integration (attachments for supported SD-WAN appliances), which can simplify SD-WAN-to-cloud routing. But the WAN itself — MPLS, SD-WAN, VPN tunnels — is still what you ran before. Budget the MPLS retirement project separately.

3. It does not reduce attachment count

Every VPC still needs its own attachment to Cloud WAN. If you had 465 VPCs attached to TGWs, you will have 465 VPCs attached to Cloud WAN. The attachment fee is actually higher per attachment on Cloud WAN than on TGW, which is where most of the 30% premium comes from.

4. It does not eliminate static routes (that is a TGW config choice)

Teams often inherit an “all-static routes” TGW design and assume Cloud WAN fixes it. It doesn’t — your TGW was probably all-static because someone chose BGP-free for security or simplicity reasons. Cloud WAN can do either static or dynamic routing; the choice is still yours.

If you want dynamic routing, Cloud WAN makes it easier. But migrating TGW static → Cloud WAN static is a lateral move on that axis.

5. It does not inherently improve intra-region resilience

Cloud WAN’s cross-region HA is excellent. Intra-region, the data plane is still a regional construct subject to the same AZ-level constraints as TGW. If your concern is “one AZ going down takes out North America,” Cloud WAN alone does not fix that — you still need the same attachment-per-AZ, the same return-path design.

---

Segment Design Methodology (Start From Traffic, Not Org Chart)

The single biggest mistake: defining segments by organizational unit. “Finance segment, Marketing segment, IT segment…” Three months in, Marketing’s data pipeline needs to read from Finance’s warehouse, and you’re drilling holes in segments.

The right question is: “What traffic must never happen?”

Answer that first, and segments fall out naturally:

• “PCI data must never reach non-PCI workloads.” → PCI segment.
• “Developer sandboxes must never reach production data.” → Sandbox segment.
• “Shared services (DNS, logging, identity) must be reachable from everything.” → Shared-services segment.

Three or four segments is usually enough for a large enterprise. Eight is a red flag. Sixteen means you’re modeling the org chart.

Pricing: A Worked Example

Scenario: 465 VPCs, 2 regions, typical enterprise traffic patterns (1 TB/day inter-VPC).

Line Item	TGW	Cloud WAN	Delta
Attachment-hours (465 × 2 regions × 730h)	~$35K/yr	~$47K/yr	+$12K
Inter-region data transfer	~$50K/yr	~$50K/yr	0
Inter-VPC data processing	~$25K/yr	~$25K/yr	0
Core network / TGW base	~$0	~$8K/yr	+$8K
Management / operator time (illustrative)	high	lower	savings
Annual infra premium	—	—	~$20K/yr

Numbers are illustrative and region-dependent — validate with AWS Pricing Calculator on your actual topology.

The infra premium is real but relatively small at scale. The operator-time savings are real but hard to quantify. If you are happy with your TGW operationally, there is no financial case to migrate. If you’re drowning in route-table tickets, the operator win usually justifies the premium.

Decision Framework

Use Cloud WAN when:

• Multi-region networking is a primary driver (3+ regions with cross-region traffic)
• You want tag-based auto-placement of new VPCs
• You have the operator budget to manage a network policy document as code
• You are starting greenfield (migration from TGW is non-trivial)

Stay on TGW when:

• Single region, or two regions with minimal cross-region traffic
• Small number of VPCs (<100) where ops cost is already low
• Heavy integration with existing static-route designs and GWLB inspection
• The 30% premium is not justified by operator savings

Key Takeaways

• Cloud WAN adds exactly three things: single global policy, tag-based segmentation, native cross-region dynamic routing.
• Cloud WAN does not reduce firewalls, kill MPLS, reduce attachments, or fix your static-route legacy.
• The 30% premium is real and comes mainly from per-attachment pricing.
• Segment design should start from “what must never happen,” not from the org chart.
• For most large enterprises, the decision is operator-driven (ops savings), not financial or capability-driven.