Security Groups, Network ACLs, and Inspection Placement

Goal

The mental model section separated network security into layers. This section focuses on the controls closest to VPC traffic: security groups, network ACLs, and AWS Network Firewall.

The goal is to help you explain which control belongs at which point in the design. This is one of the most useful AWS networking conversations because the names are easy to memorize, but the placement choices are where architecture judgment appears.

The Short Version

Use this simple distinction:

Security groups are stateful. Network ACLs are stateless. AWS Network Firewall can use stateless and stateful rule groups, but it only matters for traffic that the VPC routing design sends through the firewall path.

Security Groups: Workload Intent

A security group acts like a virtual firewall for associated AWS resources. In design terms, it is where you express the relationship between workload components.

For example:

• The load balancer security group allows HTTPS from the internet or trusted edge path.

• The application security group allows traffic from the load balancer security group.

• The database security group allows traffic only from the application security group.

• Administrative access is restricted to a trusted path, not opened broadly.

The useful habit is to describe sources by role when possible, not only by IP range. "The application tier may call the database tier" is clearer than "some private subnet CIDR may reach port 5432." CIDR rules are sometimes necessary, especially for hybrid and shared services, but role-based security group references often make the design easier to review.

Security groups being stateful means response traffic for an allowed request is handled without writing a separate reverse rule. That is why they feel natural for workload allow-listing.

Network ACLs: Subnet Guardrails

Network ACLs work at the subnet boundary. They can allow or deny inbound and outbound traffic using ordered rules.

That gives them a different job from security groups. A network ACL can be useful when the team wants a broad subnet-level guardrail, such as blocking a known unwanted range or adding another boundary around a subnet category. It is less pleasant as the primary way to describe application relationships because it does not know that "web tier" and "database tier" are logical roles.

Network ACLs are stateless. If a rule allows inbound traffic, the response is not automatically allowed just because the inbound rule matched. You must think about both directions. That can be useful for very explicit subnet policy, but it can also create fragile designs if the team tries to manage every application conversation there.

AWS Network Firewall: Inspection Needs a Path

AWS Network Firewall is a managed network firewall and intrusion detection and prevention service for VPC traffic. It can inspect traffic at VPC perimeters and on paths to internet gateways, NAT gateways, VPN, and Direct Connect, depending on how the architecture routes traffic.

The architecture point is simple:

Firewall policy only helps traffic that crosses the firewall path.

Protected subnet route table
  -> firewall endpoint
  -> internet gateway, NAT gateway, transit path, or destination

If a route table sends traffic directly to a destination without crossing the firewall endpoint, the firewall does not inspect that traffic. This is why inspection design belongs together with subnet layout, route tables, centralized networking accounts, and failure planning.

Network Firewall becomes useful when the team needs more than workload allow-listing. Examples include egress domain filtering, deep packet inspection, IDS/IPS-style controls, inspection for traffic entering or leaving a VPC, or consistent firewall policy across multiple accounts through central management.

Choosing the Right Control

Use this decision frame:

The controls can layer. A private application subnet may have a network ACL, application instances may have security groups, outbound traffic may be routed through Network Firewall, and edge traffic may be filtered by WAF before it reaches the load balancer.

Example: Protecting a Private Application Tier

Imagine an application tier that receives traffic from an internal load balancer and calls a database. The simplest strong design starts with security groups:

• Load balancer security group allows the intended listener from approved sources.

• Application security group allows inbound traffic only from the load balancer security group.

• Database security group allows inbound database traffic only from the application security group.

If the application also needs outbound internet access for updates or third-party APIs, the architecture has a separate egress question. The team might route outbound traffic through NAT and AWS Network Firewall for inspection, or avoid internet egress for AWS service calls by using VPC endpoints. That choice should be explicit.

Common Mistakes

• Treating network ACLs as a more powerful version of security groups.

• Forgetting that network ACLs are stateless and rule-ordered.

• Using IP ranges everywhere when security group references would express intent better.

• Placing AWS Network Firewall in a VPC but leaving important route tables untouched.

• Sending all traffic through inspection without considering availability, cost, latency, and operational ownership.

If Someone Asks You

How do security groups, network ACLs, and AWS Network Firewall differ?

A good answer is:

Security groups are stateful workload boundaries, so I use them to express which resources can talk to which other resources. Network ACLs are stateless subnet guardrails, useful for broader allow or deny rules at the subnet edge. AWS Network Firewall is for traffic that needs deeper or centralized inspection, but the route tables must send that traffic through firewall endpoints. They layer, but they do not replace each other one-for-one.

What You Should Remember

Security groups express workload intent; network ACLs add subnet guardrails; inspection services require routing design.

Questions to Check Your Understanding

1. Why are security groups usually better than network ACLs for application-tier relationships?

2. What does stateless behavior change about network ACL design?

3. Why can AWS Network Firewall fail to inspect traffic even when it exists in the VPC?