🔐 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)

resource "aws_network_acl" "example" {
  vpc_id = aws_vpc.main.id
}

# Inbound rule - Allow HTTP
resource "aws_network_acl_rule" "allow_http" {
  network_acl_id = aws_network_acl.example.id
  rule_number    = 100
  protocol       = "6"
  rule_action    = "allow"
  egress         = false
  cidr_block     = "0.0.0.0/0"
  from_port      = 80
  to_port        = 80
}

# Inbound rule - Deny specific IP
resource "aws_network_acl_rule" "deny_ip" {
  network_acl_id = aws_network_acl.example.id
  rule_number    = 120
  protocol       = "-1"
  rule_action    = "deny"
  egress         = false
  cidr_block     = "192.168.1.100/32"
}

---

🎯 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:

203.0.113.10/32 → ALLOW
198.51.100.25/32 → ALLOW

👉 Even if general traffic is allowed, these ensure priority handling

---

🚫 Use Case 3: Blocking Multiple Attackers

🎯 Goal:

Block multiple suspicious IPs

192.168.1.100/32 → DENY
203.0.113.200/32 → DENY
198.51.100.99/32 → DENY

👉 Important:
Place DENY rules before default deny

---

🔄 Use Case 4: Restricting Only HTTP Traffic

🎯 Goal:

Allow only web traffic (port 80)

👉 Remove HTTPS rule:

Only allow:
Port 80

👉 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:

Internet
   ↓
NACL (Subnet Firewall)
   ↓
Security Group (Instance Firewall)
   ↓
EC2 Instance

👉 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?

1. User opens website
2. Request hits NACL first
3. If allowed → goes to Security Group
4. EC2 processes request
5. 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