๐ AWS Security Group vs NACL (Certification Key Differences)
| Feature | Security Group | NACL (Network ACL) |
|---|
| Level | Instance level | Subnet level |
| Type | Stateful | Stateless |
| Rules | Allow rules only | Allow + Deny rules |
| Evaluation | All rules evaluated | Rules evaluated in order (lowest number first) |
| Return Traffic | Automatically allowed | Must be explicitly allowed |
| Scope | Applied to EC2 instances | Applied to subnets |
| Default Behavior | Deny all inbound, allow all outbound | Default NACL allows all |
| Use Case | Instance-level security | Network-level security |
๐ง Key Concepts (Exam Important)
๐น 1. Stateful vs Stateless
Security Group (Stateful)
๐ If inbound is allowed → outbound is automatically allowed
NACL (Stateless)
๐ You must define BOTH:
-
Inbound rule
-
Outbound rule
๐น 2. Allow vs Deny
๐ Security Groups:
✔ Only allow rules
❌ No deny rules
๐ NACL:
✔ Allow rules
✔ Deny rules (important for blocking IPs)
๐น 3. Rule Processing
๐ Security Group:
-
No order
-
All rules checked
๐ NACL:
-
Rules processed top to bottom
-
First match wins
๐ฅ Real Exam Scenario
๐ Question:
You need to block a specific IP address
✔ Correct Answer: Use NACL
๐ Why?
Because Security Groups don’t support deny rules.
๐️ Real-World Use Case
Security Group:
✔ Allow web traffic (HTTP/HTTPS) to EC2
NACL:
✔ Block malicious IP ranges
✔ Add extra subnet-level protection
⚠️ Common Mistakes (Exam Traps)
❌ Thinking Security Groups can deny traffic
❌ Forgetting NACL is stateless
❌ Ignoring outbound rules in NACL
❌ Confusing subnet vs instance level
๐ฏ Quick Memory Trick
๐ Security Group = Stateful + Instance
๐ NACL = Stateless + Network (Subnet)
๐ Final Insight
๐ Use Security Groups for primary security
๐ Use NACL for additional layer (defense-in-depth)
๐ NACL Example: Block a Malicious IP
๐ฏ Scenario
You want to:
๐ Allow normal users to access your application
๐ BUT block a specific malicious IP (e.g., 192.168.1.100)
๐ This is where NACL is used (because it supports DENY rules)
๐️ Step-by-Step NACL Configuration
๐งฑ Step 1: Create a Custom NACL
-
Go to VPC → Network ACLs
-
Create a new NACL
-
Associate it with your subnet
๐ฅ Step 2: Configure Inbound Rules
| Rule # | Type | Protocol | Port Range | Source IP | Action |
|---|
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | ALLOW |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | ALLOW |
| 120 | ALL | ALL | ALL | 192.168.1.100/32 | DENY |
| * | ALL | ALL | ALL | 0.0.0.0/0 | DENY |
๐ค Step 3: Configure Outbound Rules (IMPORTANT)
๐ Since NACL is stateless, you MUST allow return traffic.
| Rule # | Type | Protocol | Port Range | Destination | Action |
|---|
| 100 | ALL | ALL | 1024-65535 | 0.0.0.0/0 | ALLOW |
| * | ALL | ALL | ALL | 0.0.0.0/0 | DENY |
⚠️ Important Concepts
๐ Stateless Behavior
๐ If inbound allows traffic, outbound must ALSO allow response
๐ข Rule Order Matters
๐ Lower number = higher priority
Example:
-
Rule 100 → checked first
-
Rule 120 → checked later
๐ First match wins
๐ฅ Real Exam Insight
๐ Question:
“How to block a specific IP at subnet level?”
✔ Answer: Use NACL with DENY rule
๐ง Visual Flow
1️⃣ Request comes from IP
2️⃣ NACL checks rules (top → bottom)
3️⃣ Match found → Allow or Deny
4️⃣ If allowed → must also pass outbound
๐ Terraform Example (NACL)
๐ฏ Key Takeaway
๐ Use NACL when you need:
✔ Deny rules
✔ Subnet-level control
✔ Extra security layer
๐ฌ Final Tip
๐ Security Group = Day-to-day security
๐ NACL = Extra firewall layer for control
๐ Advanced NACL Examples (Web Server – Port 80)
๐ฏ Base Scenario
You have a public web server (port 80) and want:
✔ Allow all users
✔ Block malicious IPs
✔ Allow trusted corporate IPs
✔ Control traffic at subnet level
๐ฅ ✅ Inbound Rules (Detailed Use Case)
| Rule # | Type | Protocol | Port Range | Source IP | Action | Purpose |
|---|
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | ALLOW | Allow public web traffic |
| 105 | HTTP | TCP | 80 | 203.0.113.10/32 | ALLOW | Trusted client IP |
| 106 | HTTP | TCP | 80 | 198.51.100.25/32 | ALLOW | Corporate office IP |
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | ALLOW | Secure traffic |
| 120 | ALL | ALL | ALL | 192.168.1.100/32 | DENY | Block malicious IP |
| 121 | ALL | ALL | ALL | 203.0.113.200/32 | DENY | Block attacker IP |
| 122 | ALL | ALL | ALL | 198.51.100.99/32 | DENY | Suspicious traffic |
| * | ALL | ALL | ALL | 0.0.0.0/0 | DENY | Default deny |
๐ค ✅ Outbound Rules (Stateless Requirement)
| Rule # | Type | Protocol | Port Range | Destination | Action | Purpose |
|---|
| 100 | ALL | ALL | 1024-65535 | 0.0.0.0/0 | ALLOW | Allow return traffic |
| 110 | HTTP | TCP | 80 | 0.0.0.0/0 | ALLOW | Optional outbound web |
| 120 | HTTPS | TCP | 443 | 0.0.0.0/0 | ALLOW | Secure outbound calls |
| * | ALL | ALL | ALL | 0.0.0.0/0 | DENY | Default deny |
๐ง Use Case 1: Public Web Server with IP Blocking
๐ฏ Goal:
-
Website accessible globally
-
Block specific bad actors
๐ Solution:
-
Allow
0.0.0.0/0 on port 80
-
Add DENY rules for malicious IPs
๐ข Use Case 2: Corporate Access + Public Access
๐ฏ Goal:
-
Public users allowed
-
Priority access for corporate users
๐ Add:
๐ Even if general traffic is allowed, these ensure priority handling
๐ซ Use Case 3: Blocking Multiple Attackers
๐ฏ Goal:
Block multiple suspicious IPs
๐ Important:
Place DENY rules before default deny
๐ Use Case 4: Restricting Only HTTP Traffic
๐ฏ Goal:
Allow only web traffic (port 80)
๐ Remove HTTPS rule:
๐ Result:
-
No HTTPS access
-
Only HTTP traffic allowed
⚠️ Use Case 5: Tight Security (Whitelist Only)
๐ฏ Goal:
Only allow specific IPs
| Rule # | Port | Source | Action |
|---|
| 100 | 80 | 203.0.113.10 | ALLOW |
| 110 | 80 | 198.51.100.25 | ALLOW |
| * | ALL | 0.0.0.0/0 | DENY |
๐ Result:
❌ Public blocked
✅ Only trusted users allowed
๐ฅ Exam Tips (VERY IMPORTANT)
๐ If question says:
✔ “Block specific IP” → Use NACL
✔ “Allow traffic to instance” → Use Security Group
✔ “Subnet-level security” → NACL
๐ง Key Concepts Reinforced
✔ NACL = Stateless
✔ Must configure inbound + outbound
✔ Rule order matters (lower = higher priority)
✔ Supports DENY rules
๐ AWS NACL (Network ACL) – Real-World Explanation
A Network ACL (NACL) is like a subnet-level firewall in AWS VPC.
๐ It controls traffic entering and leaving a subnet, not individual instances.
๐ง Simple Mental Model
Think of AWS architecture like this:
๐ NACL = first gate (network level)
๐ Security Group = second gate (instance level)
๐ข REAL USE CASE 1: Public Web Application (E-Commerce Site)
๐ฏ Scenario
You are hosting:
-
Website (Port 80 / 443)
-
EC2 in public subnet
-
Global users access it
๐ Requirement
✔ Allow global users
✔ Block attackers
✔ Protect subnet level traffic
✔ Allow only web traffic
๐ฅ Inbound Traffic (Real Setup)
| Rule | Source | Port | Action | Purpose |
|---|
| 100 | 0.0.0.0/0 | 80 | ALLOW | Public website access |
| 110 | 0.0.0.0/0 | 443 | ALLOW | Secure HTTPS access |
| 120 | 192.168.1.100/32 | ALL | DENY | Block attacker IP |
| 130 | 203.0.113.50/32 | ALL | DENY | Known bot traffic |
| * | 0.0.0.0/0 | ALL | DENY | Default deny |
๐ค Outbound Traffic
| Rule | Destination | Port | Action | Purpose |
|---|
| 100 | 0.0.0.0/0 | 1024-65535 | ALLOW | Response traffic |
| 110 | 0.0.0.0/0 | 80 | ALLOW | API calls |
| * | 0.0.0.0/0 | ALL | DENY | Default block |
๐ฅ WHAT HAPPENS?
-
User opens website
-
Request hits NACL first
-
If allowed → goes to Security Group
-
EC2 processes request
-
Response returns via outbound rule
๐ฆ REAL USE CASE 2: BANKING APPLICATION (HIGH SECURITY)
๐ฏ Scenario
-
Banking app on AWS
-
Highly sensitive data
-
Must restrict traffic strictly
๐ Requirements
✔ Only trusted corporate IPs allowed
✔ Block all public access
✔ Allow API communication only
๐ฅ Inbound Rules
| Rule | Source | Port | Action |
|---|
| 100 | 203.0.113.10/32 | 443 | ALLOW |
| 110 | 198.51.100.25/32 | 443 | ALLOW |
| 120 | 0.0.0.0/0 | ALL | DENY |
๐ Result
๐ Only bank office IPs can access system
๐ Public internet completely blocked
๐ REAL USE CASE 3: API GATEWAY BACKEND SYSTEM
๐ฏ Scenario
-
Microservices architecture
-
API Gateway → EC2 backend
-
Internal communication needed
๐ Requirements
✔ Allow API Gateway traffic
✔ Allow internal service communication
✔ Block external direct access
๐ฅ Inbound Rules
| Rule | Source | Port | Action |
|---|
| 100 | VPC CIDR (10.0.0.0/16) | 8080 | ALLOW |
| 110 | API Gateway IP range | 443 | ALLOW |
| 120 | 0.0.0.0/0 | ALL | DENY |
๐ฅ Result
๐ Only internal AWS services can talk to backend
๐ No direct internet access allowed
๐จ REAL USE CASE 4: BLOCKING ATTACKS (DDoS / BOT TRAFFIC)
๐ฏ Scenario
Your website is under attack from:
-
Multiple IPs
-
Bots flooding port 80
๐ Solution using NACL
| Rule | IP | Action |
|---|
| 120 | 192.168.1.100/32 | DENY |
| 121 | 203.0.113.200/32 | DENY |
| 122 | 198.51.100.99/32 | DENY |
๐ฅ Result
๐ Traffic blocked at subnet level
๐ EC2 never receives request
๐ Saves compute resources
⚖️ KEY REAL DIFFERENCE (VERY IMPORTANT)
| Feature | Security Group | NACL |
|---|
| Level | Instance | Subnet |
| State | Stateful | Stateless |
| Best Use | Allow access | Block/Filter traffic |
| Performance | High | Medium |
๐ง IMPORTANT EXAM INSIGHT
๐ AWS exam trick:
If question says:
-
“Block IP address” → NACL
-
“Allow EC2 access” → Security Group
-
“Subnet-level control” → NACL
-
“Instance-level security” → Security Group
๐ฅ SIMPLE REAL-WORLD ANALOGY
๐ Security Group = Door lock of a house
๐ NACL = Security gate of society
๐ FINAL TAKEAWAY
NACL is used when you need:
✔ Subnet-level security
✔ IP blocking
✔ Additional firewall layer
✔ Defense-in-depth architecture