In an AWS VPC, how do security groups and network ACLs differ in what they attach to, what a rule can express, and how return traffic is treated?

## Two filters, two attachment points Inside a VPC, a packet on its way to an instance is checked by two mechanisms that look superficially alike and behave very differently. A **security group** is attached to an *elastic network interface* (ENI). An ENI is the virtual NIC that AWS gives to an EC2 instance, an ECS task with `awsvpc` networking, a Lambda function configured for VPC access, an RDS instance, an interface VPC endpoint or a load balancer node. So a security group is an instance-level filter: two instances in the same subnet can have completely different security groups and completely different reachability. A **network ACL** (NACL) is attached to a *subnet*. Every ENI in that subnet is behind the same NACL, and every packet crossing the subnet boundary in either direction is evaluated against it. A subnet is associated with exactly one NACL at a time; one NACL can be associated with many subnets. Both must permit a packet. They are AND-ed, not layered as an override: a NACL `allow` does not rescue traffic the security group never permitted, and a permissive security group does not rescue traffic a NACL denies. ## What a rule can say Security-group rules are **allow-only**. There is no `deny` action — the absence of a matching allow rule *is* the denial. There is also no rule ordering: all rules across all security groups attached to the ENI are evaluated as a set, and the traffic passes if any of them matches. Because of this, attaching a second security group can only ever widen access, never narrow it. A rule's source (inbound) or destination (outbound) can be a CIDR block, a managed prefix list, or another security group. NACL rules are **numbered** — you assign the number yourself — and carry an explicit `allow` or `deny`. Evaluation walks the rules in ascending numeric order and stops at the first match; anything unmatched falls through to the untouchable final `*` rule, which denies. This ordering is why people leave gaps between rule numbers (100, 200, 300) so a rule can be inserted later without renumbering. The source or destination of a NACL rule is a CIDR block only — a NACL cannot reference a security group. ## Stateful versus stateless: the part interviews hinge on A security group **tracks connections**. When an inbound rule admits a TCP connection, the reply packets are permitted back out no matter what the outbound rules say, and vice versa for connections the instance originates. This is why the very common configuration — restrictive inbound rules plus the default "allow all outbound" rule — works fine, and why removing the outbound rule does not break inbound-initiated traffic. A NACL tracks nothing. Each packet is evaluated on its own against the rules for the direction it is moving. The reply to a request you allowed inbound is a separate outbound packet, and it will be dropped unless an outbound rule matches it. Because a reply travels *from* the service port *to* the client's randomly chosen ephemeral port, the outbound rule that permits it is written over the ephemeral port range, not over the service port. Getting that wrong is the single most common way a hand-written NACL breaks connectivity. ## The defaults A VPC ships with a **default security group** whose inbound rule allows traffic from resources that have that same security group attached, and whose outbound rule allows all traffic. A security group you create yourself starts with **no inbound rules** and an allow-all outbound rule. The **default network ACL** that comes with a VPC allows all inbound and all outbound traffic — it is deliberately transparent, so that people who never touch NACLs are only ever filtered by security groups. A NACL you create yourself starts with **only** the implicit `*` deny in both directions, so associating a fresh custom NACL with a live subnet blackholes it instantly. ``` # custom NACL, inbound 100 allow tcp 443 0.0.0.0/0 * deny all 0.0.0.0/0 ``` ## Why AWS ships both The security group is the workhorse: it follows the workload rather than its location, it composes safely, and its statefulness means you write half as many rules. The NACL is a coarse subnet-wide guardrail with the one capability security groups lack — an explicit `deny`, which lets a platform team block a CIDR range across a subnet without touching any application's rules. Most production VPCs leave NACLs wide open and do all real work in security groups.