What Is a Cloud Firewall? FWaaS, NACLs, and NGFW

Open one security group rule to 0.0.0.0/0 on port 22 and you have published an SSH endpoint to every scanner on the internet. It is the single most common finding in a cloud security review, and it is a firewall rule. The firewall that allowed it was not a box in a rack. It was a few lines of policy attached to a virtual network, applied to thousands of workloads that spin up and disappear faster than anyone could rack a hardware appliance.

A cloud firewall is firewall capability delivered as a cloud service, filtering traffic to and from cloud workloads and distributed users without a physical appliance. That covers a wide spread of things: the provider-native security group that decides what reaches an EC2 instance, the subnet-level access list that allows or denies before traffic ever reaches the host, the managed next-generation firewall that does application-aware inspection at the network edge, and the firewall-as-a-service that ships as one slice of a SASE platform. This guide is for the people who have to reason about that filtering after an alert fires: SOC analysts reading flow logs, DFIR responders reconstructing what an instance could talk to, and engineers who own the rules. It covers what a cloud firewall is, the types and where each one sits, how it differs from a hardware firewall, stateful versus stateless and Layer 4 versus Layer 7, where it fits zero trust, and how the rules go wrong at scale.

What is a cloud firewall?

A cloud firewall enforces a traffic policy on cloud workloads from within the cloud, as software, rather than from a physical appliance at a network boundary. The decision it makes is the same one any firewall makes: given a packet or a connection, with this source, destination, port, and protocol, is it allowed or denied. What changes in the cloud is everything around that decision. The enforcement point is software-defined and lives in the provider's fabric. It scales with the workloads instead of with a box's throughput rating. And it is configured as policy, usually as code, not as a console session on an appliance.

That shift matters because cloud workloads do not sit still. An auto-scaling group adds ten instances at peak and removes them an hour later. A serverless function exists for 200 milliseconds. A hardware firewall guarding a fixed perimeter has nothing to guard when the thing it protects moves, multiplies, or never had a fixed IP to begin with. A cloud firewall attaches its policy to the workload or the virtual network the workload lives in, so the rule follows the resource regardless of how many copies exist or where they run.

A cloud firewall is also not one product. It is a layer of network security made of several enforcement points that stack: the provider's instance-level and subnet-level controls do the cheap, fast Layer 3 and Layer 4 filtering, and a next-generation firewall or a firewall-as-a-service adds application awareness and inspection on top. Calling all of them "the firewall" is fine in conversation and wrong in an investigation, where you need to know exactly which control allowed the traffic you are looking at.

Types of cloud firewall and where they sit

Cloud firewalls fall into three layers by where they enforce and what they understand. Most real environments run all three at once.

Cloud-native firewall controls are the filtering the cloud provider builds into the virtual network itself, at no extra charge. They operate at Layer 3 and Layer 4: source, destination, port, protocol. They are the first and last thing every packet passes, and they are where most cloud firewall mistakes happen because they are easy to set too broadly.

• AWS security groups attach to an instance's network interface and are stateful: if you allow an inbound request, the response is allowed back automatically regardless of outbound rules. Security groups are allow-only. There is no deny rule, so anything not explicitly permitted is denied by default.
• AWS network ACLs (NACLs) sit at the subnet boundary and are stateless: a response is not automatically permitted, so you size both directions. NACLs support both allow and deny rules, numbered from 1 to 32766 and evaluated in order, lowest number first, stopping at the first match.
• Azure network security groups (NSGs) filter traffic to and from Azure resources in a virtual network with allow and deny rules ordered by priority (100 to 4096, lower number wins). NSGs are stateful through a flow record, so a response to an allowed flow does not need its own rule.
• GCP VPC firewall rules are defined at the network level but enforced per instance as a distributed firewall, and are stateful via connection tracking. A VPC network has an implied deny for ingress and an implied allow for egress until you write rules.

Cloud next-generation firewalls (NGFW) are managed services that add Layer 7 application awareness on top of port-and-protocol filtering: intrusion prevention, TLS inspection, URL and application identification, and threat intelligence. Azure Firewall is one example, a managed stateful service that the provider scales for you. An NGFW is what you reach for when "allow TCP 443" is not enough and you need to know whether that 443 traffic is a real API call or an attacker tunneling out.

Firewall-as-a-service (FWaaS) moves the firewall off any single network entirely and delivers it from the provider's cloud to wherever the users and workloads are. FWaaS usually arrives as one component of a SASE or SSE platform. Per Gartner, Secure Access Service Edge converges networking and security functions, SD-WAN, secure web gateway, cloud access security broker (CASB), FWaaS, and zero trust network access, into a single cloud-delivered service. Security Service Edge, defined by Gartner in 2021, is the security-only subset of that. In both, FWaaS supplies the next-generation firewall functionality, including IPS and web filtering, without the capital cost of an appliance. It is the model that fits a workforce that is everywhere and an application estate that spans multiple clouds.

Cloud firewall vs traditional hardware firewall

The traditional firewall is a physical or virtual appliance at a fixed network boundary. You size it for peak throughput, rack it, cable it, and route traffic through it. It works well when the thing it protects is a stable data center with a clear inside and outside. It works badly when the thing it protects is elastic, distributed, and has no single perimeter, which is to say, the cloud.

The differences are not cosmetic. They change how you operate the control.

The practical consequence for a defender is where the evidence lives. A hardware firewall logs to its own management plane; you go to the box. A cloud firewall logs to the cloud's logging service, VPC flow logs, NSG flow logs, the provider's firewall logs, alongside the rest of your cloud telemetry. That is better for correlation and worse for anyone who assumed the perimeter still exists. There is no choke point to tap. The filtering is distributed across the fabric, so reconstructing what a workload could reach means reading policy, not sniffing a wire.

Stateful vs stateless, Layer 4 vs Layer 7

Two distinctions decide what a given cloud firewall control can actually do. Mixing them up is how reviews miss real exposure.

Stateful versus stateless is about whether the firewall remembers connections. A stateful control tracks the state of a connection, so when it allows an outbound request it automatically allows the matching return traffic. AWS security groups, Azure NSGs, and GCP VPC firewall rules are all stateful. A stateless control has no memory: each packet is judged on its own, so you must write rules for both directions of a conversation. AWS NACLs are stateless, which is exactly why a NACL that allows inbound web traffic but forgets the ephemeral-port return range silently breaks the response. Stateless controls are simpler and faster but easier to misconfigure, because the rule that looks complete only covers half the conversation.

Layer 4 versus Layer 7 is about how deep the firewall looks. A Layer 4 control sees source, destination, port, and protocol, and nothing more. It can allow port 443 or block port 23, but it cannot tell what is inside the connection. Security groups, NACLs, NSGs, and VPC firewall rules are Layer 4 controls. A Layer 7 control, the next-generation firewall, reads the application content: it identifies the application, inspects HTTP, can decrypt and examine TLS, runs an intrusion prevention system against the payload, and matches threat intelligence. That depth is what catches an attacker who is using an allowed port for something it was never meant to carry. It costs more, adds latency, and requires somewhere to terminate TLS, so you apply it where the traffic warrants the scrutiny rather than everywhere.

The two distinctions are independent. A control can be stateful and Layer 4 (a security group), stateless and Layer 4 (a NACL), or stateful and Layer 7 (an NGFW). When you read a cloud firewall finding, place the control on both axes first. It tells you what the control could have seen and what it never could.

How cloud firewalls fit cloud architecture and zero trust

The layers are meant to nest. NACLs do coarse allow and deny at the subnet edge. Security groups do fine-grained allow at each instance. An NGFW or FWaaS does deep inspection where it earns its keep. Defense in depth here is literal: a packet to a database tier passes the subnet NACL, then the instance security group, and only the traffic that clears both reaches the host. Each layer is a separate place to deny, and a separate place to log.

This maps directly onto zero trust. Zero trust replaces "trusted because it is inside the network" with "verified on every request," and a cloud firewall is one of the mechanisms that enforces it. Microsegmentation, isolating workloads so a compromise in one cannot freely reach the next, is built from exactly these controls: a security group per tier that allows only the specific flows that tier needs, so an attacker who lands on a web server cannot pivot to the database just because both live in the same VPC. The firewall stops being a perimeter and becomes a per-workload identity-aware gate. FWaaS in a SASE design takes this further, evaluating the user and device on every connection rather than trusting a network location.

For a defender, this is the payoff and the cost in one. A properly segmented cloud environment confines a breach and logs every denied attempt to cross a boundary, which is excellent telemetry. The same design means there is no single perimeter log to read; the evidence is spread across every layer's policy and logs, and reconstructing the blast radius means assembling all of them.

Managing cloud firewall rules at scale, and where they fail

A hardware firewall has one rule set on one box. A cloud estate has security groups on thousands of workloads, NACLs on every subnet, NSGs across every virtual network, and an NGFW or FWaaS on top, often across more than one cloud provider. Managing that by hand does not scale, and the failures are predictable.

The discipline that keeps it sane is infrastructure as code. Define firewall rules in Terraform, CloudFormation, or the provider's equivalent, review them like any other code, and apply them through a pipeline. The rule set becomes versioned, auditable, and consistent across accounts, and a drift check can flag any rule changed outside the pipeline. Centralized policy tooling, AWS Firewall Manager, Azure Virtual Network Manager, or third-party posture management, enforces a baseline across the whole estate so one team cannot quietly open a hole.

The failure modes recur in every cloud review:

• Overly-open rules. The classic is an inbound rule allowing 0.0.0.0/0 to a sensitive port: SSH on 22, RDP on 3389, a database port, or a management interface. It publishes the service to the entire internet. AWS itself flags 0.0.0.0/0 on SSH and RDP as a practice to authorize only to specific IP ranges. Open management ports are a leading category of AWS misconfigurations and a routine initial-access vector.
• Stateless rules that forget the return path. A NACL that allows inbound traffic but not the ephemeral-port responses, or the reverse, breaks connectivity or, worse, gets "fixed" by widening it to allow everything.
• Rule sprawl and dead rules. Thousands of rules accumulate, nobody removes the ones for decommissioned workloads, and the effective policy becomes impossible to reason about. Dead allow rules are standing risk.
• Default-allow egress left wide. Outbound is the direction teams forget. A workload with unrestricted egress is a workload that can exfiltrate data or beacon to command and control without the firewall objecting. Egress filtering is as much a control as ingress.
• Multi-cloud inconsistency. Security groups, NSGs, and VPC firewall rules differ in defaults, statefulness, and syntax. A policy that is tight in AWS can have an equivalent gap in Azure or GCP because the model is not identical.

The thread is that none of these are exotic. They are firewall rules set too broadly, never revisited, or inconsistent across clouds, which is the cloud version of the same access mistakes that have always turned a small intrusion into a large one.

The bottom line

A cloud firewall is firewall capability delivered as a cloud service: software-defined, elastic, attached to networks and workloads instead of cabled into a perimeter. It comes in three layers that stack. Cloud-native controls (security groups, NACLs, Azure NSGs, GCP VPC firewall rules) do fast Layer 3 and Layer 4 filtering. A next-generation firewall adds Layer 7 inspection where it is worth the cost. FWaaS delivers the firewall from the cloud to wherever the work is, usually as part of SASE or SSE.

Two distinctions decide what each control can do: stateful versus stateless, and Layer 4 versus Layer 7. Place a control on both axes and you know what it could have seen. The control layers nest into the microsegmentation that zero trust runs on, and they are managed as code because thousands of rules across multiple clouds cannot be managed by hand. The failures are not exotic: an open 0.0.0.0/0 rule, a stateless rule that forgets the return path, unrestricted egress, dead rules nobody removed. For a defender, the same policy that confines a breach is the evidence that explains it, provided you know which of the layers allowed the traffic you are looking at.