Security groups vs NACLs decision in AWS - Visual Side-by-Side Comparison

Process Flow - Security groups vs NACLs decision

Start: Incoming Traffic

↓

Check NACL Rules

↓

Check SG Rules

↓

End

Traffic first passes through NACL rules, then security group rules. Both must allow traffic for it to reach the resource.

Execution Sample

AWS

NACL: Allow inbound port 80
SG: Allow inbound port 80
Traffic arrives on port 80
Check NACL -> Allowed
Check SG -> Allowed
Traffic reaches server

This example shows traffic allowed by both NACL and security group, so it reaches the server.

Process Table

Step	Traffic Port	NACL Rule Check	NACL Result	SG Rule Check	SG Result	Final Outcome
1	80	Allow inbound 80	Allowed	Allow inbound 80	Allowed	Traffic reaches server
2	22	Deny inbound 22	Denied	Allow inbound 22	Allowed	Traffic blocked by NACL
3	443	Allow inbound 443	Allowed	Deny inbound 443	Denied	Traffic blocked by SG
4	8080	No rule for 8080	Denied (default deny)	Allow inbound 8080	Allowed	Traffic blocked by NACL

💡 Traffic must be allowed by both NACL and SG to reach the server; any deny blocks it.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Traffic Port	None	80	22	443	8080
NACL Result	None	Allowed	Denied	Allowed	Denied
SG Result	None	Allowed	Allowed	Denied	Allowed
Final Outcome	None	Reach Server	Blocked	Blocked	Blocked

Key Moments - 3 Insights

Why does traffic get blocked even if the security group allows it?

Because the NACL denies the traffic first, as shown in step 2 and 4 of the execution_table, NACL rules are evaluated before security groups.

Can security groups allow traffic that NACL denies?

No, traffic must pass both NACL and security group rules. If NACL denies, traffic is blocked regardless of security group settings (see step 2 and 4).

What happens if there is no explicit rule in NACL for a port?

NACLs have an implicit deny rule. If no rule matches, traffic is denied by default (step 4).

Visual Quiz - 3 Questions

Look at the execution_table, what is the final outcome for traffic on port 443?

A Traffic reaches server

B Traffic blocked by NACL

C Traffic blocked by security group

D Traffic allowed by default

💡 Hint

Check row 3 in execution_table under SG Result and Final Outcome columns.

At which step does the NACL deny traffic even though the security group allows it?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at NACL Result and SG Result columns in execution_table rows 2 and 4.

If the NACL allowed port 22 instead of denying it, what would be the final outcome at step 2?

A Traffic reaches server

B Traffic blocked by security group

C Traffic blocked by NACL

D Traffic blocked by default deny

💡 Hint

Consider that both NACL and SG must allow traffic for it to reach the server (see execution_table step 1).

Concept Snapshot

Security groups and NACLs control traffic in AWS.
NACLs act as a firewall at subnet level, evaluated first.
Security groups act at instance level, evaluated second.
Traffic must be allowed by both to reach the resource.
NACLs have stateless rules; security groups are stateful.
Default deny applies if no rule matches in NACL.

Full Transcript

In AWS, when traffic arrives, it first passes through Network ACL (NACL) rules which are stateless and apply at the subnet level. If the NACL allows the traffic, it then passes to the security group rules which are stateful and apply at the instance level. Both must allow the traffic for it to reach the server. If either denies, the traffic is blocked. For example, traffic on port 80 allowed by both NACL and security group reaches the server. Traffic on port 22 denied by NACL is blocked even if the security group allows it. Traffic on port 443 allowed by NACL but denied by security group is blocked. If no NACL rule matches, traffic is denied by default. This layered approach helps secure AWS resources effectively.

Practice

1. Which statement best describes the main difference between AWS Security Groups and Network ACLs (NACLs)?

easy

A. Security Groups control subnet-level traffic; NACLs control instance-level traffic.

B. Security Groups are stateful and control instance-level traffic; NACLs are stateless and control subnet-level traffic.

C. Both Security Groups and NACLs are stateful and control instance-level traffic.

D. NACLs are stateful and control instance-level traffic; Security Groups are stateless and control subnet-level traffic.

Solution

1. Step 1: Understand Security Groups behavior

   Security Groups are stateful, meaning they remember allowed connections and automatically allow return traffic. They work at the instance level.

2. Step 2: Understand NACLs behavior

   NACLs are stateless, so they do not remember previous traffic and require explicit rules for both inbound and outbound traffic. They apply at the subnet level.

3. Final Answer:

   Security Groups are stateful and control instance-level traffic; NACLs are stateless and control subnet-level traffic. -> Option B

4. Quick Check:

   Stateful = Security Groups, Stateless = NACLs [OK]

Hint: Security Groups = instance + stateful; NACLs = subnet + stateless [OK]

Common Mistakes:

• Confusing which is stateful or stateless
• Mixing instance-level and subnet-level controls
• Assuming both control the same traffic scope

2. Which of the following is the correct way to allow inbound HTTP traffic on port 80 using a Security Group rule in AWS?

easy

A. Allow outbound TCP traffic on port 80 from 0.0.0.0/0

B. Allow inbound UDP traffic on port 80 from 0.0.0.0/0

C. Allow inbound TCP traffic on port 80 from 0.0.0.0/0

D. Allow inbound TCP traffic on port 22 from 0.0.0.0/0

Solution

1. Step 1: Identify correct protocol and port for HTTP

   HTTP uses TCP protocol on port 80, so the rule must allow inbound TCP traffic on port 80.

2. Step 2: Confirm direction and source

   Inbound traffic must be allowed from any IP (0.0.0.0/0) to accept public HTTP requests.

3. Final Answer:

   Allow inbound TCP traffic on port 80 from 0.0.0.0/0 -> Option C

4. Quick Check:

   HTTP = TCP port 80 inbound [OK]

Hint: HTTP uses TCP port 80 inbound, not UDP or outbound [OK]

Common Mistakes:

• Allowing UDP instead of TCP
• Setting outbound instead of inbound
• Using wrong port like 22 (SSH)

3. You have a subnet with a NACL that allows inbound traffic on port 443 but denies all outbound traffic. A Security Group attached to an instance in this subnet allows inbound and outbound HTTPS traffic on port 443. What will happen when the instance tries to respond to an HTTPS request?

medium

A. The response will be blocked because the NACL denies outbound traffic.

B. The response will be allowed because Security Groups are stateful.

C. The response will be allowed because NACLs override Security Groups.

D. The response will be blocked because Security Groups deny outbound traffic.

Solution

1. Step 1: Analyze NACL outbound rules

   The NACL denies all outbound traffic, so no outbound packets can leave the subnet regardless of Security Group settings.

2. Step 2: Analyze Security Group statefulness

   Security Groups are stateful and allow return traffic, but they cannot override the stateless NACL's explicit deny on outbound traffic.

3. Final Answer:

   The response will be blocked because the NACL denies outbound traffic. -> Option A

4. Quick Check:

   NACL deny outbound blocks response despite Security Group [OK]

Hint: NACL deny rules always block, even if Security Group allows [OK]

Common Mistakes:

• Assuming Security Groups override NACLs
• Ignoring NACL outbound deny effect
• Confusing stateful and stateless behavior

4. A developer configures a NACL to allow inbound SSH (port 22) traffic but forgets to add an outbound rule to allow return traffic. The Security Group allows inbound and outbound SSH traffic. What issue will occur when trying to SSH into an instance in this subnet?

medium

A. SSH connection will fail because NACL outbound traffic is blocked.

B. SSH connection will succeed because Security Groups allow traffic.

C. SSH connection will fail because Security Groups block inbound traffic.

D. SSH connection will succeed because NACLs are stateful.

Solution

1. Step 1: Check NACL outbound rules

   NACLs are stateless, so return traffic must be explicitly allowed. Missing outbound rule blocks return SSH packets.

2. Step 2: Check Security Group rules

   Security Groups allow inbound and outbound SSH, but cannot override NACL blocking outbound return traffic.

3. Final Answer:

   SSH connection will fail because NACL outbound traffic is blocked. -> Option A

4. Quick Check:

   NACL stateless requires outbound allow for return traffic [OK]

Hint: NACLs need both inbound and outbound rules for two-way traffic [OK]

Common Mistakes:

• Assuming Security Groups fix NACL outbound block
• Forgetting NACLs are stateless
• Thinking inbound allow is enough

5. You want to secure a multi-tier web application in AWS. The web servers are in a public subnet, and the database servers are in a private subnet. Which combination of Security Groups and NACLs is the best practice to control traffic securely?

hard

A. Use NACLs to allow web traffic to web servers and database traffic only from web servers; use Security Groups to block all traffic.

B. Use NACLs to allow all traffic between web and database subnets; use Security Groups to block all traffic.

C. Use Security Groups to allow all traffic between subnets; use NACLs to allow all inbound and outbound traffic.

D. Use Security Groups to allow web traffic to web servers and database traffic only from web servers; use NACLs to block all inbound traffic except HTTP/HTTPS on the public subnet.

Solution

1. Step 1: Use Security Groups for instance-level control

   Security Groups should allow web servers to receive HTTP/HTTPS and allow database servers to accept traffic only from web servers for tight control.

2. Step 2: Use NACLs for subnet-level filtering

   NACLs should block unwanted inbound traffic on the public subnet except HTTP/HTTPS to reduce exposure at the subnet level.

3. Final Answer:

   Use Security Groups to allow web traffic to web servers and database traffic only from web servers; use NACLs to block all inbound traffic except HTTP/HTTPS on the public subnet. -> Option D

4. Quick Check:

   Security Groups for instances, NACLs for subnet filtering [OK]

Hint: Security Groups for instances, NACLs for subnet-wide rules [OK]

Common Mistakes:

• Using NACLs to allow all traffic defeats subnet security
• Blocking all traffic with Security Groups breaks communication
• Confusing roles of Security Groups and NACLs