Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon VPC security controls operate at different layers. Security groups provide stateful, instance-level traffic filtering, while network access control lists (NACLs) provide stateless, subnet-level filtering. Understanding their evaluation behavior and appropriate use cases is essential for designing secure and functional AWS networks.
This lesson demonstrates how rule changes affect SSH, ICMP, HTTP, and traffic between EC2 instances.
Key Concepts
Security Groups
A security group is a virtual firewall associated with network interfaces, typically through an EC2 instance. Its rules control traffic entering and leaving the associated network interface.
Important characteristics:
- Security groups are stateful.
- If an inbound connection is permitted, the response traffic is automatically permitted, even without a corresponding outbound rule.
- If an outbound connection is initiated, the outbound rule must allow it.
- Rules are generally allow rules only; security groups do not support explicit deny rules.
- Multiple security groups can be associated with an instance. AWS evaluates the combined effect of their rules.
- Changes to a security group take effect without restarting the instance.
- Rules can filter by protocol, port, and source or destination.
- A rule can reference another security group instead of specifying IP addresses.
For example, an instance with an outbound rule allowing only ICMP can ping a destination, but it cannot retrieve a web page over HTTP. Adding an HTTP outbound rule permits TCP port 80 traffic.
Inbound and Outbound Behavior
A security group must permit traffic in the direction in which a connection is initiated:
- An inbound SSH connection requires an inbound TCP port 22 rule.
- The SSH response is automatically allowed because the security group is stateful.
- An outbound HTTP request requires an outbound TCP port 80 rule.
- The response to that HTTP request is automatically allowed by the security group.
- Removing all outbound rules does not necessarily break inbound connections, but it prevents new outbound connections and can prevent expected response behavior for traffic initiated by the instance.
Referencing Security Groups
Security group references are useful for service-to-service access. Instead of allowing traffic from an entire subnet or CIDR range, a rule can allow traffic from instances associated with a particular security group.
Example:
SG-frontendpermits application traffic toSG-backend.SG-backendallows TCP port 443 inbound fromSG-frontend.- New or removed frontend instances automatically follow the relationship without updating IP-based rules.
This pattern is commonly called security group chaining. It expresses an application relationship rather than relying on static addresses.
Network ACLs
A network ACL is associated with a subnet and applies to traffic entering or leaving that subnet. It affects all network interfaces in the subnet.
Important characteristics:
- NACLs are stateless.
- Inbound and outbound traffic are evaluated independently.
- A permitted inbound request does not automatically permit the response.
- Both directions must have appropriate rules.
- NACLs support explicit allow and deny rules.
- Rules are evaluated in ascending numerical order.
- The first matching rule is applied, and evaluation stops.
- A final implicit deny applies if no rule matches.
- NACL rules use IP addresses or CIDR ranges; they do not use security group references.
A broad allow rule with a lower rule number can make a later deny rule ineffective. For example, if rule 100 allows all traffic and rule 101 denies all traffic, rule 101 is never reached. If the deny rule is changed to 99, it is evaluated first and blocks the traffic.
NACL Return-Traffic Requirements
Because NACLs are stateless, return traffic needs a separate rule. A typical connection may require:
- An inbound rule allowing the service port, such as TCP 80 or TCP 443.
- An outbound rule allowing the response traffic.
- Appropriate ephemeral port handling for client-side response ports.
For internet-facing workloads, carefully designed NACLs often allow the required service ports and the relevant ephemeral port range. The exact range depends on the operating system and client behavior.
Default and Custom NACLs
A default NACL normally allows all inbound and outbound traffic. A custom NACL commonly starts with rules that deny traffic unless explicit allow rules are added, depending on how it is configured.
Do not assume that a security group rule alone guarantees connectivity. Traffic must pass every relevant control, including:
- Security group rules
- NACL rules
- Route table routes
- Internet gateway, NAT gateway, or other routing components
- Host-level firewalls
- DNS and application configuration
Exam-Relevant Takeaways
- Security groups are stateful; NACLs are stateless. This is one of the most frequently tested distinctions.
- Security groups are attached to network interfaces or instances; NACLs are attached to subnets.
- Security groups support allow rules but not explicit deny rules.
- NACLs support both allow and deny rules.
- Security group rules are evaluated as a cumulative set; NACL rules are processed by ascending rule number with first match winning.
- A security group can reference another security group, which is useful for tiered architectures.
- NACL rules reference CIDR ranges and do not reference security groups.
- A security group can allow an inbound request and its response without a separate response rule.
- A NACL must allow both directions independently, including return traffic.
- A broad, low-numbered NACL allow rule can prevent a later deny rule from taking effect.
- A connection that hangs rather than immediately returning an application error can indicate that network filtering is dropping the traffic, although routing and host firewalls must also be checked.
Architecture Decision Guide
| Requirement | Prefer | Reason |
|---|---|---|
| Instance or workload-level access control | Security group | Applies directly to network interfaces and models workload relationships |
| Subnet-wide filtering | NACL | Applies to every interface in the subnet |
| Stateful connection tracking | Security group | Return traffic is automatically permitted for an allowed flow |
| Explicit deny for a known CIDR range | NACL | NACLs support deny rules |
| Allow one application tier to reach another | Security group reference | Avoids maintaining individual IP addresses |
| Block a specific source IP at the subnet boundary | NACL | Supports ordered CIDR-based deny rules |
| Fine-grained port and protocol control for an instance | Security group | Rules are attached to the workload interface |
| Broad defense-in-depth filtering | Both | Use security groups for workload policy and NACLs for subnet boundary controls |
Common Exam Traps
- Confusing stateful and stateless behavior: An inbound security group rule does not need a matching outbound response rule, but a NACL does.
- Assuming NACL rules are cumulative: NACL evaluation stops at the first matching rule. Rule numbering matters.
- Putting a deny rule after an allow-all rule: The deny rule will never be reached if the earlier allow rule matches.
- Expecting security groups to deny traffic: Security groups cannot explicitly deny a source. Remove or narrow the applicable allow rules instead.
- Using a security group reference in a NACL: NACLs use IP addresses and CIDR ranges, not security group identities.
- Forgetting ephemeral ports: Stateless filtering often requires return traffic to client-side ephemeral ports.
- Assuming an allowed security group guarantees connectivity: Routes, gateways, NACLs, operating-system firewalls, and application listeners must also be correct.
- Allowing HTTP but testing HTTPS: TCP port 80 and TCP port 443 are different rules. A successful HTTP test does not prove HTTPS is permitted.
- Allowing ICMP but expecting web traffic: Ping uses ICMP; web requests use TCP, usually on ports 80 or 443.
Real-World Engineer Notes
- Prefer narrow sources such as a trusted administrative CIDR, VPN range, or bastion security group rather than allowing SSH from
0.0.0.0/0. - Use security group references for dynamic application tiers, especially when instances scale or are replaced.
- Keep NACLs simple unless there is a clear subnet-level requirement such as broad deny rules, compliance segmentation, or defense in depth. Complex stateless rules are easy to break.
- Document NACL rule numbering and leave space between rule numbers so additional rules can be inserted later.
- Test both directions when changing NACLs. A service may accept the request but fail because the response path is blocked.
- Restrict administrative access through Systems Manager Session Manager, private connectivity, or controlled bastion access when possible instead of exposing SSH publicly.
- Treat
0.0.0.0/0as a deliberate exposure decision, not a default configuration for production workloads.
Quick Reference Summary
- Security group: Stateful, attached to network interfaces, allow rules only, supports security group references.
- NACL: Stateless, attached to subnets, supports allow and deny rules, uses ordered CIDR-based rules.
- Security group rule evaluation: Effective permissions are the union of applicable allow rules.
- NACL rule evaluation: Lowest matching rule number wins.
- Security group response traffic: Automatically allowed for an accepted flow.
- NACL response traffic: Must be explicitly allowed in the opposite direction.
- Service testing: ICMP, HTTP, HTTPS, and SSH require separate protocol or port permissions.
Flashcards
- Q: Are security groups stateful or stateless?
A: Stateful. Return traffic for an allowed flow is automatically permitted.
- Q: Are NACLs stateful or stateless?
A: Stateless. Inbound and outbound traffic are evaluated independently.
- Q: Where are security groups applied?
A: To network interfaces, commonly through EC2 instances.
- Q: Where are NACLs applied?
A: At the subnet level.
- Q: Can security groups contain explicit deny rules?
A: No. Security groups support allow rules only.
- Q: Can NACLs contain explicit deny rules?
A: Yes.
- Q: How does AWS choose among matching NACL rules?
A: It evaluates rules from the lowest number upward and applies the first match.
- Q: What happens if a NACL rule 100 allows all traffic and rule 101 denies all traffic?
A: The allow rule wins because it is the first match.
- Q: Can a NACL rule reference a security group?
A: No. NACL rules use source or destination IP addresses and CIDR blocks.
- Q: What is security group chaining?
A: Allowing traffic based on membership in another security group, such as allowing a backend group to receive traffic from a frontend group.
- Q: Does allowing inbound HTTP in a security group require a separate outbound rule for the response?
A: No, because the security group is stateful.
- Q: Does allowing inbound HTTP in a NACL require an outbound response rule?
A: Yes, because the NACL is stateless.
Practice Questions
Question 1
An EC2 instance has a security group that allows inbound TCP port 22 from an administrator’s IP address. All outbound rules are removed. The administrator can no longer establish a new SSH session. What best explains this result?
Correct answer: The instance cannot initiate or complete the required outbound traffic because the security group has no outbound permission.
Explanation: Security groups are stateful, so response traffic for an allowed inbound flow is tracked. However, removing outbound rules prevents new outbound connections and can prevent the expected return path or related traffic. Stateful does not mean outbound rules are ignored.
Question 2
A subnet NACL contains these inbound rules:
- Rule 100: Allow all traffic from
0.0.0.0/0 - Rule 110: Deny TCP port 22 from
203.0.113.10/32
SSH from 203.0.113.10 still succeeds. What change blocks this source while preserving the intended deny rule?
Correct answer: Assign the deny rule a number lower than 100, such as rule 90.
Explanation: NACLs use first-match evaluation. Rule 100 matches the source before rule 110 is considered, so the later deny is ineffective.
Question 3
A web tier in SG-Web must access an application tier in SG-App on TCP port 8443. The application instances use dynamic private IP addresses. Which configuration is most maintainable?
Correct answer: Add an inbound TCP 8443 rule to SG-App with SG-Web as the source.
Explanation: A security group reference expresses the tier relationship and automatically covers current and replacement instances associated with SG-Web. It avoids maintaining changing IP address lists.
Question 4
An administrator adds an inbound TCP 443 allow rule to a custom NACL. The load balancer can send requests to the target subnet, but clients never receive responses. Which additional configuration is most likely required?
Correct answer: An outbound NACL rule allowing the response traffic, including the applicable ephemeral port range.
Explanation: NACLs are stateless. The inbound rule permits only one direction; the return path must be explicitly allowed in the outbound rules.
Question 5
A security engineer wants to block one known malicious public IP address at the subnet boundary while leaving the existing security group configuration unchanged. Which control is appropriate?
Correct answer: Add a low-numbered deny rule for the IP address in the subnet’s NACL.
Explanation: NACLs support explicit CIDR-based deny rules and operate at the subnet boundary. The rule must precede any broader allow rule that would otherwise match first.