Harden VPC Network ACLs

Your VPC is the front door to your cloud workloads, and network ACLs (NACLs) are one of the first layers an attacker will probe. Leave them wide open with default "allow all" rules and you're one misconfigured security group away from exposing a database or admin dashboard to the internet. In this lesson, you'll learn how to harden VPC network ACLs in practice — moving from permissive defaults to a least-privilege model that filters traffic at the subnet boundary, and doing it with hands-on examples you can adapt today.

The problem this lesson solves

Most cloud environments start with NACLs that allow all inbound and outbound traffic. That's convenient for prototyping, but it's a ticking time bomb in production. NACLs are stateless — they don't track connection state — so a single overly-broad rule can let an attacker reach ports you never intended to expose. Consider these real scenarios:

• A database subnet with a NACL that allows all traffic on port 3306, so any IP in the VPC (or worse, the internet) can try to connect.
• An application subnet that allows all outbound traffic, letting a compromised instance exfiltrate data to any external server.
• A shared VPC where dev teams add permissive rules "temporarily" and never clean them up, accumulating attack surface.

Harden VPC network ACLs in practice means systematically reviewing and tightening these rules until every allowed flow has a business reason behind it. It's not just about blocking bad traffic — it's about making your network predictable, auditable, and resilient to misconfiguration.

Core concept / mental model

Think of a network ACL as a bouncer at the entrance of your subnet. Unlike a security group (which is like a guest list at the instance level and stateful), a NACL is stateless: it doesn't remember who's already inside. Every packet is judged individually. That's the key mental model shift.

If a security group allows a response to a request, the response flows automatically. With a NACL, you must explicitly allow both the request and the response. This dual-rule requirement is where most misconfigurations happen.

Another useful analogy: imagine a series of checkpoints along a road. Each checkpoint (NACL rule) has a list of allowed license plates and destinations. The road itself (the subnet) is only as secure as its weakest checkpoint. If one rule allows all traffic from 0.0.0.0/0, the rest of your careful configuration is meaningless.

Key terms: - Stateless — no memory of connections; each packet evaluated independently. - Rule number — priority; lower numbers evaluated first. Once a rule matches, evaluation stops. - Ephemeral ports — high-numbered ports (1024–65535) used for responses; often forgotten when tightening inbound rules.

How it works step by step

Here's the practical sequence to harden VPC network ACLs in practice, whether you're using AWS, GCP, or Azure (concepts translate, though rule syntax differs).

1. Inventory your subnets and NACL associations. List every subnet and its attached NACL. Identify critical subnets (databases, app tiers, management) that need tighter rules.

2. Document required traffic flows. For each subnet, write down which sources should reach which destinations and on which ports. Examples: web instances accept HTTPS from the internet; app instances talk to the database on 3306 only from the app subnet; SSH access comes from a bastion IP.

3. Remove default allow-all rules. Replace the default "allow all inbound/outbound" with explicit deny-all rules at the bottom (highest rule number). Then add precise allow rules for your documented flows.

4. Order rules by specificity. Put the most specific high-priority rules first. For example, allow SSH from your office IP, then deny all other SSH. Remember rule evaluation stops at the first match, so broad denies can go after specific allows.

5. Include ephemeral port ranges. For any inbound allow, you must also allow outbound responses on ephemeral ports (typically 1024–65535). Without this, legitimate traffic breaks even though you "allowed" it.

6. Test and monitor. Deploy the changes, then test from each required source. Use VPC Flow Logs or equivalent to verify no legitimate traffic is blocked and no unexpected traffic is happening.

Hands-on walkthrough

Let's apply this with an AWS example. We'll create a NACL for a database subnet that only allows MySQL from a specific app subnet CIDR and SSH from our office IP. Assume the VPC CIDR is 10.0.0.0/16, the app subnet is 10.0.1.0/24, and our office IP is 203.0.113.10.

Step 1: Create the NACL

# Create a network ACL for the database subnet
aws ec2 create-network-acl --vpc-id vpc-0abc12345 --tag-specifications \
  'ResourceType=network-acl,Tags=[{Key=Name,Value=db-nacl}]'

Step 2: Replace default rules with deny-all

# Get the NACL ID (from output) and set deny-all inbound and outbound rules
aws ec2 replace-network-acl-entry --network-acl-id acl-12345 \
  --ingress --rule-number 100 --protocol -1 \
  --cidr-block 0.0.0.0/0 --rule-action deny

aws ec2 replace-network-acl-entry --network-acl-id acl-12345 \
  --egress --rule-number 100 --protocol -1 \
  --cidr-block 0.0.0.0/0 --rule-action deny

Step 3: Add precise allow rules

# Allow inbound MySQL from the app subnet
aws ec2 create-network-acl-entry --network-acl-id acl-12345 \
  --ingress --rule-number 10 --protocol tcp --port-range From=3306,To=3306 \
  --cidr-block 10.0.1.0/24 --rule-action allow

# Allow inbound SSH from office IP
aws ec2 create-network-acl-entry --network-acl-id acl-12345 \
  --ingress --rule-number 20 --protocol tcp --port-range From=22,To=22 \
  --cidr-block 203.0.113.10/32 --rule-action allow

# Allow outbound responses on ephemeral ports
aws ec2 create-network-acl-entry --network-acl-id acl-12345 \
  --egress --rule-number 10 --protocol tcp --port-range From=1024,To=65535 \
  --cidr-block 10.0.1.0/24 --rule-action allow

aws ec2 create-network-acl-entry --network-acl-id acl-12345 \
  --egress --rule-number 20 --protocol tcp --port-range From=1024,To=65535 \
  --cidr-block 203.0.113.10/32 --rule-action allow

Step 4: Associate with the subnet

aws ec2 associate-network-acl --network-acl-id acl-12345 --subnet-id subnet-0def456

Expected result: The database subnet now only accepts MySQL from the app subnet and SSH from your IP. All other traffic is denied explicitly. Run a quick test from the app subnet:

# Simple port check from an instance in the app subnet
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
result = s.connect_ex(('10.0.2.5', 3306))  # DB instance private IP
print(f"MySQL port reachable: {result == 0}")
s.close()

Output:

MySQL port reachable: True

If you try from another CIDR, it should fail.

Compare options / when to choose what

You have multiple ways to enforce network restrictions. Here's how NACLs compare to alternatives:

Rule of thumb: Use NACLs as the outer perimeter for a subnet, and security groups as the inner detail. Combine them for defence in depth. For most workloads, you'll need both.

Variations to consider

• Managed prefix lists — define reusable IP ranges and reference them in NACL rules, reducing errors and easing updates.
• Tiered NACL design — create separate NACLs for each tier (web, app, db) rather than one per subnet, making audits easier.
• Infrastructure as Code — define NACLs in Terraform or CloudFormation so changes are reviewed via pull requests and versioned.

Troubleshooting & edge cases

Symptom 1: Everything works after deployment, then breaks later. You added a new instance or service and forgot to update the NACL. Always document flows and review NACLs whenever you deploy something new.

Symptom 2: MySQL connections time out even though you allowed port 3306. This is the classic stateless pitfall. You allowed inbound on 3306, but outbound responses on ephemeral ports are blocked. Add the outbound rule on 1024–65535. Check your security group too — it might be blocking at the instance level.

Symptom 3: SSH works from your office but fails from a remote worker. Your rule is pinned to a specific IP. If your office uses dynamic IPs, you'll need a VPN or a bastion host so you can keep the CIDR narrow.

Symptom 4: Broad deny rule at the top blocks everything. Rule numbers matter. If you set deny-all at rule 1, it's evaluated first and blocks all. Put broad denies at higher numbers (like 32766) to act as a safety net, not a gate.

Symptom 5: You forgot to update the NACL after a VPC peering change. Peered connections require rules in both subnets' NACLs. Always extend CIDR rules to include the peered VPC range if traffic should flow.

What you learned & what's next

You've now hardened VPC network ACLs in practice: you can explain the stateless nature of NACLs, replace permissive defaults with least-privilege rules, order rules correctly, and troubleshoot common failures. You also know how NACLs complement security groups and why ephemeral ports matter.

Next lesson in the Cloud security essentials track: Network segmentation with VPC peering and transit gateways — you'll learn how to connect multiple VPCs securely while keeping NACLs and security groups aligned across boundaries.