Security Groups and NACLs — Stateful vs Stateless, Advanced Scenarios

Why Security Groups and NACLs Matter for ANS-C01

Security Groups (SGs) and Network Access Control Lists (NACLs) are the two foundational packet-filtering controls in Amazon VPC, and the ANS-C01 exam tests them with surgical precision. Every Domain 4 task statement 4.1 question that involves "why is my traffic blocked" or "design a multi-tier secure VPC" hinges on whether you can recite, instantly and correctly, the differences between stateful and stateless filtering, the ephemeral port range, the order of evaluation, and the cross-VPC referencing rules. Candidates who passed ANS-C01 almost universally cite SG/NACL trap questions as the area with the most question density relative to study time invested.

In this Specialty-depth study guide we walk through Security Groups and NACLs from the protocol level up: how stateful connection tracking actually works, why NACLs need explicit ephemeral-port outbound rules, how to reference SGs across accounts and VPCs, the precise rule evaluation order for NACLs (numbered, first-match-wins, terminating), the limits and quotas you must know, the standard multi-tier and perimeter VPC patterns, integration with VPC endpoint policies, and how AWS Firewall Manager applies organization-wide SG baselines.

By the end of this guide you should be able to read any ANS-C01 SG/NACL question and identify the trap before you reach the answer choices. We close with FAQ, scenario walkthroughs, and a Mandarin trap callout list.

Security Groups: Stateful by Design

A Security Group is a virtual stateful firewall attached to an Elastic Network Interface (ENI). When traffic arrives at the ENI, the SG evaluates whether the traffic is permitted by an inbound rule. When the workload responds, the SG automatically allows the return traffic regardless of outbound rules. This is what "stateful" means: the SG remembers active connections and permits the return half automatically.

Inbound and outbound rules

Each SG has two rule sets: inbound rules and outbound rules. Both are allow-only — there is no "deny" rule in a Security Group. Each rule has a protocol (TCP, UDP, ICMP, or a numeric protocol), a port range (single port, range, or "all"), and a source or destination, which can be a CIDR block, another security group ID, or a managed prefix list.

By default, every SG starts with no inbound rules (deny all inbound) and one outbound rule that allows all traffic to 0.0.0.0/0. Modifying these defaults is one of the first things you do when locking down a workload. The exam often tests whether the candidate remembers that the default outbound rule allows everything — failing to remove it is a common security finding.

Security group rule evaluation

Within a single SG, all rules are evaluated as a logical OR — a packet is allowed if any rule matches. There is no order, no priority, and no first-match logic. If you attach multiple SGs to an ENI (up to 5 by default, raisable to 16), the union of all rules across all SGs applies.

This is fundamentally different from a traditional firewall where rule order matters. In an SG world, you cannot write "allow X" and then "deny everything else" — the deny is implicit (no rule means no allow). To "deny," you simply do not add an allow rule.

Stateful connection tracking details

Stateful tracking in AWS uses connection-tracking entries in the underlying Hyperplane infrastructure. For TCP, each connection is tracked by the 5-tuple (source IP, source port, destination IP, destination port, protocol) plus the TCP state machine (SYN, SYN-ACK, ESTABLISHED, FIN, RST). For UDP, AWS uses pseudo-state with idle timeouts. For ICMP, AWS tracks request/reply pairs.

A subtle but exam-relevant detail: very high-rate connections (more than 100,000 per second per ENI) can exceed the connection tracking budget and force AWS to mark some connections as "untracked," which means the return traffic is no longer auto-permitted. This is rarely tested directly but explains some operational anomalies.

NACLs: Stateless and Numbered

A Network Access Control List (NACL) is a stateless packet filter applied at the subnet boundary. Stateless means every packet — including return traffic for an established connection — is evaluated independently against both inbound and outbound rules. A NACL has no memory of past packets.

NACL rules and evaluation order

NACL rules are numbered (typically in increments of 100: rule 100, 200, 300...). Within each direction, rules are evaluated in ascending numerical order, and the first matching rule terminates the evaluation. This is fundamentally different from SGs: in NACLs, rule order matters absolutely.

Each rule specifies a number, protocol, port range, source or destination CIDR, and an action — ALLOW or DENY. NACLs support both ALLOW and DENY actions, unlike SGs.

The default NACL allows all inbound and all outbound traffic. A custom NACL denies all inbound and all outbound traffic by default — you must add explicit allow rules. The exam loves to test the difference: a freshly created custom NACL is far more restrictive than the default NACL.

Ephemeral ports — the most common NACL trap

Because NACLs are stateless, return traffic is not automatically allowed. When a client in your VPC initiates an outbound TCP connection to a server on port 443, the server replies from port 443 to a randomly chosen ephemeral port on the client (typically in the range 1024–65535 on Linux, 49152–65535 on Windows). Without an inbound NACL rule allowing the ephemeral port range, the response packets are dropped at the subnet boundary.

This is the highest-frequency NACL trap on ANS-C01. The "obvious" answer to "why can my EC2 instance not download from the internet" is "missing outbound rule" — but the actual answer is often "missing inbound NACL rule for ephemeral ports."

NACL rule numbering strategy

Best practice is to space rule numbers in increments of 100 to leave room for insertions. The wildcard rule * DENY always exists at the bottom and cannot be removed. AWS-defined rule numbers must be between 1 and 32766; numbers above 32766 are reserved.

A common pattern is:

• 100: ALLOW HTTPS inbound from 0.0.0.0/0 to TCP 443
• 200: ALLOW SSH inbound from 10.0.0.0/8 to TCP 22
• 300: ALLOW ephemeral inbound from 0.0.0.0/0 to TCP 1024-65535
• 400: DENY all from compromised CIDR
• *: DENY (implicit)

If rule 100 (ALLOW HTTPS) appears before rule 200 (DENY HTTPS from a specific CIDR), the ALLOW wins because it matches first. To DENY a specific CIDR, the DENY rule must be numbered lower than the ALLOW rule. This is one of the most-tested NACL behaviors on ANS-C01.

Security Group vs NACL: Side-by-Side

Security Group Referencing

One of the most powerful SG features — and one of the most tested — is the ability to reference another SG as the source or destination of a rule. Instead of writing "allow inbound from 10.0.1.0/24," you can write "allow inbound from sg-12345678" (the SG attached to your application servers). This is dynamic: as instances are launched and terminated, the SG membership updates automatically without rule edits.

Same-VPC SG referencing

Within a single VPC, SG-to-SG references work natively. The classic three-tier pattern uses three SGs (web, app, db) and references each tier from the next:

• Web SG: allows TCP 443 from 0.0.0.0/0
• App SG: allows TCP 8080 from web SG
• DB SG: allows TCP 5432 from app SG

This pattern enforces strict tier separation: even if an attacker compromises the web tier, they can only reach the app tier on TCP 8080 — they cannot connect to the DB directly because their source SG is the web SG, not the app SG. ANS-C01 calls this "micro-segmentation by security group reference."

Cross-VPC SG referencing

SG-to-SG references work across peered VPCs and across Transit Gateway, but only within the same AWS Region. Cross-region SG references require recreating SG references on each side, since SGs are regional resources.

For VPC peering, the SG reference works transparently — you specify the SG ID from the peer VPC as the source, and the peering connection enables the referenced SG ID to resolve. The peer VPC must be in the same Region.

For Transit Gateway, SG referencing works since 2023, but only when the two VPCs are attached to the same TGW in the same Region. If the VPCs are in different regions and connected via TGW peering, SG references do not propagate — you must use CIDR references instead.

Prefix lists for scalable references

A managed prefix list is a named set of CIDR blocks that you can reference in SG rules and route tables. AWS publishes managed prefix lists for AWS services (S3 prefix list, DynamoDB prefix list, EC2 instance connect prefix list, CloudFront origin-facing prefix list, Route 53 health check prefix list). You can also create customer-managed prefix lists for your own CIDR sets.

Customer-managed prefix lists shine in multi-account scenarios — share via AWS RAM, reference from member accounts, update centrally. The exam often tests "scalable management of CIDR rules across an organization" — the answer is customer-managed prefix lists shared via RAM.

SG and NACL Limits and Quotas

For ANS-C01, memorize these soft limits (all raisable via Service Quotas):

• 5 SGs per ENI default, 16 max
• 60 inbound + 60 outbound rules per SG default
• 1,000 effective rules per ENI (SGs × rules per SG)
• 2,500 SGs per VPC default
• 20 inbound + 20 outbound rules per NACL (hard limit on raise)
• 200 NACLs per VPC

The "1,000 effective rules per ENI" limit is the one that catches teams scaling SG-based controls without regard to total rule count. The fix is consolidation, prefix lists, or moving control to AWS Network Firewall.

Multi-Tier Architecture Patterns

The classic three-tier web architecture is the canonical SG/NACL pattern that the exam tests:

Internet
  │
  ▼ (NACL: allow 80/443 in, ephemeral out)
Public Subnet
  └── ALB (sg-web-lb: allow 443 from 0.0.0.0/0)
  │
  ▼ (NACL: allow ephemeral in, 8080 out)
Private Subnet (app tier)
  └── EC2 (sg-app: allow 8080 from sg-web-lb)
  │
  ▼ (NACL: allow ephemeral in, 5432 out)
Isolated Subnet (db tier)
  └── RDS (sg-db: allow 5432 from sg-app)

Each tier has its own subnet (with optional dedicated NACL) and its own SG. The SGs reference each other by ID, not by CIDR — this is the micro-segmentation pattern. Attackers who compromise the web ALB cannot reach the database directly because their source SG is sg-web-lb, not sg-app.

Perimeter VPC and Untrusted Network Patterns

A perimeter VPC (sometimes called a DMZ VPC or inspection VPC) is a dedicated VPC that handles ingress and egress for a multi-VPC architecture. The perimeter VPC hosts public load balancers, AWS Network Firewall endpoints, and reverse proxies. Spoke VPCs only communicate with the perimeter VPC (typically via Transit Gateway), never directly with the internet.

In this pattern:

• Perimeter VPC public subnet: SG allows ingress on 80/443 from internet; NACL hardened to those ports + ephemeral.
• Perimeter VPC private subnet: SG allows egress to spoke VPCs only.
• Spoke VPC: NACL denies any traffic to/from internet IPs; SG references perimeter VPC SGs only.

VPC Endpoint Policies and Defense in Depth

VPC interface endpoints (PrivateLink) come with their own security controls: a security group on the endpoint ENI plus an endpoint policy (a JSON resource policy that limits which principals can perform which actions through the endpoint). This is defense in depth.

A typical S3 gateway endpoint configuration:

• Endpoint policy: allow only specific buckets owned by your AWS account.
• Bucket policy on those buckets: include aws:SourceVpce condition limiting access to your endpoint ID.

The combination prevents two failure modes: workloads accessing buckets they should not (caught by endpoint policy) and external access to your buckets (caught by bucket policy SourceVpce condition). For interface endpoints to AWS services like Secrets Manager or KMS, the endpoint policy + service resource policy combination provides the same defense-in-depth.

The exam tests whether you understand that endpoint policies are NOT a replacement for SGs — they are layered on top. Interface endpoint ENIs still have SGs, and the SG controls TCP-level access from your workloads.

AWS Firewall Manager for Security Group Policies

AWS Firewall Manager extends to security groups via two policy types: audit policies and content audit policies. An audit policy continuously evaluates whether SG rules across the organization match an allowed rule pattern. A content audit policy enforces that specific SGs (a "primary SG") must be attached to all ENIs in scope.

The exam-relevant scenarios:

• Block 0.0.0.0/0:22 (SSH from anywhere): Firewall Manager content audit policy detects and remediates.
• Enforce that an organization-wide "baseline SG" is attached to every EC2 instance: content audit policy.
• Audit that no SG has both 0.0.0.0/0 inbound and outbound to 0.0.0.0/0: audit policy.

Firewall Manager requires AWS Organizations with all features, an AWS Config-enabled member account, and a delegated administrator. Without these prerequisites, the answer "use Firewall Manager" is wrong even if the requirement matches.

Common Scenarios

Scenario A: App tier cannot reach database

Symptom: app servers in the private subnet cannot connect to RDS in the isolated subnet on TCP 5432.

Diagnosis path:

1. Check sg-db inbound rule: does it allow TCP 5432 from sg-app?
2. Check sg-app outbound rule: default outbound is all-allow; usually OK.
3. Check NACL on app subnet outbound: allows TCP 5432 to db subnet CIDR? Allows return traffic on ephemeral ports inbound?
4. Check NACL on db subnet inbound: allows TCP 5432 from app CIDR? Allows return ephemeral outbound?
5. Use VPC Reachability Analyzer to confirm intent vs reality.

The typical root cause is a NACL ephemeral port rule missing on one side. SG-only configurations rarely cause this because SGs are stateful and return traffic is automatic.

Scenario B: Block all internet from a subnet except outbound HTTPS

Requirement: a private subnet must allow outbound HTTPS to 0.0.0.0/0 but block all other internet traffic, including return traffic from other protocols.

Solution:

• NACL inbound rule 100: ALLOW TCP 1024-65535 from 0.0.0.0/0 (return ephemeral for HTTPS).
• NACL inbound rule *: DENY (implicit).
• NACL outbound rule 100: ALLOW TCP 443 to 0.0.0.0/0.
• NACL outbound rule *: DENY (implicit).
• SG: allow outbound TCP 443 to 0.0.0.0/0; no inbound rules.

This combination uses NACL as the deny-by-default subnet boundary and SG as the workload-level allow.

Common Exam Traps

Other anti-patterns:

• Believing SGs support DENY rules — they do not.
• Believing NACLs are stateful — they are not.
• Believing the default NACL is the same as a custom NACL — default allows all, custom denies all.
• Using NACLs as the primary control — they are coarse and stateless; SGs are the primary control, NACLs are a defense-in-depth backup.
• Forgetting that NACL changes apply immediately to all subnets associated with that NACL.
• Putting too many rules on too many SGs (hitting the 1,000 effective rules per ENI limit).

Operational Considerations

SG and NACL changes during incidents

Both SGs and NACLs apply changes immediately. There is no propagation delay (unlike Route 53 DNS or some IAM changes). During an incident, you can isolate a compromised instance by removing all SGs and attaching a quarantine SG with no rules. The instance becomes unreachable in seconds. This is the canonical "incident response isolation" pattern.

Logging SG and NACL drops

VPC Flow Logs record SG and NACL drops with the action field set to REJECT. Combined with the new flow log fields flow-direction (ingress/egress) and the existing 5-tuple, you can identify exactly which SG or NACL rule rejected the traffic. NACL drops typically appear at the subnet boundary; SG drops appear at the ENI boundary.

Monitoring SG changes

CloudTrail records AuthorizeSecurityGroupIngress, AuthorizeSecurityGroupEgress, RevokeSecurityGroupIngress, RevokeSecurityGroupEgress, CreateSecurityGroup, and DeleteSecurityGroup API calls. AWS Config rules like restricted-ssh and vpc-sg-open-only-to-authorized-ports continuously evaluate compliance. EventBridge rules on SG-related CloudTrail events trigger automated remediation.

FAQ

Q1: When should I use NACLs instead of just Security Groups?

NACLs are most valuable for two scenarios. First, defense in depth at the subnet level — a NACL drop happens before the SG even sees the packet, providing a coarse cut for known-bad CIDRs. Second, explicit DENY rules — you can deny specific IPs while still allowing the broader range. For most workloads, SGs alone are sufficient and easier to manage; NACLs are added when compliance requires subnet-level isolation or when you want a single point to block a known threat IP across an entire subnet.

Q2: Can a Security Group reference another SG in a different account?

Yes, but only when the two VPCs are connected via VPC peering or Transit Gateway, and only within the same AWS Region. You specify the SG ID in the format sg-12345678 and the AWS adds the peer-account ownership marker automatically based on the peering or TGW relationship. Cross-region cross-account references are not supported — you must use CIDR ranges instead.

Q3: Why do I need an inbound NACL rule when SGs are stateful?

Because SGs and NACLs operate at different layers. NACLs evaluate every packet at the subnet boundary, regardless of SG state. So even though the SG would allow the return packet (it remembers the connection), the NACL must independently permit the return packet's port range (the ephemeral port range, 1024-65535). Without the inbound NACL rule for ephemeral ports, the packet is dropped at the subnet boundary before it reaches the SG.

Q4: Can I use a managed prefix list in a NACL rule?

No. NACL rules only support CIDR blocks as source and destination. Managed prefix lists are supported only in Security Groups and route tables. If you need to maintain a centrally managed CIDR list and apply it to a NACL, you must script the conversion from prefix list to individual NACL rules.

Q5: What is the rule limit per ENI when multiple SGs are attached?

The effective rule limit per ENI is 1,000 — calculated as the product of SGs attached × rules per SG. With the default 5 SGs and 60 rules each (60+60), the upper bound is 5 × 120 = 600 rules. With 16 SGs (the increased quota) and 60 rules each, you reach roughly 1,920, but the hard limit is 1,000 effective rules. Beyond that, you cannot attach the additional SGs.

Q6: How do I block a specific IP from accessing my VPC?

Two options. (1) Add a NACL deny rule with a low rule number (e.g., 50) for that specific IP. The deny terminates evaluation, blocking the IP at the subnet boundary. (2) Use AWS Network Firewall with a stateless drop rule. NACL is simpler and free; Network Firewall is more powerful but costs per GB. SGs cannot block specific IPs because SGs only allow — you cannot write an SG deny rule.

Q7: What happens if I attach no SG to an ENI?

Every ENI must have at least one SG. When you launch an instance without specifying an SG, AWS attaches the default SG of the VPC. The default SG allows all traffic between members of the same SG (instance-to-instance within the default SG) and allows all outbound to 0.0.0.0/0. You cannot delete the default SG, only modify its rules.

Q8: Are SG changes effective immediately?

Yes. Both SG rule changes and SG-to-ENI association changes propagate within seconds. There is no propagation delay in the data plane — once the API returns success, new packets are evaluated against the new rules. NACL changes have the same immediate behavior.

Q9: Can I use IAM to control who modifies SGs?

Yes. IAM policies on ec2:AuthorizeSecurityGroupIngress, ec2:RevokeSecurityGroupIngress, etc. control who can modify SG rules. Pair with CloudTrail logging and Config rules for continuous compliance evaluation. AWS Firewall Manager extends this with organization-wide policies.

Q10: Do VPC endpoints respect Security Groups?

Interface endpoints (PrivateLink) have ENIs and security groups. Workloads must have outbound rules permitting the endpoint SG, and the endpoint SG must have inbound rules permitting workload SGs. Gateway endpoints (S3, DynamoDB) do NOT have ENIs and do NOT have SGs — they rely on endpoint policies and route table prefix lists.

Summary: SG/NACL Answer Patterns

When you read an ANS-C01 SG/NACL question, run through this checklist:

• Is the question about return traffic mysteriously failing? → NACL ephemeral port rule missing.
• Is the question about rule order behavior? → NACL (numbered first match), not SG (no order).
• Is the question about cross-account access? → SG-to-SG reference via peering/TGW, same Region only.
• Is the question about denying a specific IP? → NACL deny rule, or Network Firewall.
• Is the question about three-tier isolation? → SG-to-SG references (web→app→db).
• Is the question about subnet-wide blocking? → NACL.
• Is the question about instance-level identity-based filtering? → SG.
• Is the question about scalable CIDR management across accounts? → Managed prefix lists shared via RAM.
• Is the question about org-wide SG baselines? → AWS Firewall Manager security group policy.

Master the stateful-vs-stateless distinction, the ephemeral port rule, the rule order behavior, and the SG-reference pattern, and ANS-C01 task 4.1 SG/NACL questions become predictable.

常考陷阱

• NACL ephemeral port — outbound 開了 443，記得 inbound 要開 1024-65535 才接得到回應。
• NACL 規則編號順序 — ALLOW 100 在 DENY 200 之前，ALLOW 先匹配就不會走到 DENY；要 DENY 必須編號更小。
• SG 是 stateful，NACL 是 stateless — return traffic SG 自動允許，NACL 必須明確規則。
• SG 沒有 DENY — SG 只能 allow，要 deny 就用 NACL 或 Network Firewall。
• 預設 SG vs 預設 NACL — 預設 SG 拒絕所有 inbound、允許所有 outbound；預設 NACL 允許所有；自訂 NACL 拒絕所有。
• 跨帳號 SG reference — 必須同 region，且兩個 VPC 是 peered 或 attached 到同一個 TGW。
• Gateway endpoint 沒有 SG — S3 / DynamoDB gateway endpoint 用 prefix list 路由，無 ENI 無 SG。
• Interface endpoint 有 SG — 別忘了允許 workload 連 endpoint。
• 1,000 effective rules per ENI — SGs × 規則數，超過就無法 attach 更多 SG。
• Firewall Manager 需要 Organizations + Config — 沒這兩樣，組織級 SG policy 用不了。