In order to satisfy my own curiosity on the subject, I set about testing a migration scenario from AWS TGW to Aviatrix.
We have many customers running on AWS TGW, which is a great product but lacks the Multi-Cloud agility that many of our customers seek.
One of the blocking points, however, is the complexity around migration. I do not want to underestimate this risk, but I would like to highlight how feasible it is. The below lab I put together in one afternoon.
I am not advocating managing your migration in this way, but I would simply like to point out that such migrations can be straightforward and painless when planned correctly.
I set off a continuous ping in both directions for the duration of the migration below to check the change’s impact on reachability.
Finally, in this post I am doing everything in the console. In reality, we would be scripting many of the changes as well as preparing roll-back scripts.
Disclaimer: This is not an official migration plan. I have done many data centre migrations in the past, and they require weeks and months of preparation. Use your judgment in adopting any of the suggestions I set out in the workflow below.
The Starting Point
Let’s look at the environment we have set up for testing.
In this scenario, we have 2 application VPCs deployed who communicate with each other over the TGW.
We have deployed an Aviatrix Transit Hub and connected this to the AWS TGW via an IPSec tunnel running BGP on top.
We have deployed and attached 2 Aviatrix spoke gateways in one of the VPCs and simply deployed the gateways in the other (no attachment). This is simply to show that the traffic is indeed flowing through the AWS TGW.
No impact on connectivity
Step 1 – Migrate VPC 1 to Aviatrix Transit Solution
We will modify the route table of VPC 1 (10.1.2.0/24) to use the Aviatrix transit.
This is easy since we have already made the Aviatrix spoke attachment and the 10.0.0.0/8 is already in the route table.
Traffic to 10.1.3.0/24 continues to use the TGW as there is a more specific CIDR match in the route table.
We will remove this more specific match in the 10.1.2.0/24 VPC route table.
Now the traffic routes to the Aviatrix Transit, and because we have no direct attachment to 10.1.3.0/24, we use the BGP route via the AWS TGW.
No impact on connectivity. Traffic flow is suboptimal, but this is a transitory situation.
Step 2 – Attach the Aviatrix Spokes in 10.1.3.0/24
In the Aviatrix controller, we will attach the Aviatrix spoke gateways in 10.1.3.0/24 VPC to the Aviatrix Transit hub. This will insert the 10.0.0.0/8 route automatically in the spoke VPC route table. However, since there is a more specific to 10.1.2.0/24 using the AWS TGW, there will be no impact on traffic.
No impact on traffic flow
Step 3 – Migrate the 10.1.3.0/24 spoke to Aviatrix
We do this by removing the static route 10.1.2.0/24 pointing to the AWS TGW.
Step 4 – Remove the legacy TGW attachments
Now for the clean-up, we will remove the legacy TGW VPC attachments.
No impact on traffic flow
Conclusion
Migrations are tricky and present their own risks.
Approach this in a professional way and seek support where you need it.
However, from a technology perspective, an almost seamless migration is feasible. I am aware I am only using 1 workload above and verifying using ICMP, but the premise remains the same.
Check out the next post where we do the same for Azure vWAN.
Thanks for reading.
