# VPC Security and Network ACLs

> Chapter 16 of the Courseiva AWS-SECURITY-SPECIALTY curriculum — https://courseiva.com/learn/aws-security-specialty/vpc-security-and-network-controls

**Official objective:** 6.1 — Design and implement VPC security components

## Introduction

VPC Security and Network ACLs are the fundamental tools for controlling who can enter and leave your virtual private cloud (VPC) in Amazon Web Services. They act as firewalls around your cloud resources, ensuring only authorised traffic reaches your servers and applications. For the SCS-C02 exam, mastering these concepts is critical because they appear repeatedly in questions about designing secure network architectures and troubleshooting access problems.

## The Apartment Building Security System Analogy

Your apartment building has 24 units on 4 floors.

The first layer of security is the main lobby door. Only residents have a key fob that unlocks it. Once inside, you can walk freely to any floor using the stairs or lift. This main door is like a Network ACL — it controls traffic entering or leaving the entire building (your subnet) based on rules about who can enter (inbound rules) and who can leave (outbound rules). It does not care which specific apartment you go to once you are inside; it just checks if you are allowed in the building at all.

The second layer is each individual apartment door. Even if someone gets through the main lobby door, they still need a key or code to enter Apartment 3B. This apartment door is like a Security Group — it controls traffic specifically to that resource (your EC2 instance). It remembers who has been let in and allows them to respond without asking again. If a delivery person is allowed through the main door but does not have a key to Apartment 3B, they cannot get in. This two-layer system means even if a stranger slips past the main door, your valuables are still safe behind your apartment door. In AWS, using both Network ACLs and Security Groups together creates this robust, layered defence for your virtual network.

## Core explanation

A Virtual Private Cloud (VPC) is your own isolated section of the AWS cloud where you launch virtual servers called EC2 instances (Amazon Elastic Compute Cloud). Think of it as a private, fenced-off plot of land in the cloud where you build your digital office. But having a plot of land is useless if anyone can walk in without permission. That is where security comes in.

The two main security layers for your VPC are Security Groups and Network ACLs (Access Control Lists). They are both virtual firewalls, but they work at different levels and have different rules.

A Security Group acts as a virtual firewall for your EC2 instances (the virtual servers themselves). It is like the bouncer at the door of a specific nightclub. It controls inbound traffic (traffic coming into the instance) and outbound traffic (traffic leaving the instance). The default Security Group allows all outbound traffic but no inbound traffic, unless you explicitly add a rule. A key feature is that Security Groups are stateful. This means if you allow an incoming request from the internet, the response to that request is automatically allowed to leave, even if you have not written an explicit outbound rule for that response. You only need to write rules for the initial traffic.

A Network ACL, on the other hand, is a firewall for an entire subnet (a range of IP addresses within your VPC). A subnet is like a neighbourhood within your fenced plot of land. The Network ACL controls traffic entering and leaving that subnet. It is stateless, which means it does not remember past traffic. For every packet of data, both the inbound and outbound directions must be explicitly allowed by separate rules. If you allow an incoming request but your outbound rules do not allow the response, the response is dropped.

Both Security Groups and Network ACLs work by evaluating rules in a specific order. For Security Groups, all rules are evaluated together, and if any rule allows the traffic, it is permitted (a 'whitelist' model). For Network ACLs, rules are evaluated in numerical order, starting from the lowest number. When a rule matches the traffic (either allowing or denying it), that rule is applied immediately and no further rules are checked. This is a key difference.

Why do we need both? It is a defence-in-depth strategy. Even if someone misconfigures a Security Group and accidentally allows dangerous traffic, the Network ACL on the subnet can block it. Or if the Network ACL is too permissive, the Security Group on the instance can still deny access. This layered approach is a bedrock principle of cloud security.

In the SCS-C02 exam, you will need to know the specific differences between Security Groups and Network ACLs, the numeric rule evaluation for Network ACLs, and the default configurations. You will also need to know that Security Groups are attached to ENIs (Elastic Network Interfaces — the virtual network cards of your EC2 instances), while Network ACLs are attached to subnets. You will not create rules for both at the same time; the order of evaluation matters. For instance, traffic from the internet first hits the Network ACL associated with the subnet. If the NACL allows it, the traffic then reaches the Security Group attached to the EC2 instance. If the Security Group also allows it, the traffic enters the instance.

A common scenario is setting up a web server. You would create a Security Group that allows HTTP (port 80) and HTTPS (port 443) inbound from anywhere (0.0.0.0/0). You would also create a Network ACL for the public subnet that allows inbound HTTP/HTTPS and ephemeral ports for the response traffic. On the outbound side, you would allow traffic to the internet for the responses. Getting these rules right is crucial for the exam.

## Real-world context

In a real IT role, you might be tasked with setting up a secure environment for a new customer-facing web application. Let us walk through a concrete scenario.

Your company has just launched a new e-commerce site that will run on EC2 instances inside a VPC. You need to ensure that customers can access the website (port 443 for HTTPS), but that no one can access the backend database directly from the internet. The database will live in a separate, private subnet.

Step 1: You create a VPC and within it, two subnets — a public subnet for the web server and a private subnet for the database. The public subnet has a route to the internet through an Internet Gateway (a virtual router that connects your VPC to the internet).

Step 2: You launch an EC2 instance in the public subnet to act as the web server. You attach a Security Group to it. You add a rule to the Security Group: Inbound rule allowing TCP on port 443 from the IP range 0.0.0.0/0 (any IP on the internet). You also add an outbound rule allowing all traffic (since the server needs to update software, fetch resources, etc.). Because Security Groups are stateful, you do not need a separate outbound rule for responses to incoming web requests; they are automatically allowed.

Step 3: You know the subnet itself also needs a firewall, so you create a Network ACL for the public subnet. You set the inbound rules: Rule 100 to Allow HTTP (port 80) from 0.0.0.0/0, Rule 110 to Allow HTTPS (port 443) from 0.0.0.0/0, and Rule 120 to Allow ephemeral ports (1024-65535) from 0.0.0.0/0 (these high-numbered ports are used for the response traffic back to the client). For outbound rules on the NACL: Rule 100 to Allow all traffic to 0.0.0.0/0 (so responses can go out). Because NACLs are stateless, you must explicitly allow the response traffic on both inbound and outbound rules.

Step 4: For the private subnet with the database, you create a Network ACL that denies all inbound traffic from the internet (0.0.0.0/0) but allows inbound traffic from the public subnet's CIDR block (the IP range of the public subnet, e.g., 10.0.1.0/24). You also create a Security Group for the database that allows only traffic from the web server's Security Group on the database port (e.g., port 3306 for MySQL). This is called a 'security group reference' — you reference the web server's security group ID in the database's inbound rule. This way, only that specific web server can talk to the database.

Step 5: You test the setup. A customer from the internet tries to access the website. The traffic hits the Network ACL of the public subnet; it is allowed (Rule 110 for HTTPS). Then it reaches the EC2 instance; the Security Group allows it. The web server processes the request, generates a web page, and sends it back. The outbound NACL rule allows the response. The customer sees the website. Meanwhile, a hacker tries to directly access the database by scanning its private IP. The traffic hits the private subnet's Network ACL, which denies it from the internet (since 0.0.0.0/0 is denied). Even if the NACL was accidentally permissive, the database's Security Group would still deny the traffic because the hacker's IP is not in the allowed security group reference.

As the IT professional, you are responsible for creating these rules, monitoring them, and adjusting them when requirements change. For example, if a developer needs SSH access to the web server from their office, you add the developer's static office IP to the Security Group for SSH (port 22) inbound. You also update the NACL to allow inbound SSH from that IP range. You must remember that NACL changes take effect immediately (once saved), which is great for quick fixes, but Security Group changes might take a moment to propagate across the infrastructure. You also need to audit the rules regularly, using tools like AWS Config or custom scripts, to ensure no overly permissive rules (like 0.0.0.0/0 for SSH) exist, as they are a common security risk. This real-world process is exactly what the SCS-C02 exam tests your ability to reason about.

## Exam focus

The SCS-C02 exam will test your ability to distinguish between Security Groups and Network ACLs, and to apply them correctly in architecture scenarios. Here is exactly what to expect.

Question types: 
- You will be given a scenario description (e.g., 'An application running on EC2 instances in a public subnet cannot be reached from the internet. What is the most likely cause?'). The answer choices will point to either a missing Security Group rule, a misconfigured Network ACL, or a routing issue.
- You will see questions asking you to state the difference between stateful and stateless firewalls.
- You will get a 'best practice' question: 'Which of the following is the most secure way to allow web traffic to a web server?' The correct answer will involve using both a Security Group and a Network ACL, not just one.

Traps: 
- The exam loves to test the 'stateful vs stateless' distinction. A common trap is to present a scenario where someone says 'I added an inbound rule to the Network ACL to allow HTTP, but the traffic still is not getting through.' The correct answer is that the outbound rule on the NACL also needs to allow the response traffic. Many beginners forget this because Security Groups handle it automatically.
- Another trap: rules in a Network ACL are evaluated in numeric order. If you have a 'Deny' rule with a lower number than an 'Allow' rule, the traffic will be denied even if the higher-numbered rule would allow it. The exam might present a NACL with a 'Deny all' at Rule 100 and an 'Allow HTTP' at Rule 200, and ask why HTTP traffic fails. The answer is that Rule 100 matches first and denies it.

Concepts they love to test: 
- The default configuration of a Security Group: denies all inbound, allows all outbound.
- The default configuration of a Network ACL for a custom VPC: denies all inbound and outbound until you add rules. (Note: the default NACL that comes with a VPC allows all inbound and outbound, but that is rarely used in secure designs.)
- The fact that Security Groups are attached to ENIs, not to subnets or instances directly.
- Ephemeral ports: the exam expects you to know that for high-traffic protocols like HTTP, the client uses a random port above 1023, and the firewall must allow traffic on these ports for the response to reach the client. This is especially important for Network ACLs.
- The 'security group referencing' feature: you can allow traffic from a specific security group rather than from an IP range. This is more secure and dynamic.

To memorise: 
- Security Groups = stateful, instance-level, allow rules only, evaluated as a whole.
- Network ACLs = stateless, subnet-level, allow and deny rules, evaluated in numeric order.
- Always use both for defence in depth.
- Know the ephemeral port range for different protocols (e.g., 1024-65535 for TCP).

When you read a question, first identify what layer the issue is at: is it an instance-level problem (Security Group) or a subnet-level problem (Network ACL)? Then check if the scenario implies a stateful or stateless expectation. This mindset will help you eliminate wrong answers quickly.

## Step by step

1. **Design the VPC and Subnets** — First, you plan your VPC architecture, deciding which subnets will be public (accessible from the internet) and which will be private. This determines where you will apply which Network ACL. For example, a public subnet for web servers and a private subnet for databases.
2. **Create Security Groups** — You create Security Groups for each type of resource (e.g., 'WebServer-SG', 'Database-SG'). You add inbound rules based on what traffic you want to allow (e.g., HTTP from 0.0.0.0/0 for the web server). Outbound rules are set to allow needed traffic (e.g., all outbound to the internet). Remember, Security Groups are stateful.
3. **Create Network ACLs** — You create custom Network ACLs for each subnet. For the public subnet, you add inbound rules for HTTP, HTTPS, and ephemeral ports (for responses), and an outbound rule allowing all traffic to the internet. For the private subnet, you add inbound rules allowing only traffic from the public subnet's IP range, and an outbound rule for responses.
4. **Attach Resources to Security Groups and NACLs** — Launch your EC2 instances and attach the appropriate Security Group to each instance (via its ENI). Then associate the correct Network ACL with each subnet (by editing subnet association in the VPC console). This applies the NACL rules to all instances in that subnet.
5. **Test and Validate Connectivity** — Use tools like ping or curl from the internet to test web server access. If it fails, check the Security Group inbound rules first (are HTTP/HTTPS allowed?). Then check the Network ACL rules — did you allow outbound responses on ephemeral ports? This step-by-step troubleshooting is exactly what the exam expects.

## Comparisons

### Security Group vs Network ACL

**Security Group:**
- Stateful (remembers connection state and automatically allows response traffic)
- Attached to Elastic Network Interfaces (ENIs) of EC2 instances
- Only supports allow rules; cannot explicitly deny traffic from a specific IP

**Network ACL:**
- Stateless (must explicitly allow both inbound and outbound traffic for each connection)
- Attached to subnets; applies to all instances in that subnet
- Supports both allow and deny rules; rules are evaluated in numeric order

### Default Security Group vs Default Network ACL

**Default Security Group:**
- Allows all outbound traffic
- Denies all inbound traffic from other resources until a rule is added
- Changes apply only to instances that have it attached

**Default Network ACL:**
- Allows all inbound and outbound traffic (inherently insecure)
- Associated with the entire default VPC subnet
- Changes apply to all instances in the subnet immediately

### Rule Evaluation - Security Group vs Rule Evaluation - Network ACL

**Rule Evaluation - Security Group:**
- All rules are evaluated together; if any rule allows traffic, it is permitted
- Order does not matter for the final decision
- Cannot override a Deny (since there are no Deny rules)

**Rule Evaluation - Network ACL:**
- Rules are evaluated in ascending numerical order (lowest to highest)
- First matching rule (allow or deny) is applied, and no further rules are evaluated
- A Deny rule with a lower number overrides an Allow rule with a higher number

### Use Case - Security Group vs Use Case - Network ACL

**Use Case - Security Group:**
- Best for controlling access to a specific application or server
- Commonly used to allow HTTP/HTTPS to web servers
- Ideal for granular, per-instance rules based on role

**Use Case - Network ACL:**
- Best for broad subnet-level protection, e.g., blocking known malicious IP ranges
- Commonly used to deny all inbound traffic from the internet to a private subnet
- Ideal for establishing a perimeter defence around a set of resources

## Diagram

_This diagram shows the path of traffic from the internet through a Network ACL, then to an EC2 instance with a Security Group, and how the private subnet is isolated._

```mermaid
flowchart TD
    A[Internet] --> B[Internet Gateway]
    B --> C[Network ACL for Public Subnet]
    C --> D[Public Subnet]
    D --> E[EC2 Instance with Security Group]
    E --> F[Security Group allows HTTP/HTTPS]
    E --> G[Outbound traffic via NACL ephemeral ports]
    C --> H[Network ACL allows inbound HTTP/HTTPS]
    H --> C
    subgraph VPC
        D
        I[Private Subnet]
        J[EC2 Database instance]
    end
    E -- only allowed traffic --> J
    I --> K[Network ACL for Private Subnet - denies internet]
    J --> L[Security Group allows only web server SG]
```

## Common misconceptions

- **Misconception:** Network ACLs and Security Groups are the same thing, just with different names. **Reality:** Security Groups are stateful instance-level firewalls that only allow traffic, while Network ACLs are stateless subnet-level firewalls that can allow or deny traffic and are evaluated in order. (The names sound similar and both involve rules about traffic, so beginners lump them together. The exam explicitly tests the differences.)
- **Misconception:** If I allow incoming traffic in a Security Group, the response traffic is automatically handled even if the Network ACL blocks outbound traffic. **Reality:** Traffic must pass both the Security Group and the Network ACL. The Security Group is stateful for the response, but the Network ACL is stateless. The outbound rule in the NACL must explicitly allow the response traffic. (Beginners often forget that the NACL is stateless and that traffic must pass through both firewalls in sequence. They think the Security Group's statefulness covers everything.)
- **Misconception:** You can attach a Network ACL directly to an EC2 instance to control its traffic. **Reality:** Network ACLs are attached to subnets, not to individual EC2 instances. They control traffic for all instances in that subnet. Security Groups are attached to the instance's ENI. (The wording 'Network ACL' sounds like it could be applied per instance. In reality, it operates at the subnet level, which is a different layer of abstraction.)
- **Misconception:** The order of rules in a Security Group matters, like in a Network ACL. **Reality:** Security Group rules are evaluated as a whole; the order does not matter. Any rule that allows the traffic will work. Network ACL rules are evaluated in ascending numerical order, and the first matching rule is applied. (Many people assume all firewall rule sets work the same way. The exam specifically tests that you know the order logic differs between the two.)
- **Misconception:** A Network ACL with a 'deny all' rule will always block all traffic, even if there is a higher-numbered 'allow' rule. **Reality:** Yes, that is correct — but only if the 'deny all' rule has a lower number. If the 'allow' rule has a lower number, it will be applied first. The numeric ordering matters, not just the presence of a deny rule. (This misconception arises because people think 'deny all' is an absolute block. In reality, its position in the list determines its effect.)

## Key takeaways

- Security Groups are stateful: if you allow an inbound request, the outbound response is automatically permitted without needing an explicit outbound rule.
- Network ACLs are stateless: you must explicitly create both inbound and outbound rules for traffic to flow in both directions.
- Network ACL rules are evaluated in numerical order from lowest to highest, and the first matching rule (allow or deny) is applied immediately.
- Security Groups only have allow rules; you cannot create deny rules within a Security Group.
- Network ACLs support both allow and deny rules, giving you more granular control at the subnet level.
- For defence in depth, always use both a Network ACL on the subnet and a Security Group on the instance to protect your resources.
- The default Security Group for a VPC allows all outbound traffic but denies all inbound traffic until you add a specific rule.
- The default Network ACL in a new VPC allows all inbound and outbound traffic, but it is best practice to replace it with a custom, restrictive NACL.

## FAQ

**What is the difference between a Security Group and a Network ACL?**

Security Groups are stateful firewalls attached to individual EC2 instances, controlling traffic at the instance level. Network ACLs are stateless firewalls attached to subnets, controlling traffic for all instances in that subnet. The key distinction is statefulness and the layer they operate at.

**Can a Network ACL have more than 100 rules?**

Yes, but there is a limit. By default, a Network ACL can have up to 20 rules per direction (inbound and outbound). You can request an increase to a maximum of 100 rules per direction, but this is a soft limit. In practice, keep rules minimal for performance.

**Does a Security Group allow me to block a specific IP address?**

No. Security Groups only support allow rules. To block a specific IP address, you must use a Network ACL with a deny rule for that IP, or use a separate firewall like AWS WAF (Web Application Firewall) at the application layer.

**Why do I need to allow ephemeral ports in a Network ACL for web traffic?**

Because Network ACLs are stateless, the response traffic from your web server back to the client uses a random high-numbered port (ephemeral port). You must have an outbound rule allowing these ports (e.g., 1024-65535) so the response can leave the subnet. Without it, the response is dropped, and the client never sees the webpage.

**Can I attach a single Security Group to multiple EC2 instances?**

Yes, absolutely. This is a common best practice. For example, you can create one 'WebServer-SG' and attach it to all your web server instances, so they all share the same inbound rules. This makes management easier and consistent.

**What is a default Network ACL, and should I use it?**

A default Network ACL is automatically created when you create a VPC. It allows all inbound and outbound traffic. This is insecure, so you should not use it for production. Instead, create a custom Network ACL with specific deny-all rules at the beginning and then allow only necessary traffic.

## Check your understanding

1. **A web server in a public subnet cannot be reached from the internet. You check the Security Group and it allows HTTPS inbound from 0.0.0.0/0. What is the most likely remaining cause?**

   Answer: The Network ACL for the public subnet likely has an outbound rule that does not allow the response traffic on ephemeral ports (1024-65535), because Network ACLs are stateless and need explicit outbound rules for responses.

2. **Is a Security Group stateful or stateless?**

   Answer: Stateful. If you allow an inbound connection, the outbound response is automatically allowed without needing a separate outbound rule.

3. **You have a Network ACL with Rule 100 (Deny all traffic) and Rule 110 (Allow HTTP). Will HTTP traffic be allowed?**

   Answer: No. The rules are evaluated in numeric order, so Rule 100 (Deny all) matches first and denies the HTTP traffic before Rule 110 is checked.

4. **Can you attach a Network ACL directly to an EC2 instance?**

   Answer: No. A Network ACL is attached to a subnet, not to an individual instance. It controls traffic for all instances in that subnet. To control traffic for a specific instance, you use a Security Group.

5. **What is the main advantage of using both a Network ACL and a Security Group?**

   Answer: It provides defence in depth. The Network ACL blocks unwanted traffic at the subnet level, and the Security Group provides instance-level protection. Even if one is misconfigured, the other can still block malicious traffic.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-security-specialty/vpc-security-and-network-controls