Aviatrix is the de facto standard when it comes to building Multi-Cloud unified data-plane with advance transit, traffic engineering and many other enterprise features. Hundred of customers have built their advance transit and routing backbone using Aviatrix MCNA (Multi-Cloud Network Architecture) utilizing Aviatrix Transit and Spoke Gateways.

AWS-TGW has many limitation that makes it very difficult for enterprises to adopt. As a rule of thumb Aviatrix does not recommend enterprise customers to use AWS-TGW. There are couple of scenarios where engineers/architect are forced to use AWS-TGW.

AWS Transit Gateway (TGW) is a service that enables connectivity across multiple VPCs and on-premise networks. It has native support for static network segmentation by allowing users to group VPCs into pre-defined route tables (domains). In this article, we discuss how the Aviatrix security domain feature significantly augments this capability with intelligent route control.  

TGW route tables function like virtual routing and forwarding (VRFs) that network engineers have been familiar with for some time.  A TGW route table accepts connection or membership through what AWS refers to as attachments. Attachments can be VPCs, VPNs, Dx Gateways, Peering, or other connections that may be added in the future. All attachments that are a member of a route-table share the same routing logic and are, therefore, part of the same “route domain.”   

Controlling and Programming TGW route tables 

There are two methods for adding routes to a TGW route table: Route Propagation and Static Routes.  

As the name implies, route propagation enables the automatic addition of routes from the attachment to the target route table. In the case of VPCs, this is the VPC CIDRs; for VPNs, this would be routes advertised over BGP. The key here is that when you add propagation from an attachment, you effectively enable insertion of reachability information from that attachment to the route table so that other attachments (i.e., VPCs) know how to get to the network behind that attachment.  

With that mind, it’s essential to know that this propagation is not automatically by default. The actions for attachment and propagation are not the same. While this fundamentally gives us further control into the flow of traffic between attachments, it immediately doubles the work of route management. 

Communication between route domains 

Attachments that are not part of the same route table, by design, cannot communicate. To allow for cross-domain communication between attachments, you can leverage the same propagation option discussed above. Unlike attachment association that’s one-to-one, propagation works across domains. Meaning, if I have VPC-A that is attached to RT-A and VPC-B that’s attached to RT-B, to enable communication between VPC-A and VPC-B, I can add propagation from VPC-A in RT-B and VPC-B in RT-A. I also need to ensure both of these VPC route tables have a proper route to the destination. As we can see with every change in our connection needs, we need to update and adjust associated AWS Transit Gateway (TGW) route tables and VPC route tables to enable communication across route domains. 

As this example demonstrates, updating route tables with every change that is introduced to our network is complex, time-consuming, and error-prone. It gets exponentially more challenging as the number of TGWs and VPCs grows in your network. 

Aviatrix platform includes full control of the AWS Transit Gateway (TGW) route tables, using Aviatrix security domain and connection policy concepts. 

A security domain is an abstraction of the AWS TGW route tables with added intelligence and control. Aviatrix security domain feature enables scalable and dynamic segmentation of the network. For example, you can have “dev”, “prod” and “test” security domains to isolate your development, production, and test environments in your AWS cloud. You can configure the connection policies in such a way that the VPCs in the dev security domain cannot talk to VPCs in prod, but they can talk to VPCs in the test domain.  

An Aviatrix security domain can have one or more spoke VPCs as its members. The intelligent control and management capability of the Aviatrix controller ensures that VPCs within a security domain can communicate with each other via TGW routing. This is done by the Aviatrix controller dynamically managing route propagation that we discussed above.   

By default, security domains are independent and not connected. Through the Aviatrix controller, admins can enable the connectivity amongst security domains by configuring connection policies between the domains. 

Aviatrix controller monitors changes to the network and updates routes across different route tables and VPCs based on the policies. Connection policies are applied at the domain level and are dynamically applied to all of the attachments in that domain, hence simplifying policy definitions dramatically.  

Every time a topological change to the network, such as when a new spoke VPC is added/removed, the Aviatrix controller automatically propagates the routes and performs all route table updates so that the new network state follows intended connection definitions. Also, if there is a need for route domains to talk to each other, Aviatrix will establish the connectivity and update all the associated route tables. 

It’s important to note that when an AWS Transit Gateway (TGW) is created by using AVX Controller, three security domains are created by default. 

• Default Security Domain – A default security domain is created whenever you create TGW using the Aviatrix controller. If you do not plan on building any VPC network segmentation, you can use the default domain for inter Spoke VPC and hybrid communications. This will essentially create a mesh network where every VPC can talk to each other 




• Shared Service Security Domain – When an AWS Transit Gateway (TGW) is created by the AVX Controller, the Shared Service Security Domain is created, and a corresponding route table is created on AWS Transit Gateway (TGW). You can attach a Spoke VPC to this domain and host your shared service instances such as your DevOps tools. Shared Service Security Domain is always connected to default security domain and edge security domain 




• Aviatrix Edge Security Domain – When an AWS Transit Gateway (TGW) is created by the AVX Controller, the Aviatrix Edge Domain is created, and a corresponding route table is created on AWS Transit Gateway (TGW). Aviatrix Edge Domain is designated for connecting VPCs to an on-premise network. There must be one VPC attached to this domain. In the VPC, an Aviatrix Transit GW is deployed that is used for data traffic forwarding between Spoke VPCs and on-premise networks. Aviatrix Edge Security Domain is always connected to the Shared Service Security Domain and the Default Security Domain 

In addition to the above three security domains, you can easily create additional security domains based on your network needs and establish connection policies among them. 

In summary, Aviatrix Controller simplifies and extends the AWS Transit Gateway (TGW) by using dynamic route propagation, policy abstraction, and simplifying operations through a single pane of glass. 

For a demo, or to dive deeper into this topic, email Info@aviatrix.com or visit www.aviatrix.com and start a web chat conversation with an expert now.