AWS Cloud WAN series · Part 12 of 17

Migrating Off Transit Gateway, Part 2 — The Cutover

Twelfth in the AWS Cloud WAN series, and the sequel to Part 1 on federation. Federation gave you global routing while every workload stayed on its old Transit Gateway. Phase 2 finishes the job: VPCs attach straight to the core network, Direct Connect moves to a native gateway, and the TGWs come down — all of it reversible, one workload at a time, with no flag day.

Why finish what federation started — killing the double-TGW hop

Part 1 left you in a working but compromised state. Federation peers each TGW to its same-region Core Network Edge and maps each TGW route table to a Cloud WAN segment, so routing is global and dynamic — but every VPC is still attached to its original TGW. A flow between two VPCs in the same segment takes the scenic route: VPC → TGW → Cloud WAN → TGW → VPC. That's two TGW hops bracketing the core.

Plenty of teams stop there, and that's a legitimate place to stop. But if the reason you started was to retire TGW route-table sprawl and simplify the path, Phase 2 is where you collect. It removes the intermediary so a VPC attaches directly to the Core Network Edge, and the same flow becomes VPC → Cloud WAN → VPC — one hop, no TGW in the data path (Figure 1).

The cost picture improves too, but be precise about why. The CNE-to-TGW peering hop itself is free — AWS charges no data processing on traffic between a Core Network Edge and a peered TGW. The savings come from the attachments: in federation, a VPC-to-VPC flow is data-processed at each TGW it transits, so it pays at two TGW domains plus the Cloud WAN side. After Phase 2, that collapses to a single Cloud WAN data-processing event. It's a real reduction — just don't sell it as "the peering hop was double-charged," because it wasn't.

How you move one VPC without a flag day — the reversible cutover loop

The whole of Phase 2's VPC work is one small loop, repeated per VPC. Done carefully it is per-VPC and reversible, so the blast radius of any mistake is a single workload, not the estate. The loop (Figure 2):

1. Prepare. Create the Cloud WAN VPC attachment alongside the existing TGW attachment. Put its ENIs in dedicated subnets — mind the AZ-ID consistency point from Article 5, since AZ names map to different physical zones across accounts — and tag the attachment (not the VPC resource) so your attachment policy maps it to the right segment, the rule Article 4 leans on. For a sensitive segment with require-attachment-acceptance on, accept it deliberately.
2. Validate. Confirm the attachment reaches Available (one of the eight attachment lifecycle states) and that the segment has learned the VPC's routes — all without sending it any production traffic yet.
3. Shift. Repoint the route in the VPC's own route table from the TGW to the Cloud WAN core network. This is the one step that moves live traffic, and it's the subject of the next section.
4. Verify. Check reachability and that segmentation still holds — the VPC reaches what it should and nothing it shouldn't.
5. Drain & commit. Watch the old TGW path empty, then delete that VPC's TGW attachment. Now it's on Cloud WAN alone.

Because the VPC route table is the control point, rollback for any VPC is just repointing its route back at the TGW — the same atomic operation in reverse. That property is what lets you migrate non-production first, validate a whole wave, then take production in its own waves with confidence, instead of betting the estate on one change window.

The trick that makes the shift safe — longest-prefix in the VPC route table

Cloud WAN follows Transit Gateway route-evaluation semantics, and the one rule that matters here is longest-prefix match wins, absolutely — the most specific route to a destination is chosen regardless of how it was learned. That gives you a finer instrument than flipping a whole route at once.

The blunt version of step 3 is to ReplaceRoute the existing route — say 10.0.0.0/8 → TGW becomes 10.0.0.0/8 → core network — in one atomic call. AWS specifically recommends ReplaceRoute over a console delete-then-add precisely because delete-then-add leaves a window with no route at all; ReplaceRoute swaps the target in place with no gap.

The surgical version uses longest-prefix to bleed traffic across one destination at a time (Figure 3). Leave the broad 10.0.0.0/8 → TGW in place as a fallback and add a more-specific route — 10.10.0.0/16 → core network — for just the prefix you want to move. Longest-prefix match sends anything inside 10.10.0.0/16 over Cloud WAN while everything else in 10/8 still rides the TGW. Validate that slice, add the next more-specific prefix, and so on. Rollback is deleting the more-specific route: traffic falls straight back to the /8 via the TGW. The broad fallback never changes until you're done.

Moving hybrid connectivity — Direct Connect from TGW to native DXGW

If your hybrid connectivity terminates Direct Connect on a TGW, Phase 2 is also when you move it to a native Direct Connect Gateway attachment — a DXGW that attaches straight to the core network with no intermediary TGW, learning and advertising on-prem routes over BGP automatically (Article 6 covers the native model in depth). This is the highest-risk part of the whole migration, because on-premises reachability rides on it, so it gets the most ceremony. The same parallel-then-flip discipline applies, just with BGP as the control instead of a route table:

1. Build the new path in parallel. Create new DXGWs and new transit VIFs and associate them with the core network's segment. The DXGW object is free to create, so standing up parallel gateways costs nothing and gives you a clean rollback — but note the DXGW attachment to Cloud WAN is billable once it's carrying traffic, so don't budget the hybrid path as free. A native DXGW associates with a single core network and a single segment (multiple DXGWs can share one segment), and its ASN must sit outside the core's ASN range.
2. Verify before advertising. Confirm the new BGP peers are up but not yet advertising on-prem prefixes — the path is wired and idle.
3. Flip the preference. Advertise the same on-prem prefixes on the new VIFs, then make your on-premises routers prefer the new VIFs (typically via BGP local preference). This single step is the only one that changes live routing — do it in a scheduled maintenance window.
4. Roll back if needed by withdrawing the new advertisements and reverting on-prem preference to the old VIFs.

The shape is identical to the VPC loop: everything up to the preference change is non-disruptive preparation, and only the flip touches existing flows. AWS still recommends a TGW per Region for Direct Connect in some designs, so keep workloads reaching the DXGW directly within their Region rather than creating cross-Region dependencies during the move. When the native path proves out, the TGW is left doing nothing but terminating DX during the transition — which is exactly what you retire next.

Retiring the Transit Gateways — the easy part, done last

Once VPCs are on Cloud WAN attachments and DX is on a native DXGW, the remaining TGWs carry no traffic. Decommissioning is pure cleanup, with no further traffic changes:

• Remove the TGW peerings and route-table attachments to Cloud WAN — the federation plumbing from Phase 1 — once nothing depends on them.
• Delete the now-idle TGWs. The same lifecycle discipline you met in Article 2 applies in reverse: a Cloud WAN Region can't be removed from the policy until its attachments are deleted, so always clean up attachments before deleting what they point at.
• Remove the static routes and route tables that existed only to prop up the old TGW topology.

Do this last, deliberately, and only after a stabilization period on the new paths. There's no rush: an idle TGW costs little, and keeping it around a while longer preserves the easiest possible rollback if something surfaces a week later.

Sequencing the whole cutover — parallel build, then one flip

Stacked end to end, a sane Phase 2 reads as five stages on top of the federated network (Figure 4): migrate non-production VPCs in waves, then production VPCs in waves and maintenance windows, then Direct Connect to native DXGW in a window, then stabilize, then decommission. At every stage the new path is built and validated alongside the old, and the cutover is a single deliberate change — a route flip or a BGP preference — with rollback available throughout.

One operational caution worth repeating from Article 13: don't try to create the Cloud WAN core network and its VPC attachments in the same infrastructure-as-code workspace. AWS's own guidance is to decouple the global network and core network from the regional VPCs into separate stacks for independent lifecycle management, and that separation matters most during migration, when you're creating many attachments against an already-live core network.

What you actually bought — and what you didn't

When the TGWs are gone, take the honest accounting from Article 1. You gained one versioned policy instead of a hundred per-region route tables, tag-based segmentation that auto-onboards new workloads, native global dynamic routing, and the single-hop path that quietly improves the inter-region cost picture. You did not gain fewer firewalls, a replacement for SD-WAN or MPLS, or a different regional data-plane resilience story — Cloud WAN inherits the Core Network Edge's TGW-like properties, not a new failure model.

And it isn't automatically cheaper. A named practitioner estimate puts Cloud WAN at roughly a 30% premium over an equivalent TGW design — illustrative and region-dependent, not an AWS figure — driven by the per-region CNE base of about $365/month that TGW has no equivalent for, plus a higher per-attachment fee. What Phase 2 buys is operational simplicity and global routing. If your team was drowning in TGW route-table tickets, that's the win that justified the project; if it wasn't, federation alone may have been the right place to stop.

The migration cluster assumed you'd build all of this somehow, and for any real network "somehow" means infrastructure as code. The next cluster turns to operations and engineering: Article 13 covers managing the core network policy as code with Terraform — the aws_networkmanager_core_network_policy_document data source versus raw JSON, dynamic blocks for scaling segments and regions, the dummy-base-policy bootstrap, and the AWS-maintained modules and blueprints that give you a tested starting point.