Eduarn – Online & Offline Training with Free LMS for Python, AI, Cloud & More

Saturday, April 11, 2026

AWS Security Group vs NACL (Certification Key Differences)

 

AWS Security Group vs NACL (Certification Key Differences) By EduArn.com

πŸ” AWS Security Group vs NACL (Certification Key Differences)

FeatureSecurity GroupNACL (Network ACL)
LevelInstance levelSubnet level
TypeStatefulStateless
RulesAllow rules onlyAllow + Deny rules
EvaluationAll rules evaluatedRules evaluated in order (lowest number first)
Return TrafficAutomatically allowedMust be explicitly allowed
ScopeApplied to EC2 instancesApplied to subnets
Default BehaviorDeny all inbound, allow all outboundDefault NACL allows all
Use CaseInstance-level securityNetwork-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 #TypeProtocolPort RangeSource IPAction
100HTTPTCP800.0.0.0/0ALLOW
110HTTPSTCP4430.0.0.0/0ALLOW
120ALLALLALL192.168.1.100/32DENY
*ALLALLALL0.0.0.0/0DENY

πŸ“€ Step 3: Configure Outbound Rules (IMPORTANT)

πŸ‘‰ Since NACL is stateless, you MUST allow return traffic.

Rule #TypeProtocolPort RangeDestinationAction
100ALLALL1024-655350.0.0.0/0ALLOW
*ALLALLALL0.0.0.0/0DENY

⚠️ 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 #TypeProtocolPort RangeSource IPActionPurpose
100HTTPTCP800.0.0.0/0ALLOWAllow public web traffic
105HTTPTCP80203.0.113.10/32ALLOWTrusted client IP
106HTTPTCP80198.51.100.25/32ALLOWCorporate office IP
110HTTPSTCP4430.0.0.0/0ALLOWSecure traffic
120ALLALLALL192.168.1.100/32DENYBlock malicious IP
121ALLALLALL203.0.113.200/32DENYBlock attacker IP
122ALLALLALL198.51.100.99/32DENYSuspicious traffic
*ALLALLALL0.0.0.0/0DENYDefault deny

πŸ“€ ✅ Outbound Rules (Stateless Requirement)

Rule #TypeProtocolPort RangeDestinationActionPurpose
100ALLALL1024-655350.0.0.0/0ALLOWAllow return traffic
110HTTPTCP800.0.0.0/0ALLOWOptional outbound web
120HTTPSTCP4430.0.0.0/0ALLOWSecure outbound calls
*ALLALLALL0.0.0.0/0DENYDefault 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 #PortSourceAction
10080203.0.113.10ALLOW
11080198.51.100.25ALLOW
*ALL0.0.0.0/0DENY

πŸ‘‰ 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)

RuleSourcePortActionPurpose
1000.0.0.0/080ALLOWPublic website access
1100.0.0.0/0443ALLOWSecure HTTPS access
120192.168.1.100/32ALLDENYBlock attacker IP
130203.0.113.50/32ALLDENYKnown bot traffic
*0.0.0.0/0ALLDENYDefault deny

πŸ“€ Outbound Traffic

RuleDestinationPortActionPurpose
1000.0.0.0/01024-65535ALLOWResponse traffic
1100.0.0.0/080ALLOWAPI calls
*0.0.0.0/0ALLDENYDefault 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

RuleSourcePortAction
100203.0.113.10/32443ALLOW
110198.51.100.25/32443ALLOW
1200.0.0.0/0ALLDENY

πŸ” 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

RuleSourcePortAction
100VPC CIDR (10.0.0.0/16)8080ALLOW
110API Gateway IP range443ALLOW
1200.0.0.0/0ALLDENY

πŸ”₯ 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

RuleIPAction
120192.168.1.100/32DENY
121203.0.113.200/32DENY
122198.51.100.99/32DENY

πŸ”₯ Result

πŸ‘‰ Traffic blocked at subnet level
πŸ‘‰ EC2 never receives request
πŸ‘‰ Saves compute resources


⚖️ KEY REAL DIFFERENCE (VERY IMPORTANT)

FeatureSecurity GroupNACL
LevelInstanceSubnet
StateStatefulStateless
Best UseAllow accessBlock/Filter traffic
PerformanceHighMedium

🧠 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

 

 

No comments:

Post a Comment