This chapter provides a deep dive into two fundamental AWS security components: Security Groups and Network ACLs (NACLs). Both control traffic in your VPC, but they operate at different layers and have distinct behaviors that are heavily tested on the SAA-C03 exam. Approximately 15-20% of exam questions touch on VPC security, with many specifically testing the differences between stateful and stateless firewalls. By the end of this chapter, you will understand exactly when to use each, how they interact, and how to avoid common configuration mistakes that lead to security gaps or connectivity failures.
Jump to a section
Imagine a multi-tenant office building with two layers of security. The first layer is a security guard at the entrance of each individual office suite. This guard is stateful: he keeps a clipboard listing all outgoing employees and only allows return visitors who match an outgoing entry. He can block or allow traffic based on the employee's identity (IP address) and can make decisions based on the conversation context (state). He does not care about the floor or the building entrance — only his specific suite. This is a Security Group. The second layer is the building's main gate, operated by a gatekeeper who checks a list of allowed license plates (IPs) and port numbers. The gatekeeper is stateless: he has no memory of past traffic. Every car must be checked against the list both entering and exiting, regardless of whether it just left. He can block entire floors (subnets) but cannot track individual conversations. This is a Network ACL. In the AWS cloud, Security Groups operate at the instance level (like the suite guard) and are stateful, automatically allowing return traffic. NACLs operate at the subnet level (like the building gate) and are stateless, requiring explicit rules for both inbound and outbound traffic. Understanding this distinction is crucial for designing secure VPC architectures.
What Are Security Groups and NACLs?
Security Groups (SGs) and Network ACLs (NACLs) are virtual firewalls for your Amazon VPC. They filter traffic at the instance and subnet levels respectively. The SAA-C03 exam expects you to know their differences cold, including statefulness, rule evaluation, and default behaviors.
Security Groups: Instance-Level Stateful Firewall
A Security Group acts as a virtual firewall for an EC2 instance (or other resources like ENI, RDS, Lambda). It operates at the instance level, meaning you attach one or more SGs to an instance, and all traffic to/from that instance is evaluated against the SG rules.
Stateful: If you allow inbound traffic on port 80 (HTTP), the SG automatically allows the outbound return traffic, regardless of outbound rules. Similarly, if you allow outbound traffic, the return inbound traffic is allowed automatically.
Default Behavior: When you create a new SG, it has no inbound rules (all inbound traffic is denied by default). The default outbound rule allows all traffic (0.0.0.0/0). You cannot modify these default rules; you can only add or remove custom rules.
Rule Evaluation: All rules are evaluated together. There is no priority order; if any rule allows the traffic, it is allowed. The SG uses a 'permit' model: only explicitly allowed traffic is permitted; all other traffic is implicitly denied.
Supported Rules: You can specify allow rules based on protocol (TCP, UDP, ICMP), port range, and source/destination CIDR or another SG ID. You cannot create deny rules; you can only allow or not allow.
Limits: You can have up to 5 SGs per ENI (default limit, can be increased). Each SG can have up to 60 inbound and 60 outbound rules (default).
Use Cases: SGs are ideal for instance-level security where you want to allow specific traffic (e.g., web server allowing HTTP/HTTPS from the internet, but SSH only from a management subnet).
Network ACLs: Subnet-Level Stateless Firewall
A Network ACL is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. It operates at the subnet level, meaning all instances in the subnet are subject to the same NACL rules.
Stateless: NACLs do not track connection state. You must explicitly allow both inbound and outbound traffic for each direction. For example, if you allow inbound HTTP traffic from the internet, you must also allow outbound return traffic (ephemeral ports) from the instance back to the internet.
Default Behavior: Each VPC comes with a default NACL that allows all inbound and outbound traffic. When you create a custom NACL, it denies all inbound and outbound traffic by default (implicit deny). You must add rules to allow desired traffic.
Rule Evaluation: Rules are evaluated in numerical order, from lowest to highest. The first rule that matches the traffic (allow or deny) is applied. You can create both allow and deny rules. This allows you to block specific IPs while allowing others.
Rule Numbers: You assign a number (1-32766) to each rule. AWS recommends leaving gaps (e.g., 100, 200, 300) to insert rules later. The last rule (default) is an asterisk (*) that denies all traffic; it cannot be removed.
Ephemeral Ports: Because NACLs are stateless, you must explicitly allow return traffic on ephemeral ports. For example, for inbound HTTP from the internet, you need an outbound rule allowing traffic on high ports (1024-65535) to the internet. Common ephemeral port ranges: 1024-65535 for many OSs, but AWS documentation often uses 32768-65535 for Linux.
Limits: You can have up to 20 rules per NACL (inbound + outbound combined, but each direction has its own set). Each rule can specify a CIDR, protocol, port range, and allow/deny.
How They Interact
When traffic reaches an instance, both the NACL (subnet level) and the SG (instance level) are evaluated. The NACL is evaluated first (since it's at the subnet boundary), then the SG. For traffic to be allowed, BOTH must permit it. If either denies, the traffic is blocked.
Example: An EC2 instance in a public subnet with a SG allowing HTTP (port 80) from 0.0.0.0/0. The subnet NACL must also allow inbound HTTP from 0.0.0.0/0 and outbound ephemeral ports to 0.0.0.0/0. If the NACL denies inbound HTTP, the traffic never reaches the SG.
Configuration and Verification
You can manage SGs and NACLs via AWS Management Console, CLI, or SDK.
Security Group CLI Example:
# Create a security group
aws ec2 create-security-group --group-name WebSG --description "Web server SG" --vpc-id vpc-12345
# Add inbound rule for HTTP
aws ec2 authorize-security-group-ingress --group-id sg-12345 --protocol tcp --port 80 --cidr 0.0.0.0/0
# Add inbound rule for SSH from a specific IP
aws ec2 authorize-security-group-ingress --group-id sg-12345 --protocol tcp --port 22 --cidr 203.0.113.0/24
# Describe security groups
aws ec2 describe-security-groups --group-ids sg-12345Network ACL CLI Example:
# Create a NACL
aws ec2 create-network-acl --vpc-id vpc-12345
# Add inbound rule to allow HTTP (rule number 100)
aws ec2 create-network-acl-entry --network-acl-id acl-12345 --ingress --rule-number 100 --protocol tcp --port-range From=80,To=80 --cidr-block 0.0.0.0/0 --rule-action allow
# Add outbound rule to allow return traffic (ephemeral ports)
aws ec2 create-network-acl-entry --network-acl-id acl-12345 --egress --rule-number 100 --protocol tcp --port-range From=32768,To=65535 --cidr-block 0.0.0.0/0 --rule-action allow
# Describe NACLs
aws ec2 describe-network-acls --network-acl-ids acl-12345How They Work Internally
Security Group Statefulness: The SG uses a connection tracking table. When an outbound packet is sent, the SG records the tuple (source IP, source port, destination IP, destination port, protocol). When the return packet arrives, it matches the reverse tuple and is allowed automatically, even if no inbound rule explicitly permits it. The table entries are aged out after a timeout (e.g., TCP connections after 5 minutes of inactivity, UDP after 30 seconds). This stateful behavior simplifies configuration because you don't need to manage return traffic rules.
NACL Statelessness: The NACL has no connection tracking. Each packet is evaluated independently against the inbound or outbound rule set. This means you must explicitly allow traffic in both directions. The stateless nature makes NACLs more predictable but also more complex to configure correctly, especially for protocols that use dynamic ports (like FTP or SIP).
Key Differences Summary
| Feature | Security Group | Network ACL | |---------|----------------|-------------| | Level | Instance (ENI) | Subnet | | Statefulness | Stateful | Stateless | | Default Rules | Deny all inbound, allow all outbound | Allow all inbound and outbound (default NACL) or Deny all (custom) | | Rule Types | Allow only | Allow and Deny | | Rule Evaluation | All rules evaluated together | Ordered, first match wins | | Supports Deny Rules | No | Yes | | Supports SG ID as source/destination | Yes | No (only CIDR) | | Applies to | Instances, ENIs, RDS, etc. | All instances in subnet | | Use Case | Instance-level granularity | Broad subnet-level allow/deny |
Exam Relevance
The SAA-C03 exam frequently tests the distinction between stateful and stateless. You will see scenarios where a misconfigured NACL blocks traffic that appears to be allowed by the SG. Remember: if traffic is not reaching the instance, check the NACL first. Also, know that SGs cannot block traffic from specific IPs (no deny rules); you must use NACLs for that (or host-based firewalls). Another common trap: when you create a custom NACL, it denies all traffic by default, so you must add rules to allow necessary traffic, including ephemeral ports.
Traffic enters subnet
When a packet arrives at the subnet boundary (e.g., from an internet gateway), the VPC router directs it to the appropriate subnet. The NACL associated with that subnet is evaluated first. The packet is checked against the inbound rules in numerical order. If a rule matches and allows, the packet proceeds; if a rule matches and denies, it is dropped; if no rule matches, the default deny rule (asterisk) drops it. The NACL is stateless, so it does not remember this packet.
Traffic reaches instance
If the NACL allows the packet, it is forwarded to the instance's ENI. The Security Group(s) attached to the ENI are then evaluated. The SG checks its inbound rules. Since the SG is stateful, if the packet is a response to an outbound connection that was allowed, it will be permitted even without a specific inbound rule. Otherwise, an inbound rule must explicitly allow the traffic. If no rule allows, the packet is dropped at the instance level.
Response traffic from instance
When the instance sends a response, the SG checks its outbound rules. By default, outbound traffic is allowed. If a custom outbound rule is present, it must allow the traffic. The SG updates its connection tracking table with the flow information. The packet then leaves the ENI and enters the subnet.
Response leaves subnet
The outbound packet is evaluated by the NACL's outbound rules. Because the NACL is stateless, it must have an explicit allow rule for the response traffic (e.g., ephemeral ports). If the rule exists, the packet is forwarded to the destination (e.g., internet gateway). If not, the packet is dropped. This is a common misconfiguration: allowing inbound HTTP but forgetting the outbound ephemeral port rule.
Connection tracking timeout
For stateful SGs, the connection tracking entry is maintained for the duration of the flow. For TCP, the entry is kept for 5 minutes after the last packet (configurable via timeout). For UDP, it's 30 seconds. If no packets are seen within the timeout, the entry is removed. This means if a connection is idle for longer than the timeout, subsequent packets may be treated as new and require explicit rules. This is rarely an issue for most applications but can affect long-lived idle connections.
Scenario 1: Web Application with Public and Private Subnets
A typical three-tier architecture uses public subnets for load balancers and private subnets for application and database servers. Security Groups are used to allow traffic only between specific tiers. For example, the ALB SG allows HTTP/HTTPS from the internet (0.0.0.0/0). The web server SG allows HTTP from the ALB SG (by referencing the ALB SG ID). The database SG allows MySQL (port 3306) from the web server SG. NACLs are used as a second layer of defense. The public subnet NACL allows inbound HTTP/HTTPS from 0.0.0.0/0 and outbound ephemeral ports to 0.0.0.0/0. The private subnet NACL only allows inbound traffic from the public subnet CIDR on the application port and outbound traffic to the internet for updates (e.g., on port 443). This layered approach ensures that even if a security group is misconfigured, the NACL provides a safety net. A common mistake is forgetting to update the NACL when adding a new service, causing mysterious connectivity issues.
Scenario 2: Blocking Malicious IPs at Scale
NACLs are ideal for blocking specific IP addresses or ranges because they support deny rules. For example, if an application is under DDoS attack from a set of IPs, you can add a deny rule in the NACL (with a low rule number) to block that traffic before it reaches the instances. Security Groups cannot do this because they only support allow rules. However, NACLs have a limit of 20 rules per direction, so for large blocklists, you might need to use a web application firewall (WAF) or third-party solutions. In production, NACLs are often used to block known bad actors at the subnet boundary, reducing load on instances.
Scenario 3: Compliance and Audit Requirements
Many compliance frameworks (e.g., PCI DSS, HIPAA) require network segmentation and logging. NACLs provide a clear, ordered set of rules that can be audited. Because they are evaluated in order, you can create a 'default deny' posture and only allow specific traffic. This is often required for regulated environments. Security Groups, while also auditable, are less granular because they cannot deny specific IPs. In such environments, both are used together: NACLs for broad subnet-level controls (e.g., deny all traffic from a specific network) and SGs for instance-level micro-segmentation.
The SAA-C03 exam tests NACLs vs Security Groups under Objective 1.1 (Design secure access to AWS resources). Expect 2-4 questions that directly compare them or require you to troubleshoot connectivity. The most common wrong answers stem from confusing stateful vs stateless behavior.
Common Wrong Answers and Why: 1. 'Security Groups are stateless.' This is false. SGs are stateful. Candidates often remember that NACLs are stateless and assume SGs are too. Remember: Security Groups automatically allow return traffic; NACLs do not. 2. 'NACLs evaluate all rules together.' False. NACLs evaluate rules in order, first match wins. Security Groups evaluate all rules together (any allow = allow). 3. 'You can block a specific IP using a Security Group.' False. SGs only support allow rules. To block an IP, you need a NACL deny rule or a host-based firewall. 4. 'Default NACL denies all traffic.' This is true only for custom NACLs. The default NACL (created with VPC) allows all inbound and outbound traffic. The exam often tests this nuance.
Specific Numbers and Values: - Security Group limits: 5 per ENI, 60 rules per SG (inbound+outbound). - NACL limits: 20 rules per NACL (per direction). - Ephemeral port ranges: 1024-65535 or 32768-65535 (AWS documentation often uses 32768-65535 for Linux). - Default NACL: allows all inbound and outbound (rule number 100). - Custom NACL: denies all inbound and outbound until rules are added.
Edge Cases: - When you associate a custom NACL with a subnet, all existing traffic is immediately subject to the new rules. This can cause connectivity drops if you haven't added necessary allow rules. - Security Groups can reference other SGs as source/destination. This allows for dynamic security: when you add a new instance to a SG, it automatically can communicate with other instances that reference that SG. NACLs cannot reference SGs; they only accept CIDR blocks. - For VPC peering, NACLs and SGs work the same way, but SGs can reference SGs in the peered VPC (if the VPCs are in the same region and account).
How to Eliminate Wrong Answers: - If the question involves blocking a specific IP address, the answer must involve NACLs (or a host-based firewall). Security Groups cannot do this. - If the question involves 'return traffic' or 'automatically allowed', the answer is likely Security Groups (stateful). - If the question mentions 'ordered rules' or 'deny rules', it's NACL. - If the question is about 'subnet-level security', it's NACL; if 'instance-level', it's SG. - Always check for 'default deny' vs 'default allow' when a new custom NACL is created.
Security Groups are stateful; Network ACLs are stateless.
Security Groups support only allow rules; NACLs support both allow and deny.
NACL rules are evaluated in numerical order; SG rules are all evaluated together.
Default NACL allows all traffic; custom NACL denies all traffic by default.
Security Groups can reference other SGs as source/destination; NACLs cannot.
For traffic to reach an instance, both the NACL and SG must allow it.
Ephemeral ports (e.g., 32768-65535) must be allowed in NACL outbound rules for return traffic.
Maximum of 5 SGs per ENI, 60 rules per SG; maximum of 20 rules per NACL per direction.
Use NACLs to block specific IPs; use SGs for instance-level micro-segmentation.
When troubleshooting connectivity, check NACL first (subnet level) then SG (instance level).
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 deny)
All rules evaluated together (any allow = allow)
Can reference other Security Groups as source/destination
Network ACL
Operates at the subnet level
Stateless: requires explicit allow for both directions
Supports both allow and deny rules
Rules evaluated in numerical order, first match wins
Only supports CIDR blocks (no Security Group references)
Mistake
Security Groups and NACLs are interchangeable; you only need one.
Correct
They are complementary. SGs operate at the instance level and are stateful; NACLs operate at the subnet level and are stateless. Best practices use both for defense in depth.
Mistake
Security Groups can block traffic from specific IP addresses by adding a deny rule.
Correct
Security Groups only support allow rules. To block specific IPs, you must use a Network ACL with a deny rule or a host-based firewall like iptables.
Mistake
The default VPC NACL denies all inbound traffic.
Correct
The default NACL (created with VPC) allows all inbound and outbound traffic. Custom NACLs deny all traffic by default.
Mistake
NACLs are stateful because they use connection tracking.
Correct
NACLs are stateless. They do not track connections. You must explicitly allow both inbound and outbound traffic. Security Groups are stateful and use connection tracking.
Mistake
You can use Security Group IDs in NACL rules to allow traffic from specific instances.
Correct
NACL rules only support CIDR blocks, not Security Group IDs. Only Security Groups can reference other Security Groups as sources or destinations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, Security Groups only allow rules; they cannot deny traffic. To block a specific IP, you must use a Network ACL with a deny rule (or a host-based firewall). For example, to block 1.2.3.4, add a NACL inbound rule with rule number 100, source 1.2.3.4/32, action DENY. This is a common exam trap: candidates often think SGs can block IPs.
A custom NACL denies all inbound and outbound traffic by default. Immediately upon association, all traffic to/from the subnet will be blocked unless you have added appropriate allow rules. This includes traffic that was previously allowed by the default NACL. Always ensure you have added necessary rules before associating a custom NACL to avoid connectivity loss.
You need two rules: an inbound rule allowing TCP on port 80 from the source (e.g., 0.0.0.0/0) and an outbound rule allowing TCP on ephemeral ports (e.g., 32768-65535) to the same destination. Because NACLs are stateless, the return traffic must be explicitly allowed. This is a frequent exam scenario.
Yes, a Security Group has separate inbound and outbound rule sets, but they are part of the same SG. You can add rules to both directions. However, because SGs are stateful, you often only need to worry about inbound rules; outbound return traffic is automatically allowed. For outbound-initiated traffic, you need outbound allow rules.
The default NACL is created automatically with each VPC and allows all inbound and outbound traffic (rule 100). A custom NACL you create denies all inbound and outbound traffic until you add allow rules. The default NACL cannot be deleted, but you can replace it with a custom one by associating the custom NACL with the subnet.
Security Groups are stateful, meaning they track connections. When an outbound packet is allowed, the SG creates a connection tracking entry. Return packets matching that entry are automatically allowed, regardless of inbound rules. This tracking is based on the 5-tuple (source IP, source port, destination IP, destination port, protocol).
No, NACL rules only accept CIDR blocks. They cannot reference Security Group IDs. If you need to allow traffic based on instance membership, you must use Security Groups. For example, to allow traffic from all instances in a particular SG, you would use that SG as the source in a Security Group rule, not a NACL.
You've just covered NACLs vs Security Groups: Deep Dive — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?