> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Aviatrix Multicloud Transit Network FAQ

> 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...

## 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
  <a href={"/docs/enterprise/" + "10.1" + "/concepts-architectures/components/tgw/tgw-orchestrator-faq"}>Network Domains</a>
  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 <a href={"/docs/enterprise/" + "10.1" +
"/concepts-architectures/components/connectivity/activemesh-about"}>About
ActiveMesh</a>.

## 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 <a href={"/docs/enterprise/" + "10.1" +
"/concepts-architectures/components/security/hpe-about"}>High Performance
Encryption Mode solution</a>.

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

To configure Aviatrix Multicloud Transit Network, follow the instructions in <a href={"/docs/enterprise/" + "10.1" +
"/guides/connectivity/transit/transitvpc-workflow"}>Single-Region Multicloud
Transit Network Workflow</a>.

If you plan to deploy an AWS Transit Gateway (TGW) based transit network, follow
the instructions in
[Aviatrix Transit Gateway Orchestrator Workflow](https://legacy.docs.aviatrix.com/documentation/latest/network/remote-user-to-cloud.html/tgw/tgw-overview).

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 <a href={"/docs/enterprise/" + "10.1" +
"/guides/connectivity/transit/transitvpc-workflow"}>Single-Region Multicloud
Transit Network Workflow</a>.

## How do I build a Multi-Region Transit solution?

Inter-region transit network (see

<a href={"/docs/enterprise/" + "10.1" + "/concepts-architectures/architecture/connectivity/tgw-design-patterns"}>TGW Design Patterns</a>
) can be connected directly. Follow the instructions in
<a href={"/docs/enterprise/" + "10.1" + "/guides/connectivity/peering/transit-gateway-peering-workflow"}>Multi-Region Multicloud Transit Gateway Peering Workflow</a>
.

## 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

<a href={"/docs/enterprise/" + "10.1" + "/guides/security/egress/egress-legacy-overview"}>Aviatrix FQDN Filtering (Legacy)</a>
. 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

<a href={"/docs/enterprise/" + "10.1" + "/guides/connectivity"}>
  UserVPN
</a>

.

## 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.

<Tip>
  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.
</Tip>

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

## 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](https://registry.terraform.io/providers/AviatrixSystems/aviatrix/latest).

## 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](https://aws.amazon.com/premiumsupport/knowledge-center/create-vpn-direct-connect/)
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](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
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.