Skip to main content

How Egress Security Has Evolved and Why You Should Care

In the traditional on-premise era, enterprises owned the underlying infrastructure and had layers of security built into their network architecture. Because of this layered security model, they could centrally define security mechanisms to control the internet egress traffic effectively. However, in public cloud environments, things work differently. The networks and the workloads in public clouds are either directly exposed to the internet, or they are just one hop away from the internet. Hence, it becomes extremely important to look in-depth into how we can effectively secure our workloads and control internet egress traffic.

Typical enterprise cloud deployments often have workloads spread across multiple networks (e.g., VPC/VNET/VCN). Depending upon the cloud platform that you are using, your workloads may have access to the internet by default, or they may be one hop away from the internet. So, if you do not have a robust mechanism to effectively control internet egress traffic, it can have serious repercussions. For example, without an effective egress traffic control mechanism, it may get difficult to keep track of destinations that workloads access on the internet. This information is important and is required to log and document for multiple reasons. One of the most common cases is cloud workloads that are subject to corporate or regulatory compliance, such as PCI or HIPAA. The solution is to secure the applications by controlling what they can access on the internet to prevent unauthorized access or attacks on these applications.

Cloud platforms provide various native cloud constructs, such as NAT gateways, firewall rules, ACLs, etc., to filter the internet egress traffic. But, in most cases, these native constructs are not enough. Most lack the functionality and flexibility that enterprises need to control the internet egress traffic effectively. Examples of this include:

  • Native constructs can only filter traffic based on the IP addresses and not FQDNs. (This is extremely important as IP addresses change all the time, and it becomes difficult to keep track of IP addresses and to build filtering rules based on them.)
  • Lack of support for HTTP/HTTPs and non HTTP/HTTPs based filters.
  • Lack out-of-box integration with logging tools.
  • Can not provide visibility into allowed and denied sessions.
  • Lack of support for egress traffic filtering based on a specified source.
  • Significant manual change management leading to potential human error

Hear discussions with Cloud Teams at Wawa and ReAssure about the challenges they faced using native services that filter on IP address lists that regularly change or open source solutions with limited central control and visibility.

Aviatrix’s Egress Security Solution

The Aviatrix platform offers an egress filtering solution that enterprises can use either in a distributed or a centralized way based on their network design. This solution lets enterprises filter internet-bound traffic across multi-cloud environments based on FQDNs instead of IP addresses. The Aviatrix solution satisfies organizational and regulatory compliance requirements (e.g., PCI, HIPAA, SOC2) for restricting outbound traffic to the internet, while eliminating the complexity of manually creating filtering rules, at an instance level, using constantly changing IP address lists. Powered by the Aviatrix cloud network platform, the solution delivers enterprise-class visibility, centralized control, and multi-cloud optionality.

To learn more about Aviatrix Egress FQDN Filtering tap into our most popular resources, including our Validated Egress Filtering Design Guide for AWS, Azure and GCP. Our video tutorials, solution brief, blog posts, documentation and more are available to help you get up to speed quickly