This chapter provides a deep dive into two fundamental AWS networking security components: Security Groups and Network Access Control Lists (Network ACLs). Understanding their differences, use cases, and how they interact is critical for the SOA-C02 exam, as approximately 10-15% of questions touch on these topics directly or indirectly. You will learn the stateless vs stateful behavior, rule evaluation logic, default configurations, and how to troubleshoot common misconfigurations. By the end, you will be able to design secure VPC architectures and answer exam questions with confidence.
Jump to a section
Imagine a corporate office building with a single main entrance and a separate fire exit. The building has two layers of security: a security guard at the entrance (Security Group) and a protective wall around the entire building (Network ACL). The security guard is stateful: he remembers who has entered and lets them leave without re-checking. He also allows return visits from known visitors. The wall is stateless: it has holes (rules) that allow specific types of traffic in and out, but it does not remember who passed through. For example, the wall might have a hole for mail delivery (port 25) and another for visitors (port 80). The guard can make decisions based on the identity of the person (e.g., employee vs visitor), while the wall only looks at the type of package (e.g., letter vs box). In AWS, Security Groups operate at the instance level (like a guard at each office door) and are stateful, while Network ACLs operate at the subnet level (like a wall around the whole floor) and are stateless. When a packet enters a subnet, it first hits the Network ACL (wall) and then the Security Group (guard). For outbound traffic, the order is reversed: Security Group first, then Network ACL. Because the guard is stateful, he remembers the conversation and allows the response back through without re-checking the rules. The wall, being stateless, must have explicit rules for both directions. This distinction is crucial for exam questions about connection tracking and default behaviors.
What Are Security Groups and Network ACLs?
Security Groups and Network ACLs are both virtual firewalls for controlling traffic in an Amazon VPC, but they operate at different levels and with different characteristics.
Security Groups act as a virtual firewall for an instance (or other resources like ENI, EC2, Lambda, etc.). They are stateful and support allow rules only (no explicit deny). All rules are evaluated until a matching allow is found; if no rule matches, traffic is implicitly denied.
Network ACLs act as a firewall for a subnet. They are stateless and support both allow and deny rules, evaluated in order by rule number. The default Network ACL allows all inbound and outbound traffic; custom Network ACLs deny all traffic by default.
The exam often tests your ability to choose the correct component for a given scenario, especially when dealing with stateless vs stateful behavior.
How They Work Internally: Packet Processing
When a packet enters a VPC, the following sequence occurs (for inbound traffic): 1. The packet arrives at the subnet's Network ACL. 2. The Network ACL evaluates the packet against its inbound rules in ascending order by rule number. The first rule that matches the packet's characteristics (protocol, source IP, destination port) determines whether the packet is allowed or denied. If no rule matches, the packet is denied (default deny). 3. If allowed by the Network ACL, the packet is then evaluated by the Security Group associated with the destination instance's ENI. 4. The Security Group checks its inbound rules. Because it is stateful, it also tracks the connection state. If the packet matches an allow rule, it is permitted and the connection is tracked. If no rule matches, the packet is dropped.
For outbound traffic, the order is reversed: Security Group first, then Network ACL.
Stateful vs Stateless: The Key Differentiator
Stateful (Security Group): Automatically allows return traffic for an allowed connection. For example, if you allow inbound HTTP (port 80) from the internet, the Security Group automatically allows the outbound return traffic (the web server's response) without needing an explicit outbound rule. This is because the Security Group tracks the connection state (source IP, destination IP, ports, protocol). The tracking is done using a connection tracking table that stores entries for active flows. The default timeout for TCP connections is 5 minutes (configurable via the tcp_established_timeout parameter in the VPC flow log settings? Actually, connection tracking is not directly configurable, but the idle timeout is 5 minutes for TCP).
Stateless (Network ACL): Does not track connections. Each packet is evaluated independently. Therefore, you must explicitly allow both inbound and outbound traffic for a given communication. For example, to allow web traffic from the internet to an instance in a subnet, you must allow inbound on port 80 in the Network ACL and also allow outbound ephemeral ports (1024-65535) for the return traffic. This is a common exam trap: candidates forget that Network ACLs require bidirectional rules.
Rule Evaluation and Numbers
Security Groups: Rules are evaluated collectively. All rules are considered; there is no concept of order. The decision is based on whether any rule allows the traffic. If multiple rules match, the most permissive applies (since there are no deny rules, all rules are allows). The implicit deny at the end applies only if no allow rule matches.
Network ACLs: Rules have a number (1-32766). They are evaluated from lowest to highest. The first rule that matches determines the action (allow or deny). This allows you to create explicit deny rules (e.g., block a specific IP) before allowing other traffic. The default Network ACL has a single allow-all rule (rule 100) for both inbound and outbound. Custom Network ACLs have a default deny-all rule (rule *).
Default Configurations
Default VPC Security Group: Allows all inbound traffic from other instances associated with the same security group, and allows all outbound traffic. This is important for exam questions about default VPC behavior.
Custom Security Group (when created): Initially has no inbound rules (implicitly denies all) and one outbound rule that allows all traffic. This is a common source of confusion: many think outbound is also denied by default, but it is actually allowed.
Default Network ACL: Allows all inbound and outbound traffic (rule 100: ALLOW ALL). This is the only case where a Network ACL is permissive.
Custom Network ACL: Initially denies all inbound and outbound traffic (only rule *: DENY ALL). You must add rules to allow traffic.
Interaction Between Security Groups and Network ACLs
Both layers must allow traffic for it to reach an instance. If either denies, the traffic is blocked. The exam frequently tests scenarios where one is misconfigured. For example, a common question: "An instance cannot be reached from the internet. The Security Group allows HTTP, but the Network ACL denies it. What is the issue?" Answer: The Network ACL must be modified.
Ephemeral Ports
When a client initiates a connection to a server, the client uses a random high-numbered port (ephemeral port) as the source port. The server responds to that port. For stateless firewalls (Network ACLs), you must allow inbound traffic on ephemeral ports for the return traffic. AWS documentation specifies the ephemeral port range for different clients:
Linux clients: 32768-60999
Windows clients: 49152-65535
Many AWS services: 1024-65535
The exam expects you to know that you should allow the entire range 1024-65535 for outbound traffic to be safe, or at least the appropriate range. Security Groups handle this automatically.
Key Differences Table (for reference)
Scope: Security Group = instance/ENI level; Network ACL = subnet level.
State: Stateful vs Stateless.
Rules: Allow only vs Allow and Deny.
Evaluation: All rules evaluated (no order) vs Ordered by number.
Default: Inbound: deny all; Outbound: allow all (custom SG) vs Inbound: deny all; Outbound: deny all (custom NACL).
Supports explicit deny? No vs Yes.
Supports rule numbering? No vs Yes.
Applies to: Instances in the same subnet can have different SGs vs All instances in the subnet share the same NACL.
When to Use Which
Security Groups: Primary choice for instance-level security. Use when you need stateful filtering, or when you want to control traffic based on instance characteristics (e.g., allow SSH only from a specific security group).
Network ACLs: Use when you need a subnet-wide layer of defense (defense in depth), when you need to explicitly deny traffic (e.g., block a specific IP range), or when you need stateless filtering for compliance reasons. Also useful for controlling traffic between subnets in a VPC.
Troubleshooting
If traffic is not reaching an instance, check both the Security Group and Network ACL. Use VPC Flow Logs to see if traffic is being blocked by either layer.
Common mistake: Adding an inbound rule to a Security Group but forgetting to add an outbound rule for the return traffic? Actually, Security Groups are stateful, so outbound return traffic is automatically allowed. But for Network ACLs, you must add both inbound and outbound rules.
Another common mistake: Creating a custom Network ACL and forgetting to add rules, then wondering why all traffic is blocked.
Exam Tips
The exam loves to test the concept of statefulness. A typical question: "An application server receives requests from clients on port 443. The Security Group allows inbound HTTPS. Do you need to add an outbound rule?" Answer: No, because Security Groups are stateful.
Another typical question: "You have a Network ACL that allows inbound HTTP from 0.0.0.0/0. Clients cannot receive responses. What is the problem?" Answer: The Network ACL must also allow outbound traffic on ephemeral ports.
Know the default rules: Custom Security Group allows all outbound by default; custom Network ACL denies all outbound by default.
Remember that Security Groups can reference other Security Groups as sources or destinations, which is useful for tiered architectures (e.g., allow web tier SG to talk to app tier SG).
Packet arrives at subnet boundary
An inbound packet from the internet reaches the VPC and is directed to a specific subnet based on the route table. Before it can enter the subnet, it must pass through the Network ACL associated with that subnet. The Network ACL is a stateless firewall that examines the packet's headers (source IP, destination IP, protocol, source port, destination port). It does not consider any previous packets or connection state. The Network ACL evaluates the packet against its inbound rules in order of rule number (lowest to highest). The first matching rule determines the action (allow or deny). If no rule matches, the packet is denied by the default deny rule (rule *).
Network ACL rule evaluation
The Network ACL processes the packet by comparing it to each rule sequentially. For example, if rule 100 allows TCP traffic on port 80 from 0.0.0.0/0, and the packet is TCP destination port 80, it matches and is allowed. If there is a rule 90 that denies traffic from a specific IP, that rule is checked first. The packet is either allowed or denied immediately upon the first match. This ordered evaluation allows for explicit deny rules that can override later allow rules. The rule number range is 1-32766, with higher numbers evaluated later. It is best practice to leave gaps between rule numbers (e.g., 10, 20, 30) to allow insertion of new rules later.
Packet enters subnet and reaches ENI
If the Network ACL allows the packet, it enters the subnet. The packet then travels to the Elastic Network Interface (ENI) of the target instance. At this point, the Security Group associated with the ENI takes effect. The Security Group is stateful and maintains a connection tracking table. For a new connection (not yet tracked), the Security Group checks its inbound rules. Since Security Groups have no ordered evaluation, all rules are considered. If any rule matches the packet (e.g., allow TCP port 80 from 0.0.0.0/0), the packet is allowed. If no rule matches, the packet is dropped (implicit deny). Once allowed, the connection is tracked, and subsequent packets of the same flow are automatically allowed without rule re-evaluation.
Outbound return traffic from instance
When the instance sends a response packet (e.g., HTTP response), the outbound traffic first hits the Security Group. Because the Security Group is stateful and has tracked the inbound connection, it automatically allows the outbound return traffic regardless of outbound rules. However, if the instance initiates a new outbound connection, the Security Group checks its outbound rules. By default, custom Security Groups have an outbound rule that allows all traffic. If that rule is removed, outbound traffic for new connections would be blocked. After the Security Group, the outbound traffic passes through the Network ACL. The Network ACL evaluates its outbound rules statelessly. For the return traffic to succeed, the Network ACL must have an outbound rule that allows the traffic (e.g., allow TCP ephemeral ports from the subnet to the client). If missing, the response is dropped.
Connection tracking and timeout
Security Groups track the state of connections using a connection tracking table. Each entry includes source IP, destination IP, source port, destination port, and protocol. The table is updated as packets flow. For TCP connections, the tracking starts when the first packet of a handshake is allowed. The connection is considered established after the three-way handshake completes. The idle timeout for TCP connections is 5 minutes (300 seconds). If no packets are exchanged for 5 minutes, the connection is removed from the table. For UDP, the timeout is 30 seconds. If a packet arrives after the timeout, it is treated as a new connection and must match an inbound rule. This is important for long-lived connections or applications with idle periods. The exam may test scenarios where a connection drops after inactivity.
In a typical three-tier web application architecture, Security Groups and Network ACLs are used together for defense in depth. For example, a company hosts a web application with public-facing web servers in a public subnet, application servers in a private subnet, and database servers in another private subnet. The Security Groups are configured as follows: WebSG allows HTTP/HTTPS from 0.0.0.0/0 and allows SSH from a bastion host security group only. AppSG allows traffic only from WebSG on the application port (e.g., 8080). DBSG allows traffic only from AppSG on the database port (e.g., 3306). This ensures that each tier can only communicate with the tier directly above it. Network ACLs are added at the subnet level to provide an additional layer of control. For the public subnet, the Network ACL allows inbound HTTP/HTTPS from 0.0.0.0/0 and outbound ephemeral ports to 0.0.0.0/0. For the private subnets, the Network ACLs are more restrictive: they allow inbound traffic only from the public subnet's CIDR on specific ports and outbound traffic to the public subnet's CIDR for responses. This prevents lateral movement if an instance is compromised. A common misconfiguration is forgetting to update the Network ACL when adding a new port or service. For example, if a developer adds a new application port to the Security Group but forgets to add the corresponding rule to the Network ACL, the traffic will be blocked at the subnet boundary. This leads to hours of debugging. Another issue is when using a custom Network ACL without adding the default ephemeral port outbound rule, causing asymmetric routing or dropped responses. In production, it is common to use VPC Flow Logs to monitor traffic and verify that both Security Groups and Network ACLs are correctly configured. Performance-wise, both Security Groups and Network ACLs operate at line rate and do not introduce significant latency. However, having very large rule sets can impact performance slightly, though AWS optimizes the data plane. The main consideration is to keep rules as simple as possible to ease troubleshooting.
The SOA-C02 exam tests Security Groups and Network ACLs under Objective 5.1: Implement network connectivity and security. Specifically, you must be able to:
Differentiate between stateful and stateless firewalls.
Determine the appropriate use of Security Groups vs Network ACLs.
Configure rules correctly for both inbound and outbound traffic.
Understand default configurations and how they affect connectivity.
Troubleshoot connectivity issues by analyzing which layer is blocking traffic.
The most common wrong answers on exam questions: 1. Assuming Security Groups are stateless. Candidates often confuse the two. Remember: Security Groups are stateful; Network ACLs are stateless. 2. Forgetting that Network ACLs require explicit outbound rules for return traffic. A typical question shows a Network ACL allowing inbound HTTP but not outbound ephemeral ports, and candidates think it works because Security Groups are stateful. But Network ACLs are separate. 3. Thinking that custom Security Groups deny all outbound by default. Actually, custom Security Groups have an outbound rule that allows all traffic. Only inbound is denied by default. 4. **Believing that Network ACL rules are evaluated in order and the first match applies, but forgetting that the default deny (rule *) only applies if no rule matches.** Some candidates think that if no rule matches, the packet is allowed, which is wrong.
Specific numbers and terms that appear verbatim on the exam:
Ephemeral port ranges: 1024-65535, 32768-60999 (Linux), 49152-65535 (Windows).
Rule number range: 1-32766.
Default Network ACL: allows all inbound and outbound (rule 100).
Custom Network ACL: denies all inbound and outbound (rule *).
Security Group: up to 60 inbound and 60 outbound rules per SG (hard limit).
Network ACL: up to 20 rules per ACL (default limit, can be increased).
Edge cases the exam loves: - Security Group self-referencing: A Security Group can reference itself as a source or destination. This is used to allow instances within the same SG to communicate freely. For example, allow all traffic from sg-xxxxxx (the same SG). This is common for multi-tier apps where the SG is used for the web tier and the app tier references it. - Network ACL with deny rules: You can create a deny rule to block specific traffic before allowing other traffic. For example, deny traffic from a known malicious IP range (e.g., 10.0.0.0/8) and then allow all other traffic. The order matters: the deny rule must have a lower number than the allow rule. - Associating a Network ACL with a subnet: A subnet can only be associated with one Network ACL at a time. If you disassociate it, the subnet is associated with the default Network ACL (which allows all). This is a common exam scenario.
To eliminate wrong answers, always start by identifying whether the question involves stateful or stateless behavior. Then check if the rules are bidirectional. If the question is about connectivity from the internet to an instance, both the Network ACL (subnet) and Security Group (instance) must allow the traffic. If only one is mentioned, consider the other. Also, pay attention to the direction: inbound vs outbound. For outbound traffic from an instance, the Security Group must allow it (if it's a new connection) and the Network ACL must allow it. But for return traffic, only the Network ACL matters because Security Groups are stateful.
Security Groups are stateful; Network ACLs are stateless.
Security Groups support only allow rules; Network ACLs support allow and deny rules.
Security Group rules are evaluated collectively; Network ACL rules are evaluated in order by rule number.
The default custom Security Group allows all outbound traffic; the default custom Network ACL denies all outbound traffic.
Network ACLs require explicit outbound rules for ephemeral ports to allow return traffic.
Both Security Groups and Network ACLs must allow traffic for it to reach an instance.
Ephemeral port range for Linux clients: 32768-60999; for Windows: 49152-65535; general safe range: 1024-65535.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Operates at the instance/ENI level
Stateful: automatically allows return traffic
Supports allow rules only (no explicit deny)
Rules evaluated collectively (no order)
Default: inbound deny all, outbound allow all (custom SG)
Network ACL
Operates at the subnet level
Stateless: requires explicit inbound and outbound rules
Supports both allow and deny rules
Rules evaluated in order by rule number (1-32766)
Default: inbound deny all, outbound deny all (custom NACL)
Mistake
Security Groups are stateless and require explicit outbound rules for return traffic.
Correct
Security Groups are stateful. They automatically allow return traffic for connections that were allowed inbound. No explicit outbound rule is needed for the return traffic. However, if the instance initiates a new outbound connection, the outbound rules apply.
Mistake
Network ACLs are stateful and automatically allow return traffic.
Correct
Network ACLs are stateless. Each packet is evaluated independently. You must explicitly allow both inbound and outbound traffic for a communication to succeed. For example, for inbound HTTP, you need an inbound rule allowing port 80 and an outbound rule allowing ephemeral ports for the response.
Mistake
Custom Security Groups deny all outbound traffic by default.
Correct
When you create a custom Security Group, it has an outbound rule that allows all traffic (0.0.0.0/0 on all ports). Only inbound traffic is denied by default. You must explicitly add inbound rules to allow traffic in.
Mistake
Network ACL rules are evaluated in order, and the last rule (rule *) allows all traffic.
Correct
Rule * is a default deny rule that applies only if no other rule matches. It does not allow all traffic; it denies all traffic. The default Network ACL has a rule 100 that allows all, but custom Network ACLs have rule * as deny.
Mistake
You can associate a Network ACL with multiple subnets, but a subnet can have multiple Network ACLs.
Correct
A Network ACL can be associated with multiple subnets (one-to-many). However, a subnet can be associated with only one Network ACL at a time. If you associate a different Network ACL, the previous association is removed.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Security Groups are stateful. When you allow inbound traffic (e.g., HTTP on port 80), the Security Group automatically tracks the connection and allows outbound return traffic without needing an explicit outbound rule. This is a key difference from Network ACLs. However, if the instance initiates a new outbound connection (e.g., to download updates), you need an outbound rule allowing that traffic.
Check the Network ACL associated with the subnet. The Network ACL is stateless and must allow inbound HTTP (port 80) and outbound ephemeral ports (1024-65535) for the return traffic. If the Network ACL blocks the return traffic, the client never receives the response. Also verify that the route table has a route to the internet gateway.
No, Security Groups only support allow rules. To block a specific IP, you must use a Network ACL with a deny rule. For example, create a Network ACL rule with a lower number that denies traffic from that IP, and then allow all other traffic with a higher-numbered rule. Alternatively, you can use a Security Group with a source that excludes that IP, but that is not a clean block.
A custom Network ACL initially denies all inbound and outbound traffic. It has a single default rule (rule *) that denies all traffic. You must add rules to allow desired traffic. This is opposite to the default VPC Network ACL, which allows all traffic.
Yes, a Security Group can be associated with multiple instances (and ENIs). In fact, it's common to use the same Security Group for all instances in a tier. Conversely, an instance can have multiple Security Groups (up to 5 by default). The rules from all associated Security Groups are combined (union) when evaluating traffic.
Security Groups track UDP connections similarly to TCP, but the idle timeout is shorter: 30 seconds for UDP. If no packets are exchanged for 30 seconds, the connection is removed from the tracking table. Subsequent packets are treated as a new connection and must match an allow rule. This is important for applications like DNS or VoIP that may have gaps in traffic.
If you disassociate a Network ACL from a subnet, the subnet automatically becomes associated with the VPC's default Network ACL (which allows all inbound and outbound traffic). This can be a security risk if you intended to have a restrictive ACL. Always ensure you have a replacement ACL ready before disassociating.
You've just covered Network ACLs vs Security Groups Deep Dive — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?