A Practical Guide to Migrating from Transit Gateway to AWS Cloud WAN

As enterprises adopt multi-cloud and hybrid strategies, managing hundreds of network connections and routing policies has become increasingly complex. Organizations are therefore shifting toward CloudWAN (Cloud Wide Area Network) architectures that provide centralized connectivity and simplified operations—but migrating without disrupting production workloads remains a significant challenge.

CloudWAN Fundamentals

The fundamentals of CloudWAN has been previously discussed but let me give a quick recap.

CloudWAN is a managed networking service offered by AWS. It allows organizations to easily build, manage, and monitor a global network that securely connects branch offices, on-premises data centers, and VPCs using the AWS' backbone. It replaces complex, manual router configurations with centralized, policy-based automation. Instead of piecing together different networks, you define your network's design, security, and routing rules in a single policy document, and the cloud provider automatically deploys and manages it. Check Cloud WAN for more information

Global Network

This is the top-level container — it holds core network and any associated attachments (VPCs, VPNs, etc.).

Core Network

The core network is essentially the backbone/fabric that ties your network attachments (VPCs, VPNs, Transit Gateways, on-prem links) together.

Core Network Edge

A Core Network Edge (similar to Transit Gateway) is a regional connection point provisioned and managed by AWS in each AWS Region that you include in your core network via your core-network policy.

Core Network Policy

A policy document (in declarative language) that states how your network should be configured:

• which AWS Regions to include
• how attachments map to segments
• routing rules
• traffic-isolation rules

Cloud WAN then implements the network configuration automatically.

Attachments

These are VPCs, VPN connections, Transit Gateways, SD-WAN links, on-premises branch office links that are hooked to your network.

Network Segmentation

Cloud WAN lets you define segments — isolated routing domains. So you can isolate e.g. production, development, branch offices, or sensitive resources even if they share the same overall network backbone.

Current Design

Here is a simplistic network diagram using Transit Gateway, Direct Connect
and VPCs.

You can see there are 2 region - us-east-1 and ca-central-1. Both accounts / VPCs represent networking resources in respective account. There are multiple TGWs. TGWs are central to this design, there region TGWs that allows connectivity within the region - for example, so that multiple development VPCs could be connected. There is also inter-region TGWs that allows connectivity from DX gateway from another region. This is designed to reduced data transfer cost.

Migration Challenges

Moving from the current architecture to Cloud WAN can be complex specially because we want to achieve this by minimising downtime. Following are some of the challenges you might experience.

Routing disruptions

Routing disruptions is a significant risks during Cloud WAN migration, specially when transitioning from an existing Transit Gateway architecture similar to our case. As route propagation shifts from Transit Gateway route tables to Cloud WAN's core network policy and segments, there is potential for asymmetric routing, blackholed traffic, or transient loops if both environments advertise overlapping prefixes simultaneously. This is especially acute during phased migrations where some VPCs remain attached to the Transit Gateway while others move to Cloud WAN, requiring careful peering and static route management between the two. We need to know our routes upfront incase there are overlapping routes to mitigate any risks.

Misconfigured network policies

Cloud WAN replaces individual route table management with a centralized core network policy — a policy-as-code model that improves consistency but concentrates risk, since a single misconfigured segment action, attachment rule, or tag can affect connectivity across every Region. Common pitfalls include incorrect segment isolation settings, attachment tags that fail to match policy rules, and misunderstanding policy versioning and rollback. Treat the core network policy like production code: version control, peer review, and testing in a non-production environment before promoting changes.

DNS propagation issues

DNS is often an afterthought in network migrations, yet it can quietly undermine a successful cutover. Resolution paths involving Route 53 Resolver endpoints, private hosted zones, and hybrid forwarding rules may need re-plumbing for the new segments, while cached records with long TTLs can leave clients resolving to stale endpoints well after the change. On-premises resolvers forwarding into AWS are especially vulnerable if resolver endpoints sit in VPCs that changed segments. Audit resolver rules and zone associations beforehand, lower TTLs ahead of the cutover, and validate resolution from every segment — cloud and on-premises — after migration.

Asymmetric routing

Asymmetric routing is a scenario where data packets travel from a source to a destination along one path, but take a completely different route when returning. This situation will occur when we cutover traffic from TGW to Cloud WAN. Therefore, if you are performing firewall inspection, either the firewall needs to support asymmetric routing and you are willing to use it or you might get downtime.

Firewall and security rule mismatches

Migrating to Cloud WAN often changes the paths traffic takes through inspection points, which means firewall rules tuned for the old topology may no longer behave as intended. Centralized inspection architectures using AWS Network Firewall or third-party appliances must be re-integrated with Cloud WAN's service insertion or segment routing, and rules referencing specific CIDR ranges, availability zones, or interface addresses can silently fail to match traffic arriving via new paths. Stateful firewalls also risk dropping established sessions if traffic suddenly shifts to an asymmetric path where return packets traverse a different inspection point. Addressing this requires mapping every inspection choke point in the current design, translating rules to the new traffic paths, and running controlled connectivity tests across representative flows before decommissioning legacy infrastructure.

Assessment

Cloud WAN Migration Assessment Checklist

• Network inventory & topology mapping — Document all VPCs, Transit Gateways, VPNs, Direct Connect connections, and peering; identify overlapping CIDRs across accounts and Regions. This is needed so you can later create the attachments.

• Traffic flow & dependency analysis — Use flow logs to map east-west, north-south, and inter-Region traffic; baseline bandwidth and latency for post-migration validation.

• Routing & segmentation design review — Catalogue route tables, propagations, and static routes; define how existing routing domains map to Cloud WAN segments and attachment policies. Even before you cutover, you can create the segments and segment routing policies.

• Security & inspection architecture — Identify all inspection points and firewall rule sets tied to current paths; map to Cloud WAN service insertion and validate compliance requirements.

• DNS & hybrid connectivity dependencies — Inventory Route 53 Resolver rules, private hosted zones, BGP configurations, and advertised prefixes for on-premises integration.

• Operational readiness — Define ownership of the core network policy, change management workflow, monitoring strategy, and team training needs for the policy-as-code model.

• Cost modeling — Compare Cloud WAN pricing (core network edges, attachments, data processing) against the current Transit Gateway baseline.

• Migration sequencing & risk plan — Prioritize workloads into migration waves, define rollback criteria per wave, and tie validation tests to pre-migration baselines.

Let me know if you'd like this trimmed further to one-liners, or expanded with sub-items under each area.

Target Architecture

The proposed architecture is shown below. All the TGWs are replaced with a single Cloud WAN. The beauty is it is a central policy that can be easily managed instead of configuring and maintaining all the TGWs.

So, instead of connecting the development VPCs from ca-central-1 and us-east-1 using TGWs, we now have Cloud WAN with segmentation, that is performing all the connectivity. Since, these are development VPCs, I have added a DEVELOPMENT segment that contains the attachments for development VPCs. I also added a HYBRID segment that connects the DX Gateways. It's ideal to connects DX Gateways to HYBRID so it can be easily shared with other regions or segments.

The DEVELOPMENT segment has been setup with the policy so that it will allow traffic with the development VPCs but not with production VPCs. Also, the DX gateways will contain a policy so the correct DX is preferred in the region. The diagram below shows the attachments and routing between the regions and VPCs.

Migration Planning

If you are extending your infrastructure into a new region, then, the Cloud WAN design is quite easy as you can afford downtime and can experiment with the routing. However, my situation is different, I want to migrate the existing TGW based design to Cloud WAN. The critical aspect is we cannot afford downtime or we need to minimise as much as possible. This is true for any 24x7 business like healthcare, finance, etc.

First thing is there is no real separate development environment for networking as we will migrate everything to Cloud WAN. Therefore, it's a live test. In my workplace, we use development, UAT, production and few sandbox VPCs, similar to most companies. Since, we can afford downtime in development and UAT, we will start with for migration only in ca-central-1 region.

Cutover runbooks

Let's call development VPC account -> ca1-dev account.
Let's call core network account -> global-network account.
Assumption: Core network policy allows attachments using tags.

1. Share core-network with ca-central-1 region. This will create the CNEs.
2. Share existing TGW in ca-central-1 to global-network account.
3. Peer TGW route table to Cloud WAN in ca1-dev account.
4. Create TGW route table attachments from ca1-dev account. Select peering id from Step 3. Tag it to the correct segment. Note traffic will start to route over Cloud WAN now.
5. Create attachments to for ca1-dev VPC in global-network account.
   • Traffic from VPC will flow over TGW
   • Traffic to VPC will flow over Cloud WAN
6. Update VPC route tables and add a default route 0.0.0.0/0 to core network.

Once you complete Step 5, you need to pay attention as this will result in asymmetric routing. If your firewall or current design doesn't support asymmetric routing, it will drop packets and you will lose traffic. This will work properly again once you complete Step 6.

For Step 6, you might also need to update existing default route or any specific route like 10.0.0.0/8 to DX.

Multiple region DX preference

Once you connect multiple DX to the HYBRID segment, the traffic can use either DX as both are connected and available. To ensure you use the regional DX, you need to update the routing policy to prefer the DX. You can use the routing policy as shown below using your ASN and MED values.

"routing-policies": [
    {
      "routing-policy-name": "PreferUsEast1DX",
      "routing-policy-description": "Prefer us-east-1 DX only",
      "routing-policy-direction": "inbound",
      "routing-policy-number": 10,
      "routing-policy-rules": [
        {
          "rule-number": 1,
          "rule-definition": {
            "match-conditions": [
              {
                "type": "prefix-equals",
                "value": "0.0.0.0/0"
              },
              {
                "type": "asn-in-as-path",
                "value": 65001
              }
            ],
            "condition-logic": "and",
            "action": {
              "type": "set-local-preference",
              "value": "500"
            }
          }
        }
      ]
    }

Rollback

If you need to rollback, I suspect you will already know this once you complete Step 4. If that's the case, simply un-tag the TGW attachments. In case, you have completed Step 6 and need to rollback, then it's a bit of work. You will need to update the VPC route tables and remove the default route and also un-tag the VPC and TGW attachments.

Once you have migrated ca1-dev VPC, you can plan your next segment or region based on your situation.

Minimal Downtime Strategies

Connecting to Cloud WAN is the easy part in the migration process. You can easily create all the CloudFormation or CDK templates for creating the TGW peering, attachments and VPC attachments. This deploys quite quickly. The main challenge is updating all the route tables for the VPC to add the default route. Learning from failure, the fastest way would be to run a script that will add the default routes.

#!/bin/bash

# Variables - update these for your environment
CORE_NETWORK_ARN="arn:aws:networkmanager::123456789012:core-network/core-network-0123456789abcdef0"

# List of route table IDs to update
ROUTE_TABLE_IDS=(
  "rtb-0123456789abcdef0"
  "rtb-0abcdef1234567890"
  "rtb-0fedcba9876543210"
)

for RTB in "${ROUTE_TABLE_IDS[@]}"; do
  echo "Processing route table: $RTB"

  # Try to create the route; if it already exists, replace it
  if aws ec2 create-route \
      --route-table-id "$RTB" \
      --destination-cidr-block "0.0.0.0/0" \
      --core-network-arn "$CORE_NETWORK_ARN" 2>/dev/null; then
    echo "  Route created in $RTB"
  else
    echo "  Route exists, replacing in $RTB"
    aws ec2 replace-route \
      --route-table-id "$RTB" \
      --destination-cidr-block "0.0.0.0/0" \
      --core-network-arn "$CORE_NETWORK_ARN"
  fi
done

Monitoring & Validation

Monitor using Network Manager

Network Manager is the primary console for Cloud WAN observability. You can using the dashboard to check attachment states, segment topology, and route tables per segment and edge location. It also emits events (via EventBridge) for topology changes, attachment state transitions, and policy version deployments — you can set up rules to alert on unexpected changes like attachments going down.

Monitor using CloudWatch metrics

Cloud WAN publishes metrics to CloudWatch under the AWS/NetworkManager namespace, including BytesIn/BytesOut per attachment and per core network edge. Key things to alarm on:

• Sudden drops in traffic on an attachment (could indicate a routing or blackhole issue)
• Traffic on attachments that should be idle (indicates leakage between segments or a misrouted flow)

Also, Compare post-migration throughput against the baselines you captured during assessment — significant changes mean something not right and warrant investigation.

Also, perform tests to confirm DNS resolution, DX connectivity and that the actual applications are working.

Conclusion

Migrating to AWS Cloud WAN is as much an operational shift as a networking one. The common pitfalls — routing disruptions, policy misconfigurations, DNS issues, and firewall mismatches — all stem from gaps between how the legacy network actually behaves and how teams assume it does. Your success is determined before the first cutover: a thorough assessment, a plan with clear rollback criteria, and monitoring in place from day one. The Cloud WAN network is globally scalable and policy-driven network that's simpler to operate and easier to reason about than the topology it replaces.