AWS security groups, network ACLs, and AWS Network Firewall all control network traffic, but they operate at different points and with different state models.

• Security groups are stateful allow rules attached to resources such as network interfaces.
• Network ACLs are stateless allow-and-deny rules applied at the subnet boundary.
• AWS Network Firewall is a managed VPC firewall that provides centralized stateless and stateful inspection.

The current AWS Certified Security – Specialty exam expects security engineers to design layered infrastructure security, not choose one control and assume the others are redundant.

Security groups protect resource interfaces

A security group acts as a virtual firewall for supported AWS resources.

It is commonly associated with elastic network interfaces used by:

• EC2 instances
• load balancers
• databases
• other VPC-connected services

Security groups contain allow rules.

They do not contain explicit deny rules.

If traffic does not match an allowed path, it is not permitted.

This makes security groups a strong workload-level segmentation control.

Within an AWS VPC, security groups operate close to the protected resources at the network-interface layer.

Security-group connection tracking is one of the biggest differences from network ACLs.

If traffic is allowed into a resource through a security-group rule, the response traffic is allowed back through the stateful connection tracking.

You do not need a second reverse-direction rule merely to permit the reply.

For example, if an application security group allows inbound TCP 443 from a load balancer, return traffic for that established connection is tracked automatically.

Statefulness simplifies application rules.

It also means security-group behavior should not be reasoned about like an ordered packet-filter ACL.

Network ACLs operate at subnet scope

A network access control list is associated with one or more subnets.

Every subnet has a network ACL association.

A custom NACL contains numbered inbound and outbound rules.

Rules can explicitly:

• allow
• deny

traffic based on network attributes.

The rules are evaluated in number order until a match is found.

That makes NACLs useful when the network team wants a broader subnet boundary in addition to resource-level security groups.

An access control list applies ordered allow/deny logic. AWS NACLs add subnet scope and stateless return-traffic requirements to that general model.

A NACL does not automatically remember that a connection was established.

If inbound traffic is allowed, the required outbound return traffic must also be allowed by the outbound NACL rules.

This is why ephemeral ports matter.

A client may connect to a server’s TCP port 443, but the reverse traffic uses the client’s ephemeral port range.

An overly restrictive NACL can allow the incoming request and then block the response.

This is a common troubleshooting pattern.

Security groups and NACLs therefore behave differently even when their source/destination rules look similar.

Security groups are usually the primary workload control

AWS guidance notes that workloads can be secured using security groups alone in many cases.

NACLs can add another layer.

This is a useful default.

Use security groups to express workload-level relationships such as:

• web tier may reach application tier
• application tier may reach database tier
• only the management service may reach admin port

Then use NACLs where the subnet boundary needs an additional broad control.

Do not duplicate every security-group rule into a NACL unless the architecture has a reason.

Duplicated rule sets increase operational complexity.

Network Firewall is for routed inspection

AWS Network Firewall is different from both.

Traffic must be routed through Network Firewall endpoints for inspection.

The firewall can use:

• stateless rule groups
• stateful rule groups
• managed rule groups
• Suricata-compatible stateful rules
• domain and protocol-aware inspection capabilities depending on configuration

Network Firewall is therefore appropriate for centralized inspection architectures.

Examples include:

• internet ingress/egress inspection
• traffic between VPCs
• centralized security VPCs
• Transit Gateway architectures
• domain filtering
• intrusion-prevention rules

The same firewall fundamentals behind centralized stateful inspection apply when deciding what traffic AWS Network Firewall should evaluate.

Network Firewall has both stateless and stateful engines

AWS Network Firewall processes traffic through separate rule engines.

The stateless engine evaluates packets individually.

A stateless rule can:

• pass
• drop
• forward traffic to the stateful engine

The stateful engine evaluates traffic in the context of the flow.

It supports deeper rule behavior and Suricata-compatible inspection.

This gives the service much richer inspection capability than a NACL.

Do not confuse the existence of stateless Network Firewall rules with VPC NACLs. They operate in different products and architectures.

Routing determines whether Network Firewall sees the traffic

A firewall cannot inspect traffic that never passes through it.

Network Firewall deployments therefore depend heavily on route-table design.

For example, an egress architecture may route application-subnet traffic through firewall endpoints before it reaches a NAT gateway or internet gateway.

An east-west architecture may send traffic between VPCs through a centralized inspection path.

If routing bypasses the firewall endpoint, the rules do not apply.

Always troubleshoot both:

• firewall policy
• network path

A production workload can use all three.

For example:

Security group

• allow app servers to reach database servers on the database port

NACL

• block a known malicious CIDR across the subnet boundary

Network Firewall

• inspect centralized egress and block suspicious domains or intrusion signatures

These controls do not need identical rules.

Each layer should enforce the policy appropriate to its scope.

Choose by enforcement point

Use security groups when:

• the rule belongs close to the resource
• stateful allow-only behavior is appropriate
• workload segmentation is the goal

Use network ACLs when:

• a subnet-level stateless boundary is useful
• explicit deny is required
• broad network-layer filtering complements security groups

Use AWS Network Firewall when:

• traffic should pass through centralized inspection
• stateful or Suricata-style controls are needed
• managed rule groups or deeper filtering are required

Follow the packet path before changing a rule

Most AWS network-security troubleshooting gets easier when the engineer traces the packet from source to destination and identifies which control can actually see it. A security group is attached to an elastic network interface and evaluates allowed traffic for that resource. A network ACL is associated with a subnet and evaluates packets crossing that subnet boundary. AWS Network Firewall only evaluates traffic that routing deliberately sends through its firewall endpoints. The same packet can encounter all three controls, but each one operates at a different enforcement point.

That distinction prevents a common mistake: adding a Network Firewall rule for traffic that never traverses the firewall endpoint. A route table can bypass the inspection path entirely. In that case, the firewall policy may be perfectly written and still have no effect. Conversely, a packet can pass centralized inspection and then be rejected by the destination security group because the resource-level allow rule is missing.

Return traffic also explains many asymmetric failures. Security groups are stateful, so response traffic for an allowed connection is automatically tracked. NACLs are stateless, so rules must accommodate both directions, including ephemeral ports where applicable. Network Firewall has its own stateless and stateful processing behavior. If one direction follows a different route from the other, stateful inspection can fail even though individual rules appear reasonable.

A practical packet-path review therefore includes the source ENI, source security group, source subnet NACL, route tables, any transit or firewall endpoints, destination subnet NACL, and destination security group. VPC Flow Logs and firewall logs can narrow the search, but they do not replace understanding which hop should enforce the policy.

Layer controls according to the threat model

Security groups are usually the first workload boundary because they express which peers and ports should reach a resource. Their stateful behavior makes them well suited to application communication. NACLs are useful when a subnet-level stateless filter or explicit deny is required, but a very complex NACL design becomes hard to reason about because rule order, direction, and ephemeral-port behavior all matter.

Network Firewall belongs where the organization needs routed inspection that goes beyond simple source, destination, protocol, and port decisions. Stateful inspection, managed rule groups, domain-oriented controls, and Suricata-compatible rules can support centralized egress inspection, segmentation between networks, or inspection around shared connectivity. That does not make the firewall a replacement for security groups. Resource-level least privilege still reduces blast radius if traffic reaches the destination VPC.

The strongest design assigns each control a clear job. Security groups answer which resources may communicate. NACLs provide coarse subnet-boundary constraints where needed. Network Firewall performs centralized inspection on paths that are explicitly routed through it. When two layers duplicate hundreds of rules without a documented reason, the environment becomes harder to troubleshoot and easier to misconfigure.

For exam and production scenarios alike, choose the control by asking where must the decision be enforced, does the control need state, and must it explicitly deny or deeply inspect traffic? Those three questions usually identify the correct layer faster than memorizing feature lists.
Troubleshooting should also separate reachability from inspection quality. A route or rule change that restores connectivity is not automatically the correct security fix. For example, opening a broad security-group CIDR may make an application work while bypassing the intended least-privilege design. The safer method is to prove the required source, destination, protocol, and port, then make the smallest change at the control that actually owns that decision. Flow logs, Reachability Analyzer, and firewall logs can support that proof, but the architecture still determines which evidence is authoritative for each hop.