The core distinction
Security groups and NACLs both control traffic in a VPC. They are not interchangeable. Knowing which one to use — and why — is tested repeatedly on the AWS SAA-C03 exam.
Security group: Applied to an EC2 instance (or an elastic network interface). Stateful — if you allow inbound traffic on port 443, the return traffic is automatically allowed outbound without an explicit outbound rule. Default behaviour: deny all inbound, allow all outbound.
Network ACL (NACL): Applied to a subnet. All instances in the subnet are affected. Stateless — return traffic must be explicitly allowed by a separate outbound rule. Rules are evaluated in numerical order and the first match wins. Default behaviour (default NACL): allow all inbound and outbound.
The stateful vs stateless trap
This is the most tested distinction. The exam describes a scenario where a rule is added to allow inbound traffic, but responses are not returning. The question asks why.
If the solution involves a security group, this scenario cannot happen — security groups automatically allow return traffic (stateful). If the solution involves a NACL, it can and does happen. A NACL rule allowing inbound HTTPS (port 443) does not automatically allow the response traffic on the ephemeral port range (1024-65535). You must add an explicit outbound rule permitting traffic on those ephemeral ports.
When you see "traffic is being dropped on the return path" in an AWS question, the answer is almost always a missing NACL outbound rule — not a missing security group rule.
Rule evaluation order matters for NACLs, not for security groups
NACL rules are evaluated in number order. Rule 100 is evaluated before rule 200. The first matching rule wins, and the rest are ignored. A DENY rule at 90 will block traffic even if an ALLOW rule at 100 permits it.
Security groups do not use rule numbers. All rules are evaluated, and if any rule permits the traffic, it is allowed. You cannot create a DENY rule in a security group — only ALLOW rules exist. To block specific traffic with a security group, you remove the permit rule. NACLs allow explicit DENY rules.
Layered defence with both
The exam often presents a scenario where you need to block a specific IP address from reaching any instance in a subnet, while still allowing other traffic. Security groups cannot block specific IPs with a DENY rule — you would have to modify every instance's security group. A NACL DENY rule at a low number blocks the IP for all instances in the subnet in one change.
This is the intended use case for NACLs: subnet-level blocking of known bad actors. Security groups handle per-instance allow rules.
Default NACL vs custom NACL behaviour
The default NACL (created automatically with each VPC) allows all inbound and outbound traffic. Instances are initially open to the network — the security group is what provides protection.
A custom NACL (one you create and associate) starts with an implicit DENY ALL. You must add explicit allow rules, including the ephemeral port range for return traffic. Failing to add the ephemeral outbound rule is the most common NACL configuration mistake — and the most common SAA-C03 exam trap.
Which to use: exam answer guidance
The exam will describe a requirement and ask which control to apply. Use this logic:
- Block a specific IP for all instances in a subnet → NACL (subnet-level, supports DENY)
- Allow traffic to specific instances only → Security group (instance-level)
- Concerned about return traffic being blocked → NACL issue (stateless); security groups handle return automatically
- Need to allow only HTTPS to an EC2 instance → Security group inbound rule, port 443, source 0.0.0.0/0
- Need to explicitly deny traffic at the subnet border → NACL DENY rule
Practice AWS VPC questions
AWS SAA-C03 practice questions on Courseiva include VPC design, security group, and NACL scenarios. The AWS VPC fundamentals topic guide covers routing, subnets, gateways, and security controls. For the certification overview, see the AWS SAA-C03 exam page.
Frequently asked questions
Can I apply a security group to a subnet? No. Security groups apply to EC2 instances (technically to their ENIs). NACLs apply to subnets. This is a common confusion and appears in distractor answers.
What is the ephemeral port range? Ephemeral ports (also called dynamic or short-lived ports) are the temporary ports used for return traffic. AWS recommends allowing 1024-65535 for inbound NACL return rules. Linux uses 32768-60999 by default. The SAA-C03 exam uses 1024-65535 as the range.
Do NACLs apply to traffic between instances in the same subnet? No. NACLs only evaluate traffic entering and leaving the subnet boundary. Traffic between two instances in the same subnet does not cross the NACL. Security groups do apply to this traffic.
Stateful vs Stateless — A Concrete Example That Makes It Stick
The difference between stateful (Security Groups) and stateless (NACLs) isn't just a vocabulary distinction — it determines which rules you have to write and on which resource.
Take a web client connecting to an EC2 instance on port 443:
The TCP three-way handshake: the client sends a SYN from a random ephemeral port (say 54321) to the server at port 443. The server sends SYN-ACK back to the client's source port 54321. The client sends ACK.
With a Security Group (stateful):
- Inbound rule needed: allow TCP port 443 from 0.0.0.0/0
- The SG tracks the connection state. When the server sends its response back to port 54321, the SG automatically allows it through without a matching outbound rule. You don't need an outbound rule for port 54321.
- Result: one rule written (inbound 443), return traffic allowed automatically
With a NACL (stateless):
- Inbound rule needed: allow TCP port 443 from 0.0.0.0/0 (the client's SYN arriving)
- Outbound rule needed: allow TCP ports 1024-65535 to 0.0.0.0/0 (the server's response going back to the client's ephemeral port)
- Additionally: the client's NACL needs outbound TCP 443 AND inbound TCP 1024-65535 for the return traffic
- Result: four rules written across two NACLs, or the single-direction flow breaks
Every time you add a NACL rule for a service, you must also add the ephemeral port return-traffic rule. Forgetting the ephemeral port range is the most common NACL misconfiguration — and the most commonly tested trap.
NACL Rule Numbering Strategy — Why 10, 20, 30 Not 1, 2, 3
NACLs evaluate rules in ascending numeric order, stopping at the first match. Rule 100 is evaluated before rule 200. If you number rules 1, 2, 3, ... you have no room to insert a rule between 1 and 2 later. You'd have to renumber everything.
The convention is to space rules by 10 (or 100 for less frequent changes). This leaves room to insert a rule between 10 and 20 by numbering it 15.
A practical example from exam scenarios: you have a rule allowing all HTTP inbound (port 80) at rule 100. You need to add a rule blocking a specific malicious IP range (203.0.113.0/24). You add it at rule 90 — before the allow-all rule at 100. NACL processes 90 first, matches the malicious IP, returns DENY, and never reaches rule 100.
This ordering behavior is why NACLs are used for broad blocking at the network level: you can deny entire IP ranges before any allow rules process. Security Groups can only allow — you can't explicitly deny a specific IP in a Security Group rule.
The NACL Ephemeral Port Trap — The Most Missed Question
This is worth reading twice because it's the single most frequently tested NACL detail on the SAA-C03 exam.
When a client makes a TCP connection, the operating system assigns a source port from the ephemeral range. On Linux, this is typically 32768-60999. On Windows, it's 49152-65535. AWS documentation uses 1024-65535 as the conservative range to cover all clients.
The problem: NACLs are stateless. When a web server responds to a client HTTP request, the response packet has:
- Source: the server's IP, port 80
- Destination: the client's IP, ephemeral port (e.g., 54321)
For this response to flow out of the web server's subnet, the NACL on that subnet needs an outbound rule allowing TCP to ports 1024-65535. Many people write "allow outbound port 80" assuming the response goes back out on port 80. It doesn't — the response destination port is the client's ephemeral port.
The exam question: "Users cannot reach a web application. The EC2 instances have a Security Group allowing inbound port 80. A NACL on the public subnet allows inbound TCP port 80 and outbound TCP port 80. Why can't users reach the application?"
Answer: the NACL outbound rule allows port 80, but the response traffic goes to the client's ephemeral port (1024-65535). The outbound NACL rule needs to allow TCP 1024-65535 outbound (or all TCP outbound), not just port 80.
VPC Flow Logs — When the Exam Asks About Troubleshooting
VPC Flow Logs capture metadata about IP traffic to and from network interfaces in your VPC. They don't capture packet contents, but they capture enough to diagnose whether traffic is being allowed or denied.
Each flow log record includes: source IP, destination IP, source port, destination port, protocol, packets, bytes, start/end time, and — most importantly — action (ACCEPT or REJECT).
The action field tells you which layer is blocking traffic:
- If flow logs show ACCEPT but the application still fails: the packet reached the instance, but the application rejected it (wrong port, wrong config, application error). Security groups and NACLs are not the problem.
- If flow logs show REJECT: a Security Group or NACL is dropping the traffic. Check both.
The distinction the exam tests: Security Groups log accepted traffic only by default — you won't see rejected SG traffic unless you have flow logs at the ENI or subnet level. NACLs log both ACCEPT and REJECT. If you need to determine whether traffic is being blocked by a NACL (as opposed to a Security Group), flow logs are the diagnostic tool.
Flow logs can be published to CloudWatch Logs or S3. They have a delivery delay of several minutes — they're for post-hoc analysis, not real-time monitoring.
SG References vs CIDR — When to Use Each
Security Groups can allow traffic from a CIDR range (e.g., 10.0.0.0/8) or from another Security Group (e.g., sg-XXXXXXXX). The difference matters for dynamic environments.
CIDR-based rules: allow traffic from a specific IP range. Works when the source IPs are static and predictable. The problem: if an Auto Scaling group launches new instances, their IPs are dynamic and might not fall within a pre-specified range.
Security Group reference: allow traffic from any ENI that is a member of a specific Security Group. When the ASG launches a new instance and attaches the specified SG to it, that instance immediately qualifies to send traffic — even though its IP was unknown at rule creation time.
The exam scenario: "An application tier ASG needs to access a database tier. The application tier instances get dynamic private IPs from Auto Scaling. What Security Group rule on the database SG allows only app tier traffic?"
Answer: reference the application tier's Security Group in the database SG's inbound rules. Don't use the VPC CIDR — that would allow any instance in the VPC, not just the app tier.
SG references also simplify scaling: as the app tier scales from 5 to 50 instances, the database SG rule doesn't change. It references the SG, and all members of that SG automatically qualify.
Practice Question Sets
Working through real SAA-C03 questions is the fastest way to lock in how the exam phrases these scenarios. Pick a session that fits your time: