In this blog article, I will show you a solution for filtering outbound traffic in AWS at low cost. There are a variety of methods to filter outbound traffic for AWS workloads. I will introduce and compare some of them. At the end, I will explain a cost-effective solution and also provide it as an Infrastructure-as-Code template.
What is outbound traffic filtering?
Outbound traffic filtering refers to the process by which outbound traffic from a network is monitored and regulated. Especially in cloud environments such as AWS, this is an important security measure to control which data is allowed to leave the network and which is not.
In detail, outbound traffic filtering can include the following:
- Blocking of data traffic: Unauthorized or unwanted data packets are prevented from leaving the network. This could be traffic to known malicious domains or IPs, for example.
- Regulation of data flow: Restrictions on bandwidth or the type of traffic (such as certain protocols or ports) to optimize the use of network resources.
- Monitoring and logging: Recording outbound traffic to detect unusual activity and respond to security incidents.
Which network architecture is frequently seen?
In many AWS environments, especially smaller ones, it is often observed that each VPC has its own NAT gateway. These gateways allow EC2 instances located in private subnets to access the internet. The Security Groups and Network Access Control Lists (NACLs) are usually only configured for inbound traffic, while outbound traffic often remains unrestricted.
But why is this the case? In my opinion, it is because the security groups and NACLs can only be used to restrict IP addresses and ports, but not domains. The AWS NAT gateway also offers no option for domain filtering.
As a result, it is not feasible with this standard network architecture in smaller environments that the EC2 instances in the private subnets can only access allowed domains such as amazonaws.com and susecloud.net, while all other outbound traffic is blocked.
Of course, someone could come up with the idea of simply allowing the IP addresses of amazonaws.com and susecloud.net in a NACL and blocking all others. However, this is not a maintainable solution as the IP addresses of the domains can change at any time.
How can outbound filtering for domains be implemented?
I would like to discuss the following three possibilities:
- Route 53 Resolver DNS Firewall
- AWS Network Firewall
- Squid Proxy on EC2
Route 53 Resolver DNS Firewall
If Route 53 is used for DNS resolution - which is definitely recommended - it is possible to use the Route 53 Resolver DNS Firewall. This is a firewall managed by AWS that can restrict DNS resolution. For example, DNS resolution could be allowed only for amazonaws.com and susecloud.net, while all other domains are not resolved. This means that the EC2 instance will not receive an IP address from Route 53 in response when trying to access microsoft.com, for example. This would restrict outbound traffic: EC2 instances would no longer be able to surf the Internet at will or access other domains that are not on the Allow list. This solution is also very cost-effective at USD 0.0005 per month per domain and USD 0.60 per million requests processed. For smaller environments, the cost is less than 1 USD per month.
However, there is a catch: the EC2 instances still have the option of processing all outbound traffic directly via the IP addresses and creating their own host entries in /etc/hosts or simply entering a different DNS server and thus no longer using Route 53.
AWS Network Firewall
The AWS Network Firewall is inserted as an intermediate layer through a dedicated subnet between the NAT gateway and the Internet gateway. It offers a variety of advanced features, including stateful and stateless rule processing, Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), inbound and outbound traffic filtering, deep packet inspection and compatibility with Suricata, an open source IDS/IPS. It also enables effective domain filtering. The firewall is characterized by its high availability and can be managed directly via the AWS Management Console.
One disadvantage, however, is that it does not fall into the "low budget" category, as the cost per availability zone (AZ) is around USD 288, plus the fees for traffic (USD 65 per TB). For a VPC that includes three availability zones, the monthly costs including traffic can quickly add up to USD 1,000. Despite the many features of the AWS Network Firewall, these costs can be too high for many smaller AWS environments.
Squid Proxy on EC2
Now we come to the cost-efficient solution mentioned at the beginning. One option is to replace the NAT gateways with EC2 instances running the open source software Squid Proxy. This proxy makes it possible for EC2 instances located in a private subnet to communicate only via HTTP and HTTPS and to allowed domains. In addition, a Squid proxy can be set up for each availability zone (AZ), whereby data traffic is redirected via the Squid proxy of another AZ in the event of a failure. Automated patching of Amazon Linux 2 and the Squid proxy is also available.
Although this solution may offer fewer features and is not as highly available or powerful as an AWS Network Firewall, it can still be interesting. By replacing the NAT gateways, which cost around 37 USD per AZ plus 53 USD per 1 TB of traffic, with a solution that is only around 25 USD per AZ, the total cost can be significantly reduced compared to passing traffic through the AWS NAT gateway unfiltered.
The Squid proxy solution can also be implemented centrally in a dedicated AWS Network account to serve as a central internet-outbound for multiple VPCs.
In this GitHub-Repository
, I explain how you can deploy the solution quickly and easily using a CloudFormation template.
Conclusion
Choosing the most suitable solution for your AWS environment depends on a number of factors and should be carefully considered. I look forward to your feedback and am eager to find out if my Squid proxy solution is also used in your AWS environment.
We look forward to a personal exchange on this topic. Follow our author Patrick Zink on LinkedIn and feel free to write to him on the topic.