Security Groups and NACLs

Security groups act as virtual firewalls at the instance (ENI) level. They are stateful, meaning if you allow inbound traffic on a port, the response traffic is automatically permitted outbound regardless of outbound rules. This simplifies rule management significantly — you only need to define what traffic to allow, and return traffic is handled implicitly. Security groups support only allow rules; there is no deny mechanism. To block traffic, you rely on the absence of an allow rule or use NACLs for explicit denials.

Security group rules specify protocol (TCP, UDP, ICMP), port range, and source or destination. Sources and destinations can reference CIDR blocks, other security groups, or AWS service prefixes. Referencing another security group as a source is powerful — for example, allowing port 443 only from a load balancer's security group rather than a broad CIDR range. This creates dynamic, self-documenting access control. Outbound rules default to allowing all traffic (0.0.0.0/0 on all ports), which many hardening guides recommend restricting.

Common patterns include: web tier security groups allowing 80/443 from 0.0.0.0/0 and 22 from a bastion CIDR; application tier groups allowing only the application port from the web tier security group; and database groups allowing only 3306 (MySQL) or 5432 (PostgreSQL) from the application tier security group. Each security group can reference up to 5 security groups as sources or destinations, and you can assign up to 5 security groups to a single ENI.

Security groups operate at layer 4 (transport). For layer 7 filtering, consider Web Application Firewall (WAF) integration. Security groups are associated with VPCs and cannot span VPCs — for cross-VPC filtering, use VPC peering or transit gateway with separate security group configurations. Changes to security group rules take effect immediately without requiring instance restarts or causing downtime.

Network ACLs (NACLs) operate at the subnet level and are stateless. Stateless means each request and response is evaluated independently — if you allow inbound HTTP, you must also explicitly allow outbound HTTP on the ephemeral port range. This is the fundamental difference from security groups and makes NACLs more complex to manage. NACLs support both allow and deny rules, which is useful for explicitly blocking known bad IP ranges or traffic patterns that you want to reject before reaching instances.

NACL rules are evaluated in order by rule number, starting from the lowest. The first matching rule determines whether traffic is allowed or denied. If no rule matches, the default NACL denies all traffic. AWS provides a default NACL that allows all inbound and all outbound traffic — this is intentionally permissive. Custom NACLs start with a deny-all baseline. This rule-number ordering is critical: a deny rule at number 100 will override an allow rule at number 200, even if the allow rule matches more specific traffic.

A practical example: you might create a custom NACL that allows inbound SSH (port 22) from your corporate CIDR at rule 100, allows HTTP/HTTPS at rules 200-300, allows ephemeral ports (1024-65535) for return traffic at rule 400, and has an explicit deny-all at rule 999. The ephemeral port allowance is essential because NACLs are stateless — without it, server responses to client requests would be dropped.

NACLs apply to all instances in their associated subnet. A subnet can only have one NACL, but one NACL can be associated with multiple subnets. Use NACLs as a coarse-grained defense layer (blocking entire IP ranges, enforcing compliance rules) and security groups as fine-grained, instance-level controls. For most architectures, security groups handle primary access control and NACLs serve as an additional safety net or for explicit deny rules that security groups cannot express.