AWS Security Groups vs. Network ACLs: Key Differences, Examples, and Best Practices

madhuchamara — Sun, 18 Oct 2026 06:13:31 +0000

Introduction

When designing a secure network in Amazon Web Services (AWS), two important components of Amazon VPC networking are Security Groups (SGs) and Network Access Control Lists (NACLs).

Both control network traffic entering and leaving an AWS environment, but they operate at different levels and follow different rule-evaluation models.

Understanding their differences helps you design secure cloud infrastructure, troubleshoot connectivity issues, and avoid common networking mistakes.

The key distinction is:

Security Groups: Stateful firewalls associated with network interfaces and supported resources.
Network ACLs: Stateless packet filters associated with VPC subnets.

They are complementary security controls rather than direct alternatives.

What is an AWS Security Group?

An AWS Security Group acts as a virtual firewall for supported resources, such as EC2 instances. It is associated with a resource's network interface and controls which inbound and outbound traffic is permitted.

Security Groups use allow rules. Traffic that does not match an applicable allow rule is denied.

Example: Web server Security Group

Imagine an EC2 instance hosting a website.

You could configure its Security Group with these inbound rules:

Type Protocol Port Source Purpose
HTTPS TCP 443 0.0.0.0/0 Allow public HTTPS access
SSH TCP 22 Your trusted IP /32 Allow restricted administration

In production, expose only the services that need public access. If possible, use AWS Systems Manager Session Manager or another controlled administrative path instead of exposing SSH to the internet.

Important characteristics

Stateful filtering

Security Groups track connection state. When an inbound request is allowed, its response traffic is automatically permitted by the Security Group. You do not need a separate outbound rule solely to permit the response.

Allow rules only

Security Groups do not support explicit DENY rules. You allow the required traffic and leave other traffic unmatched.

All applicable rules are considered

Security Group rules do not use numbered, first-match evaluation. When multiple Security Groups are attached to a network interface, their allowed traffic is combined. A matching allow rule in one Security Group can permit traffic even if another Security Group has no matching allow rule.

Resource-level control

Security Groups can reference other Security Groups as sources or destinations where supported. This makes it possible to grant access based on workload membership rather than maintaining static IP allowlists.

What is an AWS Network ACL?

A Network Access Control List (NACL) controls traffic at the subnet boundary. Every VPC subnet is associated with one NACL at a time. A NACL can be associated with multiple subnets.

Unlike Security Groups, NACLs support both ALLOW and DENY rules.

Example: Subnet-level filtering

Suppose a public subnet contains a web server. A NACL could include rules such as:

Rule number Direction Traffic Action
100 Inbound TCP 443 from an approved source ALLOW
110 Inbound TCP 22 from a prohibited CIDR DENY
120 Inbound Other required traffic ALLOW, if appropriate

These entries are illustrative, not a complete production NACL. A real configuration must account for the application’s required traffic, response traffic, and the default rule that denies unmatched traffic.

Important characteristics

Stateless filtering

NACLs do not track connection state. Inbound and outbound packets are evaluated independently, including response traffic.

Explicit ALLOW and DENY

A NACL can explicitly block a CIDR range at the subnet boundary. This is useful for coarse-grained subnet protection.

Numbered, first-match rules

Rules are evaluated in ascending numerical order. The first matching rule determines the action, and later rules are not evaluated for that traffic.

For example, a DENY rule numbered 100 is evaluated before an ALLOW rule numbered 200. If the traffic matches rule 100, the later ALLOW rule cannot override it.

Subnet-level scope

NACL rules apply to traffic entering or leaving the associated subnet. They are not a replacement for routing controls, Security Groups, or application-level authorization.

Security Groups vs. NACLs: Detailed Comparison Feature Security Group Network ACL Primary scope Resource/network interface Subnet Stateful or stateless Stateful Stateless Rule actions ALLOW ALLOW and DENY Rule evaluation All applicable rules contribute to the result Lowest-numbered matching rule wins Inbound rules Yes Yes Outbound rules Yes Yes Return traffic Automatically permitted for tracked connections Must independently match the relevant rules References to other Security Groups Supported in applicable rules Not supported Typical role Primary workload-level firewall Additional subnet-level filtering Common troubleshooting issue Missing allow rule or overly restrictive outbound rule Missing return-traffic rule or an earlier matching rule

The two controls should be designed together. Passing a NACL does not guarantee that a Security Group permits traffic, and passing a Security Group does not bypass a restrictive NACL.

Stateful vs. Stateless: A Practical Example

Consider a client connecting to a web server over HTTPS.

The client uses TCP source port 51514 and connects to destination port 443.

The request travels as follows:

The client sends a packet from source port 51514 to server port 443.
The subnet's inbound NACL evaluates the request.
The Security Group attached to the server's network interface evaluates the request.
The web server responds from source port 443 to client port 51514.
The outbound NACL evaluates the response packet.
With a Security Group

If the inbound HTTPS connection is permitted, the Security Group automatically permits the tracked response traffic. You do not need to add a Security Group rule solely for the client's response destination port.

With a NACL

The NACL does not remember the original connection. The outbound response must independently match an outbound ALLOW rule. If the NACL blocks the client's return port, the connection may time out even though inbound HTTPS was allowed.

For internet-facing servers, carefully design the NACL's return-traffic rules and the ephemeral port ranges required by the client population. Do not assume that allowing inbound port 443 alone is sufficient.

How They Work Together in an AWS Architecture

Consider a three-tier application:

Internet → Public subnet (load balancer) → Private application subnet → Private database subnet

Each subnet has an associated NACL, while resources use Security Groups appropriate to their roles.

Public load balancer

The load balancer Security Group permits the required public listener traffic, such as HTTPS on port 443.

Application tier

The application Security Group allows inbound traffic only from the load balancer Security Group on the application port.

Database tier

The database Security Group allows the required database port only from the application Security Group.

For example, if the application uses PostgreSQL, the database Security Group might allow TCP port 5432 from the application Security Group rather than from the entire VPC or internet.

NACLs can provide additional subnet-level restrictions, such as blocking a prohibited CIDR range or enforcing a stable subnet boundary.

This design follows least privilege: each workload receives only the network access it needs.

When Should You Use Each? Use Security Groups as your primary control when: Restricting access to EC2 instances and other supported resources. Allowing application traffic from specific workload Security Groups. Controlling administrative access to instances. Defining the allowed connections between application tiers. Consider NACLs when: You need explicit DENY rules for a subnet. You need an additional coarse-grained security boundary. You want a subnet-level safeguard against a known unwanted CIDR range. Your security requirements call for a control that applies independently of individual resource Security Groups.

NACLs are not mandatory as a second restrictive firewall layer in every design. Overly complicated NACLs can increase operational overhead and cause unexpected connectivity failures.

Common Mistakes and Troubleshooting Tips Mistake 1: Allowing inbound traffic but forgetting NACL return traffic

Symptom: A service accepts inbound requests in principle, but connections time out.

Cause: The NACL allows the request but does not permit the response packet's destination port.

Solution: Review both inbound and outbound NACL rules, including the relevant ephemeral port ranges.

Mistake 2: Expecting a Security Group to explicitly deny an IP

Symptom: You want to block one IP address while allowing other traffic through the same port.

Cause: Security Groups do not provide explicit DENY rules.

Solution: Review whether a NACL, AWS Network Firewall, or another appropriate control is suitable for the requirement. Be careful: a NACL deny can affect every resource in the subnet.

Mistake 3: Assuming a NACL rule can override an earlier rule

Symptom: A later ALLOW rule appears correct, but traffic remains blocked.

Cause: An earlier matching DENY rule wins.

Solution: Inspect the numbered rules in ascending order.

Mistake 4: Assuming network rules alone establish connectivity

Symptom: Security Groups and NACLs appear correct, but the service is unreachable.

Cause: Connectivity may also depend on route tables, gateways, DNS, host firewalls, service listeners, or application configuration.

Solution: Verify the full network path and consider VPC Flow Logs to help investigate accepted and rejected traffic.

Best Practices

Use Security Groups as the primary resource-level network access control.
Apply least privilege to inbound and outbound rules.
Prefer Security Group references for communication between supported workloads.
Avoid unrestricted administrative access from the internet.
Use NACLs for clearly defined subnet-level controls rather than duplicating every Security Group rule.
Leave gaps between NACL rule numbers to make future changes easier.
Document the purpose and owner of each rule.
Review unused and overly broad rules periodically.
Test restrictive NACL changes carefully, particularly return traffic.
Use VPC Flow Logs and other AWS monitoring tools to help troubleshoot network connectivity. Conclusion

AWS Security Groups and Network ACLs serve different purposes in VPC security.

Security Groups provide stateful, resource-level filtering using allow rules. NACLs provide stateless, subnet-level filtering using numbered ALLOW and DENY rules.

The practical rule is simple:

Use Security Groups to control which workloads can communicate. Use NACLs when you need additional subnet-level filtering.

When both are designed carefully, they can provide complementary layers of network protection without making connectivity unnecessarily difficult to manage.

DEV Community: madhuchamara

AWS Security Groups vs. Network ACLs: Key Differences, Examples, and Best Practices

Introduction