AWS offers a lot of firewall solutions, and now a new one. Here’s how to make sense of all these firewalls.

In November 2020, AWS announced the “AWS Network Firewall.” This proliferation of firewalls gets confusing, so I wrote this post to sort everything out.

We start with a comparison of AWS firewalls and similar network defense systems, the use cases for each one along with what attacks they protect against, and what rules they use for detecting threats.

We’ll follow up with a story to illustrate the use cases you might encounter as your application scales and its financial importance grows.

When to use each AWS firewall service

We start at the bottom, from the lowest-level infrastructure and work upward since, in general, that is how you should also build your defenses.

Security Groups

Security Groups protect Elastic Network Interfaces, generally attached to EC2 instances, but also to other services like RDS or Lambda in a VPC. They can protect, for example, against unauthorized SSH connections. They block access based on source and destination ports and IP ranges. You should define Security Groups, allowing minimal necessary access, whenever you create instances.

Network ACLs

Network ACLs protect subnets, for example, against unauthorized connections to a database from anywhere by the backend server. Like Security Groups, they block access based on source and destination ports and IP ranges. You should define NACLs when you partition your systems in subnets by function, which you should do when you define your tiers. With NACLs, subsystems are allowed to access others according to their function in the architecture, so long as the subnets have been accordingly defined.

Kubernetes Network Policies

Kubernetes Network Policies protect applications in Elastic Kubernetes Service. Like Security Groups and NACLs, they block access based on source and destination ports and IP ranges. But they also can use Kubernetes labels, allowing functional access control according to fine-grained units. You should define these Network Policies when creating any but the simplest set of Kubernetes services.

Network Firewalls

Network Firewalls protect all the networks of an organization, for example against Trojan bots that exfiltrate data. They block access based on standard downloadable rulesets. As with Security Groups and NACLs, these rulesets include signatures defined by source and destination ports and IP ranges. In addition, they can also use deep packet inspection and so block based on domains, URLs, and protocols (so long as TLS is terminated before the Network Firewall). You should add Network Firewalls when you need consistent policies for Intrusion Detection and Protection across the organization.

AWS Shield Standard

AWS Shield Standard protects web apps and APIs against DDOS. It blocks access based on HTTP(S) traffic patterns, including the frequency and source of invocations. You should add AWS Shield Standard to any public web app with business significance. (It’s free, and enabled for some resources by default.)

AWS Shield Advanced

AWS Shield Advanced does the same as Standard, but with more monitoring, reimbursement for attack costs, and, most importantly, a skilled human operations team. You should consider AWS Shield Advanced for any business-critical web apps, taking into account the expense of Advanced vs Standard.

Web Application Firewall

Web Application Firewall (WAF) protects web apps against Cross-Site Scripting, SQL Injection, Insecure Direct Object References, and/or others in the OWASP list. It detects and blocks access based on the signatures defined by patterns in the headers or body of an HTTP(s) request. You should consider WAF for protection while you fix known application vulnerabilities, or if you are using vulnerable applications whose code is out of your control, or if you believe your code has minimal vulnerabilities but want extra protection just to be sure.

A Tale of Firewalls

To show how you adopt different firewalls as the application grows, here is a tale of use cases.

Pat just started building a web application for her startup. She’s a bit old-fashioned, and so decides to use a single EC2 instance for a simple proof of concept. She sets up a security group as an instance-level firewall, allowing access to the instance only on ports 80 and 443, so HTTP/S requests reach it; and on port 22 for her office IP range, so she can administer it by SSH. She has now protected the instance from attacker access on ports other than 80 or 443; and she has blocked any SSH access from unauthorized IP addresses.

Her proof of concept is already secure at this early stage against many types of attacks, but as she adds more complexity to the network and the application, and as the application gains more financial significance, she will need more defenses.

To go beyond that simple proof of concept and on to a robust n-tier application, she sets up a database and separates the front-end and back-end servers. Each tier gets a separate subnet. She configures Network Access Control Lists (NACLs) as a subnet entrypoint firewall, allowing HTTP/S requests to access the frontend subnet, the frontend to access the backend, the backend to access the database, and nothing more.

Scalability has its limits; and even if the application keeps going under load, a DDOS attack would run up expenses. So she introduces AWS Shield Standard, which is free. This is adequate DDOS protection. Much later, when the application has scaled tremendously and is a major revenue source, the expense of AWS Shield Advanced might be worth it. The Advanced product offers, most importantly a skilled operations team from AWS — a reminder for the security space in general, that the threat is smart people finding new ways to attack you, and so you need smart people finding the right way to defend you at all times.

Pat ports the application to Elastic Kubernetes Service for ease of orchestration and management. Here, the Kubernetes Network Policy defines restrictions on what Kubernetes services can contact other services, allowing finer-grained functional access control than what could be done with subnets.

Penetration testing of the application shows a variety of vulnerabilities from the OWASP list, including Insecure Direct Object References, Cross Site Scripting, and SQL Injection. So, Pat and the development team add AWS Web Application Firewall, while also prioritizing the necessary fixes and long-term security effort in the application development team.

Finally, the big day comes: Exit!, and the startup is acquired by a large corporation. Now, the application becomes part of a larger application portfolio, and the network becomes part of a complex infrastructure, with multiple VPCs and on-premises networks managed by different organizational units. To keep all this protected, the corporation has specified consistent network policies across the organization. The AWS Network Firewall is added to restrict access by standard defensive rulesets defined by ports, IP addresses, domains, URLs, and protocols. This protects not only against the same attacks as Security Groups and Network ACLs, but also detects and prevents intrusion by trojan bots or human hackers that run code in the network and corrupt or exfiltrate data.

Big organizations require a centralized approach to manage their resources and policies — a system is only as strong as the weakest link. The AWS Firewall Manager is introduced to manage Network Firewalls, WAFs, and other systems, keeping a consistent protection across the organization.

I hope that that sorts out the many firewalls of AWS. If you have questions, feel free to ask in the comments.

— —

Thank you to my colleague Dr. Artem Shchodro for your valuable comments.