AWS Security Groups vs Network ACLs: When to Use Each

Security groups and network ACLs are both AWS VPC firewalls, but they work differently: security groups are stateful, allow-only filters attached to resources, while network ACLs are stateless allow-and-deny filters attached to subnets. Most secure AWS designs use security groups as the primary control and network ACLs as a coarse backstop.

If you are building toward a cloud security career, this is one of the first AWS topics interviewers probe, and one of the most common sources of real-world misconfiguration. This guide explains how each control works, where they differ, and how to combine them.

Where these controls sit in a VPC

Traffic inside an Amazon VPC can be filtered at two layers:

1. The subnet boundary, controlled by a network access control list (network ACL, or NACL).
2. The network interface of a resource, controlled by one or more security groups.

A packet entering an EC2 instance in a subnet must pass both. If either layer denies it, the packet is dropped. That is why understanding both matters, and why a "my security group is open but traffic still fails" ticket often ends at a NACL.

How security groups work

According to the AWS VPC documentation, a security group acts as a virtual firewall for associated resources, such as EC2 instances. Key behaviors:

• Stateful. If an instance sends a request, the response is allowed back in regardless of inbound rules. Responses to allowed inbound traffic can leave regardless of outbound rules.
• Allow rules only. You cannot write an explicit deny rule. Anything not allowed is denied.
• Resource-level. A security group applies to network interfaces, and you can attach multiple security groups to one resource.
• Reference other security groups. A rule can name another security group as its source, which lets you express "the app tier may talk to the database tier" without hardcoding IP addresses.

Every VPC has a default security group. A new custom security group starts with no inbound rules and an outbound rule allowing all traffic. Review those defaults rather than assuming they match your policy.

What security groups do not filter

AWS documents that security groups do not filter some infrastructure traffic, including Amazon DNS, DHCP, EC2 instance metadata, the Amazon Time Sync Service, and reserved addresses used by the default VPC router. NACLs share this limitation. If you need to control metadata access, use instance-level settings such as enforcing IMDSv2, not firewall rules.

How network ACLs work

The network ACL documentation describes a subnet-level control with different mechanics:

• Stateless. Return traffic is not automatically allowed. If you allow inbound HTTPS, you must also allow the outbound response, which uses ephemeral ports.
• Allow and deny rules. You can explicitly block an address range.
• Numbered rules. Rules are numbered from 1 to 32766 and evaluated from lowest to highest. The first match wins and the rest are ignored.
• Subnet-level. Each subnet is associated with exactly one NACL, but one NACL can cover many subnets.

A practical habit is to number rules in increments such as 100, 200, and 300 so you can insert a rule later without renumbering everything.

The default NACL that comes with a VPC allows all inbound and outbound traffic. A custom NACL you create denies everything until you add rules. Teams that create a custom NACL and forget the return-traffic rules cause some of the most confusing outages in AWS.

Security groups vs network ACLs: side-by-side

Feature	Security group	Network ACL
Applies to	Network interface (resource)	Subnet
State	Stateful	Stateless
Rule types	Allow only	Allow and deny
Rule evaluation	All rules evaluated together	Numbered, first match wins
Return traffic	Automatic	Must be allowed explicitly
Multiple per resource	Yes, several security groups	One NACL per subnet
Can reference another group	Yes	No, uses CIDR blocks only
Best used for	Fine-grained, tier-to-tier access	Coarse subnet guardrails, explicit blocks

A practical layered design

Consider a classic three-tier application: a load balancer, an application tier, and a database tier.

Security groups do the precise work

• Load balancer security group: allow inbound 443 from the internet.
• App security group: allow inbound on the application port only from the load balancer security group.
• Database security group: allow inbound on the database port only from the app security group.

Because rules reference security groups, not IP addresses, the design keeps working as instances scale up and down. No one can reach the database directly, even from inside the VPC, unless they are in the app tier.

NACLs add a coarse backstop

Use NACLs sparingly. Good uses include:

• Blocking a known-bad CIDR range quickly during an incident, since NACLs support deny rules.
• Enforcing a subnet-wide rule, such as denying inbound SSH and RDP from the internet on private subnets, as a second line of defense.
• Isolating a subnet that holds sensitive workloads from other subnets.

Bad uses include trying to replicate your whole security group policy in NACL rules. That creates two policies to maintain, doubles the places a change can break something, and makes troubleshooting slow.

Common mistakes to avoid

1. Opening SSH or RDP to the whole internet. AWS guidance is to authorize only specific IP ranges, never 0.0.0.0/0 or ::/0, for administrative ports. Better still, use AWS Systems Manager Session Manager and close those ports entirely.
2. Reusing the default security group. Resources that land in it by accident inherit rules you did not design. Create purpose-built groups.
3. Wide port ranges. Allow only the ports a service needs, from only the sources that need them.
4. Forgetting ephemeral ports in a NACL. Stateless filtering requires you to allow the return path.
5. Too many people can edit rules. Use least-privilege IAM so only a small set of principals can modify security groups and NACLs. Our guide to least privilege in the cloud shows how to scope those permissions.
6. No visibility. Without logs you cannot tell whether a rule is too tight or too loose.

Verify and monitor your rules

AWS recommends VPC Flow Logs to capture IP traffic information for network interfaces and publish it to CloudWatch Logs or Amazon S3. Flow Logs record whether traffic was accepted or rejected, which helps you diagnose overly restrictive or overly permissive rules. AWS also offers Traffic Mirroring to copy traffic to out-of-band monitoring appliances.

For continuous posture checks, services such as AWS Config and Security Hub can flag security groups that allow unrestricted access to sensitive ports. See our overview of AWS Security Hub and Security Hub CSPM and our broader look at cloud network security fundamentals.

How this shows up in jobs and exams

Security groups versus NACLs is a staple of cloud security interviews and appears in AWS certification study material. Be ready to explain stateful versus stateless filtering, why return traffic matters for NACLs, and how you would block one malicious IP quickly (a NACL deny rule). Pair that knowledge with hands-on practice: build a small VPC, break it on purpose, and fix it using Flow Logs. That learn, practice, build, document approach is exactly how the PrimeSec curriculum teaches AWS networking and security, with labs you can show in a portfolio.

Frequently asked questions

What is the main difference between a security group and a network ACL? A security group is a stateful, allow-only firewall attached to a resource's network interface. A network ACL is a stateless firewall attached to a subnet that supports both allow and deny rules, evaluated in numbered order.

Do I need both security groups and network ACLs? Not strictly, since every subnet has a NACL and every resource has a security group by default. In practice, security groups handle most access control, and NACLs are used as an additional layer for subnet-wide guardrails or explicit blocks. AWS recommends considering NACLs as defense in depth.

Why is my security group allowing traffic but the connection still fails? Check the subnet's network ACL. Because NACLs are stateless, you must allow both the inbound request and the outbound response, including ephemeral ports. Also check route tables, and use VPC Flow Logs to see whether traffic is being accepted or rejected.

Can a security group deny traffic? No. Security groups only contain allow rules, and traffic that does not match an allow rule is denied. If you need an explicit deny, such as blocking a specific CIDR range, use a network ACL.

What happens in a network ACL when multiple rules match? Rules are evaluated from the lowest number to the highest, and the first matching rule is applied. Later rules are ignored for that packet, so rule order matters.

Is this topic covered in AWS security certifications? VPC network controls are part of the foundational knowledge expected for AWS security roles and certification study. Check the current exam guide on the official AWS Certification site for the exact domains and objectives, since they change over time.

Next step

Understanding VPC controls is a core skill, and you build it by doing. Explore the PrimeSec curriculum to see the hands-on AWS labs, or enroll today to start the 20-week Cloud and AI Platform Security Engineer program.