security groups, NACLs, and network firewall, know the difference

three layers of aws network control that most people never touch

if you run anything in aws, you've opened up a security group. you added port 443, maybe port 22 from your ip, called it a day and moved on. that's normal. what's not normal is stopping there and assuming your network is "secured" because one layer looks tidy. aws actually gives you three separate controls that stack on top of each other, and most folks only ever configure one of them. the other two sit there, wide open, doing nothing, waiting to either save you or embarrass you.

this post is about knowing what each layer actually does, so you can go check your own setup instead of trusting the green checkmarks in the console.

security groups: your first and most familiar layer

security groups are stateful and attached to the resource itself, an ec2 instance, an rds database, a load balancer. stateful means if you allow inbound traffic on a port, the response traffic is automatically allowed back out, you don't have to think about return paths. security groups are also allow-only, there's no explicit "deny" rule. everything not allowed is implicitly denied.

this is the layer almost everyone configures, and for good reason, it's the most direct way to control what talks to your app. the mistake defenders make isn't ignoring security groups, it's treating them as the only control that matters. a security group locked down to your app's needs is great, but it doesn't stop lateral movement inside the subnet, and it does nothing about traffic patterns across your whole vpc.

go check yours right now. look for security groups with 0.0.0.0/0 on ports that have no business being public, rdp, ssh, database ports. that's the first thing an auditor checks and the first thing an attacker scans for.

nacls: the coarse guardrail people forget exists

network access control lists sit at the subnet level, not the resource level, and they are stateless. stateless means inbound and outbound rules are evaluated independently, if you allow inbound traffic on a port, you also have to explicitly allow the outbound response, nothing is remembered for you. nacls also support both allow and deny rules, evaluated in numbered order, first match wins.

because nacls apply to the entire subnet, they're a blunt instrument. that's actually their strength. use them as a coarse guardrail, a subnet-wide rule that says "nothing from this ip range talks to anything in this subnet, period," regardless of what any individual security group says. this is useful for blocking a known-bad range, segmenting a subnet that should never reach the internet, or adding a hard backstop in case someone misconfigures a security group later.

most aws accounts still have the default nacl, which allows all traffic in and out. that's fine as a starting point, but if you've never touched it, you don't have a subnet-level backstop, you just have a formality.

network firewall: the layer for deep inspection and egress control

aws network firewall operates at the vpc level and is stateful, but it's a different kind of stateful than security groups. it uses suricata-compatible rules, which means you can do actual packet inspection, not just "allow port 443," but "allow port 443 except to this list of known malicious domains" or "alert if traffic matches this ids signature."

this is the layer for two things most people skip entirely: intrusion detection and egress filtering. security groups and nacls control who can come in and, loosely, who can go out, but they don't inspect what's actually inside that traffic. network firewall does. it's how you catch a compromised instance trying to phone home to a c2 server, or beaconing out to a domain that showed up on a threat feed yesterday.

if you're only using security groups, you have zero visibility into outbound behavior. that's the layer attackers count on being unmonitored.

how these layers actually stack up

traffic hitting your instance passes through the nacl first, subnet-wide, stateless, coarse. then it hits the security group, resource-level, stateful, precise. if you've deployed network firewall, that traffic can also route through it for inspection before or after those two, depending on how you've architected your vpc.

none of these replace each other. security groups without nacls means no subnet-level backstop. nacls without security groups means no per-resource precision. either without network firewall means no deep packet inspection and no egress monitoring.

the takeaway

go audit your own vpc this week. check your security groups for anything open to the world that shouldn't be. check whether your nacls are still on the default allow-all config. and if you're running anything sensitive, look into whether network firewall makes sense for egress filtering, because that's the layer most breaches exploit simply because nobody's watching outbound traffic. three layers, three jobs, and the goal isn't to max out every rule, it's to actually understand what each one is doing for you.