Security Groups vs Network ACLs: The AWS Firewall Rules That Finally Made Sense

A beginner-friendly comparison of AWS Security Groups and Network ACLs, including how they control traffic, where they operate, and when to use each one.

Prince Malviya

Published Oct 3, 2026

Last modified Oct 3, 2026

🔐 Security Groups vs Network ACLs: The AWS Firewall Rules That Finally Made Sense

When I started learning AWS networking, two terms kept appearing:

Security Groups
Network ACLs

Both control network traffic.

So naturally, I wondered:

Why does AWS need two different security controls?

After learning how they work, the difference became much clearer.

The easiest way I now remember it is:

Security Groups protect resources. Network ACLs protect subnets.

Let's break that down.

🏗️ First, Where Do They Sit?

Imagine this simple architecture:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
                    🌍 Internet
                         │
                         ▼
                  ┌──────────────┐
                  │     VPC      │
                  │              │
                  │ Public Subnet│
                  │              │
                  │   ┌──────┐   │
                  │   │ EC2  │   │
                  │   └──────┘   │
                  │      ▲       │
                  │      │       │
                  │ Security     │
                  │   Group      │
                  └──────────────┘

The Security Group is associated with the resource, such as an EC2 instance.

A Network ACL operates at the subnet level.

So the traffic path can be thought of as:

1
2
3
4
5
6
7
8
9
10
11
12
13
Internet
   │
   ▼
Network ACL
   │
   ▼
Subnet
   │
   ▼
Security Group
   │
   ▼
EC2

This distinction is fundamental.

🛡️ What Is a Security Group?

A Security Group acts like a virtual firewall for AWS resources such as EC2 instances.

For example, I might create rules like:

1
2
3
4
5
6
7
8
9
Inbound Rules

HTTPS
Port: 443
Source: 0.0.0.0/0

SSH
Port: 22
Source: My trusted IP

This means:

HTTPS traffic can reach the instance.
SSH is restricted to my trusted IP.
Other inbound traffic isn't allowed by the security group's inbound rules.

🔄 Security Groups Are Stateful

This is one of the most important differences.

Security Groups are stateful.

Imagine my EC2 instance receives a request:

1
2
3
4
5
6
7
8
9
Client
  │
  │ HTTPS Request
  ▼
EC2
  │
  │ Response
  ▼
Client

If the inbound request is allowed by the Security Group, the response traffic is automatically allowed as part of that established connection.

I don't need to create a separate rule specifically for the response traffic.

That's what stateful means in this context.

🚧 What Is a Network ACL?

A Network Access Control List (NACL) operates at the subnet level.

Instead of protecting one specific EC2 instance, it controls traffic entering or leaving a subnet.

For example:

1
2
3
4
5
6
7
8
9
10
11
VPC
 │
 ├── Public Subnet
 │      │
 │      └── NACL
 │             │
 │             └── EC2
 │
 └── Private Subnet
        │
        └── NACL

A subnet has an associated Network ACL.

This provides another layer of network control.

🔢 NACL Rules Use Rule Numbers

NACL rules are evaluated in order.

For example:

1
2
3
4
5
6
7
8
9
10
Rule #100
Allow TCP 443
Source: 0.0.0.0/0

Rule #200
Allow TCP 80
Source: 0.0.0.0/0

Rule #* 
Deny everything else

AWS evaluates the rules starting with the lowest rule number.

The first matching rule is applied.

This means the order of NACL rules matters.

🔄 NACLs Are Stateless

This is another major difference.

Network ACLs are stateless.

If I allow inbound traffic, I also need to consider the corresponding outbound traffic.

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Client
   │
   │ Request
   ▼
NACL
   │
   ▼
EC2
   │
   │ Response
   ▼
NACL
   │
   ▼
Client

The inbound and outbound traffic are evaluated separately.

This is different from Security Groups.

⚔️ Security Group vs NACL

Here's the comparison that helped me remember the difference:

Feature	Security Group	Network ACL
Operates at	Resource level	Subnet level
Stateful	✅ Yes	❌ No
Supports explicit deny	❌ No	✅ Yes
Rules	Allow rules	Allow + Deny
Rule order	Doesn't use numbered evaluation order	Lowest number evaluated first
Controls	Traffic to/from associated resources	Traffic entering/leaving subnet
Common use	Protect EC2 and other resources	Additional subnet-level traffic control

🧠 A Simple Analogy

I found this analogy useful.

Imagine an apartment building.

🏢 Network ACL = Building security

The building security decides:

"Who is allowed into this part of the building?"

It operates at a broader level.

🚪 Security Group = Apartment door

The apartment door controls:

"Who can access this particular apartment?"

It's much more specific.

So:

1
2
3
4
5
6
7
8
9
10
Building Security
       │
       ▼
    Subnet
       │
       ▼
Apartment Door
       │
       ▼
   Resource

This isn't a perfect technical analogy, but it helped me understand the different scopes.

🌐 Real-World Example

Suppose I'm building a web application.

My architecture looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
                    🌍 Internet
                         │
                         ▼
                  Load Balancer
                         │
                         ▼
              ┌──────────────────┐
              │   Public Subnet   │
              │                   │
              │  Network ACL      │
              │        │          │
              │        ▼          │
              │  Load Balancer    │
              └────────┬──────────┘
                       │
                       ▼
              ┌──────────────────┐
              │  Private Subnet  │
              │                  │
              │  Network ACL     │
              │       │          │
              │       ▼          │
              │      EC2         │
              │   Security Group │
              └────────┬─────────┘
                       │
                       ▼
                  Database

I can use Network ACLs as a subnet-level control and Security Groups as a more specific resource-level control.

🔗 Security Groups Can Reference Other Security Groups

Another useful feature is that Security Groups can reference other Security Groups in certain AWS networking scenarios.

For example:

1
2
3
4
5
6
7
8
9
Load Balancer SG
       │
       │ allows HTTPS
       ▼
Application SG
       │
       │ allows database traffic
       ▼
Database SG

Instead of relying entirely on IP addresses, I can express relationships between application components.

For example:

Allow the database to receive traffic from the application servers' Security Group.

This makes large architectures easier to manage.

⚠️ Common Beginner Mistakes

❌ Mistake 1: Thinking Security Groups support explicit deny rules

They don't.

Security Groups use allow rules, and traffic that isn't allowed is denied.

❌ Mistake 2: Forgetting that NACLs are stateless

Inbound and outbound traffic are evaluated independently.

❌ Mistake 3: Thinking a public subnet automatically means every resource is publicly accessible

It doesn't.

Routing, IP addressing, Security Groups, and other configuration still matter.

❌ Mistake 4: Opening SSH to the entire internet unnecessarily

A rule such as:

1
2
Port: 22
Source: 0.0.0.0/0

allows SSH attempts from anywhere.

For administrative access, a narrower trusted source is generally preferable when practical.

❌ Mistake 5: Using complicated NACL rules without understanding the traffic flow

Because NACLs are stateless and rule ordering matters, troubleshooting them can become difficult if the rules aren't carefully designed.

🔍 How I Think About Troubleshooting Now

If an EC2 instance can't communicate with something else, I don't immediately blame the application.

I walk through the network:

1
2
3
4
5
6
7
8
9
1. Is the resource in the correct subnet?
             ↓
2. What does the route table say?
             ↓
3. Does the Network ACL allow the traffic?
             ↓
4. Does the Security Group allow the traffic?
             ↓
5. Is the resource configured correctly?

This approach gives me a much better way to troubleshoot AWS networking.

🎯 My Mental Model

After learning both concepts, I remember them like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
              VPC
               │
          ┌────▼────┐
          │ Subnet  │
          └────┬────┘
               │
          Network ACL
               │
               ▼
          ┌─────────┐
          │Resource │
          └────┬────┘
               │
        Security Group

Network ACL → subnet-level control

Security Group → resource-level control

And the biggest difference:

Security Groups are stateful and allow-based, while Network ACLs are stateless and support both allow and deny rules.

🚀 Final Takeaway

AWS networking initially looked like a collection of unrelated terms:

VPC → Subnet → Route Table → Internet Gateway → Security Group → NACL

But once I started thinking about where traffic enters, where it goes, and which layer controls it, the architecture became much easier to understand.

# aws-networking # amazon-vpc

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Security Groups vs Network ACLs: The AWS Firewall Rules That Finally Made Sense

Prince Malviya

🔐 Security Groups vs Network ACLs: The AWS Firewall Rules That Finally Made Sense

🏗️ First, Where Do They Sit?

🛡️ What Is a Security Group?

🔄 Security Groups Are Stateful

🚧 What Is a Network ACL?

🔢 NACL Rules Use Rule Numbers

🔄 NACLs Are Stateless

⚔️ Security Group vs NACL

🧠 A Simple Analogy

🏢 Network ACL = Building security

🚪 Security Group = Apartment door

🌐 Real-World Example

🔗 Security Groups Can Reference Other Security Groups

⚠️ Common Beginner Mistakes

❌ Mistake 1: Thinking Security Groups support explicit deny rules

❌ Mistake 2: Forgetting that NACLs are stateless

❌ Mistake 3: Thinking a public subnet automatically means every resource is publicly accessible

❌ Mistake 4: Opening SSH to the entire internet unnecessarily

❌ Mistake 5: Using complicated NACL rules without understanding the traffic flow

🔍 How I Think About Troubleshooting Now

🎯 My Mental Model

🚀 Final Takeaway