The Missing Tier in AWS Network Controls
In this post explore AWS's egress control options, highlighting gaps and the need for a cost-effective solution.
AWS offers 3 ways of controlling network egress - Network ACLs, Security Groups and the Network Firewall. Security groups rely on static IP addresses, but that isn't how the modern web works. Amazon's Network Firewall is powerful, but at 290-1000+USD per month plus traffic, that option is expensive. Modern applications need a middle ground. Without a middle tier startups and smaller business will continue to deploy insecure networks.
In this post, I want to share some of the alternatives, and what I believe AWS is still missing.
Limitations of Security Groups
Today most SaaS applications sit behind a CDN, such as Amazon Cloudfront or Cloudflare. The pool of potential IPs used by the CDN is huge and constantly changing. This makes it impossible for customers to use security groups to limit network egress to the service. Most teams give up and allow all HTTPS traffic out. If the application is compromised, an attacker can use the lack of egress controls to easily exfiltrate data.
Network Firewall
Amazon's Network Firewall provides greater control over network egress. This includes creating rules based on the SNI header of HTTPS requests. Rather than defining target IP addresses, the rules can be crafted around the target hostnames.
This is the type of egress controls most AWS customers need - even if they don't realise it. Outside of large enterprises, few organisations can justify the expense of using a Network Firewall. The highly available zone isolated configuration is cost prohibitive for anyone but the largest companies.
Some argue that in the cloud, egress controls are overrated, especially for serverless apps. This isn't helped by the fact that by default Amazon configures security groups with open egress. You might think you can ignore egress controls. Reality hits when you're compromised. That's when the layers of the security onion come into play.
The Alternatives
If we don't want to pay hundreds of dollars a month for strict egress controls, what are the options?
You can run a NAT instance instead of a NAT Gateway. On your NAT instance you can configure the firewall to push all HTTPS traffic through a transparent TLS proxy. The proxy would inspect theSNI included in the ClientHello message. While this is relatively cheap, it isn't for the faint hearted or inexperienced. Running this setup reliably requires skill and advanced cloud engineering knowledge.
You might be thinking, but what about Amazon's Route 53 Resolver DNS Firewall? Firstly, this isn't a firewall. It is custom DNS configuration. If you have open egress, nothing stops an attacker using DNS over HTTPS (DoH) for domain name lookups. Route 53 won't prevent connections to arbitrary IP addresses. This "not really a firewall" firewall gets expensive when properly configured.
The Real Solution
The web is constantly evolving. Sites rely on CDNs for security, reliability and performance. Today AWS customers have the choice of using circa 2000 network security controls or paying hundreds of dollars a week for more modern controls. As the use of AI agents rise, implementing tight network controls becomes more important than ever.
AWS should offer a lightweight, managed layer 7 service that filters HTTPS. This new service would restrict egress based on the target host. It would block all outbound traffic by default. Users would configure an allowed list of target domains for HTTPS egress. This service should only charge for traffic processed. A price point well below a NAT Gateway would help drive adoption.
ReInvent 2025 is still 8 months away… 🌊
Shout out to Stephen Sennett for his valuable feedback on this post.
Need Help?
If you want to adopt Proactive Ops, but you're not sure where to start, get in touch! I am happy to help get you.
Proactive Ops is produced on the unceeded territory of the Ngunnawal people. We acknowledge the Traditional Owners and pay respect to Elders past and present.