MPLS vs SD-WAN vs CloudWAN: Enterprise Networking Explained Simply

Enterprise networking has three layers that confuse almost everyone the first time they encounter them: MPLS, SD-WAN, and now AWS CloudWAN. This post breaks down what each one does, when to use it, and how they fit together — no prior networking expertise required.

The Problem

You’re an enterprise with 50 offices across 3 continents, a data center, and a growing AWS footprint. Your traffic needs to flow between all of these — securely, reliably, and without costing a fortune.

The traditional answer was MPLS: private circuits from your telecom provider. Reliable, but expensive and rigid. Then SD-WAN arrived, promising the same connectivity over cheap internet links. Now AWS CloudWAN enters the picture, managing connectivity inside AWS itself.

The confusion: these aren’t competing alternatives. They’re complementary layers that solve different parts of the same problem. Most enterprises will use two or three of them simultaneously. Understanding where each one starts and stops is the key to designing a WAN that actually works.

The Solution

Think of enterprise networking as a relay race with three legs:

1. MPLS — the private highway between your offices and data centers
2. SD-WAN — the smart GPS that picks the best path across any available road
3. CloudWAN — the AWS-internal backbone that connects your VPCs and regions

Each technology owns a segment of the end-to-end path. The architecture looks like this:

The key insight: traffic flows from on-premises (MPLS or SD-WAN) through a connectivity bridge (VPN or Direct Connect) into AWS, where CloudWAN takes over and routes it to the right VPC in the right region using policy-based rules.

How It Works

MPLS: The Private Highway

Multiprotocol Label Switching is the oldest of the three. Your telecom operator (Orange, AT&T, NTT) builds dedicated private circuits between your sites. Traffic never touches the public internet — it travels on the operator’s private backbone with guaranteed bandwidth and latency.

Analogy: Renting a private toll road between each of your offices. Fast, safe, but costly and rigid.

How it works technically:

1. Your office router sends a packet destined for another office
2. The operator’s edge router adds a label (a short fixed-length identifier) to the packet
3. Each router along the path reads only the label (not the full IP header) and forwards accordingly
4. At the destination edge, the label is removed and the packet is delivered normally

This label-switching is what makes MPLS fast — routers don’t need to do complex IP lookups. It also enables traffic engineering: the operator can define explicit paths for different traffic classes (voice, video, data) with different quality guarantees.

Characteristic	Detail
Who manages it	Your telecom operator
Traffic path	Private operator backbone — never touches the internet
Performance	Guaranteed SLA (latency, jitter, packet loss)
Cost model	Per-circuit, per-bandwidth tier. Expensive.
Add a new site	Weeks to months (new circuit provisioning)
Flexibility	Low — changing bandwidth or adding sites requires contract changes
Security	Private by nature, but not encrypted

When MPLS makes sense:

• You need guaranteed latency for real-time applications (voice, video, trading)
• Regulatory requirements mandate private circuits
• You have a stable office footprint that doesn’t change often

When it doesn’t:

• You’re adding offices frequently (M&A, geographic expansion)
• Cost pressure is high — MPLS can be 3-5x more expensive than internet links
• You need agility — provisioning takes weeks, not hours

SD-WAN: The Smart GPS

Software-Defined Wide Area Network is the disruption that changed enterprise networking economics. Instead of expensive private circuits, SD-WAN uses commodity internet connections (broadband, 4G/5G, fiber) and adds intelligence on top.

Analogy: A GPS that picks the best route in real-time across all available roads — highways, local roads, toll roads — based on traffic conditions.

How it works technically:

1. SD-WAN appliances (physical or virtual) sit at each office
2. Each appliance connects to multiple internet links (broadband, 4G, sometimes MPLS too)
3. A centralized controller (Cisco Meraki, VMware Velocloud, Fortinet, etc.) defines policies: “Route voice traffic over the lowest-latency link, send bulk data over the cheapest link”
4. Appliances create encrypted tunnels (IPsec/WireGuard) between sites over the internet
5. Real-time path selection: if one link degrades, traffic shifts to another in milliseconds

The magic is the overlay network: SD-WAN creates a virtual private network on top of public internet. The controller manages all routing centrally, so adding a new site is as simple as plugging in an appliance and connecting it to any internet link.

Characteristic	Detail
Who manages it	You, via a centralized dashboard (Meraki, Velocloud, etc.)
Traffic path	Public internet with encrypted tunnels
Performance	Best-effort, but smart routing compensates. No hard SLA.
Cost model	Internet link cost + SD-WAN license. 60-70% cheaper than MPLS.
Add a new site	Hours — just needs an internet connection
Flexibility	High — policies are software-defined, change in minutes
Security	Encrypted tunnels (IPsec) over public internet

When SD-WAN makes sense:

• Cost reduction is a priority — replace or augment expensive MPLS circuits
• You’re adding sites frequently (retail, logistics, M&A)
• You want centralized management with per-application traffic policies
• Cloud-first strategy — SD-WAN integrates natively with cloud providers

When it doesn’t:

• Hard SLA requirements that only private circuits can guarantee
• Locations with poor or unreliable internet connectivity

CloudWAN: The AWS-Native Backbone

AWS Cloud WAN manages connectivity inside AWS — between VPCs, across regions, and from your on-premises network into AWS. It’s the missing piece that SD-WAN and MPLS don’t cover: once traffic enters AWS, who manages the routing?

Before CloudWAN, the answer was Transit Gateway (TGW): a regional hub that connects VPCs, VPNs, and Direct Connect. TGW works well for simple topologies, but becomes painful at scale — you need one per region, manual peering between them, manual route tables, and no unified view.

CloudWAN replaces this with a policy-driven global network. You write a declarative policy that says “these VPCs belong to production, these to development, route traffic between them this way” — and CloudWAN implements it across all regions automatically.

Analogy: If MPLS is a private road and SD-WAN is a smart GPS, CloudWAN is the air traffic control system inside the AWS cloud — routing traffic between VPCs based on rules you define, not manual route tables.

The core concepts:

Concept	What It Does
Core Network	The global backbone — spans all AWS regions you select
Segments	Isolated routing domains (e.g., production, development, PCI). Traffic between segments is blocked by default.
Core Network Policy	Declarative rules that define segments, routing, and access control. Written once, applied globally.
Attachments	How things connect to the core network: VPCs, VPNs, Direct Connect gateways, Transit Gateways
Core Network Edge (CNE)	Per-region presence that inherits Transit Gateway capabilities
Network Function Groups	Groups of attachments routed to security appliances (firewalls, IDS) via Service Insertion
Service Insertion	Route traffic through inspection VPCs before it reaches its destination — centralized security without modifying applications

Characteristic	Detail
Who manages it	You, via AWS Network Manager console or policy JSON
Traffic path	AWS global backbone between regions
Performance	AWS backbone — low latency between regions, high bandwidth
Cost model	Per-attachment + per-GB data processing. Higher than TGW for simple setups.
Add a new VPC	Minutes — attach to core network, policy assigns it to the right segment
Flexibility	High — policy changes propagate globally
Security	Network segmentation + Service Insertion for centralized inspection

When CloudWAN makes sense:

• Multi-region AWS presence (3+ regions)
• Network segmentation requirements (prod/dev/PCI isolation)
• Centralized security inspection across all VPCs
• Frequent VPC creation (M&A, new projects, multi-account strategy)
• TGW management has become a full-time job

When TGW suffices:

• Single region, simple hub-and-spoke
• Few VPCs with straightforward routing
• Cost sensitivity — TGW is cheaper for simple topologies

How They Connect: The Full Picture

In a typical enterprise, all three technologies work together:

Branch Office
  └─ SD-WAN appliance (Meraki)
      ├─ Broadband link ──────────┐
      ├─ 4G backup ──────────────┤
      └─ (optional) MPLS circuit ─┤
                                   ▼
                          SD-WAN encrypted tunnel
                                   │
                          ┌────────┴────────┐
                          │  AWS Connectivity │
                          │  VPN or Direct    │
                          │  Connect          │
                          └────────┬────────┘
                                   │
                          ┌────────┴────────┐
                          │  AWS CloudWAN    │
                          │  Core Network    │
                          │                  │
                          │  Policy routes   │
                          │  to segments:    │
                          │  ├─ Production   │
                          │  ├─ Development  │
                          │  └─ Shared Svcs  │
                          └────────┬────────┘
                                   │
                     ┌─────────────┼─────────────┐
                     ▼             ▼             ▼
                  VPC Prod     VPC Dev      VPC Shared
                 eu-west-1    eu-west-1     us-east-1

Layer responsibilities:

Layer	Manages	Ends At
MPLS	Office-to-office private connectivity	Data center / Direct Connect PoP
SD-WAN	Office-to-cloud smart routing over internet	AWS VPN endpoint
CloudWAN	VPC-to-VPC routing across regions inside AWS	Target VPC

The Cost Comparison

This is what drives most decisions in practice:

Scenario	MPLS	SD-WAN	CloudWAN
10 offices, 1 data center	$15-30K/month	$5-10K/month	N/A (on-prem only)
10 offices to AWS (1 region)	$15-30K + DX	$5-10K + VPN	TGW suffices (~$500/mo)
10 offices to AWS (3+ regions, 20 VPCs)	$15-30K + DX	$5-10K + VPN	CloudWAN ($1-3K/mo)
Network provisioning time	Weeks	Hours	Minutes
Ongoing management effort	Operator handles	Medium (dashboard)	Low (policy-driven)

The sweet spot for CloudWAN is when your AWS network complexity justifies the premium over Transit Gateway — typically at 3+ regions, 10+ VPCs, or when you need network segmentation and centralized security inspection.

What I Learned

• MPLS, SD-WAN, and CloudWAN aren’t competing — they’re layers. Most enterprises use at least two simultaneously. MPLS handles the private backbone, SD-WAN optimizes office-to-cloud traffic, and CloudWAN manages AWS-internal routing. Understanding where each layer starts and stops eliminates most of the confusion.

• SD-WAN’s real value isn’t cost savings — it’s agility. Yes, replacing MPLS circuits with internet links saves 60-70%. But the bigger win is going from weeks-to-provision to hours-to-provision. For enterprises doing M&A or geographic expansion, this changes the speed of integration entirely.

• CloudWAN is overkill for simple setups, transformative for complex ones. If you have 3 VPCs in one region, Transit Gateway does the job. But the moment you’re managing multiple regions, need segment isolation (prod/dev/PCI), or want centralized security inspection, CloudWAN pays for itself in reduced operational complexity and configuration errors.

• The policy-driven model is the real differentiator. With TGW, you manually configure route tables per region. With CloudWAN, you write a policy once and it propagates globally. Adding a new VPC in a new region means one attachment — the policy automatically places it in the right segment with the right routing. That’s the -70% provisioning time and -80% configuration error reduction that matters at scale.

What’s Next

• Build a hands-on CloudWAN lab topology with segments and Service Insertion — document the step-by-step
• Compare CloudWAN pricing in detail: per-attachment + data processing costs vs TGW for 5, 10, 20 VPC scenarios
• Explore CloudWAN + Direct Connect integration patterns for hybrid deployments
• Write a follow-up on Service Insertion deep dive: routing traffic through inspection VPCs with Network Function Groups