How can I use Aviatrix to build a centralized architecture for directing VPC egress traffic to an SD-WAN solution?

As organizations start growing, the networks connecting remote locations and datacenters also grow. Many organizations have started using new generation SD-WAN Technologies to augment or replace their traditional WAN networks and to also tackle rising network hardware costs. In addition to the cost effectiveness, SD-WAN technologies are also giving organizations ability to do policy-based routing and benefit from security services directly built into the network.

Also, with the advent of hybrid networks, many organizations want to connect their SD-WAN technologies to their AWS VPCs in the cloud. This involves ability to handover the VPC traffic directly to a centralized SD-WAN gateway and then let it do the policy-based routing and data security using its POP network.

Today, we will take a look at how you can build a centralized architecture to hand-over all the VPC egress traffic to a SD-WAN solution using the Aviatrix Orchestrator for AWS Transit Gateway

What are we trying to achieve?

The objective here is to ensure that all the outbound traffic from your VPCs including internet (0.0.0.0/0) should go to a centralized VPC (let us call it: SD-WAN VPC) where the SD-WAN gateway resides. In this case, SD-WAN gateway will do the policy-based routing and decide the best route for data based on defined policies. Because the objective is to handover all the egress traffic including internet to the SD-WAN gateway, in the SD-WAN VPC, ideally, it should only have private subnets and no public subnet. SD-WAN gateway will reside in one of the private subnets. All the private subnets will have default route 0.0.0.0/0 pointing to SD-WAN gateway elastic network interface. This will ensure that all the traffic destined for 0.0.0.0/0 goes to SD-WAN gateway. However, there may be a scenario, where SD-WAN gateway itself needs public subnets to accommodate various policy-based routing options. This can cause a problem as any traffic destined for 0.0.0.0/0 in the public subnet will automatically egress through the internet gateway and we will not be able to handover the traffic to the SD-WAN gateway.

To handle this, we will have to ensure that while attaching the centralized VPC to the transit gateway only private subnets in each Availability Zones (AZ) are attached. As, you may already know, we have to attach at least one subnet per AZ, to the AWS Transit Gateway, to enable that AZ. Once an AZ is enabled, transit gateway can route traffic to all the subnets in that AZ. If we attach public subnets to the Transit Gateway, the traffic destined for 0.0.0.0/0 will automatically egress through the internet gateway in that public subnet thereby defeating the purpose. For this reason, we will only attach private subnets in each of the AZs to the transit gateway. This will ensure that all the traffic destined for 0.0.0.0/0 will go to the private subnets and from there to the SD-WAN Gateway because of the default route. Please note that if you have instances in the public subnets of the SD-WAN VPC, you will still be able to send traffic to them as route tables associated with private subnets will still have direct route to your public subnet CIDR

While setting this up, Aviatrix Orchestrator will automatically configure all the AWS Transit Gateway and VPC route tables dynamically and will also ensure that only private subnets from centralized VPC are attached to the AWS transit gateway. VPC to VPC communication and routing will be handled directly by AWS Transit Gateway. Here is the architecture diagram for this:

• Dev Security Domain can talk to SD-WAN Security Domain
• Prod Security Domain can talk to SD-WAN Security Domain
• Dev and Prod Security Domains cannot talk to each other

Let us build this solution step by step using Aviatrix. Based on the above diagram, we have three VPCs, Dev, Prod and SD-WAN. The traffic from Dev and Prod VPCs will be handed over to the SD-WAN gateway in the SD-WAN VPC. Create all three VPCs in the AWS console and follow the below steps after that:

How to build this solution using Aviatrix:

1. 1. Create a Transit Gateway using Aviatrix TGW Orchestrator. TGW Orchestrator > PLAN > Step 1

1. 1. Create the Dev, Prod and SD-WAN Security Domains. TGW Orchestrator > PLAN > Step 2

1. 1. Build connection policies for the domains created in the above step based on the architecture diagram. TGW Orchestrator > PLAN > Step 3

1. 1. Attach all the three VPCs to their respective domains. TGW Orchestrator > Build > Step 1

Rest of the points have to be completed on AWS Console. For now, we have to insert 0.0.0.0/0 routes manually in the VPC and TGW route tables. In Aviatrix R4.1 software release, this will be done automatically from the Aviatrix Orchestrator workflow.

1. Configure route tables of Dev and Prod VPCs with 0.0.0.0/0 pointing to TGW Attachments
2. Configure route tables of private subnets of SD-WAN VPC with 0.0.0.0/0 pointing to SD-WAN gateway ENI
3. Configure route tables of public subnets of SD-WAN VPC with direct routes pointing to Deva and Prod VPCs
4. Configure TGW route tables of Dev and Prod Security Domains with 0.0.0.0/0 pointing to SD-WAN VPC Attachment
5. Check the Attachement1 (SD-WAN Attachment of the TGW) to ensure that only private subnets are attached in the AZ. If any public subnet is attached, then click on Modify, remove public subnet and attach the private subnet in the respective AZ

With this workflow, all of the traffic sent by Dev and Prod VPCs to your on-premise will be handed over to SD-WAN gateway and it will decide the best route for that traffic based on the defined policies and its POP network.