For a Centralized FQDN type design for Private Subnets, We will use the FQDN function at the transit layer with a scalable model such that the Aviatrix Transit GWs will do ECMP to one or more FQDN gateway to handle the load of the entire region. This type of design is useful when customers want a centralized way to control and monitoring of Egress policy of all of their Private workloads across AWS regions.

Let’s focus on a Design that looks like below. VPCs in region East will use the Transit East VPC for FQN egress Services and VPCs in West region will use the Transit West VPC for FQN egress Services.

We will skip the details of how to build Aviatrix Transit as this is not the main topic of this article. When building the Aviatrix Transit Gateways in AWS follow a “Transit FireNet” type design and therefore Transit GWs must:

1)    be at least c5.xlarge or more

2)    have the Transit FireNet Function enabled.

3)    have activemesh enabled when launching the Aviatrix Transit Gateway.

4)    have Aviatrix Transit Network in Connected mode.

To enable, the Transit FireNet Function, go to Transit Network---> Transit Firenet and enable FireNet function as shown below:

 Launch FQDN gateway from Firewall Network--->Setup. Make sure to pick the same AZ as the Transit VPC GW. This can be repeated to deploy as many FQDN gateway depending on the scale.

 In order for the Centralized FQDN cluster to take effect, we need to enable the Egress function so that all VPCs start receiving the default route. To do this, go to Firewall Network--->Advance and choose both Transit FireNet (East and West) to turn on this functionality

 We will also need to filter the default route 0.0.0.0/0 between the Transit peering. This is such that each region points to its own centralized FQDN Transit.

 Finally, to enable FQDN functionality, create your FQDN filter rules and attach respective gateways. This is done from the Security--->Egress control

While a Centralized FQDN type design is possible for Private Subnets, Public Subnets will need to have a dedicated FQDN gateway per VPC. This is because public EIPs of instances are advertised to internet by public cloud via their own infrastructure and a centralized FQDN will not be able to do that and therefore, we will deploy Public FQDN gateways in each VPC where this is required.

Consider a Topology below:

 To deploy the public FQDN gateway, go to Security -----> Public Subnet and add a new Gateway

 The new gateway deployed here, Public-FQDN-1, will enable Aviatrix to edit the Route Table of the public instance to egress via this gateway, thereby we can apply the filter policies.