Cloud Networking
Intermediate 15 min read Cloud Networking

Security Groups and NACLs

The two firewall layers and their temperaments

Security groups filter at the resource; NACLs filter at the subnet. Stateful vs stateless, allow vs deny, evaluation order — knowing these decides whether traffic flows or mysteriously times out.

security groupNACLNSGfirewall rulesstatefulstateless
Prerequisites: Route Tables and Gateways
Before we start

What you will learn

  • Explain stateful vs stateless filtering
  • Layer SGs/NSGs with NACLs correctly
  • Debug rules with effective-rule tooling
In 60 seconds

Security groups (AWS) attach to resources and are stateful (responses auto-allowed). NACLs attach to subnets, are stateless and support explicit deny. Azure NSGs and GCP firewall rules add their own semantics.

Introduction

What is this?

AWS security groups are stateful allow-rules attached to an interface/instance (no explicit deny; default-deny all not explicitly allowed). NACLs attach to a subnet and evaluate each packet statelessly against an ordered number list with allow AND deny; responses to allowed outbound still need their own inbound rule. Azure's NSG is stateful and supports deny, attached to subnet or NIC. GCP firewall rules are VPC-wide, priority-ordered, and use target tags.

Motivation

Why do you need it?

  • The security group is the primary 'who may talk to this app' control — one per tier.
  • NACLs catch subnet-wide egress abuse that per-instance rules miss.
  • Misplaced stateless NACL rules are the #1 'my app is timing out mysteriously' cause.
  • Effective-rule tooling shows the actual deny a resource sees.
Think about it

Mental model

Imagine

Apartment locks and lobby guards

Think of

Security groups and NACLs

Each apartment door (security group) checks who enters that flat and remembers who it let out (stateful). The lobby guard (NACL) checks every face independently with no memory (stateless), applying building-wide rules at the floor.

Mechanics

How it works

  • Security group: evaluate inbound then outbound; stateful return-traffic allowance; no explicit deny.
  • NACL: evaluate each packet against ascending rule numbers; first match wins; stateless.
  • Azure NSG: stateful, Allow/Deny priorities, attach to subnet and NIC (both apply).
  • GCP firewall: VPC-wide priority-ordered rules with target tags and service accounts.
  • Effective checks: AWS reachability analyzer, Azure NSG flow logs/effective rules, GCP network topology.

Packet evaluation order across layers.

Packet enters
NACL
Security group
Listener
Real world

In production

  • An app tier's SG allows 8080 from the ALB SG only; the DB SG allows 5432 from the app SG.
  • A NACL on an egress-heavy subnet denies outbound traffic to port 25 while individual SGs stay open.
  • Azure NSGs at the NIC carve per-app rules while subnet NSGs deny internet ingress broadly.
Guidelines

Best practices

  • Reference SGs by other SGs (not bare CIDRs) so tier relationships stay readable.
  • Default-deny inbound; scope outbound to what the workload needs.
  • Keep NACL rules coarse and SR-ID stable; combine with SG for evaluation order advantage.
  • Enable flow logs for visibility before you need forensics.
Watch out

Common mistakes

  • Putting fine-grained rules in NACLs, then chasing stateless return-rule bugs.
  • Using bare 0.0.0.0/0 for 'simpler' rules.
  • Allowing 22/3389 from anywhere.
  • Not testing rules with both directions — stateless surprise.
Root cause analysis

Common issues

Error
Connection times out but SG allows the port
Root cause

Stateless NACL lacks the outbound/inbound response rule

Fix

Add ephemeral-port inbound (TCP 1024-65535) on the NACL and matching outbound.

Error
Instances in the same subnet can't ping each other
Root cause

NACL or SG missing ICMP rules

Fix

Allow ICMP in both directions, or verify the SG has an ICMP rule.

When things break

Debugging tips

  • Timeout = network drop (check NACL/SG/route); reset = app refused. Distinguish them.
  • Use effective rules / reachability analyzer to see the applied state, not the config.
  • For stateless NACL, remember inbound and outbound are independent; log violations.
  • Check SG references: the ALB SG must allow the app's port, and the app SG must allow ALB.
Interviews

Interview checkpoint

Practice

Hands-on lab

Model SG and NACL Evaluation as a Decision Table
25 min · intermediate
In progress
Objectives
  • Simulate stateful vs stateless filtering
  • Trace a request through NACL then security group
  • Spot the classic stateless return-rule bug

Model SG and NACL Evaluation as a Decision Table

25 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

If a connection times out but the security group allows the port, what's a plausible cause?

2

NACLs are stateful: allowed outbound automatically permits the response inbound.

Go deeper

Official documentation

AWS — Security groups
docs
AWS — NACLs
docs
Azure — NSG overview
docs