AWS Network Firewall: Deploying Stateful Inspection in VPCs

Security groups and network ACLs decide which ports and addresses can talk inside a VPC, but they cannot see domain names, inspect payloads or stop a compromised workload from calling out to an attacker's server over port 443. AWS Network Firewall is the managed service that fills that gap: a stateful firewall and intrusion prevention engine, built on Suricata, that sits in the routing path at the VPC perimeter. Deploying it well is mostly about routing, rule evaluation order and logging, and getting any of the three wrong produces a firewall that is billed, attached and quietly passing everything. This guide covers how the service is built, who should be allowed to change it, how rule groups, managed rules and TLS inspection fit together, what to log and alert on, and a hardening baseline with rollout and rollback steps. It is written for cloud network and security engineers; for VPC fundamentals such as security groups, NACLs and endpoints, see the Amazon VPC Security Guide.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• Routing is the control. The firewall only inspects traffic your VPC route tables send to its endpoints in dedicated firewall subnets; a missing route or an asymmetric path means traffic bypasses inspection without any error.
• Use strict rule order with a default drop. AWS recommends strict evaluation order. The default action order runs every pass rule before any drop rule regardless of priority, which surprises teams writing allow lists.
• Only stateful traffic is logged. Flow, alert and TLS logs cover traffic forwarded to the stateful engine; packets passed or dropped by stateless rules appear only in CloudWatch metrics.
• Managed rule groups are a fast start, not a policy. AWS maintains active threat defence, domain and IP, and threat signature groups, but egress allow lists for your own workloads still have to be written and owned.
• TLS inspection changes the trust model. Outbound decryption needs a CA certificate in AWS Certificate Manager that clients trust, drops non-TLS traffic in scope; plan separately for ECH, QUIC and StartTLS traffic, which sits outside TLS inspection (confirm current scope with AWS).

How AWS Network Firewall works

The service is defined by four resource types and two inspection engines.

Stateless engine first. Each packet is checked individually against stateless rules, with actions Pass, Drop, Forward to stateful rules, or a custom action that publishes a CloudWatch metric dimension. Separate default actions apply to full packets and to UDP fragments; AWS notes fragments of other protocols are silently dropped. In almost every design the stateless default should be forward to stateful (aws:forward_to_sfe in the API), so that the stateful engine makes the decision and logs it.

Stateful engine second. Flows are tracked in a state table identified by source, destination, ports, protocol and direction. Stateful rule actions are pass, drop, reject (TCP only, sends a reset) and alert. A drop or alert match does not end evaluation, and an alert match does not imply pass.

Deployment. Network Firewall creates firewall endpoints in firewall subnets that must hold nothing else, and an endpoint cannot filter traffic entering or leaving its own subnet. VPC route tables steer traffic through it. The default source-preservation mode keeps original IP addresses and handles TCP, UDP and ICMP. A firewall can also be attached directly to a transit gateway, owned locally or shared through AWS RAM, which avoids building inspection VPC plumbing by hand. AWS lists VPC peering traffic, Global Accelerator traffic with client IP preservation and AmazonProvidedDNS traffic from EC2 as unsupported for inspection, so DNS-layer filtering needs a separate control such as Route 53 Resolver DNS Firewall. See the DNS Security Guide.

Choosing rule order, default actions and deployment model

AWS also warns against relying on a default drop for application-layer matching such as HTTP headers: the default can act on a single packet before data spanning several packets is evaluated, so write explicit application drop rules instead. Under Application drop established (bidirectional), TCP control packets after the handshake may need explicit pass rules. Test both in alert-only mode before enforcing.

How identity and access work in AWS Network Firewall

Network Firewall is controlled entirely through IAM, and its own service identities are few but important.

• Human and pipeline access: callers authenticate as IAM roles (preferably federated through IAM Identity Center) and requests are signed with Signature Version 4. Identities have no permissions by default, and identity-based policies, permissions boundaries, SCPs, RCPs and session policies all apply. See the AWS IAM Policies and Roles Guide.
• Service-linked role: AWSServiceRoleForNetworkFirewall, trusted only by network-firewall.amazonaws.com and using the managed policy AWSNetworkFirewallServiceRolePolicy. It creates, describes and deletes the VPC endpoints for the firewall, reads VPC CIDRs and describes ACM certificates for TLS inspection. Do not try to replace it, but do monitor who can delete it.
• Log delivery role: enabling logging may create AWSServiceRoleForLogDelivery. The destination (S3 bucket, CloudWatch Logs group or Data Firehose stream) needs a policy that allows delivery and nothing broader.
• Cross-account sharing: transit gateways for firewall attachment are shared through AWS RAM; rule groups and policies can be shared too, so a central security account can publish policy for workload accounts. Treat a RAM share as a trust relationship that needs review.
• Encryption: firewall data at rest uses AWS owned keys by default, with customer managed KMS keys as an option. If you choose a customer managed key, the key policy becomes part of the firewall's access model. See the AWS KMS Security Guide.

Admin roles and privileged access

Whoever can edit the firewall policy can turn off egress control for every VPC that shares it, so firewall administration is privileged network access.

Use SCPs to deny network-firewall:Delete*, logging configuration changes and policy association changes outside the network administration role, and to stop workload accounts from editing route tables that point at firewall endpoints. Delete protection is enabled when a firewall is created through the API, and must be explicitly disabled before deletion; the console's delete flow disables it for you, so console access to production is itself a risk. See the AWS Organizations and SCPs Guide.

Integrations, API tokens and service accounts

• Infrastructure as code: the service supports CloudFormation, the CLI (aws network-firewall), SDKs and the REST API. Rule changes should flow through a pipeline whose deploy role is scoped to Network Firewall in the security account and assumed through OIDC federation rather than stored access keys. See the GitHub Actions to AWS federation guide.
• AWS Firewall Manager: centrally configures firewalls across accounts in AWS Organizations. The Firewall Manager administrator account effectively controls inspection for the organisation and deserves the same protection as the management account.
• Managed rule groups: AWS managed groups (active threat defence, domain and IP, threat signature) are maintained by AWS and mostly free of extra charge; each set counts as one stateful rule group towards the policy limit. AWS Marketplace groups are partner-maintained: review the vendor's update and false-positive process before attaching.
• TLS inspection certificates: inbound inspection uses server certificates in ACM; outbound inspection uses a CA certificate that clients must trust. That CA can mint certificates for any domain your clients visit, so its private key and issuance must be governed like any other high-value CA. Self-signed certificates are not supported for inbound inspection and cross-signed roots are not supported. See the AWS Certificate Manager and Private CA Guide and the TLS Inspection Guide.
• Egress allow lists as identity control: workloads holding API keys and cloud credentials are the main exfiltration risk. Domain allow lists limit where a stolen credential can be used from inside your VPCs. See the Cloud Egress Filtering guide.

TLS inspection: what changes

TLS inspection is billed as advanced inspection by volume. Decide it per traffic class: outbound inspection of server workloads to the internet is usually worthwhile; inspecting regulated or privacy-sensitive flows may need legal review.

Logging and detection

Three log types are available for the stateful engine, and each can go to its own destination: Amazon S3, CloudWatch Logs or Amazon Data Firehose.

Tune detections against T1071.001 Web Protocols, T1572 Protocol Tunneling, T1048 Exfiltration Over Alternative Protocol, T1567 Exfiltration Over Web Service and, for attacks on the control itself, T1685 Disable or Modify Tools. Logging costs scale with volume, so send alert logs everywhere and sample or summarise flow logs where budget forces a choice.

Metrics that show it is working:

• Percentage of VPCs with internet or transit egress routed through a firewall endpoint (target: all in-scope VPCs).
• Percentage of production firewalls with alert logging enabled and delivered to the SIEM.
• Number of policies using strict order with a default drop, against total policies.
• Mean time from approved egress request to deployed rule, which shows whether teams will route around the firewall.
• Count of rule group changes made outside the pipeline (target: zero).

Hardening baseline

1. Design routing first. Dedicated firewall subnet per Availability Zone, routes from workload subnets to the endpoint in the same zone, and return routes from the internet or NAT gateway back through the same endpoint to avoid asymmetric paths and cross-zone charges.
2. Create the policy in strict order. Stateless default forward to stateful for full packets; decide fragment handling explicitly; set HOME_NET where the inspection VPC CIDR is not the right scope, including on every endpoint association.
3. Start in alert mode. Use Alert established (or Alert all) with no default drop, attach AWS managed threat signature and domain groups, enable alert and flow logs, and run for at least two business cycles to learn real egress.
4. Build allow lists. Turn observed destinations into domain list or Suricata rule groups per application, owned by named teams, stored in version control.
5. Enforce in rings. Switch to Drop established (or an application drop variant) for a non-production VPC, then a low-risk production VPC, then the rest. Watch DroppedPackets and alert logs at each step.
6. Set stream exception policy. Reject for most egress so clients recover quickly; keep Drop where fail-closed matters more than availability.
7. Lock down change. SCPs and pipeline-only roles for policy, rule group and logging changes; CloudTrail alerts on DisassociateSubnets, UpdateLoggingConfiguration, DeleteFirewall and rule group updates.
8. Add TLS inspection deliberately. Only after the allow list is stable, per scope, in a change window, with the client trust store change rolled out first.
9. Rollback. Keep the previous rule group versions in version control; the fastest safe rollback is re-deploying the prior rule group or switching the default back to alert, not removing routes, which silently removes inspection.

Common misconfigurations

• Action order with allow lists: a broad pass rule beats every drop rule regardless of priority, so the "deny" rules never fire.
• Asymmetric or missing routes: one Availability Zone or one subnet left on the old route table sends traffic around the firewall. The ReceivedPackets metric for that zone stays at zero and nobody notices.
• Stateless rules doing the real work: packets passed by stateless rules are never logged, so investigations find no record.
• Firewall subnet shared with workloads: an endpoint cannot inspect traffic in its own subnet, so anything placed there is uninspected.
• Endpoint associations without policy variables: HOME_NET is not inherited, so rules scoped to it behave differently on the associated endpoint.
• Assuming DNS is covered: AmazonProvidedDNS queries from EC2 are not inspected, so DNS tunnelling and lookups of malicious domains need DNS Firewall or equivalent.

Framework mapping

In ISO/IEC 27001:2022 terms this supports Annex A 8.20 (networks security), 8.22 (segregation of networks), 8.16 (monitoring activities) and 8.23 (web filtering).

Practitioner checklist

• Every in-scope VPC routes internet and transit egress through a firewall endpoint in the same Availability Zone, with symmetric return paths.
• Firewall subnets contain only firewall endpoints.
• Policies use strict order, stateless default forward to stateful, and a deliberate default drop plus alert.
• AWS managed threat signature and domain groups attached and reviewed for false positives.
• Application egress allow lists in version control with named owners and a pipeline-only deploy role.
• Alert logs (and flow logs where affordable) delivered to the SIEM, with CloudWatch alarms on zero ReceivedPackets per zone and on drop spikes.
• SCPs deny firewall, policy and logging changes outside the network administration role; delete protection left on.
• DNS-layer filtering deployed separately for AmazonProvidedDNS traffic.
• TLS inspection, if used, scoped narrowly, with the CA governed and TLS metrics monitored.
• Documented rollback that reverts rules or defaults rather than removing routes.

Standards and references

• AWS Network Firewall Developer Guide: What is AWS Network Firewall?
• AWS Network Firewall Developer Guide: Evaluation order for Suricata compatible rules
• AWS Network Firewall Developer Guide: Stream exception policy options
• AWS Network Firewall Developer Guide: Considerations for TLS inspection configurations
• AWS Network Firewall Developer Guide: Firewall logging
• AWS Network Firewall Developer Guide: CloudWatch metrics
• AWS Network Firewall Developer Guide: Using service-linked roles
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Amazon VPC Security Guide · Cloud Egress Filtering · Suricata IDS Guide · AWS Security Guide · Firewall Rule Review Checklist