> For the complete documentation index, see [llms.txt](https://docs.wehost.co.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wehost.co.in/grup-labs/aws-nacl-vs-security-group-the-practical-guide-with-console-walkthroughs.md). # AWS NACL vs Security Group: The Practical Guide (With Console Walkthroughs) Security Groups are stateful bouncers on the instance/ENI. NACLs are stateless speed bumps at the subnet edge. That is the core idea. The rest is details, and you are here for the details. ## TL;DR | Feature | Security Group | NACL | | --------------------- | --------------------------------- | -------------------------------------------- | | Level | Instance/ENI | Subnet | | Stateful or Stateless | Stateful | Stateless | | Rule Types | Allow only | Allow and Deny | | Applies To | ENIs/Instances | Entire Subnet | | Rule Evaluation | All rules are evaluated as a set | Rules are processed by number (lowest first) | | Defaults | Inbound denied, outbound allowed | Default NACL allows all; you can change it | | Typical Use | App-level firewalling | Broad subnet filtering and quarantine | | Logging | VPC Flow Logs (via ENI or Subnet) | VPC Flow Logs (via Subnet) | | Console Path | EC2 -> Security Groups | VPC -> Network ACLs | If you only remember one thing: * SG = stateful allow-lists on ENIs; * NACL = stateless allow+deny lists on subnets with ordered rules. ### Why you should care * Reality check: * SGs do not support deny. * NACLs do. * SGs track connections; * NACLs do not. NACL rule order matters * SG rule order does not. * Real world: Subnet-wide quarantine, hot IP blocks, blast-radius control, and keeping your SGs clean all hinge on knowing which lever to pull. * Performance note: NACLs are checked per packet; SGs are connection-aware. If you are pushing very high packet rates, the difference shows up in behaviour and troubleshooting. ### See it yourself: AWS Console Walkthroughs #### Security Groups 1. Open AWS Console -> EC2 -> Security Groups. 2. Click a group. Inspect Inbound rules and Outbound rules tabs. 3. Click the References/Attached resources tab to see ENIs/instances using this SG. 4. Try to add a Deny. You cannot. SGs are allow-only. 5. Housekeeping: Filter for groups with zero attached network interfaces. Those are candidates for cleanup. #### Network ACLs 1. Open AWS Console -> VPC -> Network ACLs. 2. Pick a NACL. Inspect Inbound rules and Outbound rules. Note the rule numbers and the implicit deny at the end. 3. Check the Subnet associations tab to see which subnets inherit these rules. 4. Create a Deny rule for a test source IP and give it a small rule number (for example 100) so it wins. 5. Housekeeping: Filter for NACLs with zero subnet associations. Those are usually safe to archive or delete after review. Pro tip: Make one small change at a time, then test. NACL mistakes are easy to make and hard to debug if you pile on changes. (been here) ### Hands-on mini lab (15-30 min) Goal: Experience stateful vs stateless behavior and allow vs deny in a safe sandbox. #### Setup * One VPC with two public subnets: web-subnet and admin-subnet. * An EC2 instance in web-subnet (call it web1). * An EC2 instance in admin-subnet (call it admin1). * An Internet Gateway and route tables so both are reachable. #### Security Groups * SG-web: inbound allow TCP 80 from 0.0.0.0/0, outbound allow all. * SG-admin: inbound allow TCP 22 only from your public IP, outbound allow all. #### NACLs * NACL-web: allow inbound 80 from 0.0.0.0/0, allow ephemeral response ports outbound. No explicit deny. * NACL-admin: add a deny inbound rule for your home IP block as a test (for example, rule 100 deny 203.0.113.0/24), then allow the rest. #### Tests 1. From your laptop, curl . Should work. 2. From your laptop, ssh admin1. If your IP matches the deny in NACL-admin, you should be blocked regardless of SG. 3. From admin1, curl . This should work if SGs allow it. If you add a NACL deny between the subnets, it will fail even if SGs allow. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.wehost.co.in/grup-labs/aws-nacl-vs-security-group-the-practical-guide-with-console-walkthroughs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.