Why should I choose Aviatrix Multicloud Transit Network Architecture?
Aviatrix Multicloud Transit Network architecture is about building connectivity between the cloud
and on-prem in the most agile manner possible. In the Aviatrix Multicloud Transit Network
architecture, there is one connection (not including the backup) between
on-prem and a Transit VPC or VNet. Everything else (the Spoke VPC and VNets to
on-prem traffic) is routed through the Transit VPC or 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 may take 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.
Does the Aviatrix Transit Network support high availability?
Yes. Aviatrix Transit Gateways operates in ActiveMesh Mode.
ActiveMesh mode is enabled by default. To learn more, see About ActiveMesh.
How do I deploy high bandwidth applications in the Aviatrix Transit solution?
Aviatrix’s High Performance Encryption
solution provides 10Gbps Transit network throughput. To learn more, see High Performance Encryption Mode solution.
To configure Aviatrix Multicloud Transit Network, follow the instructions in Single-Region Multicloud Transit Network Workflow.
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 Single-Region Multicloud Transit Network Workflow.
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 Multi-Region Multicloud Transit Gateway Peering Workflow.
How can I fit an Egress Firewall into the Aviatrix Transit Network 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 FQDN Filtering (Legacy). This is the most efficient way to
provide a FQDN filter for all TCP/UDP protocols.
How do I deploy a UserVPN on Aviatrix Multicloud Transit Network solution?
We recommend that you deploy UserVPN 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. To learn more, see UserVPN.
Does Aviatrix Multicloud 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.
Can I automate the Aviatrix Multicloud Transit Network setup?
There are multiple resources to help you automate Aviatrix Multicloud Transit Network setup.
Note that if you are building a Transit Network following the workflow,
you should use Terraform.
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.
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.
Just create two Network Domains in your deployment.
