Security Groups vs NACLs Explained: Cloud Firewalls for Cloud+

Security groups are the instance-level firewall in cloud platforms. They are compared constantly with network access control lists, and the comparison is one of the most reliably examined points in cloud networking.

The core distinction: stateful versus stateless

Security groups are stateful. If you allow inbound traffic on port 443, the response is automatically permitted outbound. The platform tracks the connection and allows return traffic without a matching rule.

Network ACLs are stateless. Every packet is evaluated independently. Allowing inbound 443 does not permit the response — you must also allow the outbound traffic, and because responses come from ephemeral ports you generally have to allow a wide ephemeral range outbound.

That single difference explains most misconfigurations. A NACL that permits inbound HTTPS but nothing outbound produces a connection that establishes and then appears to hang, and the ephemeral port range is the thing people forget.

The full comparison

Aspect	Security group	Network ACL
Applies to	Instance / network interface	Subnet
State	Stateful	Stateless
Rule types	Allow only	Allow and deny
Evaluation	All rules; any match permits	In numbered order; first match wins
Default	Deny all inbound, allow all outbound	Varies; default permits, custom denies
Rule targets	CIDR or another security group	CIDR only

Allow-only, and why it matters

Security groups cannot express a deny rule. Everything not explicitly allowed is implicitly denied, and rules are evaluated as a union — if any rule permits the traffic, it passes.

The consequence is that you cannot use a security group to block one specific address while allowing a broader range. To carve out an exception you need a NACL, which supports explicit deny.

That is the clearest answer to "when would you use a NACL rather than a security group": blocking a specific IP or range, and applying a coarse control across an entire subnet.

Referencing other security groups

The feature that makes security groups genuinely better than IP-based rules, and a likely exam point.

A rule can permit traffic from another security group rather than a CIDR block. A database security group can allow port 3306 from the web-tier security group, and every instance in that group is permitted regardless of its IP address.

This survives autoscaling. Instances come and go with new addresses, and the rule never changes. Writing the same policy with CIDR blocks would require updating rules every time the fleet scales.

Layering them

They are not alternatives; they apply in sequence. Inbound traffic passes the NACL at the subnet boundary first, then the security group at the interface. Both must permit it.

The usual pattern is coarse subnet-level control in the NACL — blocking known-bad ranges, enforcing broad segmentation — and fine-grained per-workload control in security groups. Defence in depth, with the specific rules where they are easiest to reason about.

Common mistakes

0.0.0.0/0 on management ports. SSH or RDP open to the internet is the most exploited cloud misconfiguration there is. Use a bastion host, a VPN or a managed session service instead.

Forgetting ephemeral ports in NACLs, producing hanging connections.

Over-broad rules that accumulate. Rules are added during troubleshooting and never removed. Review them.

Assuming a security group protects between instances in the same group. It does not, unless the group references itself — traffic between members is not automatically allowed, and equally is not automatically inspected.

Relying on these alone. Neither inspects payload. They are layer 3 and 4 controls; application-layer attacks need a WAF.

Where they sit in the shared responsibility model

Worth stating plainly: the provider supplies the capability, and configuring it is the customer's responsibility. A security group left wide open is a customer misconfiguration, not a provider failure — which is the category that accounts for the large majority of cloud data exposure.

What to remember

Security groups are stateful, instance-level and allow-only. NACLs are stateless, subnet-level, support deny, and evaluate rules in numbered order with first match winning. Stateless means return traffic needs its own rule, including ephemeral ports. Security groups can reference other security groups, which is what makes them work with autoscaling. Both apply, so both must permit the traffic.

Related reading: The shared responsibility model · Web application firewalls · RFC 1918 private ranges