Amazon Web Services (AWS) offers customers different methods for securing resources in their Amazon Virtual Private Cloud (Amazon VPC) networks. One important security measure is to effectively control inbound (ingress) and outbound (egress) VPC network traffic in order to distinguish between legitimate and illegitimate requests. If internal servers are compromised, they can pose a threat to a larger network of resources—especially when attempting to steal sensitive data or communicate with command and control systems. This webpage provides AWS customers with best practices and common approaches for controlling egress traffic as part of a holistic network security strategy. See VPC Security Capabilities for broader network security recommendations.

When deciding on an appropriate network egress control design, it is important to leverage AWS native routing and firewall capabilities to control network traffic. It is also important to consider how to complement AWS network security features with third-party network gateway and host-based tools. The following sections provide an overview of both AWS and third-party options for controlling VPC egress traffic.

Each VPC has subnet route tables with defined rules that control the flow of traffic out of the VPC, and each individual subnet can have different traffic routing rules. When designing VPC subnets, consider which public-facing EC2 instances require direct access to the internet and which do not. For example, public load balancers, proxy servers, and network gateways require direct internet access while internal load balancers, application servers, and database servers typically do not. Place all EC2 instances that do not require direct access to the internet in private subnets so their egress traffic can be directed to outbound network gateways with routing rules. This reduces a network’s attack surface and allows for additional network controls such as network address translation (NAT) or deep packet inspection.

VPC endpoints are horizontally scaled, redundant, highly available virtual devices that provide private connectivity between EC2 instances in a VPC and another AWS service without imposing availability risks or bandwidth constraints. They enable customers to use routing policies, security groups, endpoint policies, and service-specific policies to control traffic destined for supported AWS services. (VPC endpoints currently support connections with Amazon S3 within the same region, with support for other services coming later.) Route table configuration allows VPC endpoint routes to be made available to specific subnets, while not to others. Security groups allow outbound traffic, such as HTTPS traffic, to be restricted to specific VPC endpoints. Both routing policies and security groups leverage service prefix lists, which logically represent the range of public IP addresses used by the service. Endpoint and service policies enable customers to implement granular service access policies, further restricting which endpoints or service resources may be accessed.

Customer EC2 instances in a private subnet sometimes need to communicate with the public Internet. A NAT device enables this connection, replacing internal servers’ private IP addresses with public IP addresses on the way out of the network, and retranslating response IP addresses on the way back in. AWS offers two types of NAT options: NAT gateways and NAT instances. NAT gateways are AWS managed while customers are responsible for managing NAT instances. NAT gateways provide better availability and bandwidth over individual NAT instances, however customers can leverage multiple NAT instances to increase availability and network performance. Third-party options provide additional network traffic control and monitoring capabilities. See In-Line Gateways below for more information about this option.

Note that security groups cannot be directly associated with a NAT gateway. Instead, customers can use EC2 instance security groups outbound rules to control authorized network destinations or leverage a network ACL associated with the NAT gateway’s subnet to implement subnet-level controls over NAT gateway traffic.

In addition to AWS-provided network controls, AWS partners provide additional tools to control both ingress and egress traffic. These tools provide network security capabilities that are often required by customers looking to perform additional levels of packet inspection for network intrusion detection and prevention (IDP), implement data loss prevention services (DLP), or perform application-level traffic filtering. These solutions can be grouped in to the following categories: host-based solutions, forward proxy servers, and in-line gateways.

A forward proxy server acts as an intermediary for requests from internal users and servers, often caching content to speed up subsequent requests. Companies usually implement proxy solutions to provide URL and web content filtering, IDS/IPS, data loss prevention, monitoring, and advanced threat protection. AWS customers often use a VPN or AWS Direct Connect connection to leverage existing corporate proxy server infrastructure, or build a forward proxy farm on AWS using software such as Squid proxy servers with internal Elastic Load Balancing (ELB).

Web proxy servers are the most common type of proxy server used today. Web proxies control HTTP and HTTPS traffic and have ubiquitous support from web clients such as web browsers, web command line tools, programming tools, and web application servers. SOCKS proxy servers, although less common than web proxies, leverage custom SOCKS proxy clients to control any type of IP network traffic. In either case, each EC2 instance must be configured (typically through initial instance bootstrapping or application deployment and configuration) to leverage the proxy solution at either the OS or application level.

In-line gateways force egress traffic through predefined network choke-points, which provide additional security capabilities but can also introduce potential single points of failure or bandwidth bottlenecks into the network. Therefore, it is important to design gateway-based solutions that leverage multiple subnets and Availability Zones (AZs), Auto Recovery for EC2, or availability monitoring and recovery scripts.

High Availability Options

VPC subnets support a single default route destination, which means customers can only scale in-line gateways horizontally by adding additional subnets, each supported by a different EC2 instance gateway appliance. AWS recommends, at a minimum, implementing one in-line gateway per AZ to provide additional availability and capacity, and independently control traffic from each AZ. If additional outbound capacity is needed, create additional private subnets with a default outbound route directing traffic to additional in-line gateways.

Physical hardware failures or software issues within the virtual machine hosting the gateway appliance can affect network egress availability for the individual subnet that it supports. For critical infrastructure components such as egress gateways, use Auto Recovery to automatically recover EC2 instances in the event of underlying hardware failures or a non-responsive OS. Additionally, consider incorporating AWS network APIs into custom network monitoring scripts to automatically recover failed gateway appliances or redirect routing paths to healthy instances. We also recommend checking with the appliance provider for any high availability mechanisms they have built for their product; you may not need to write your own custom monitoring scripts.

Multi-VPC Design Considerations

As a company expands its deployment to multiple VPCs, it must consider traffic latency, performance, and overall cost when implementing egress controls. It can be complex and cost prohibitive to deploy in-line gateways for each subnet or VPC. An alternative solution is to route outbound network traffic from all VPCs in the same AWS Region to a transit egress VPC hosting redundant security appliances. This method creates a regional hub-and-spoke network topology that uses virtual gateways (VGWs) or EC2 network appliances in each VPC to forward traffic to regional egress gateways. This design minimizes the total number of in-line security appliances and enables centralized management and operation of these devices. AWS Marketplace partners, including Aviatrix, Check Point, FortiNet, Juniper, Palo Alto Networks, and Sophos offer different solutions for implementing this design. For additional guidance on implementing hub-and-spoke networks on AWS, see AWS Global Transit Network.