How do I create a centralized egress control architecture using AWS Transit Gateway (TGW) and Aviatrix?

One of the challenges of security in cloud environments is controlling Egress traffic. To be specific, by egress here we mean allowing a connection that’s initiated from within the cloud, or a VPC, to be routed to the public internet. Security conscious cloud architects opt to ensure all the VPCs are sealed from Internet, but there are uses case where allowing traffic to exit the VPC is required, such as for updating repositories.

Centralized or distributed?

Here at Aviatrix, we have been enabling our customers to deploy Egress control with policy-based filtering for quite some time. This was achieved by deploying what we refer to as distributed Egress control, which meant there would be a gateway in each VPC that needed Egress control. This works fine if there are requirements for granular control per VPC, and if there are limited number of VPCs. While that option is still viable and applicable, many customers prefer to control traffic egress from one central point. This is especially true as enterprises’ number of VPCs grow rapidly and the need for centralized control and monitoring grows with it.

Previously, achieving a central egress control for your AWS environment meant peering VPCs in a hub and spoke fashion, which was operationally impractical due to latency and complexity challenges. With the recent addition of AWS Transit Gateway (TGW) feature, paired with Aviatrix orchestration and security overlays, we now offer an operationally practical solution for centralized Egress. In this post, we will walk you through setting up a centralized Egress control with Aviatrix system’s orchestration.

What does centralized Egress mean?

The idea here is to ensure all traffic that is destined for 0.0.0.0/0 goes through a single VPC in which Egress policy enforcement can take place before a connection is allowed to exit to internet. In this fashion, Aviatrix egress control is deployed in a single VPC in each region, let’s call it Egress Transit VPC. Communication between spoke VPCs and Egress Transit VPC is handled by AWS Transit Gateway (TGW) to ensure optimal latency, throughput and high availability, while Egress Control is done through Aviatrix. Let’s take a look at a simple diagram that depicts this architecture.

Let’s look at how to build this use case

In our hypothetical case we want to allow instances that are in VPC A of Dev domain to be able to Egress. Prod domain is not allowed to Egress, so we will not configure it as such.

Pre-requisite:

At a high level, this workflow is a combination of Aviatrix AWS Transit Gateway (TGW) Orchestration, Egress Control and injection of default route in select VPC route table as well as AWS Transit Gateway (TGW)’s route table for source domain. Assumption here is that you have already created and configured a AWS Transit Gateway (TGW) using AWS Transit Gateway (TGW) Orchestration workflow, with security domains and VPC attachments already configured for all but Egress use case. Otherwise, please follow AWS Transit Gateway (TGW) Orchestration workflow to confiture AWS Transit Gateway (TGW) and its attachments.

1. 1. Create VPC with at least one private subnet and one public subnet to serve as our Egress transit VPC. Let’s call it “Aviatrix Egress Transit VPC”.
   2. Follow Egress Control workflow to create an Aviatrix gateway in this VPC and enable appropriate filtering policies link
   3. Using step 2 of TGW Orchestration’s Plan workflow, create an Egress security domain. In this example we call this Domain “Aviatrix_Egress_Domain”

1. 1. Use step 3 of the same workflow to configure Security policies to allow Dev Domain to Talk to Aviatrix_Egress_Domain

1. 1. Attach the VPC we created for Egress to this Domain

1. 1. Configure VPC A’s route tables to forward traffic for 0.0.0.0/0 to Transit Gateway
      Note that in this step, for a specific VPC and a specific route table, we are defining a default route that’s pointing to AWS Transit Gateway (TGW), effectively routing all traffic that use default route towards AWS Transit Gateway (TGW). This step has to be completed on every VPC that require egress. Once configured, your route table should look similar to below:

1. 1. Configured AWS Transit Gateway (TGW) Route table
      1. This step is also very important. You need to insert the default route in the route tables that is associated with Dev domain, no other AWS Transit Gateway (TGW) route table needs to be modified. First select the appropriate route table, click on “Routes” tab, and then click “Create route” to add a route.

1. 1. Create the default route as shown below, and ensure that you pick the right attachment that points to the Egress VPC

Your instances in VPC A should now be able to access internet through Aviatrix GW.

Configure Security Groups to allow traffic

If your security groups are not configured to allow traffic from internal subnet, since we are configuring traffic to flow from one VPC to another VPC through AWS Transit Gateway (TGW), you need to ensure that corresponding traffic is allowed between the source instances and Aviatrix gateway that sits in the Egress VPC. Aviatrix controller’s flightpath is powerful connectivity validation tool that can help you test this connectivity. For example, if you are allowing HTTPs connections through Egress, you need to ensure TCP 443 gets through end to end. This is accomplished by adjusting Security Groups associated with the source instance interface, as well as Aviatrix Egress gateway’s interface to allow TCP 443.