Stateless behavior of NACLs in AWS - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
We want to understand how the number of checks grows when network traffic passes through Network ACLs (NACLs).
Specifically, how many rule evaluations happen as more packets flow through.
Analyze the time complexity of NACL rule evaluations for incoming and outgoing packets.
// Example NACL rules evaluation for each packet
for each packet in network_traffic:
check inbound rules for packet
if allowed:
forward packet
check outbound rules for response packet
if allowed:
forward response
This sequence shows how NACLs check rules for both incoming and outgoing packets separately because they are stateless.
Each packet causes these repeated operations:
- Primary operation: Rule checks on inbound and outbound traffic.
- How many times: Twice per packet (once inbound, once outbound).
As the number of packets increases, the number of rule checks grows proportionally.
| Input Size (n packets) | Approx. Rule Checks |
|---|---|
| 10 | 20 |
| 100 | 200 |
| 1000 | 2000 |
Pattern observation: The total checks double the number of packets because each packet is checked twice.
Time Complexity: O(n)
This means the number of rule checks grows directly in proportion to the number of packets passing through.
[X] Wrong: "NACLs only check rules once per connection, so rule checks stay constant regardless of traffic."
[OK] Correct: NACLs are stateless, so they check every packet separately, causing rule checks to grow with traffic volume.
Understanding how stateless checks scale helps you explain network security behavior clearly and confidently in real-world cloud roles.
"What if NACLs were stateful and tracked connections? How would the time complexity of rule checks change?"
Practice
Solution
Step 1: Understand the meaning of stateless
Stateless means the system does not keep track of previous packets or connection states.Step 2: Apply this to NACLs
NACLs evaluate each packet on its own, without remembering if it is part of an existing connection.Final Answer:
Each packet is checked independently without remembering previous packets -> Option BQuick Check:
Stateless means no memory of past packets = A [OK]
- Thinking NACLs remember connection states like security groups
- Assuming NACLs allow return traffic automatically
- Confusing stateless with blocking all traffic by default
Solution
Step 1: Identify the correct port and protocol for HTTP
HTTP uses TCP protocol on port 80.Step 2: Confirm the rule direction and action
To allow inbound HTTP traffic, the rule must be inbound with action ALLOW.Final Answer:
Allow inbound traffic on port 80 with rule number 100, protocol TCP, action ALLOW -> Option AQuick Check:
Inbound TCP port 80 ALLOW = D [OK]
- Using wrong port number or protocol
- Setting rule direction incorrectly
- Using DENY action instead of ALLOW
Inbound Rule 100: ALLOW TCP port 80Outbound Rule 100: DENY all trafficWhat will happen when an instance in the subnet tries to send a response to an HTTP request?
Solution
Step 1: Analyze inbound rule
Inbound HTTP traffic on port 80 is allowed, so requests can reach the instance.Step 2: Analyze outbound rule
Outbound rule denies all traffic, so responses from the instance are blocked.Final Answer:
The response will be blocked because outbound is denied -> Option CQuick Check:
Outbound DENY blocks response despite inbound ALLOW = B [OK]
- Assuming NACLs are stateful and allow return traffic automatically
- Ignoring outbound rules when troubleshooting
- Confusing inbound and outbound directions
Solution
Step 1: Review NACL rules for SSH
Inbound SSH (port 22) is allowed, but outbound SSH must also be allowed for return traffic.Step 2: Understand stateless nature of NACLs
NACLs do not remember connection state, so both inbound and outbound rules must permit traffic.Final Answer:
Outbound SSH traffic is not allowed in the NACL -> Option AQuick Check:
Both directions must allow SSH for connection success = C [OK]
- Assuming NACLs are stateful and outbound rules are unnecessary
- Blaming security groups without checking NACLs
- Ignoring outbound rules for return traffic
Solution
Step 1: Understand HTTP/HTTPS traffic flow
Clients initiate outbound connections to ports 80 and 443; responses come back on ephemeral ports (1024-65535).Step 2: Configure NACL rules for stateless behavior
Outbound rules must allow TCP ports 80 and 443; inbound rules must allow ephemeral ports for return traffic.Final Answer:
Allow inbound ephemeral ports 1024-65535, allow outbound TCP ports 80 and 443 -> Option DQuick Check:
Outbound to 80/443, inbound ephemeral ports for response = A [OK]
- Allowing inbound ports 80/443 instead of ephemeral ports
- Not allowing ephemeral ports inbound blocks responses
- Allowing all traffic unnecessarily
