AWS Cloud WAN series · Part 5 of 17

AWS Cloud WAN: Attachment Types in Practice

Fifth in the AWS Cloud WAN series. Article 4 covered how attachments get mapped to segments; this one covers what the attachments actually are — the five ways something connects to a Core Network Edge, what each is good at, and the two traps (asymmetric inspection and the AZ-ID shuffle) that bite regardless of which type you pick. Every claim is sourced to AWS docs.

Everything joins the core through an attachment — and there are exactly five kinds

A Core Network Edge (CNE) is the regional connection point Cloud WAN manages for you in each Region. AWS is blunt about what it is: a CNE “is also known as an AWS Transit Gateway, and it inherits many of the same properties.” That one sentence is the cheat code for this whole article. The way things attach, how appliance mode pins flows, how the edge breaks a routing tie — it’s TGW mechanics with a global control plane on top. Whatever connects to that edge does so through an attachment, and every attachment walks the same lifecycle: it sits in one of eight states (Creating, Pending attachment acceptance, Available, Failed, and a few more) until it lands at Available and starts carrying traffic.

There are five types, and the whole list fits in a sentence: VPC for cloud workloads, Site-to-Site VPN and Direct Connect gateway for on-premises, Connect for SD-WAN appliances, and Transit Gateway peering for coexisting with TGWs you already run. Figure 1 shows them fanning into a single edge. One detail worth banking early: all five types work both for ordinary workload segments and for the Network Function Groups that service insertion uses for inspection (Articles 8–10), so you’re never boxed in on where appliances versus workloads can live.

Connecting your cloud workloads — the VPC attachment and the limits it inherits

The VPC attachment is the one you’ll create most. It wires an Amazon VPC straight to the edge, and because the edge is a managed TGW, it behaves like a TGW VPC attachment and inherits the same limits. You pick the subnets where the attachment’s elastic network interfaces land — one subnet per Availability Zone you want to serve, and that single subnet lets traffic reach every subnet in that AZ.

Two gotchas catch people. You cannot use a Local Zone subnet for a Cloud WAN VPC attachment — it errors out. And cross-VPC DNS resolution only works between VPCs on the same edge — not across Regions, not across different edges. That second one surprises teams who assume Cloud WAN’s global reach extends to name resolution; it doesn’t, and the fix (Route 53 Resolver, or same-edge placement) is a design decision, not a toggle.

Reaching outside AWS — VPN to start, Direct Connect for production, Connect for SD-WAN

Three of the five types exist to get traffic in and out of AWS, and they sort by how serious you are about the link.

Site-to-Site VPN is the fast on-ramp: a managed IPsec VPN from your on-premises equipment into the core. It supports dynamic routing over BGP and benefits from the vpn-ecmp-support toggle (on by default), which spreads traffic across multiple equal-cost tunnels for throughput and redundancy. Each tunnel tops out around 1.25 Gbps, and ECMP aggregates several. It’s the right call to get hybrid working this week, or anywhere Direct Connect simply isn’t available — but for predictable, production-grade performance most enterprises eventually want a private circuit.

Direct Connect gateway is that private circuit. The native attachment connects a Direct Connect gateway straight to the core network with no intermediary Transit Gateway, exchanging routes bidirectionally over BGP. Two constraints matter here and recur in Article 6: a DXGW’s ASN must sit outside the edge’s ASN range, and a single DXGW can associate with only one Cloud WAN segment (though multiple DXGWs can share one segment). This whole attachment type is the subject of the next article, so I’ll keep it short — just know it’s the native, no-TGW path, and it’s BGP-only.

Connect is the odd one out: it exists to plug third-party SD-WAN appliances into the core without standing up IPsec VPNs. Here’s the correction worth internalizing, because plenty of write-ups get it wrong: a Cloud WAN Connect attachment rides on top of an existing VPC attachment as its transport — not a Direct Connect attachment. (DX-as-transport for Connect is a Transit Gateway feature; it isn’t a thing in Cloud WAN.) Over that transport it builds GRE tunnels with BGP for dynamic routing — GRE peers run up to ~5 Gbps each — and it draws tunnel addresses from the inside-cidr-blocks pool you defined in the policy back in Article 2. Connect is BGP-only; it does not support static routes. The reason it exists is segmentation carry-through: you map each SD-WAN VRF to a Cloud WAN segment, usually by creating one GRE-based Connect attachment per segment, so isolation survives end to end into AWS.

Living alongside your Transit Gateways — the peering attachment

The fifth type is the one that makes Cloud WAN adoption survivable in a brownfield estate. Transit Gateway peering peers a Core Network Edge with a TGW in the same Region, and then — this is the precise part — you extend a specific TGW route table to a specific Cloud WAN segment. The whole TGW does not map to a segment; one route-table attachment maps one route table to one segment, and you can create several over a single peering — one per routing domain you want to keep separate.

This is the linchpin of migration and coexistence (Articles 11–12): you keep TGWs for what they’re good at — regional hubs, and terminating Direct Connect — while extending native segmentation into Cloud WAN. In fact, if you want Direct Connect reachability without moving off your TGW yet, this is how you get it: terminate the DX on the regional TGW as you do today, peer that TGW to the edge, and reach on-prem over the peering. AWS still recommends a TGW per Region for Direct Connect in some designs, precisely so each Region’s workloads reach the circuit locally.

Two rules. Peering routing is dynamic BGP only — try to add a static route and it errors. And the hard one: the TGW’s ASN must differ from the edge’s ASN. Plan ASNs across your whole estate before you build (the same conflict Article 2 flagged), because a CNE’s ASN is immutable once set. There’s a billing nicety too: the peering itself bills at the attachment hourly rate, but the route-table attachments layered on it carry no additional charge.

Why stateful inspection silently breaks — appliance mode and the AZ-ID trap

These two traps share a root cause — where a flow physically lands — and neither depends on which attachment type you chose. Both will produce baffling, intermittent failures if you miss them.

Appliance mode first, because it’s non-negotiable for any stateful device. A firewall or IPS tracks connection state, so it must see both directions of a flow on the same instance in the same AZ. Without help, the outbound packet might traverse the appliance in AZ-a while the return comes back through a different appliance in AZ-b — which has no state for that flow and drops it. That’s asymmetric routing, and it breaks inspection quietly (Figure 3).

Appliance mode forces the edge to pin a given flow to a single AZ in the appliance VPC for that flow’s lifetime. When source and destination are in the same AZ it uses that AZ’s appliance interface; when they differ it picks one AZ by flow-hash and sticks with it. The details that trip people up:

• It’s enabled on the VPC attachment where the appliance lives, and it’s only supported on VPC attachments — but the flow can enter from any attachment type (VPC, VPN, Connect).
• It is independent of service insertion. Even if you use Network Function Groups (Articles 8–10) to steer traffic, you still need appliance mode on the inspection VPC attachment for stateful inspection to work.
• AZ affinity is automatic, and it’s a setting, not a paid feature.

The general rule is blunt: any inspection VPC attachment gets appliance mode, full stop.

The AZ-ID trap is the subtler sibling. AWS randomizes Availability Zone names per account — us-east-1a in one account is not necessarily the same physical zone as us-east-1a in another, because AWS shuffles the name-to-physical mapping per account to balance load. For most workloads this is invisible. For Cloud WAN it isn’t: shared-services and inspection VPCs often need attachments from different accounts to land in the same physical zone for low-latency, symmetric paths. The fix is to place attachment subnets by AZ ID (e.g. use1-az1), which is stable across accounts, rather than by AZ name — and to pin that in your IaC. Miss it and you get latency and symmetry problems that are genuinely hard to explain.

When the same destination is learned twice — how a route wins

Attach enough things and the edge will eventually learn the same destination CIDR from several places at once. It needs a tiebreaker, and because the edge is a managed TGW, it follows TGW route-evaluation semantics. Walk it top down (Figure 4):

Rung 1 — most specific prefix wins. A /24 beats a /16 regardless of where either was learned. Standard longest-prefix-match, and it’s the strongest tool you have: if you want traffic to prefer a path, advertise (or summarize to) a more specific prefix on it.

Rung 2 — static beats propagated. For the same prefix, a static or local route outranks anything learned dynamically. (This is exactly the property that makes a TGW-to-Cloud-WAN migration safe: a static route on the TGW keeps winning until you delete it, so you can stand Cloud WAN up alongside with zero traffic impact — Articles 11–12.)

Rung 3 — equal prefix from different sources. A fixed source-priority order applies: static, then prefix-list, then VPC-propagated, then Direct Connect gateway, then Connect, then Site-to-Site VPN, then TGW peering. One correction here that the older write-ups get backwards: VPC-propagated outranks Direct Connect gateway-propagated, not the other way around.

Rung 4 — equal prefix, same type, BGP. Now BGP attributes decide: shorter AS_PATH, then lower MED, with the same-Region edge preferred when AS_PATH lengths are equal. And if everything is genuinely equal across Regions? The edge that forwards is chosen at random — AWS’s word, not mine — which is the root of those “why is this traffic exiting the wrong Region” mysteries.

The practical upshot: specificity is your strongest, most reliable lever. Everything below it is a default. With the 2025.11 routing policies (Article 2) you can now actively shape these decisions — setting local preference, prepending or replacing AS_PATH, adjusting MED — rather than living with the defaults. Mind the boundaries, though: VPC attachments only support inbound allow/drop filtering (VPCs don’t speak BGP), summarization is outbound and BGP-attachments-only, and BGP community propagation covers VPN and Connect but not Direct Connect or TGW peering. That shaping is what makes a primary/backup Direct Connect design behave predictably instead of randomly.

Which attachment for which job — the decision

Strip away the detail and the choice is short:

• Cloud-only VPC connectivity → VPC attachment. Always.
• Quick hybrid, or where DX isn’t available → Site-to-Site VPN.
• Production-grade hybrid with predictable performance → Direct Connect gateway (Article 6).
• Extending an SD-WAN fabric into AWS → Connect, mapping each VRF to a segment.
• Coexisting with or migrating off existing TGWs — or keeping a TGW for DX termination → TGW peering (Articles 11–12).

Most real global networks run several at once — VPC attachments for workloads, DXGW or VPN for hybrid, Connect for SD-WAN sites, peering attachments during a migration window. The segmentation model from Article 3 holds across all of them: a segment is a segment regardless of how an attachment reaches it. So the type decision is mostly local and reversible; the two decisions that actually hurt to get wrong — appliance mode on inspection VPCs, and AZ-ID placement — cut across every type, which is why they got their own section.

Hybrid connectivity is where many Cloud WAN projects live or die, and Direct Connect earns its own treatment. Article 6 goes deep on the native Direct Connect gateway attachment: how route advertisement works per Region, tuning BGP best-path for symmetric on-premises↔AWS routing, the single-segment-per-DXGW constraint, and how it compares to the older “DX via a Transit Gateway” pattern you may be migrating away from.