AWS Cloud WAN series · Part 6 of 17

AWS Cloud WAN: Hybrid Connectivity with Direct Connect

Sixth in the AWS Cloud WAN series. Hooking the cloud spine to your data centers is the part that bites. Direct Connect can now attach a gateway straight to the core network — but the routing is a BGP exercise, not a Cloud WAN one. Here's how routes flow both ways, why return traffic drifts asymmetric, and the constraints that quietly reshape the design — every claim sourced to AWS docs.

Two ways in from the data center — and why the new one is simpler

For most of Cloud WAN's life there was no native Direct Connect support. To bring DX into a Cloud WAN network you stood up an intermediary Transit Gateway per Region as a terminator: the transit VIF landed on the TGW, and the TGW peered with the Core Network Edge. It worked, and it's still a perfectly valid pattern — AWS even recommends a TGW per Region for DX in some multi-Region designs, specifically so each Region's workloads reach the gateway directly without creating cross-Region dependencies. But it means running and paying for TGWs whose only job is to terminate DX.

Since January 14, 2025, there's a cleaner option: the native Direct Connect Gateway attachment. You attach a DXGW directly to the core network — no intermediary TGW — with automatic, bidirectional BGP route propagation between AWS and on-premises over a transit VIF. It inherits the rest of Cloud WAN too: central policy, tag-based attachment automation, and segmentation. For a greenfield hybrid design this is the simpler, cheaper path; for an existing DX-via-TGW deployment it's a migration target (Article 12), not an obligation. Figure 1 contrasts the two.

One cost footnote that trips people up: the Direct Connect gateway object is free — "there are no charges for using a Direct Connect gateway" — but the DXGW attachment to a Cloud WAN core network is billable at the standard per-hour and per-GB rates, on top of DX port-hours and data transfer out. "Free gateway" does not mean free hybrid connectivity.

How routes flow both ways — and the one association rule that sets your paths

The mechanics are worth getting exactly right, because every later design decision falls out of them.

Inbound (on-premises → AWS). Cloud WAN learns the BGP routes your on-prem routers advertise over the transit VIF and DXGW. They land in the segment route tables of the Core Network Edges associated with the attachment, and from there propagate across every Region the segment spans — so an on-prem prefix learned in one Region is reachable from that segment's VPCs everywhere.

Outbound (AWS → on-premises). Cloud WAN propagates the segment's routes to the DXGW, which advertises them over the transit VIFs. Two details do the heavy lifting here: each CNE associated with the DXGW advertises only its local routes toward the gateway, and the AS_PATH attribute is retained in those advertisements. That retained AS_PATH is the lever you pull on-premises to tell which Region a route came from and steer return traffic accordingly.

The single most important design rule drops straight out of this: associate the Direct Connect Gateway with every Cloud WAN Region where the attached segment is present. Miss one, and the CNE in that unassociated Region has no local DXGW attachment, so it forwards on-prem-bound traffic to a remote CNE instead. When several remote CNEs advertise the prefix with equal AS_PATH and MED, the forwarding CNE is chosen at random — AWS's own wording. That random pick is exactly how you end up with asymmetric paths and unpredictable latency. Associate the gateway everywhere the segment lives, and each Region uses its local exit (Figure 2).

Underneath all of this is the same best-path logic Cloud WAN inherits from Transit Gateway, covered in Article 5: the most-specific prefix wins absolutely, then shorter AS_PATH, then lower MED, with a same-Region CNE preferred when AS_PATH lengths are equal. Keep that order in mind — the symmetry work in the next section is mostly about feeding BGP the right prefixes and attributes so its tiebreakers land where you want.

Why return traffic drifts asymmetric — and the BGP tuning that fixes it

Symmetric routing — traffic taking the same path both directions — is non-negotiable when a stateful firewall is in the path, and worth having everywhere for predictability. Asymmetry plus stateful inspection equals dropped traffic, full stop. Cloud WAN gives you sensible defaults, but any multi-path hybrid design needs active BGP tuning on top.

The defaults working for you. Cloud WAN always prefers the local-Region path as long as the learned prefixes have equal AS_PATH length — local-Region preference is the foundation of optimal routing. And because the most-specific prefix wins, advertising specific prefixes from each on-prem location — rather than one summary from everywhere — lets Cloud WAN make the correct per-destination choice.

The tuning you do yourself. On your on-prem routers, set BGP attributes (typically local preference) so that for each location one transit VIF is primary and another is backup — active/passive failover, where a primary VIF failure shifts traffic to the backup automatically. For multiple DXGWs or multiple on-prem locations, lean on the retained AS_PATH plus per-location specific prefixes so the gateway forwards each destination to the right location's primary VIF; where you're forced to advertise the same summary prefix from several locations, you influence Cloud WAN's choice by using multiple Direct Connect Gateways.

The newest lever. With the 2025.11 routing policies (Article 2), you can now set local preference, AS_PATH, and MED inside Cloud WAN to shape inbound and outbound path selection — a capability that used to live only on your on-prem routers. This is the cleanest way to build a deterministic primary/backup multi-path hybrid design. The watchword from AWS's own guidance: when stateful firewalls inspect a flow, weigh Region preferences carefully in your routing policies to keep the flow symmetric.

Where does VPN fit? A Site-to-Site VPN over the internet is the usual backup to DX — cheap insurance for when a circuit or a whole DX location goes dark. One wrinkle to plan around: private-IP VPN and Connect attachments aren't supported when a DXGW attachment is the transport type, so a backup VPN lands as its own Cloud WAN attachment rather than riding the DXGW's transport. Figure 3 shows the primary/backup shape.

What the native attachment won't let you do — the constraints to design around

The native DXGW attachment carries specific limitations. Know them before you commit a design to it — most are BGP-by-design, and one of them routinely reshapes the segment model.

The one-segment-per-DXGW limit is the one that most often bends a design. If your hybrid model needs on-prem reachable from both a hybrid segment and, say, a shared-services segment, you either route between those segments with a share (Article 3) or stand up a second DXGW dedicated to the other segment. Decide that before you draw the segment map, not after.

When to attach native, and when to keep DX on a TGW

Native isn't automatically the answer. Here's the practical call.

Plenty of mature networks run both — native DXGW where it's clean, TGW-terminated DX where history or a missing feature requires it. The segmentation model holds either way, which is what makes mixing them safe.

Putting it together — a resilient multi-Region hybrid design

Stack the pieces and a common resilient design emerges (Figure 4): two or more Regions, each with a Core Network Edge; a hybrid segment present in all of them; a Direct Connect Gateway associated with every Region the hybrid segment lives in; two transit VIFs per on-prem location (primary and backup) with local-preference tuning on-prem; specific prefixes advertised per location; and — where stateful inspection is involved — routing policies pinning Region preference for symmetry. Workload VPCs in other segments reach on-prem by sharing their segment with the hybrid segment (Article 3), and each Region exits through its local DXGW association.

The payoff is direct, local-Region egress to on-premises, automatic failover when a VIF or location drops, and symmetric return paths that keep stateful firewalls happy. Nothing here is exotic — it's the same handful of rules applied consistently: associate everywhere, advertise specifics, set primary/backup in BGP, and pin the Region where inspection demands it.

What's next. Hybrid routing pulled multi-Region behavior into view — local-Region preference, cross-Region propagation, the random-remote-CNE failure mode. Article 7 zooms out to multi-Region routing mechanics in their own right: how the full-mesh CNE peering works, how segments propagate globally versus regionally, the "every Region needs an attachment for the destination" principle, and the equal-attribute edge cases (like routes chosen at random) you design around.