My goal with this post is not to unpack all the technical detail behind any of these technologies, but rather to demonstrate the convergence of three in-demand features from VMare and AWS – HCX, Direct Connect, and Transit Gateway. This convergence represents years of extended effort on the part of both VMware and AWS, as well as no small number of Solution Architects, Product Managers, software engineers, and customers.
Background
Since we first announced VMware Cloud on AWS, one of our secret weapons (#notsosecret) has been Hybrid Cloud Extension (HCX). The ability to enable cross-vCenter / cross-cloud migrations of virtual machines without also requiring massive changes to your existing infrastructure is incredibly compelling. Here is one of my favorite blogs on the topic:
It would be a major oversight if I did not also mention this most excellent demo from my good friend Sean Lambert (@vSeanLambert, #cloudTAM) showing HCX used to migrate between two SDDCs in VMC on AWS:
And as you might expect, lots of customers have wanted to run their HCX migrations over Direct Connect (DX). We have made this relatively simple by providing a network profile for HCX to use in VMC on AWS that integrates directly with a customer’s DX. Others have written about both using AWS DX with VMC on AWS:
Enter AWS Transit Gateway
Nearly as soon as Amazon announced their Transit Gateway in late 2018, customers and vendors alike were trying to figure out how to integrate with it, and VMware customers were no exception. There is a ton of interest in the integration between VMware Cloud on AWS and Transit Gateway – for the simple reason that it simplifies the routing architecture to the cloud, as well as the day-to-day administration of routes. There has been plenty written on TGW and VMC already, and I do not plan to re-hash it here… I will once again simply provide the references for you to investigate:
- http://www.gilles.cloud/2018/12/aws-transit-gateway-and-vmware-cloud-on.html
- http://www.gilles.cloud/2019/12/aws-transitive-routing-with-transit.html
There are unfortunately some limitations with a ‘native’ AWS TGW and VMware Cloud on AWS – most significantly the fact that a VMC SDDC may not attach to a TGW using a ‘native’ VPC attachment. The SDDC may only attach using a VPN attachment, which limits it to 1.25 Gbps throughput, which may severely limit the network performance from the SDDC over the TGW.
Introducing VMware Transit Connect
Since Transit Connect is essentially a VMware-managed Transit Gateway and allows attaching at native speeds, it eliminates this throughput issue, as well as some of the more subtle support issues that may arise by trying to perform vMotion tasks over a 3-rd party routing infrastructure. My colleague Gilles Chekroun (@twgilles) put together a fantastic overview of everything you need to know about the VMware Transit Connect.
- https://youtu.be/QVe9SPQn4cA
- http://www.gilles.cloud/2020/06/vmware-cloud-on-aws-managed-transit.html
Beginning today, Transit Connect is now available with VMware Cloud on AWS SDDC version 1.12. This first became available in VMware Cloud on AWS with SDDC version 1.11 – though to gain this functionality it had to be enabled by request. Now that SDDC version 1.12 is generally available, all new customers will be enabled with the ability to deploy a Transit Connect (existing customers may have to wait until their org / SDDC is upgraded).
I had the opportunity recently to run a proof of concept for a customer, and as it turns out their preferred / optimal path to the cloud leverages a Direct Connect (with DX Gateway) – so even though one of the primary use cases for Transit Connect is to enable high-throughput communications between multiple SDDCs, in this case it simply served to enable the customer to further utilize their existing fiber connection to AWS. This customer wanted to be able to migrate workloads over to VMC on AWS using HCX to maintain their existing IP space.
Configuring HCX with VTC
We started by creating a couple compute segments in the SDDC – this was to ensure we could validate the advertisements of cloud-based networks back over the Transit Connect and DX.
Then, following the documented procedure to create a Transit Connect (found in the official M.11 docs here), we created a SDDC Group and worked with the customer’s AWS team to accept the request to attach to their DX GW.
It was remarkably simple and easy – granted the customer already had both their DX and their DX GW configured – but nonetheless I was very pleased with the ease of the implementation.
Then we proceeded to deploy HCX as normal (again – see some of the above links for a thorough overview of HCX deployment). We had to make 2 changes to the HCX deployment:
- We had to ensure name resolution for HCX resolved to private IP addresses (configured through the SDDC Settings page).
- When configuring the HCX Service Mesh we had to use the Direct Connect network profile for the cloud-side HCX configuration.
Once that was done, the appliances deployed and configured their tunnels with zero issues.
You can see below there is a new dashboard for reviewing routes learned and advertised over the Transit Connect – “SDDC Interconnectivity” – and all the routes came up very quickly.
You can find a great set of instructions for deploying HCX here as part of the public onboarding documentation.
The key takeaway here is that deploying HCX over VMware Transit Connect is exactly the same as deploying with a Direct Connect Private VIF.
I was super pleased with the experience, and the work that has been accomplished by the joint VMware and AWS teams. Hopefully you will have a chance to try out this solution yourself!
My Occasional IT Blog... 