To make it short:
we are classifying spokes in security domains and isolate these domains from each other. That can be extended to multi-cloud, on-prem, vpn. (More details)
Let’s focus on AWS TGW today…
There is also feature called “TGW Orchestration” which allows Aviatrix controller to program TGW and manage its RTB and also utilizing these security domains. It is pretty powerful but has one big limitation – we are able to extend segmentation only to EDGE transit domain. So if you peer this Transit to another Aviatrix transit pair in a different CSP you will not see them. That’s why we are going to build it differently – by defining Connections between Aviatrix Transit and AWS TGW. With Connection definition we can extend it further and fully utilize potential given with MCNA (Multi-Cloud Network Architecture) by Aviatrix. Sometimes you just might not be the owner of TGW and you just need to do it that way.
Desired Topology
When defining connection you need to be aware how Aviatrix Gateways are actually building it. Usually both of them are trying to establish connection to whatever remote IP you define. Please take a look on the following examples:
Connection OPTION 1
this is typical configuration where you want full mesh and you can see both Transit GW build x2 tunnels for each one of the Remote Gateway IP.
| 
|
Connection OPTION 2
 Here you can see that we broke the rule of full mesh and we specify that primary Transit GW builds connection to pub_IP1 and HA GW builds second connection to pub_IP2. | 
|
Knowing that, lets define our AWS TGW’s peers and specific connections
Due to the fact that in AWS we can specify only 1 IP as Peer (CGW – customer gateway) we need to follow option2. Otherwise 2nd Aviatrix Gateway would try to establish another tunnel which will never be up (dummy tunnel). The example should look like this:
Repeating this step for all 4 connections and we have the following (we can list them under SITE2CLOUD -> Setup):
Let’s check BGP … (after all configuration is done Aviatrix and AWS)
AWS TGW configuration
With the concept of individual RTB per DEV and PROD we already achieved the isolation.
Aviatrix segmentation
Let’s define our security policy. The workflow for domain segmentation is very easy.
Enable Segmentation
create domains
Define Policy
Our 2 domains (RED, BLUE) should not talk to each other so nothing under Connected.
If we had “Shared Services” VPC we could define such and put as “Connected” under each.
Associate “Attachment” to domain
Complete list of all Attachments per Domain:
Testing connectivity
Investigating the path we can see traffic going through our Tunnel and each one of the Aviatrix Gateway.
Copilot - view
Copilot is really powerful tool for day 2 operations. One of it’s key benefit is Topology MAP which is dynamically generated based on Controller’s data read from individual CSPs.
Here you can see:
- Transit Gateways deployed in HA mode
- 1 spoke for PROD environment
- 1 spoke for DEV environment
- all x4 connections towards TGW with x2 tunnels per each connection
- latency on each one of the IPSEC tunnel – that is handy
Additionally we can verify Security policy and confirm which “Security attachment” is allowed to talk with the rest (it even says what type of node it is: Spoke or Site2Cloud). BTW I’m not daltonist – could have named segmenets better though
