blogs-image

VPC Security Groups vs NACLs: What’s the Difference?

Introduction

When securing your AWS Virtual Private Cloud (VPC), you’ll encounter two key network security mechanisms: Security Groups and Network Access Control Lists (NACLs). Both play crucial roles in controlling traffic, but they operate at different layers and have distinct use cases. Understanding their differences is essential for building robust, secure, and scalable cloud architectures.

Purpose of Security Groups and NACLs

Security Groups

  • Acts as a virtual firewall for EC2 instances
  • Controls inbound and outbound traffic at the instance level
  • Stateful: return traffic is automatically allowed
  • Applied to ENIs (Elastic Network Interfaces)

Network ACLs (NACLs)

  • Acts as a firewall for subnets
  • Controls inbound and outbound traffic at the subnet level
  • Stateless: return traffic must be explicitly allowed
  • Rules are evaluated in order (lowest to highest number)

Prerequisites

  • An active AWS account
  • Basic understanding of AWS VPC concepts
  • IAM permissions to manage VPC, EC2, and network resources
  • Familiarity with AWS Management Console or AWS CLI

Feature Comparison

Feature Security Groups NACLs
Level Instance (ENI) Subnet
Stateful/Stateless Stateful Stateless
Default Behavior Deny all inbound, allow all outbound Allow all inbound and outbound
Rule Evaluation All rules are evaluated Rules evaluated in order
Applies To ENIs (EC2, Lambda ENIs, etc.) All resources in a subnet
Allow/Deny Rules Allow only Allow and Deny
Limits Up to 5 per ENI (default) 20 inbound and 20 outbound rules per NACL

Step-by-Step Guide

Create and Attach a Security Group
  1. Navigate to VPC Dashboard.
  2. Choose Security Groups → Create security group.
  3. Enter a name, description, and select the VPC.
  4. Add inbound/outbound rules (e.g., allow TCP 22 for SSH).
  5. Click Create.
  6. Attach the security group to an EC2 instance via Actions → Networking → Change Security Groups.
Create and Configure a NACL
  1. Go to VPC Dashboard.
  2. Select Network ACLs → Create network ACL.
  3. Provide a name and select the VPC.
  4. Add inbound and outbound rules (specify allow/deny, protocol, port range, source/destination).
  5. Associate the NACL with one or more subnets.
  6. Click Save.

Usage Examples

1. SSH Access to EC2 (Git Operations)

# Security Group Rule: Allow SSH
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 203.0.113.0/24

Allows developers to perform Git operations over SSH from trusted IPs.

2. REST API Endpoint Protection

// Security Group: Allow inbound HTTPS
{
  "IpProtocol": "tcp",
  "FromPort": 443,
  "ToPort": 443,
  "CidrIp": "0.0.0.0/0"
}

Restricts REST API access to HTTPS only, improving API gateway security.

3. Deny All Traffic Except Internal (NACL)

// NACL Rule: Allow only VPC internal traffic
{
  "RuleNumber": 100,
  "Protocol": "-1",
  "RuleAction": "allow",
  "CidrBlock": "10.0.0.0/16"
}
{
  "RuleNumber": 200,
  "Protocol": "-1",
  "RuleAction": "deny",
  "CidrBlock": "0.0.0.0/0"
}

Ensures only internal VPC traffic is allowed at the subnet level.

4. Allow Outbound Internet Access (Security Group)

// Outbound rule: Allow all
{
  "IpProtocol": "-1",
  "FromPort": 0,
  "ToPort": 65535,
  "CidrIp": "0.0.0.0/0"
}

Permits instances to access the internet for updates or API calls.

5. Restrict Database Access (Security Group)

// Allow only app servers to access RDS
{
  "IpProtocol": "tcp",
  "FromPort": 3306,
  "ToPort": 3306,
  "SourceSecurityGroupId": "sg-app-servers"
}

Limits database access to specific application servers, reducing attack surface.

Security Best Practices

  • Use least privilege: Only allow required ports and IPs.
  • Regularly review and audit rules for both Security Groups and NACLs.
  • Apply Security Groups to individual resources for granular control.
  • Use NACLs for broad subnet-level restrictions (e.g., block malicious IPs).
  • Enable VPC Flow Logs to monitor traffic and detect anomalies.
  • Document changes and use version control for infrastructure as code (e.g., Terraform).

Frequently Asked Questions

Yes, and it’s recommended. Security Groups provide instance-level control, while NACLs add subnet-level restrictions. Both are evaluated independently.

The most restrictive rule applies. If either denies traffic, it is blocked.

No. Security Groups are allow-only. To explicitly deny traffic, use NACLs.

NACL rules are evaluated in order, starting from the lowest rule number. The first matching rule is applied.

Yes, both support IPv4 and IPv6 rules.

Conclusion

Security Groups and NACLs are foundational to AWS VPC security. Use Security Groups for granular, instance-level control and NACLs for broad, subnet-level restrictions. By understanding their differences and best practices, you can design a secure, scalable, and robust network architecture in AWS.