AWS Cloud WAN series · Part 11 of 17

Migrating off Transit Gateway, Phase 1: Federation

Eleventh in the AWS Cloud WAN series. Almost nobody builds Cloud WAN on a blank slate — you start with a working Transit Gateway mesh you can't take down. This is how you slide Cloud WAN in underneath that mesh as a dynamic global spine, run both side by side, and keep a rollback at every step. Phase 2, the full cutover, is the next article.

Why you migrate in phases, not in one night — the three stops

The typical starting point is a network that works: a TGW in each of a few Regions, statically peered, with route tables hand-maintained for cross-Region reach. Because a TGW is a regional construct and inter-Region TGW peering carries only static routes, achieving cross-Region segmentation means writing static routes for every cross-Region destination, in every Region's route tables, by hand. It works, but every new VPC or Region is manual surgery in several tables at once. That static, doesn't-scale reality is exactly what Cloud WAN's dynamic, full-mesh backbone replaces.

You don't earn that by ripping the TGWs out. You earn it in phases, and the migration has three stops you can halt at (Figure 1):

• Before — your current TGW mesh. The baseline.
• Federation (Phase 1, this article) — replace static TGW-to-TGW peering with Cloud WAN as a dynamic routing hub between the TGWs. You may stop here permanently and use Cloud WAN purely as a global routing spine.
• Cloud WAN only (Phase 2, Article 12) — move the VPC attachments off the TGWs onto Cloud WAN and decommission the TGWs you no longer need.

Phasing is the entire point. Each step is reversible, and Phase 1 changes routing between your TGWs without disturbing the workloads on them. This works at all because a single AWS global network is allowed to contain both Transit Gateways and a Cloud WAN core network at the same time — coexistence is a supported state, not a hack.

What federation actually swaps — TGW peering for a Cloud WAN spine

In federation you keep every TGW and every workload attachment exactly where it is. What you replace is the inter-Region connectivity — the statically-peered TGW-to-TGW links — with connectivity through a Cloud WAN core network (Figure 2). The mechanism is the Transit Gateway peering plus the route-table attachment covered in Article 5:

• You create a Cloud WAN core network whose segments mirror your TGW routing domains — a prod segment, a dev segment.
• You peer each TGW with the Core Network Edge (CNE) in its Region. Unlike static TGW-to-TGW peering, a CNE peering supports dynamic routing over BGP.
• Over each peering you create route-table attachments, each extending one specific TGW route table to one Cloud WAN segment.

Remember that a CNE is, mechanically, an AWS-managed Transit Gateway — the docs say it “is also known as an AWS Transit Gateway, and it inherits many of the same properties.” So peering your TGW to a CNE is conceptually TGW-to-TGW peering, except the far side is a managed edge that AWS auto-meshes to every other Region's edge over the global backbone. Routes that land in a TGW route table get advertised dynamically through the Cloud WAN segment to every other TGW route table mapped to that same segment, in any Region. Cross-Region connectivity becomes dynamic and global, and your prod/dev isolation is now enforced by Cloud WAN segments instead of by hand-maintained static tables.

How your segmentation survives the move — one route table, one segment

The subtlety that trips people up: the whole TGW does not map to a segment. A route-table attachment extends one individual TGW route table to one Cloud WAN segment, and you create as many route-table attachments over a peering as you have route tables to map. So the prod route table extends to the prod segment, the dev route table to the dev segment (Figure 3). That granularity is what preserves your segmentation natively across Regions: prod routes only ever reach prod, dev only dev, with no chance of the two mixing in a shared peering table the way they could when one static peering had to carry every environment.

Two prerequisites bite before you ever see a route, and both come from earlier articles:

• ASNs must be unique. Each TGW's ASN must differ from the CNE's ASN it peers with — the same ASN-planning discipline from Article 2. A CNE's ASN is immutable once set, and it can't overlap a TGW you intend to peer, so sort the numbering before you peer, not after.
• Peering is same-Region only. A TGW peers with the CNE in its own Region. You never peer a TGW in one Region to a CNE in another — the Cloud WAN mesh is what handles inter-Region.

One more operational note for when you wire this up: tag the attachments so your attachment policies place the route-table attachments into the right segments. Attachment policies read the tags on the attachment object, not on the underlying resource — the rule Article 4 dwells on, and an easy one to forget when the resource is a TGW route table rather than a VPC.

Why nothing breaks the moment you turn it on — static beats dynamic

Here's the part worth understanding precisely, because it's what lets you migrate without a flag-day. When you stand the Cloud WAN peerings up alongside your existing static TGW peering, both paths exist at once. Which one does traffic take? The static TGW peering routes win.

That isn't luck — it's the documented route-evaluation order. For the same destination prefix, a TGW prefers routes in a fixed priority, and static routes sit at the very top, above every dynamically-propagated route; Cloud WAN's TGW-peering-propagated routes sit at the bottom of that list. So at the instant you add Cloud WAN, nothing changes: traffic keeps flowing over the old static peering, and the new dynamic Cloud WAN routes sit in the tables as less-preferred alternatives (Figure 4, left). AWS calls this out directly as the safe-migration lever — a static route on the TGW takes precedence over a dynamically-learned Cloud WAN route for the same prefix.

That gives you a validation window with no risk attached. You can:

1. Add the core network, peerings, and route-table attachments with zero traffic impact, and wait for each attachment to reach the Available state.
2. Verify the Cloud WAN segments contain exactly the routes you expect — prod routes in prod, dev in dev, nothing crossing over.
3. Only when you're satisfied, delete the static peering routes on the TGWs. At that moment the dynamic Cloud WAN routes become the active path and inter-Region traffic shifts onto Cloud WAN (Figure 4, right).

If anything looks wrong during validation, you simply don't delete the static routes — and you can tear the Cloud WAN peerings down with no impact. The cutover is one deliberate, reversible action (removing static routes), not a risky simultaneous reconfiguration. That's the textbook controlled migration: introduce the new path, validate it in parallel, then flip preference. One caveat the docs add: also remove any VPC-specific cross-Region static routes for the traffic to actually move — a leftover static route anywhere in the path keeps pinning traffic to the old hop.

What federation won't buy you — the cost it doesn't cut

One consideration AWS's pricing page doesn't make obvious: federation is not automatically cheaper. In a TGW → Cloud WAN → TGW path, the data-processing meter runs on each domain it enters. The peering hops themselves are free — AWS states plainly that no data-processing charge applies to traffic over the CNE-to-TGW peering — but data processing is charged where traffic arrives into each domain through a billable VPC or VPN attachment, so a flow that crosses two TGWs via Cloud WAN can be processed on both the TGW side and the Cloud WAN side. There's a direction asymmetry on top of that: Cloud WAN applies data-transfer charges in both the in and out directions, while TGW applies them outbound only.

So the practical reading:

• Don't assume federation reduces cost. Its value in Phase 1 is operational — dynamic global routing, one policy, trivial Region adds — not necessarily financial.
• The cost case improves in Phase 2. Once VPCs attach directly to Cloud WAN and you retire the intermediary TGWs, traffic stops double-processing through two TGWs and the picture changes.
• Model your own traffic. Whether federation is cost-neutral, cheaper, or pricier depends on how much of your traffic is inter-Region TGW-to-TGW versus everything else. Remember Cloud WAN also adds a per-Region edge fee — roughly $365/month per CNE — that TGW has no equivalent for. Article 16 treats cost in full.

If your goal is purely the operational win, federation delivers it and you can stop at Phase 1 indefinitely. If your goal includes cost reduction, plan to continue to Phase 2.

How to roll it out without a flag-day — the Phase 1 checklist

A safe federation rollout, in order:

1. Plan ASNs so every TGW differs from its CNE; resolve any conflict first, because a CNE ASN can't be changed later.
2. Create the core network with segments mirroring your TGW routing domains.
3. Peer each TGW with its same-Region CNE.
4. Create route-table attachments, mapping each TGW route table to the matching segment, and tag the attachments so attachment policies place them correctly.
5. Validate that each segment's route table holds exactly the expected routes with isolation intact. Traffic still flows over static peering at this stage — no impact.
6. Delete static peering routes on the TGWs, Region by Region or environment by environment, watching traffic shift to Cloud WAN. This is the only step that changes live routing.
7. Confirm connectivity and segmentation post-cutover, and keep the option to re-add the static routes until you're confident.

At the end of Phase 1 you have a global, dynamically-routed network with your segmentation enforced natively by Cloud WAN — and every workload still sitting on its original TGW, untouched.

When to stop at Phase 1 — and when to go on to Phase 2

Here's the decision to carry forward. Stop at federation if what you wanted was the routing: a dynamic, full-mesh global spine, one policy instead of a wall of static tables, and Region adds that no longer mean hand-editing every peer's routes. Phase 1 is a legitimate permanent architecture, not just a way-station — coexistence is a supported state, so you can run TGWs-under-Cloud-WAN for as long as you like.

Go on to Phase 2 if you want the cost case to improve or the TGWs gone. Federation keeps the double-TGW hop in the path; only moving VPC attachments directly onto Cloud WAN and decommissioning the redundant TGWs removes it. That's the next article: moving VPC attachments off TGW with the atomic route-repoint trick, migrating Direct Connect from a TGW-terminated model to native DXGW attachments with minimal downtime, and the BGP and maintenance-window practices that keep the full cutover low-risk.