SD-WAN Meets AWS: Five Ways Into the Cloud, One Fabric Riding BGP

SD-WAN is a control-plane/data-plane split that turns any transport into one programmable, encrypted overlay. Getting it into AWS isn't one integration but a menu of five — IPsec-to-Transit-Gateway, TGW Connect, Cloud WAN Connect, an appliance in a VPC, and Direct Connect as underlay — each a different bandwidth, scaling, and cost shape. Under all of them, the fabric rides BGP. This is the foundation, and the complete map of the doors into the cloud.

1The task you've actually been handed

You've been handed the AWS side of an SD-WAN rollout. The network team has a controller and a hundred branch edges, and they want “connectivity into AWS.” That sounds like one task. It isn't. It's a choice among five integrations that look nearly identical on a slide and diverge sharply the moment you care about bandwidth, encryption, and cost. Before you can pick well, two things have to be clear: what SD-WAN actually is beneath the marketing, and the one protocol every option rides. This article is that foundation, and the complete map of the doors into the cloud.

2What SD-WAN actually is

Strip away the vendor decks and SD-WAN is one architectural move: it decouples the control plane from the data plane (figure below). A centralized controller holds policy and topology for the whole network; the branch edges do nothing clever on their own — they just forward packets per the policy pushed down to them. Old routers married the two in every box, so every site was its own brain; SD-WAN centralizes that brain and leaves the edges dumb and fast.

On top of that split sits a transport-independent overlay: each edge builds encrypted tunnels — IPsec or GRE — to the others over whatever underlay is available at that site, while the controller applies app-aware policy (path selection, QoS, failover) across all of them centrally. The overlay is one logical fabric; the underlays beneath it are interchangeable pipes.

The reason it exists is economic: you replace an expensive MPLS mesh with cheap broadband plus a controller, buying policy and path selection in software instead of a premium private circuit to every site. MPLS doesn't vanish; it becomes one underlay option the overlay can prefer for sensitive traffic while sending the rest over commodity internet.

Which leaves the distinction the rest of this article leans on. The underlay is the physical or IP transport that moves packets — the internet, an MPLS circuit, a Direct Connect line; the overlay is the SD-WAN tunnels and policy layered on top. Everything that follows is two questions: where does the overlay terminate inside AWS, and what underlay does it ride to get there.

3The BGP the fabric rides on

Before the doors, the protocol under all of them. AWS's dynamic-routing edge speaks BGP on nearly every attachment, and that is not a detail — it's the reason the whole fabric holds together. BGP is how routes are learned and withdrawn dynamically: when a site or a tunnel drops, BGP reconverges on its own, without a human touching a route table. In a network of a hundred branches, that automatic reconvergence is the point.

It's eBGP between two autonomous systems (figure below) — the customer AS at 65010 in our examples, and AWS's, whose Transit Gateway defaults to 64512 (customizable; Direct Connect and Connect peers each get their own session). Each side advertises its prefixes and installs the other's.

The scaling lever falls straight out of this. Advertise the same prefixes across multiple BGP paths — multiple tunnels or Connect peers — and AWS load-balances across them with equal-cost multi-path (ECMP): you add bandwidth by adding paths, not by widening one pipe. Nearly every scaling story in this article is really an ECMP story. The one exception, flagged in the figure, is a static-routed VPN — it skips BGP, so it loses dynamic failover and ECMP, which is exactly why SD-WAN integrations always reach for the BGP-speaking options.

4The five ways in — the map

Now the anatomy. A branch or SD-WAN edge reaches AWS through one — often several — of five integrations, each terminating the overlay in a different place. Read left to right: the edge (with its underlay beneath it) passes through one of five doors into an AWS core — the regional Transit Gateway or the global Cloud WAN core — which feeds your VPC workloads.

The five lanes, top to bottom, are the five sections that follow — with one exception: Direct Connect (e) is drawn apart as an underlay rail beneath doors a–c, because it carries them rather than terminating anything itself. The axis running down the stack is encapsulation versus bandwidth: more encapsulation buys encryption but costs throughput; less buys throughput but pushes security onto an underlay you then have to trust.

That's the map. Now each door — what it is, what it costs you in bandwidth and encryption, and when to reach for it.

5Door A · IPsec VPN → Transit Gateway

The classic, and where most people start. You bring up an IPsec tunnel from your customer gateway (or SD-WAN edge) to a Site-to-Site VPN attachment on a Transit Gateway. The defining feature: encryption is included — the tunnel is IPsec, so the overlay is protected without you arranging anything underneath it.

Bandwidth is 1.25 Gbps per tunnel on the classic VPN and 5 Gbps per tunnel on the newer high-throughput tunnels, with two tunnels per connection. You scale it with ECMP over multiple tunnels on a dynamic-routing TGW: two 5 Gbps tunnels give you 10 Gbps, and adding VPN connections adds more (roughly two connections, four tunnels, ≈ 20 Gbps) — which requires BGP for dynamic routing plus customer-gateway hashing to spread flows across the tunnels.

The cost shape is the friendliest of the five: per VPN-connection-hour plus data processing and transfer — the cheapest door to stand up, with the fewest moving parts. Reach for it when you want encryption built in, moderate bandwidth, and minimal operational surface.

6Door B · Transit Gateway Connect (GRE + BGP)

When you outgrow IPsec throughput, TGW Connect is the native SD-WAN answer. It's a GRE tunnel — not IPsec — from the SD-WAN appliance to the Transit Gateway, with BGP for routing. Dropping IPsec drops its encapsulation and crypto overhead, which is exactly where the extra bandwidth comes from.

Each Connect peer carries 5 Gbps, and you can run up to 4 peers per Connect attachment for 20 Gbps — advertise the same prefixes across the peers and ECMP aggregates them. That's four times the per-tunnel headroom of a classic VPN tunnel, with less overhead per bit.

On cost, Connect rides on top of an existing transport attachment (a VPN or a DX), so you pay for that underlay plus TGW data processing — and per dollar, you get more bandwidth than stacking IPsec tunnels. Reach for it when you've outgrown IPsec throughput and can provide a trusted underlay beneath it.

7Door C · Cloud WAN Connect (GRE or tunnel-less)

The same Connect idea, but attached to the global Cloud WAN core instead of a single regional TGW. You connect the SD-WAN at a Core Network Edge (CNE) in each Region, and you get built-in segmentation and policy-as-code spanning Regions — one fabric, centrally governed, everywhere you operate.

It comes in two flavors. GRE mode mirrors TGW Connect: 5 Gbps per peer, 4 peers, 20 Gbps. Tunnel-less Connect is the interesting one — BGP only, no GRE and no IPsec, up to 100 Gbps per Availability Zone, which is the full VPC-attachment bandwidth with zero encapsulation overhead. It removes the per-tunnel ceiling entirely: bandwidth becomes the attachment, not the tunnel. You run two BGP sessions per peer for redundancy.

The cost is a Cloud WAN core network edge (per Region, per hour) plus the attachment plus data — more than a TGW for a single Region. The win you're paying for is global reach and segmentation across the core, or the raw throughput of tunnel-less. Reach for it when the SD-WAN spans multiple Regions, when you need segmentation across the core, or when you need the highest throughput available.

8Door D · SD-WAN appliance in a VPC

Sometimes the native doors don't expose a feature you need, and you want the vendor's own edge running inside AWS. So you run the vendor's virtual appliance on EC2 — Cisco Catalyst 8000V, Aviatrix, Fortinet, Palo Alto, and the like — inside a VPC, terminating the overlay on their software. That buys full vendor feature parity in the cloud and a uniform edge stack across cloud and on-prem.

Bandwidth here is whatever the EC2 instance can do — bounded by the NIC and instance limits. You scale it up by choosing a bigger instance, or out by placing appliances behind a Gateway Load Balancer with autoscaling. But that scaling is now yours to plan, and so is the patching, the capacity, and the lifecycle.

That's why this is the heavy door. The cost shape is EC2 compute you run 24/7, plus a vendor license, plus data — the most expensive and most operationally demanding of the five, in exchange for being the most feature-complete. Reach for it when you need a specific vendor capability the native Connect options don't expose, or a single uniform edge stack across cloud and branch. Don't reach for it by default just because the vendor's appliance is familiar.

9Door E · Direct Connect as the underlay

The fifth door isn't really a door at all, and that's the whole point. Direct Connect is an underlay choice, not an overlay entry point. It's a private DX circuit that carries the SD-WAN overlay instead of the public internet — the IPsec or GRE tunnels of doors a, b, and c ride the DX private path rather than the open web. It terminates nothing; it just carries.

The transport is dedicated at 1, 10, or 100 Gbps (with sub-1G hosted options), and it's private, predictable, and low-jitter in a way the internet never is. You scale it by adding circuits or LAGs, and it underpins the highest, most consistent throughput available. The cost shape inverts the VPN's: high fixed DX port-hours, cheap per-GB, plus low DX data transfer — so it's economical at sustained high volume and cheaper on egress than the internet.

Reach for it when traffic is latency- or jitter-sensitive, when volume is high and sustained, or when compliance requires a private path — and pair it with door (b) or (c) for the fastest, most predictable SD-WAN into AWS. But remember what it is: transport. You still need a VPN or a Connect attachment on top to actually terminate the overlay and segment the traffic.

10Choosing — the comparison

Line the five up on the axes that actually differ, and one through-line falls out of the table: more bandwidth means less encapsulation, which pushes security down onto the underlay you then have to trust — either a Direct Connect private path or an IPsec wrap. That single trade-off explains almost every difference below.

11Where it bites — failure modes

Every one of these is a real mistake teams make with these doors, and every one traces back to the two ideas at the top of the article: the overlay/underlay split, and the fact that the fabric rides BGP.

That's the anatomy. You now have the two load-bearing concepts — the control/data-plane overlay, and BGP with ECMP under all of it — and the complete map of the five doors with their bandwidth, encryption, and cost shapes. The rest of this series goes door by door into the build detail; this is the foundation you'll keep coming back to.

References

All facts verified 2026-07-17 against current AWS documentation and launch announcements.

• AWS Site-to-Site VPN documentation — and the “5 Gbps high-throughput VPN tunnels” launch (per-tunnel bandwidth, two tunnels per connection, ECMP over dynamic-routing tunnels).
• AWS Transit Gateway Connect documentation — and “Simplify SD-WAN connectivity with Transit Gateway Connect” (GRE + BGP, 5 Gbps per peer, up to 4 peers / 20 Gbps per attachment, unencrypted underlay).
• AWS Cloud WAN Connect documentation — and the tunnel-less Connect launch (GRE 20 Gbps or tunnel-less BGP-only up to 100 Gbps per AZ, Core Network Edge per Region, two BGP sessions per peer, segmentation).
• AWS SD-WAN integration blogs — Transit Gateway and Direct Connect integration patterns; vendor virtual appliances on EC2 (Cisco Catalyst 8000V, Aviatrix, Fortinet, Palo Alto), Gateway Load Balancer scale-out.
• AWS Transit Gateway documentation — default ASN 64512, customizable; dynamic-routing and ECMP behavior.
• AWS Direct Connect documentation — 1 / 10 / 100 Gbps dedicated (and sub-1G hosted) private transport, port-hour + data-transfer cost model, underlay role beneath the overlay.
• BGP fundamentals (networking canon) — eBGP between autonomous systems, dynamic learn/withdraw, ECMP as the scaling mechanism; the static-VPN exception.