Security Groups vs. Network ACLs
By the end of this lesson, you'll be able to:
- Recall Security Groups from Module 3 and apply them in a networking, multi-tier context
- Explain what a Network ACL controls and how it differs in scope from a Security Group
- Explain the stateful vs. stateless distinction between the two, and why both exist
Prerequisites: "NAT Concepts for Private Subnets"
Security Groups, briefly revisited in a networking context
Module 3 already covered Security Groups in depth as a virtual firewall for an EC2 instance — this lesson doesn't re-teach that. What's new here is applying the same tool across a multi-tier architecture, the shape this course's Module 6 project builds toward:
- Web tier — inbound HTTPS allowed only from the load balancer (not the entire internet directly).
- App tier — inbound allowed only from the web tier's Security Group.
- Database tier — inbound allowed only from the app tier's Security Group, where the architecture supports referencing another Security Group as the source, per Module 5's warning against broad database access.
Each tier only accepts traffic from the specific tier in front of it — never a wider source than that tier genuinely needs, the same least-privilege reasoning Module 2 and Module 3 already established.
Network ACLs: a second, independent layer, at the subnet level
A Network ACL (NACL) is a different control, operating at the subnet level rather than the individual-resource level a Security Group operates at — every resource inside that subnet is subject to the same NACL rules. Unlike a Security Group, a NACL supports both allow and deny rules explicitly.
Stateful vs. stateless — the practical difference
This is the core distinction: a Security Group is stateful — if inbound traffic is allowed in, the corresponding return traffic is automatically allowed back out, without needing a matching outbound rule written by hand. A NACL is stateless — an allowed inbound request's return traffic is not automatically permitted; it needs its own separate outbound rule, evaluated on its own.
Neither control replaces the other — a request can be evaluated against both a subnet's NACL and a resource's Security Group, and it has to be permitted by both to succeed. This lesson keeps the specific rule-numbering and ordering details NACLs use in the AWS Console out of scope — the concept of "subnet-level, stateless, both allow and deny" is the beginner-level target.
Exercise
A three-tier architecture has a web tier, an app tier, and a database tier. For each tier, describe (in plain English) what its Security Group should allow inbound, referencing the tier in front of it rather than the whole internet. Then explain one thing a Network ACL controls that a Security Group does not.
Show hint
Each tier's inbound rule should reference the specific tier that's supposed to talk to it — not a broader source.
Security Groups vs. Network ACLs Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Security Groups (from Module 3) control traffic at the level of an individual resource and are stateful, automatically allowing return traffic for an allowed request, while Network ACLs control traffic at the level of an entire subnet, are stateless, and support both allow and deny rules — the two are evaluated independently, not as substitutes for each other.