VPC Security (Security Groups, NACLs)

VPC Security: Security Groups & NACLs – A Comprehensive Guide for AWS Security Specialty

Why Is VPC Security Important?

Amazon Virtual Private Cloud (VPC) is the foundational networking layer for nearly every AWS workload. Securing traffic flowing in and out of your VPC resources is one of the most critical responsibilities of a cloud security professional. Two core mechanisms – Security Groups and Network Access Control Lists (NACLs) – form the backbone of VPC-level traffic filtering. Misconfigurations in either can lead to unauthorized access, data exfiltration, or service disruptions. For the AWS Security Specialty exam, VPC security is a heavily tested domain because it underpins virtually every other security control in AWS.

What Are Security Groups?

Security Groups act as virtual stateful firewalls that control inbound and outbound traffic at the Elastic Network Interface (ENI) level. Every EC2 instance, RDS database, Lambda function (in a VPC), ELB, and other ENI-attached resources can be associated with one or more Security Groups.

Key characteristics of Security Groups:

• Stateful: If you allow an inbound request, the response traffic is automatically allowed regardless of outbound rules, and vice versa.
• Allow rules only: You can only specify allow rules. There is no way to create an explicit deny rule in a Security Group.
• Default behavior: By default, a new Security Group allows no inbound traffic and allows all outbound traffic.
• Evaluated as a whole: All rules across all associated Security Groups are evaluated together before a decision is made. If any rule allows the traffic, it is permitted.
• Applied at the instance (ENI) level: Security Groups are attached directly to the network interface, not to the subnet.
• Supports referencing other Security Groups: Instead of specifying IP ranges, you can reference another Security Group ID as a source or destination. This is extremely powerful for building self-referencing or cross-tier access patterns (e.g., allowing the web-tier SG to talk to the app-tier SG).
• Changes take effect immediately: Any modification to a Security Group rule is applied in real time without needing to restart instances.

What Are Network Access Control Lists (NACLs)?

NACLs act as stateless firewalls that control traffic at the subnet level. Every subnet in a VPC must be associated with exactly one NACL. If you don't explicitly associate a subnet with a custom NACL, it uses the default NACL.

Key characteristics of NACLs:

• Stateless: Inbound and outbound rules are evaluated independently. If you allow inbound HTTP traffic, you must also explicitly allow the outbound response traffic (typically on ephemeral ports 1024-65535).
• Allow and Deny rules: NACLs support both allow and deny rules, making them suitable for explicitly blocking specific IP addresses or ranges.
• Rule numbering and order: Rules are evaluated in ascending numerical order (lowest number first). The first rule that matches the traffic is applied, and subsequent rules are not evaluated. There is always a default catch-all rule (rule number *) that denies all traffic if no other rule matches.
• Default NACL: The default NACL that comes with every VPC allows all inbound and outbound traffic. Custom NACLs, by contrast, deny all traffic by default until you add allow rules.
• Applied at the subnet level: A single NACL applies to all resources within the associated subnet.
• Changes take effect immediately.

How Security Groups and NACLs Work Together

Traffic flowing to and from an instance passes through both layers of defense:

1. Inbound traffic first hits the NACL (subnet level). If the NACL allows the traffic, it then reaches the Security Group (ENI level). Both must allow the traffic for it to reach the instance.
2. Outbound traffic first hits the Security Group. If allowed, it then passes through the NACL. Again, both must allow the traffic.

Think of it as a defense-in-depth model:
• NACLs = the outer perimeter (subnet boundary)
• Security Groups = the inner perimeter (instance boundary)

Comparison Table

Feature | Security Group | NACL
Level of operation | ENI (instance) level | Subnet level
Statefulness | Stateful | Stateless
Rule types | Allow only | Allow and Deny
Rule evaluation | All rules evaluated together | Rules evaluated in order (by number)
Default inbound | Deny all | Allow all (default NACL) / Deny all (custom NACL)
Default outbound | Allow all | Allow all (default NACL) / Deny all (custom NACL)
Applies to | Only resources explicitly associated | All resources in the subnet
SG referencing | Supported | Not supported (IP/CIDR only)

Common Architectures and Best Practices

• Use Security Groups as your primary control: Because they are stateful and support SG-to-SG referencing, Security Groups are easier to manage and less error-prone for most use cases.
• Use NACLs as an additional layer for explicit denies: If you need to block a specific IP address or CIDR range (e.g., a known malicious IP), NACLs are the appropriate tool since Security Groups cannot deny traffic explicitly.
• Ephemeral port awareness with NACLs: Because NACLs are stateless, you must account for ephemeral (dynamic) ports in your outbound rules for return traffic. For Linux, this is typically ports 1024-65535; for Windows, 49152-65535. The exam frequently tests this.
• Least privilege principle: Start with the most restrictive rules and only open what is necessary. Avoid using 0.0.0.0/0 in Security Group inbound rules unless absolutely required (e.g., public-facing load balancers on ports 80/443).
• VPC Flow Logs: Enable VPC Flow Logs on your VPC, subnets, or ENIs to capture information about the IP traffic going to and from network interfaces. Flow Logs record whether traffic was accepted or rejected, helping you troubleshoot Security Group and NACL misconfigurations.
• Tagging and naming conventions: Use descriptive names and tags for Security Groups to maintain clarity (e.g., web-tier-sg, db-tier-sg).
• Avoid modifying the default Security Group: AWS best practice is to not use or leave rules in the default Security Group. Create custom Security Groups instead.
• Self-referencing Security Groups: For resources that need to communicate within the same tier (e.g., cluster nodes), create a Security Group that references itself as a source. This ensures that any instance added to the group can communicate with other instances in the same group.

Troubleshooting Traffic Issues

When traffic is being blocked unexpectedly, follow this systematic approach:

1. Check Security Group inbound rules – Is the port/protocol/source allowed?
2. Check Security Group outbound rules – Is the destination/port allowed for the response?
3. Check NACL inbound rules – Is the traffic allowed at the subnet level? Remember rule ordering.
4. Check NACL outbound rules – Are ephemeral ports open for the return traffic?
5. Check route tables – Is there a route to/from the destination?
6. Check VPC Flow Logs – Look for REJECT entries to pinpoint where traffic is being dropped.

Advanced Scenarios Tested in the Exam

• Cross-VPC communication (VPC Peering / Transit Gateway): Security Groups in a peered VPC can reference each other by SG ID only within the same region. For cross-region peering, you must use CIDR-based rules.
• PrivateLink / VPC Endpoints: Endpoint policies combined with Security Groups on the endpoint ENI control access to AWS services privately.
• Multiple Security Groups on one ENI: When multiple SGs are attached, all rules from all groups are aggregated. If any rule allows the traffic, it passes.
• NACL rule limits: By default, you can have up to 20 inbound and 20 outbound rules per NACL (adjustable). This limit is tested indirectly in architecture questions.
• Security Groups per ENI limit: By default, up to 5 Security Groups can be associated with a single ENI (adjustable up to 16). Each SG can have up to 60 inbound and 60 outbound rules.

Exam Tips: Answering Questions on VPC Security (Security Groups, NACLs)

1. Stateful vs. Stateless is the #1 concept: If a question describes return traffic being blocked, immediately think about NACLs and ephemeral ports. Security Groups handle return traffic automatically because they are stateful.

2. "Block a specific IP" = NACL: Whenever a question asks how to block a specific IP address or range, the answer is almost always a NACL deny rule, because Security Groups only support allow rules.

3. "Allow traffic between tiers" = Security Group referencing: If a question asks about allowing traffic from web servers to application servers, look for the answer that uses Security Group referencing (e.g., allow inbound from sg-web on port 8080 in sg-app).

4. Remember default behaviors: Default Security Group allows all inbound from itself and all outbound. Default NACL allows all inbound and outbound. Custom NACL denies all by default. A new Security Group denies all inbound and allows all outbound.

5. Watch for ephemeral port questions: If a NACL allows inbound on port 443 but the response is not working, the outbound rule likely needs to allow ephemeral ports (1024-65535).

6. Rule ordering matters for NACLs only: If a question mentions rule numbers, it's about NACLs. A deny rule at number 100 will override an allow rule at number 200 for the same traffic. Security Groups evaluate all rules collectively – order does not matter.

7. Look for defense-in-depth answers: AWS recommends using both Security Groups and NACLs. If a question asks for the most secure approach, the answer that uses both layers is usually correct.

8. VPC Flow Logs for visibility, not enforcement: Flow Logs tell you what happened but do not block or allow traffic. If a question asks about monitoring or troubleshooting, Flow Logs are the answer. If it asks about enforcement, think SGs and NACLs.

9. SGs are associated, NACLs are applied: Security Groups are explicitly associated with ENIs/instances. NACLs are associated with subnets and automatically apply to everything in that subnet. If a question asks about protecting a specific instance, think Security Group. If it asks about protecting all instances in a subnet, think NACL.

10. Elimination strategy: If an answer choice mentions creating a "deny rule in a Security Group," eliminate it immediately – Security Groups do not support deny rules. If an answer mentions referencing a Security Group ID in a NACL rule, eliminate it – NACLs only work with IP/CIDR ranges.

11. Understand the interplay with other services: Questions may combine VPC security with AWS Config rules (e.g., detecting unrestricted Security Groups), AWS Firewall Manager (centrally managing SGs across accounts), or AWS Network Firewall (for advanced stateful inspection). Know when each tool is appropriate.

12. Cost awareness: Security Groups and NACLs are free. If a question presents a cost-effective security solution, SGs and NACLs are preferred over third-party firewall appliances when they can meet the requirements.

By thoroughly understanding these two complementary mechanisms, their differences, and how they interact, you will be well-prepared to tackle VPC security questions on the AWS Security Specialty exam with confidence.