Overview of Aviatrix Multicloud Transit Network

Why should I choose Transit Architecture?

Transit architecture is about building connectivity between the cloud and on-prem in the most agile manner possible. In the Transit architecture, there is one connection (not including the backup) between on-prem and a Transit VPC/VNet. Everything else (the Spoke VPC/VNets to on-prem traffic) is routed through the Transit VPC/VNet.

The alternative to Transit architecture (often referred to as "flat" architecture) is to build one connection, either IPsec over the Internet or Direct Connect, each time you spin up a new VPC or VNet in the cloud. This requires changes at the on-prem edge, which requires a change control process that takes days to weeks.

How does the Aviatrix Transit Network Solution Differ from Cisco’s CSR-Based Solution?

They differ in the following areas:

  • Central Control - With the Aviatrix solution, the Aviatrix Controller is the single pane of glass for all networking in the cloud.

  • AWS Transit Gateway Integration If you have AWS deployment, Aviatrix Transit integrates with an AWS TGW seamlessly for high bandwidth Spoke VPC connection. Customers who do not require end to end encryption can now use the TGW native service to connect the Spoke VPCs.

  • Network Segmentation In the CSR-based solution, all Spoke VPCs have connectivity to each other through the Transit GW, even though these Spoke VPCs belong to different AWS accounts or business teams. In contrast, in the Aviatrix solution the Spoke VPC/VNets have no connectivity to each other, by default. Connectivity is built by design. With the TGW integration, you can customize the Network Domains to meet your segmentation requirements.

  • Connectivity Efficiency In the Aviatrix solution, traffic between any two Spoke VPC/VNets can be routed via TGW or directly, as opposed to going through the instance based Transit GW as required by the CSR-based solution. Decoupling the different traffic streams reduces performance bottlenecks and removes single failure points.

  • No unwanted route propagation Since Spoke VPC/VNets run BGP in CSR solution, if a Spoke VPC/VNet also connects to a partner network via VGW, the partner network routes could be propagated to your own on-prem network.

  • Simplicity In Aviatrix’s solution, BGP is only deployed between Transit GW and VGW. No Spoke VPCs run BGP. Simplicity leads to stability. Workflow-based, step-by-step instructions help you build out a Transit VPC/VNet solution in minutes.

  • Monitoring The Aviatrix solution integrates with Splunk, Sumo, remote syslog, ELK and DataDog to forward events from gateways to your favorite central logging service.

  • Scalable AWS has various limits in its infrastructure, such as a route entry limit of 100. This limits how many on-prem CIDRs and VPC CIDRs can be carried on a Transit GW. The Aviatrix solution overcomes that limitation.

How do I configure a global Transit Network with the Aviatrix Solution?

To configure Aviatrix Multicloud Transit Network, follow the instructions in Multicloud Transit Network Workflow Instructions (AWS/Azure/GCP/OCI).

If you plan to deploy an AWS Transit Gateway (TGW) based transit network, follow the instructions in Aviatrix Transit Gateway Orchestrator Workflow.

If you plan to deploy an Azure transit solution that does not require to encrypt traffic between the Transit VNet and Spoke VNet, follow the instructions in Multicloud Transit Network Workflow Instructions (AWS/Azure/GCP/OCI).

Should the Aviatrix Transit Network all be deployed in ActiveMesh mode?

ActiveMesh mode is enabled by default. To learn more, see Overview of Aviatrix ActiveMesh.

Should I deploy one Transit Group for Dev and one for Prod?

If your reason for two Transit hubs is security and a smaller blast radius, you need not worry about these when using the Aviatrix solution. Simply create two Security Domains in your deployment.

I have two regions and two Direct Connects. How do I build a Multi-Region Transit solution?

Inter-region transit network (see TGW Design Patterns) can be connected directly. Follow the instructions in Aviatrix Transit Gateway Encrypted Peering.

I have more than 100 VPCs. How do I overcome AWS Route Limits (100)?

When AWS VGW carries more than 100 routes, its BGP session will crash unexpectedly, resulting in your network outage.

Azure network has similar limitations, the following techniques work for both cloud providers.

These are the options Aviatrix solution provides:

1. Summarizing Spoke VPC/VNet Routes

Enable Spoke VPC route summarization so that Transit GW advertise as few routes to VGW as possible. As long as you can limit the number of total routes on the VGW to less than 100, the Transit Network can support as many Spoke VPC/VNets as you need.

Aviatrix Controller sends out alert/warning messages when it determines that the total routes carried by the VGW exceeds 80. This is to alert you to start reducing routes carried by the VGW to avoid potential network outage. This alert message is sent each time there is a route VGW advertised from VGW to Transit GW.

2. Bypassing VGW

To permanently solve the route limit problem and not have to worry about summarizing routes at all and ever, use External Device Option to connect to on-prem directly over Direct Connect or the Internet.

I have a few high bandwidth applications. How do I deploy them in a Transit solution?

Aviatrix’s High Performance Encryption Mode solution provides 10Gbps Transit network throughput.

How can I fit an Egress Firewall into the Aviatrix Transit solution?

There are two types of requirements.

Egress Control Policies

If your compliance requires egress policies and you have currently implemented AWS NAT gateways, consider using Aviatrix Egress Control. Aviatrix Egress Control is the most efficient way to provide a FQDN filter for all TCP/UDP protocols.

How can I route VPC/VNet Egress Internet-bound traffic to on-prem to go through the corporate firewall?

If you advertise 0.0.0.0/0 to VGW, Spoke VPCs will have that route point to the Transit GW and route egress Internet traffic to VGW and back to on-prem. Make sure you do not have NAT enabled on the Spoke GW or AWS NAT service enabled in the VPC/VNet.

What are the automation methods for a Transit Network?

There are multiple resources to help you automate Transit Network setup. Note that if you are building a Transit Network following the workflow, you should use Terraform.

Does the Aviatrix Transit Network support High Availability?

Yes. Aviatrix Transit Gateways operates in ActiveMesh Mode.

When a t2 series Transit GW communicate with VGW over IPsec, there is a 3% packet drop for packet size less than 150 bytes by Transit GW due to an issue with AWS Xen hypervisor and the kernel version GW is using. This will be fixed in a future release.

Note that this packet drop issue does not affect Spoke Gateways.

How do I build encryption over Direct Connect?

AWS provides native solutions to add VPN capability between VGW and on-prem over Direct Connect. This improves security as data in motion is encrypted. Follow the instructions here for this capability.

We build an encryption between Aviatrix Transit GW and a VGW and between a Transit GW and a Spoke GW to provide an end-to-end encryption protection.

How do I build redundancy between VGW and on-prem?

AWS provides a few native options for redundancy between VGW and on-prem. You can build redundant active/active VPN connections, redundant active/active DX connections and DX with backup VPN connections.

Read this doc for implementation details.

How do I deploy a user VPN Use Case on Transit Network solution?

We recommend you to deploy User VPN in a shared service VPC/VNet. If this shared service VPC/VNet has connectivity to all other VPC/VNets, a user can reach any instances in these VPC/VNets as long as his/her profile policy allows.

Does Transit Network support Azure VNet?

You can launch a Spoke Gateway in Azure VNet. A best practice is to set up the Azure VNet the same way you usually do with AWS VPC: two types of subnets, public subnets and private subnets with respective routing tables, where the Spoke Gateway is launched in public subnet.

In Azure there is no explicit concept of public subnet. The idea here is to set up separate subnets and respective routing tables for the Aviatrix Gateway and user VMs. For convenience, we use the term "public subnet" to describe the subnet where Aviatrix Spoke gateway is launched.

Such separation of subnets and routing tables provides you with the flexibility if you plan to use Spoke gateway also for FQDN functions.