A public cloud firewall is the set of network filtering controls your cloud provider gives you, usually applied at the instance and subnet levels. The layers behave differently: some remember connections and some do not. Mixing them up is how teams end up with traffic that works in one place and fails in another.
What does NIST say a firewall is?
NIST SP 800-41 defines firewalls as devices or programs that control the flow of network traffic between networks or hosts that have differing security postures. In a public cloud there is no physical perimeter device you own, but the same job exists: decide which traffic may reach which workload. NIST's recommended default is deny by default, which it says decreases the risk of attack and can reduce the volume of traffic on networks.
How do the two main layers differ?
Take AWS as a documented example. Other providers use different names and details, so check the equivalent documentation for yours.
Per the AWS VPC documentation, security groups are stateful. If you send a request from an instance, the response traffic is allowed in regardless of inbound rules, and responses to allowed inbound traffic may leave regardless of outbound rules. The same page lists traffic that security groups do not filter, including requests to the Amazon DNS service, DHCP and instance metadata.
Network ACLs are stateless. The AWS documentation says information about previously sent or received traffic is not saved, so if you allow specific inbound traffic to a subnet, responses are not automatically allowed. You need a rule for the return path. NACL rules apply as traffic enters and leaves the subnet, not as it moves within one.
Constructed example. A team opens port 443 inbound to a web subnet in the network ACL and in the security group. The site works for some users and fails for others. The cause: the ACL has no outbound rule for the high numbered ports that clients use as the return path. The stateful security group lets the reply through, but the stateless ACL, checking outbound traffic by itself, drops it. A stateless layer needs both directions spelled out.
Why does this matter for security?
- Security groups are the finer, per workload control. Attach them to function, not to everything.
- Network ACLs are a coarse subnet level backstop, good for blocking known bad ranges or protecting a whole tier.
- Neither inspects application content. They decide on addresses, ports and protocols.
- The exceptions matter. Metadata and DNS traffic bypass security group filtering, so protecting them takes other measures such as metadata service hardening and DNS policy. Check your provider's current docs for specifics.
NIST also notes firewalls can only act on traffic they can inspect, so encrypted payloads pass on the basis of their headers. A cloud firewall will not catch a malicious request inside TLS.
How to check or apply this
- List every security group and ACL in each account and which resources use them.
- Remove rules that allow all sources, especially on administrative ports, unless there is a written reason.
- Prefer rules that reference other security groups over IP ranges for traffic between your own tiers.
- Keep ACLs simple and documented, and remember return traffic if they are stateless.
- Turn on flow logs and review rejected and accepted traffic for surprises.
- Treat firewall rules as code: store them in version control, review changes, and test in a non production account.
- Add controls above the network layer, such as a web application firewall or API checks, for application attacks.
How do you review a rule set quickly?
Sort by risk. First rules open to the whole internet. Then rules covering management ports. Then rules with very wide port ranges. Then unused rules, which flow logs can reveal. Delete in that order, with a rollback plan for each change.
Quick check
What does stateful mean for a cloud firewall?
It remembers allowed connections, so reply traffic for an allowed request is permitted automatically. A stateless layer evaluates each packet alone and needs explicit rules for both directions.
Is a cloud firewall enough to protect a web app?
No. It filters by address, port and protocol. Application attacks inside allowed traffic need other controls such as input validation, authorization checks and application layer filtering.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- AWS documentation, Security groups
- AWS documentation, Network ACLs
Last reviewed: 18 October 2026.
