Security groups vs network ACLs: which one do you need?

Every VPC gives you two firewalls: security groups and network ACLs (NACLs). Both have inbound and outbound rules, both talk about ports and IP ranges, and both can stop traffic reaching your instance. So which one do you use?

Usually both, as two layers. But they behave very differently, and exam questions are built around those differences. Two ideas explain almost all of them:

• A security group protects one network interface (an instance, a load balancer, a database) and remembers connections.
• A network ACL protects a whole subnet and remembers nothing: it judges every packet on its own.

Where each one sits

Picture a request arriving from the internet at an EC2 instance in a public subnet:

1. It enters the VPC through the internet gateway.
2. The network ACL on the subnet checks it on the way into the subnet.
3. The security group on the instance’s network interface checks it on the way into the instance.

The reply takes the same path in reverse. The security group lets it straight out (it remembers the request). The network ACL checks it again, as if it had never seen the conversation.

Security groups: stateful, allow-only

A security group is a set of allow rules attached to a network interface. You can attach more than one; together they allow anything any of them allows.

• Stateful. If a request is allowed in, the response is allowed out automatically, whatever the outbound rules say. The same goes for a request your instance sends out.
• Allow rules only. There’s no “deny” rule. Anything not allowed is refused.
• All rules are evaluated together; order doesn’t matter.
• Sources can be other security groups. “Allow port 5432 from the app servers’ security group” keeps working as app servers come and go, with no IP addresses to update.
• A new security group allows no inbound traffic and all outbound traffic, until you change it. The VPC’s default security group also allows inbound traffic from other members of itself.
• Changes take effect straight away.

Network ACLs: stateless, allow and deny

A network ACL is a numbered list of rules attached to a subnet. Every subnet has exactly one; one network ACL can cover many subnets.

• Stateless. Inbound and outbound are checked separately. If you allow a request in, you must also allow the response out, or it’s dropped.
• Allow and deny rules. So a NACL can block a specific IP address or range, which a security group can’t.
• Rules are checked in order, lowest number first, and the first match wins. A final * rule denies anything that matched nothing. Number rules in steps (100, 200, 300) so you can slot new ones in between.
• The default network ACL that comes with a VPC allows all traffic in and out. A custom network ACL you create denies all traffic until you add rules.

The ephemeral port trap

Because a NACL is stateless, return traffic needs its own rule. A client connecting to your web server on port 443 sends from a random high port, its ephemeral port, and your server’s reply goes back to that port. Your NACL’s outbound rules must allow those ports (AWS suggests 1024–65535 to cover common clients), not just 443.

Forget that and the request gets in, the reply never gets out, and the connection times out.

Side by side

So which one do you need?

• Security groups do the everyday work. Give each tier its own group: the load balancer allows 443 from anywhere, the app servers allow traffic only from the load balancer’s group, the database only from the app servers’ group. Most well-run VPCs barely touch their NACLs.
• Add NACL rules for broad, subnet-wide limits: blocking a known bad IP range, or making sure a private subnet can never talk to certain networks, whatever someone puts in a security group later.
• For web attacks, look higher up. Blocking SQL injection or rate-limiting abusive clients is a job for AWS WAF, not either of these.

When traffic doesn’t get through

“I opened the port in the security group but it still doesn’t work” is a rite of passage. Check:

1. The security group on the destination allows the port and source.
2. The network ACL on both subnets (source and destination) allows the request and the ephemeral-port reply.
3. The route table actually has a route there (an internet gateway or NAT gateway, for example).

VPC Flow Logs record whether traffic was accepted or rejected. An inbound request marked ACCEPT with its reply marked REJECT points straight at a network ACL: a security group would have let the reply out.

Exam traps

• “Block traffic from a specific IP address.” Network ACL deny rule. Security groups have no deny.
• “Allow traffic only from the web tier.” Security group that references the web tier’s security group, not a list of IP addresses.
• “Inbound is allowed but responses never arrive.” A stateless NACL missing an outbound rule for ephemeral ports.
• “Stateful” or “instance level” means security group; “stateless” or “subnet level” means network ACL.
• “A deny rule doesn’t seem to work.” Check the rule numbers: a lower-numbered allow rule matched first.
• “A new custom network ACL and nothing works.” Custom NACLs deny everything until you add rules.

For the full details, see the Amazon VPC User Guide on security groups, network ACLs, comparing the two and VPC Flow Logs.