Solution Guide:
Aviatrix Secure Egress Filtering on AWS Cloud
Overview
This soluon guide provides automaon and step-by-step instrucons for deploying the Aviatrix Secure
Egress soluon on the AWS Cloud. This soluon guide uses AWS APIs to automacally deploy an Aviatrix
Controller and Aviatrix CoPilot for enabling the Aviatrix Secure Egress soluon in a new or exisng virtual
private cloud (VPC). This guide assumes you are familiar with Network Address Translaon (NAT), AWS
NAT Gateways, and their uses case or enabling egress traffic for VPC private subnets.
What problem does this soluon solve?
Amazon EC2 instances are launched in VPC private subnets to be protected from the internet and require
internet access to download security patches, soware updates, access code repositories, SaaS
applicaons, and reach other important sites (this traffic is commonly referred to as Egress traffic). As a
security best pracce, organizaons may also want to enable egress but only with a strict set of security
policies that define the domains on the internet that be accessed and nothing more, have visibility of all
egress traffic as it is permied or denied by the security policies. Accomplishing this on your own can be
challenging, me-consuming, and could result in costly data processing charges.
The Aviatrix Secure Egress Filtering soluon that you will deploy using this guide provides egress NAT
capabilies you need along with fine-grained domain-based security controls, distributed firewalling, and
deep traffic visibility in a simple, cost-effecve soluon that you can centrally manage from the Aviatrix
plaorm UI or with automaon using the Aviatrix Terraform provider.
Aviatrix Secure Egress Filtering on AWS
AWS offers you different methods for helping to secure resources in Amazon Virtual Private Cloud
(Amazon VPC) networks. One important security measure is to effecvely control inbound (ingress) and
outbound (egress) VPC network traffic so that you can disnguish between legimate and illegimate
requests.
Workloads in AWS are typically limited to applicaons and services where the desnaon of outbound
traffic is known. For example, a reporng applicaon might connect to google.com for authencaon
and might also query salesforce.com for data. Another applicaon might associate with a hosted
database service or a file-sharing service.
Specifying policies by IP address isn't praccal for these types of services because the domain names can
translate to many different IP addresses. Also, security groups for EC2 instances must be managed on
each server, and there's a strict limit on the number of entries that are added.
