Stateless
Stateless rules
Judges each packet without flow context, by source and destination, port, and protocol. The action is pass, drop, or forward to the stateful engine.
AWS Network Firewall · Managed firewall · IPS
Inspect traffic in and out of your VPCs with Suricata rules
AWS Network Firewall is a managed stateful firewall and intrusion detection and prevention service for VPC traffic. You write rules in familiar Suricata syntax, and AWS manages capacity and availability.
Firewall policy · strict orderflow → verdict
- Packet in10.0.1.25:49152 → 198.51.100.10:443 TCP
- Stateless5-tuple match · per packet
passdropforward - StatefulSuricata compatible · per flow · tls.sni
passdroprejectalert
The stateful engine inspects, in flow context, only the packets that the stateless engine forwards.
100 Gbps
Maximum auto-scaling throughput per Availability Zone
Suricata
Stateful rules compatible with the open-source IPS
4
Stateful actions (pass · drop · reject · alert)
3
Log types (Alert · Flow · TLS)
Why Network Firewall
When you need inspection beyond security groups and NACLs
Security groups and network ACLs allow or deny traffic by IP address and port. When you need domain-based outbound control, protocol detection, or signature-based intrusion prevention, add a firewall layer.
Managed
Scaling without the operational burden
Scales automatically with traffic, and AWS manages availability and resiliency. You don't run appliance instances yourself.
Inspect
Deep, flow-level inspection
Identifies protocols such as HTTPS regardless of port, and inspects packet payloads with rules.
Central
One policy, many VPCs
A single firewall policy manages endpoints in multiple VPCs or a Transit Gateway attachment.
Stateful rules
Write rules in native Suricata syntax
Below is an example outbound allowlist. Under strict order, the default for new firewall policies, rule groups are evaluated by priority and rules within a group in the order they are written.
egress-allowlist.rulesSuricata compatible
# Allow TLS only to approved domains
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; content:".amazonaws.com"; endswith; nocase; flow:to_server; msg:"allow AWS endpoints"; sid:1000001; rev:1;)
pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; content:"repo.example.com"; startswith; endswith; flow:to_server; msg:"allow package repo"; sid:1000002; rev:1;)
# Block cleartext management protocols immediately with a TCP RST
reject tcp $HOME_NET any -> $EXTERNAL_NET 23 (flow:to_server; msg:"block telnet"; sid:1000003; rev:1;)
# Log, then drop, all other TLS
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"unapproved TLS destination"; flow:to_server, established; sid:1000004; rev:1;)
drop tls $HOME_NET any -> $EXTERNAL_NET any (flow:to_server, established; sid:1000005; rev:1;)Strict order
Default · recommendedThe default for new policies. Rule groups are evaluated from the lowest priority number, and rules within a group in the order you define them. The policy sets the default action for traffic that matches no rule; new policies default to Application drop established (server-directed only).
Action order
LegacyKept for compatibility with existing policies. All pass rules are evaluated first, followed by drop, reject, and alert. Within the same action, the priority keyword sets the order. The rule group's evaluation order must match the policy's.
rejectis TCP onlyBlocks matching traffic and sends a TCP RST to the sender. It can't be used with the FTP and IMAP protocols.
Features
Key features
Domain filtering
Domain list rules
Identifies the domain from the TLS SNI for HTTPS and the Host header for HTTP. Beyond allow and deny lists, you can use reject and alert actions, and match all subdomains with entries such as .example.com.
TLS inspection
TLS inspection
Uses ACM certificates to decrypt encrypted traffic, hand it to the stateful engine, and re-encrypt it. Inbound uses server certificates; outbound uses an imported CA certificate. With session holding on, connection setup packets aren't sent to the destination until SNI rules are evaluated.
Managed rules
AWS managed rule groups
Add domain and IP, and threat signature (StrictOrder and ActionOrder versions) managed rule groups, plus AWS Marketplace partner rule groups, to a policy. Active threat defense, based on Amazon threat intelligence, is on by default when you create a new policy in the console and is billed separately.
Multi-VPC
Endpoints in multiple VPCs
VPC endpoint associations place one firewall's endpoints in other VPCs. Share the firewall through AWS RAM to protect VPCs in other accounts with the same policy. All endpoints share the per-AZ throughput.
Logging
Alert · Flow · TLS logs
Choose Amazon S3, CloudWatch Logs, or Amazon Data Firehose as the destination for each log type. Matches on drop, alert, and reject rules are written to the alert log.
Web categories
URL and domain category filtering
Write rules using predefined web categories such as GenAI, social media, and streaming. Combined with TLS inspection, you get finer control at the URL level.
Containers
Container attribute-based rules
Target rules by Amazon EKS namespace, cluster, and label, or by Amazon ECS cluster and attributes. Wildcards are supported, at no additional charge.
Preview
Explicit forward proxy
Running explicit proxy mode under the same firewall policy is in public preview (August 2026, US East (Ohio)). It isn't generally available yet, so don't build it into production designs.
Deployment models
Four ways to send traffic to the firewall
The firewall receives traffic through routing. Deployment models differ by which route tables point to the firewall as the next hop.
| Model | Setup | Traffic steering | Best fit |
|---|---|---|---|
| Distributed Distributed |
A firewall subnet in each VPC and a firewall endpoint per AZ | VPC route tables, IGW edge route table | Inspecting internet ingress and egress separately per VPC, with separate policies |
| Centralized · inspection VPC Inspection VPC + TGW |
Firewall in an inspection VPC, attached to Transit Gateway as a VPC | TGW route tables and inspection VPC route tables. Appliance mode on the inspection VPC attachment | Inspecting inter-VPC, hybrid, and egress traffic in one place |
| TGW-attached TGW-attached firewall |
Firewall attached directly as a Transit Gateway attachment. No inspection VPC to build | TGW route tables only. Appliance mode is always on | Central inspection without managing inspection VPC subnets and routing |
| Cloud WAN Service insertion |
Inspection VPC attached to a network function group | send-via (east-west) and send-to (north-south) actions in the core network policy | Policy-based inspection of traffic across Regions and segments |
Reference architecture
Central inspection attached directly to Transit Gateway
Spoke VPC and on-premises traffic follows the TGW route tables to the firewall attachment. The VPC the firewall uses is managed by Network Firewall and isn't visible to you; traffic that passes inspection continues to the destination VPC or the egress VPC.
On narrow screens, swipe the diagram sideways.
Getting started
Steps to deploy your first firewall
- STEP 1
Write rule groups
Create stateless and stateful rule groups, or choose managed rule groups.
- STEP 2
Firewall policy
Combine rule groups and set the evaluation order (strict order by default) and default actions.
- STEP 3
Create the firewall
Specify the VPC and a firewall subnet per AZ, or attach directly to a Transit Gateway (shared through RAM if another account owns it).
- STEP 4
Update routing
In the VPC or TGW route tables, set the firewall endpoint or attachment as the next hop.
- STEP 5
Logging and validation
Turn on alert and flow logs, and confirm that allows and blocks behave as intended.
Pricing
Cost components
The base charges are firewall endpoint hours and the volume of traffic processed, per Region and Availability Zone. TLS inspection and active threat defense add charges when turned on.
| Component | Billed by | Notes |
|---|---|---|
| Firewall endpoint | Endpoint hours per Region and AZ | There's an endpoint in each AZ, so you're billed per AZ |
| Traffic processing | GB processed per Region and AZ | NAT gateway hourly and data processing charges on the same path are waived in proportion to firewall usage |
| Advanced Inspection (TLS inspection) | Additional endpoint hours per Region and AZ | No extra data processing charge beyond standard traffic processing |
| Secondary endpoints | Hours per VPC endpoint association (lower rate than primary endpoints) | No additional data processing charge for secondary endpoints |
| Active threat defense | GB processed per Region and AZ | Only when the active threat defense managed rule group is on. It's on by default for new policies created in the console, so check the cost |
| Marketplace rule groups | Price set by the seller | Billed on top of Network Firewall charges when you subscribe to AWS Marketplace partner managed rule groups |
| Related charges | Billed by other services | Data transfer (Amazon EC2 pricing), Transit Gateway charges for TGW-attached firewalls (TGW pricing), log destinations (S3 · CloudWatch Logs · Firehose pricing) |
Rates vary by Region and usage. TGW-attached firewalls carry no extra charge beyond standard Network Firewall and Transit Gateway pricing, and Transit Gateway flexible cost allocation lets you allocate data processing costs to other accounts. For current rates, see the AWS Network Firewall pricing page.
Next step
Design an inspection architecture that fits your network
Bring the traffic directions to inspect, your VPC and account structure, and whether you use TGW or Cloud WAN, and we'll review the deployment model and rule design together.