• Filtering Control – Native cloud constructs such as Internet or NAT Gateways filter on IP address, but not on FQDN’s. This createsagapinvisibilityforcloudoperationsandsecurityteams. ProvideFQDNcontextincentralizedsecuritypoliciesfor your VPC/VNET egress traffic across regions and clouds.
• Domain Name Discovery – Log internet sites (domains, URLs) apps in VPCs or VNets visit to help create filtering policies.
• White Listing – Create FQDN “Allow” lists to reduce an attacker’s ability to exfiltrate data and limits the ability for malicious
  traffic to communicate with your cloud applications and resources.
• Security Policies – Centrally manageable white listed domains that enable policies to be applied easily to any VPC or VNet through deployment workflows or Terraform automation.
• Compliance – Ensure egress filtering meets corporate or regulatory compliance, such as PCI, HIPAA and SOC2.
• High Performance at Low Cost – Optimize costs by enabling distributed FQDN filtering to operate on low cost cloud
  compute platforms (e.g. EC2 T2-micro instances).
• Automation – Support for Terraform Infrastructure as Code automation and integration with CI/CD pipeline.

Aviatrix Intelligent Centralized Controller

The Aviatrix controller is the brain of the cloud network platform. The platform leverages the centralized intelligence and knowledge of the controller to dynamically program both native cloud network constructs and Aviatrix’s own gateway’s advanced services. Combined with Aviatrix’s Terraform provider this design enables network and security Infrastructure-as- Code automation across a multi-cloud environment.

Aviatrix Gateways

Aviatrix gateways deliver advanced cloud networking and security services. For this validated design Aviatrix Gateways are deployed to provide the distributed filtering services, based on policies (FQDN White lists or IP addresses) to limit VPC or VNet egress traffic to known domain names or domain paths with wild card support. Aviatrix gateway replaces native NAT gateways and provide high throughput with limited compute requirements. Aviatrix Gateways are primarily deployed to deliver transit network and security services such as intelligent dynamic routing, active-active network high-availability, end-to-end and high- performance encryption and collect operational visibility data. Egress FQDN gateways can also operate as spoke gateways to deliver these services but may require higher-performance underlying cloud compute capacity.

Aviatrix CoPilot (optional)

Aviatrix CoPilot provides a global operational view of your multi-cloud network not available from AWS, Azure or any other cloud provider. Enterprise IT teams – who need day-two operational visibility for cloud networking – use CoPilot’s dynamic topology mapping to maintain an accurate view of their global multi-cloud networks, FlowIQ to analyze global network traffic flows and global heat maps and time series trend charts to easily pinpoint and troubleshoot traffic anomalies. CoPilot leverages the intelligence and advanced network and security services delivered by the Aviatrix cloud network platform. With Aviatrix, cloud network and security operations teams have familiar day-two operational capabilities such as packet capture, trace route and ping to resolve problems faster. Operational features include resource tagging, resource clustering, infrastructure monitoring and alerting, all specifically built for multi-cloud network operations.

Filtering Control

Native cloud constructs such as Internet or NAT gateways filter on IP address, but not on FQDN’s. This creates a gap in visibility for cloud operations and security teams. Aviatrix provides the FQDN context in centralized security policies for VPC/VNET egress traffic across regions and clouds. FQDN filtering rules can utilize wildcard. The rules not only support HTTP/HTTPS but also additional protocols such as SFTP, FTP, ICMP etc. Traffic can be filtered by IP/port/protocol.

Discovery Mode and Security Policies

Discover what internet sites apps visit before creating filtering policies. This gives egress traffic visibility without disrupting the existing policies and control. The results can be exported and analyzed to create fine grained FQDN based rules. Centrally managed groups of white listed domains allow policies to be applied easily in deployment workflows. FQDN “Allow” lists, reduces an attacker’s ability to exfiltrate data and limits the ability for malicious traffic to communicate with cloud services.

Compliance

Many cloud workloads are subject to corporate or regulatory compliance, such as PCI. Aviatrix FQDN filtering based egress security is an easy and quick to deploy solution to achieve compliance and audit requirements. The solution could also be integrated with 3rd party audit and logging systems such as Splunk, Sumologic, Datadog and any other system that supports syslog and/or netflow.

Automation, Visibility and Operational Control

Deployment and updates easily fit into existing CI/CD pipelines with Terraform and the Aviatrix API. Visibility and operational control over internet bound traffic is an important element of any enterprise cloud architecture. Cloud applications with unrestricted access to the Internet-based services expose environment to attack. Best practices limit application network communications to only known Internet-based services. For example, app tier services that require build packages from GitHub must have access to github.com, but all other access should be filtered and blocked. Aviatrix provides the visibility to understand what Internet-based services applications are communicating with and gives the control to filter those communications by Fully Qualified Domain Names (FQDN).

When designing for secure egress solution, organizations should consider availability, manageability, performance and cost to make sure proposed design meet the business and technical requirements.

The Aviatrix Egress FQDN Filtering solution is extremely flexible and can be deployed number of different ways based on business and technical requirements. It is a low friction solution that fits easily in existing processes without requiring significant modifications to the existing cloud provisioning workflows.

There are number of different deployment models and design patterns. This document focuses on four major designs that are widely deployed by the Aviatrix customers. In all the designs presented here, Aviatrix gateways provide NAT for the egress traffic and FQDN filtering for VPC or VNet egress to the Internet.

In this design the Aviatrix Egress FQDN Filtering gateways are deployed in each application VPC and/or VNET where the egress filtering is required.

Local Egress FQDN Filtering without Aviatrix transit design is deployed by organizations that are providing services to tenan ts residing in those application VPC/VNETs. Usually those tenants are completely isolated from a traffic flow perspective and ha ve unique filtering requirements.

In this design, Aviatrix gateway deployment is automated by the Aviatrix controller, which takes care of necessary route updates in VPC/VNET and manages the lifecycle of entire interaction.

This design is highly available. Aviatrix recommends provisioning at least two gateways per VPC/VNET, each in separate availability zones for service high availability and redundancy. The Aviatrix Egress FQDN Filtering gateways are deployed in Active/Active mode to deliver great optimized throughput performance.

All management is done from the centralized Aviatrix controller. The FQDN rule creation and application is policy based. Organizations can easily make it part of their automation or CI/CD pipeline leveraging the Aviatrix Terraform Provider or API capabilities.

The cost of the Egress FQDN Filtering gateway can be charged-backed or shown-backed to the respective tenants.

In this design the Aviatrix Egress FQDN Filtering gateways are deployed in a central VPC or VNET. This centralized VPC/VNET is called the Transit VPC/VNET. This design provides both scale-up and scale-out depending on throughput requirements. Organizations can increase instance sizes or increase the number of Egress FQDN Filtering gateways directly from the controller.

This design pattern is mainly applicable to following type of businesses:

• Organizations that are already using AWS Transit Gateway and due to internal policies or strategy are not willing or able to migrate to Aviatrix Transit-based design
• Organizations that will only be in AWS cloud. Note that 100% of Aviatrix customers who have believed this, were multi-cloud within 6 months.

The biggest drawback is that this design pattern cannot be repeated across multiple clouds. It is dependent on the native AWS Transit Gateway service.

The Aviatrix controller provides centralized deployment, management and control for AWS Transit Gateway and connected VPCs. All necessary routes and security policies in the application VPC, AWS Transit Gateway, and Egress FQDN Filtering Gateways are automatically programmed, managed and controlled by Aviatrix Controller.

Customers opting for this design should be aware about following:

• The VPC attachments to AWS Transit Gateway are in the clear (not encrypted).
• There are limited monitoring and troubleshooting options provided by AWS for AWS Transit Gateway. Customers looking
  for advance monitoring and troubleshooting should consider the “Centralized Egress with Aviatrix Transit” design to
  leverage Aviatrix enterprise -class visibility.
• The Aviatrix Transit Gateway is a multi-purpose service node that can perform various functions. In this design the Aviatrix
  Transit Gateways are providing high-availability and load balancing for the Aviatrix Egress FQDN Filtering Gateways
• High availability for AWS Transit Gateway is provided by AWS
• This design provides both scale-up and scale-out depending on throughput requirements. Organizations can increase
  instance sizes or increase the number of Egress FQDN Filtering gateways directly from the controller.