Overview of Transit Gateway to External Devices

Overcoming the AWS VGW 100 route limit AWS has route entry limits of 100 per each routing table. Combining the number of VPC CIDRs and the list of on-prem CIDRs, this route limit is fast approaching or already a problem. Typically, an Aviatrix Transit Gateway connects to VGW over IPsec and runs a BGP session with VGW. VGW then connects to on-prem devices. By connecting directly to an external device, the VGW is bypassed.

Overcome AWS VGW performance reset VGW adjusts instance size based on network bandwidth consumption, leading to unexpected outage.

Azure Transit Network This feature allows an Aviatrix Transit GW to connect to on-prem over Azure Express Route or Internet.

High Performance with on-prem By using GRE tunneling protocol, Aviatrix Multicloud Transit Gateway builds multiple GRE tunnels to on-prem routers to achieve 10Gbps throughput.

Integrate with SD-WAN gateways deployed in the cloud BGP over LAN as part of the External Device option provides an efficient mechanism to connect to SD-WAN cloud gateways by interoperating with them over LAN in the same VPC/VNet while exchanging routes dynamically via BGP.

All Other Cloud Providers Use this feature to connect to network of cloud providers such as Alibaba Cloud, Tencent Cloud, VMware Cloud, IBM Cloud and others.

AWS Transit Gateway AWS released Transit Gateway (TGW), I need to migrate my current CSR-based Transit VPC solution.

No Route Propagation AWS Transit Gateway (TGW) does not propagate on-prem learned routes to Spoke VPC route table, it requires manual programming.

Transit Solution for Azure We have multiple Azure VNETs now, we need to form a transit network and connect them to on-prem and to AWS Transit network.

Change Control Each time a new VPC is stood up, a change control process has to take place to modify the edge router for Direct Connect or IPsec over Internet. This is not agile and the risk of errors in configuration is not acceptable.

BGP The CSR-based Global Transit solution runs VGW in each spoke VPC/VNet which runs a BGP session to Transit hub. This is operationally challenging to manage and troubleshoot. The BGP in VGW is a black box and invisible to the outside.

Not Secure All spoke VPC/VNets in the CSR-based Global Transit solution have connectivity to each other through BGP route propagation. There is no network segmentation. The blast radius is my entire cloud network and datacenters. This is not acceptable by the security team.

Extra Charge In the CSR-based solution, traffic from one spoke VPC/VNet to another spoke VPC/VNet traverses through one transit and sometimes two transit hubs, resulting in 2x or 3x egress charge.

Too Complex The CloudOps is a team of 6 engineers managing 34 AWS services, the skill set and resources it takes to manage the CSR-based Transit network is beyond what we want to handle.

10Gbps Transit My current Transit network performance is capped at 1.25Gbps, our network requires much higher bandwidth.

AWS VGW (This is the default setting)

External Device (over Direct Connect or over Internet)

Azure VNG