Security groups vs NACLs decision in AWS - Performance Comparison
Start learning this pattern below
Jump into concepts and practice - no test required
When deciding between security groups and network ACLs, it's important to understand how the number of rules affects processing time.
We want to know how the time to check rules grows as more rules are added.
Analyze the time complexity of evaluating inbound traffic against security group and NACL rules.
// Security Group rules evaluation (allow only, implicit deny)
for each rule in securityGroupRules:
if rule matches traffic:
allow
stop checking
// NACL rules evaluation
for each rule in naclRules ordered by rule number:
if rule matches traffic:
allow or deny
stop checking
This sequence checks each rule one by one until a match is found to decide if traffic is allowed or denied.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Checking each rule against incoming traffic.
- How many times: Once per rule until a match is found.
As the number of rules increases, the time to evaluate traffic grows roughly in proportion to the number of rules.
| Input Size (n) | Approx. Rule Checks |
|---|---|
| 10 | Up to 10 checks |
| 100 | Up to 100 checks |
| 1000 | Up to 1000 checks |
Pattern observation: The number of checks grows linearly with the number of rules.
Time Complexity: O(n)
This means the time to decide if traffic is allowed grows linearly as more rules are added.
[X] Wrong: "Security groups or NACLs check all rules instantly regardless of number."
[OK] Correct: Each rule is checked one by one until a match is found, so more rules mean more checks and longer evaluation time.
Understanding how rule evaluation scales helps you design efficient security setups and shows you can think about system performance clearly.
"What if security groups supported rule indexing to jump directly to matching rules? How would the time complexity change?"
Practice
Solution
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.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.Final Answer:
Security Groups are stateful and control instance-level traffic; NACLs are stateless and control subnet-level traffic. -> Option BQuick Check:
Stateful = Security Groups, Stateless = NACLs [OK]
- Confusing which is stateful or stateless
- Mixing instance-level and subnet-level controls
- Assuming both control the same traffic scope
Solution
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.Step 2: Confirm direction and source
Inbound traffic must be allowed from any IP (0.0.0.0/0) to accept public HTTP requests.Final Answer:
Allow inbound TCP traffic on port 80 from 0.0.0.0/0 -> Option CQuick Check:
HTTP = TCP port 80 inbound [OK]
- Allowing UDP instead of TCP
- Setting outbound instead of inbound
- Using wrong port like 22 (SSH)
Solution
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.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.Final Answer:
The response will be blocked because the NACL denies outbound traffic. -> Option AQuick Check:
NACL deny outbound blocks response despite Security Group [OK]
- Assuming Security Groups override NACLs
- Ignoring NACL outbound deny effect
- Confusing stateful and stateless behavior
Solution
Step 1: Check NACL outbound rules
NACLs are stateless, so return traffic must be explicitly allowed. Missing outbound rule blocks return SSH packets.Step 2: Check Security Group rules
Security Groups allow inbound and outbound SSH, but cannot override NACL blocking outbound return traffic.Final Answer:
SSH connection will fail because NACL outbound traffic is blocked. -> Option AQuick Check:
NACL stateless requires outbound allow for return traffic [OK]
- Assuming Security Groups fix NACL outbound block
- Forgetting NACLs are stateless
- Thinking inbound allow is enough
Solution
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.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.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 DQuick Check:
Security Groups for instances, NACLs for subnet filtering [OK]
- Using NACLs to allow all traffic defeats subnet security
- Blocking all traffic with Security Groups breaks communication
- Confusing roles of Security Groups and NACLs
