AWSSecurityadvanced

AWS Network Firewall Guide

Implement deep packet inspection, IPS, domain filtering, and TLS inspection with AWS Network Firewall for VPC security.

CloudToolStack Team24 min readPublished Mar 14, 2026

Prerequisites

Understanding of VPC networking, subnets, and route tables
Familiarity with network security concepts (firewalls, IPS)

Introduction to AWS Network Firewall

AWS Network Firewall is a managed network security service that provides stateful packet inspection, intrusion prevention, web filtering, and network traffic filtering for your VPCs. It sits in the traffic path between your VPC subnets and the internet (or other VPCs), inspecting every packet and applying rules to allow, drop, or alert on traffic based on protocol, port, IP address, domain name, and deep packet inspection signatures.

Unlike security groups and network ACLs, which provide basic port and IP-based filtering, Network Firewall can inspect traffic at the application layer. It can block traffic to specific domains (DNS-based filtering), detect and prevent known attack patterns using Suricata-compatible intrusion prevention signatures, inspect TLS-encrypted traffic (with TLS inspection), and log detailed traffic metadata for forensic analysis. This makes it essential for environments with compliance requirements, sensitive data, or defense-in-depth security strategies.

This guide covers Network Firewall architecture and deployment, creating rule groups for stateless and stateful inspection, building firewall policies, integrating with VPC routing, configuring TLS inspection, analyzing firewall logs, and best practices for production deployments.

Network Firewall vs. Security Groups vs. NACLs

Security Groups are instance-level, stateful firewalls that filter by port and IP. NACLs are subnet-level, stateless firewalls that filter by port and IP. Network Firewall adds deep packet inspection, domain filtering, IPS/IDS, TLS inspection, and Suricata-compatible rule evaluation at the VPC perimeter. Use all three together for defense in depth: Network Firewall at the VPC edge, NACLs at the subnet boundary, and Security Groups at the instance level.

Architecture and Deployment Models

Network Firewall deploys as a set of firewall endpoints in dedicated subnets within your VPC. Traffic is routed through these endpoints using VPC route table entries. The firewall inspects traffic inline and applies your rules before forwarding permitted traffic to its destination. There are three common deployment models.

Deployment Model Comparison

Model	Use Case	Traffic Flow
Distributed	Firewall per VPC	Internet → IGW → Firewall subnet → App subnet
Centralized (TGW)	Shared firewall for multiple VPCs	VPCs → Transit Gateway → Inspection VPC → Internet
Combined	East-west + north-south inspection	Both inter-VPC and internet traffic inspected

Creating a Network Firewall

Creating a Network Firewall involves three steps: defining rule groups (the individual filtering rules), creating a firewall policy (which groups rules together and defines default actions), and deploying the firewall (which creates the firewall endpoints in your VPC subnets).

bash

# Step 1: Create a stateless rule group (fast L3/L4 filtering)
aws network-firewall create-rule-group \
  --rule-group-name block-known-bad-ips \
  --type STATELESS \
  --capacity 100 \
  --rule-group '{
    "rulesSource": {
      "statelessRulesAndCustomActions": {
        "statelessRules": [
          {
            "ruleDefinition": {
              "matchAttributes": {
                "sources": [{"addressDefinition": "198.51.100.0/24"}, {"addressDefinition": "203.0.113.0/24"}],
                "destinations": [{"addressDefinition": "0.0.0.0/0"}],
                "protocols": [6, 17]
              },
              "actions": ["aws:drop"]
            },
            "priority": 1
          },
          {
            "ruleDefinition": {
              "matchAttributes": {
                "sources": [{"addressDefinition": "0.0.0.0/0"}],
                "destinations": [{"addressDefinition": "0.0.0.0/0"}],
                "destinationPorts": [{"fromPort": 22, "toPort": 22}],
                "protocols": [6]
              },
              "actions": ["aws:drop"]
            },
            "priority": 2
          }
        ],
        "customActions": []
      }
    }
  }' \
  --tags Key=Environment,Value=production

# Step 2: Create a stateful rule group (domain-based filtering)
aws network-firewall create-rule-group \
  --rule-group-name allow-domains \
  --type STATEFUL \
  --capacity 200 \
  --rule-group '{
    "rulesSource": {
      "rulesSourceList": {
        "targets": [
          ".amazonaws.com",
          ".aws.amazon.com",
          ".github.com",
          ".docker.io",
          ".docker.com",
          ".ubuntu.com",
          ".npmjs.org",
          ".pypi.org"
        ],
        "targetTypes": ["HTTP_HOST", "TLS_SNI"],
        "generatedRulesType": "ALLOWLIST"
      }
    }
  }' \
  --tags Key=Environment,Value=production

Suricata-Compatible IPS Rules

bash

# Create a stateful rule group with Suricata IPS rules
aws network-firewall create-rule-group \
  --rule-group-name intrusion-prevention \
  --type STATEFUL \
  --capacity 500 \
  --rule-group '{
    "rulesSource": {
      "rulesString": "# Drop SQL injection attempts in HTTP traffic\ndrop http any any -> any any (msg:\"SQL Injection Attempt\"; content:\"SELECT\"; nocase; content:\"FROM\"; nocase; distance:0; sid:1000001; rev:1;)\n\n# Drop HTTP requests with suspicious user agents\ndrop http any any -> any any (msg:\"Suspicious User Agent - sqlmap\"; content:\"sqlmap\"; http_header; nocase; sid:1000002; rev:1;)\n\n# Alert on outbound SSH connections (unexpected)\nalert tcp any any -> any 22 (msg:\"Outbound SSH Connection Detected\"; flow:to_server,established; sid:1000003; rev:1;)\n\n# Drop known command-and-control traffic patterns\ndrop tcp any any -> any any (msg:\"Possible C2 Beacon\"; content:\"POST\"; http_method; content:\"/api/beacon\"; http_uri; sid:1000004; rev:1;)\n\n# Alert on DNS queries to suspicious TLDs\nalert dns any any -> any any (msg:\"DNS Query to Suspicious TLD\"; dns.query; content:\".xyz\"; endswith; sid:1000005; rev:1;)"
    },
    "statefulRuleOptions": {
      "ruleOrder": "STRICT_ORDER"
    }
  }' \
  --tags Key=Environment,Value=production

Rule Capacity Planning

Each rule group has a capacity limit that you set at creation time and cannot change later. Capacity is consumed based on the complexity of rules: simple IP/port rules use 1 capacity unit, while Suricata rules with content matching use more. Over-provision capacity for future growth because you cannot increase it after creation. A firewall policy can reference up to 20 stateless and 20 stateful rule groups, with a maximum total capacity across all groups.

Firewall Policy and Deployment

A firewall policy combines rule groups into a single policy that defines how the firewall handles traffic. The policy specifies the default actions for stateless traffic (pass, drop, or forward to stateful engine), the order of stateful rule evaluation, and the rule groups to apply. You then deploy the firewall with this policy into specific VPC subnets.

bash

# Create the firewall policy
aws network-firewall create-firewall-policy \
  --firewall-policy-name production-policy \
  --firewall-policy '{
    "statelessDefaultActions": ["aws:forward_to_sfe"],
    "statelessFragmentDefaultActions": ["aws:drop"],
    "statelessRuleGroupReferences": [
      {
        "resourceArn": "arn:aws:network-firewall:us-east-1:123456789:stateless-rulegroup/block-known-bad-ips",
        "priority": 1
      }
    ],
    "statefulDefaultActions": ["aws:drop_established", "aws:alert_established"],
    "statefulRuleGroupReferences": [
      {
        "resourceArn": "arn:aws:network-firewall:us-east-1:123456789:stateful-rulegroup/allow-domains",
        "priority": 1
      },
      {
        "resourceArn": "arn:aws:network-firewall:us-east-1:123456789:stateful-rulegroup/intrusion-prevention",
        "priority": 2
      }
    ],
    "statefulEngineOptions": {
      "ruleOrder": "STRICT_ORDER",
      "streamExceptionPolicy": "DROP"
    }
  }' \
  --tags Key=Environment,Value=production

# Deploy the firewall
aws network-firewall create-firewall \
  --firewall-name production-firewall \
  --firewall-policy-arn "arn:aws:network-firewall:us-east-1:123456789:firewall-policy/production-policy" \
  --vpc-id vpc-xxx \
  --subnet-mappings '[
    {"SubnetId": "subnet-fw-az1"},
    {"SubnetId": "subnet-fw-az2"},
    {"SubnetId": "subnet-fw-az3"}
  ]' \
  --delete-protection \
  --subnet-change-protection \
  --tags Key=Environment,Value=production

# Get the firewall endpoint IDs (needed for route table configuration)
aws network-firewall describe-firewall \
  --firewall-name production-firewall \
  --query 'FirewallStatus.SyncStates' \
  --output json

VPC Route Table Integration

After deploying the firewall, you must configure VPC route tables to direct traffic through the firewall endpoints. This is the most critical configuration step: if routes are not properly set up, traffic will bypass the firewall entirely. The routing configuration differs based on your deployment model and whether you are inspecting north-south (internet) traffic, east-west (inter-VPC) traffic, or both.

bash

# Get the firewall endpoint IDs for each AZ
ENDPOINT_AZ1=$(aws network-firewall describe-firewall \
  --firewall-name production-firewall \
  --query 'FirewallStatus.SyncStates."us-east-1a".Attachment.EndpointId' \
  --output text)

ENDPOINT_AZ2=$(aws network-firewall describe-firewall \
  --firewall-name production-firewall \
  --query 'FirewallStatus.SyncStates."us-east-1b".Attachment.EndpointId' \
  --output text)

# Route table for the Internet Gateway (ingress routing)
# Routes traffic from the internet to the firewall before reaching app subnets
aws ec2 create-route \
  --route-table-id rtb-igw \
  --destination-cidr-block 10.0.1.0/24 \
  --vpc-endpoint-id $ENDPOINT_AZ1

aws ec2 create-route \
  --route-table-id rtb-igw \
  --destination-cidr-block 10.0.2.0/24 \
  --vpc-endpoint-id $ENDPOINT_AZ2

# Associate the route table with the Internet Gateway
aws ec2 associate-route-table \
  --route-table-id rtb-igw \
  --gateway-id igw-xxx

# Route table for application subnets (egress routing)
# Routes outbound traffic from apps through the firewall
aws ec2 create-route \
  --route-table-id rtb-app-az1 \
  --destination-cidr-block 0.0.0.0/0 \
  --vpc-endpoint-id $ENDPOINT_AZ1

aws ec2 create-route \
  --route-table-id rtb-app-az2 \
  --destination-cidr-block 0.0.0.0/0 \
  --vpc-endpoint-id $ENDPOINT_AZ2

# Route table for firewall subnets (forward to internet gateway)
aws ec2 create-route \
  --route-table-id rtb-firewall \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-xxx

Asymmetric Routing Warning

The most common Network Firewall deployment mistake is asymmetric routing, where inbound and outbound traffic for the same connection flow through different firewall endpoints in different AZs. This breaks stateful inspection because the firewall cannot correlate the request with its response. Always ensure that traffic for a given subnet flows through the firewall endpoint in the same AZ. Use AZ-specific route tables, not a shared route table, for subnets in different AZs.

TLS Inspection

Network Firewall supports TLS inspection (SSL decryption) for outbound HTTPS traffic. This allows the firewall to inspect encrypted traffic for threats and policy violations. TLS inspection works by intercepting TLS connections, decrypting the traffic using a CA certificate you provide, inspecting the plaintext content, and re-encrypting it before forwarding. This is essential for detecting malware communications, data exfiltration, and policy violations hidden in encrypted traffic.

bash

# Create or import a CA certificate in ACM for TLS inspection
aws acm import-certificate \
  --certificate file://ca-cert.pem \
  --private-key file://ca-key.pem \
  --certificate-chain file://ca-chain.pem \
  --tags Key=Purpose,Value=tls-inspection

# Create a TLS inspection configuration
aws network-firewall create-tls-inspection-configuration \
  --tls-inspection-configuration-name production-tls \
  --tls-inspection-configuration '{
    "serverCertificateConfigurations": [
      {
        "serverCertificates": [],
        "scopes": [
          {
            "sources": [{"addressDefinition": "10.0.0.0/16"}],
            "destinations": [{"addressDefinition": "0.0.0.0/0"}],
            "sourcePort": [{"fromPort": 0, "toPort": 65535}],
            "destinationPorts": [{"fromPort": 443, "toPort": 443}],
            "protocols": [6]
          }
        ],
        "certificateAuthorityArn": "arn:aws:acm:us-east-1:123456789:certificate/xxx"
      }
    ]
  }'

# Associate TLS inspection with the firewall policy
aws network-firewall update-firewall-policy \
  --firewall-policy-name production-policy \
  --firewall-policy '{
    "tlsInspectionConfigurationArn": "arn:aws:network-firewall:us-east-1:123456789:tls-inspection-configuration/production-tls",
    "statelessDefaultActions": ["aws:forward_to_sfe"],
    "statelessFragmentDefaultActions": ["aws:drop"],
    "statefulDefaultActions": ["aws:drop_established"],
    "statefulRuleGroupReferences": []
  }' \
  --update-token <update-token>

Logging and Monitoring

Network Firewall supports three types of logs: alert logs (records for traffic that matches rules with alert or drop actions), flow logs (metadata for all traffic passing through the firewall), and TLS logs (TLS handshake details for inspected connections). Logs can be sent to CloudWatch Logs, S3, or Kinesis Data Firehose.

bash

# Enable logging for the firewall
aws network-firewall update-logging-configuration \
  --firewall-name production-firewall \
  --logging-configuration '{
    "logDestinationConfigs": [
      {
        "logType": "ALERT",
        "logDestinationType": "CloudWatchLogs",
        "logDestination": {
          "logGroup": "/aws/network-firewall/production/alerts"
        }
      },
      {
        "logType": "FLOW",
        "logDestinationType": "S3",
        "logDestination": {
          "bucketName": "firewall-logs-bucket",
          "prefix": "flow-logs"
        }
      }
    ]
  }'

# Query alert logs in CloudWatch
aws logs filter-log-events \
  --log-group-name "/aws/network-firewall/production/alerts" \
  --start-time $(date -u -v-1H '+%s000') \
  --filter-pattern '{ $.event.alert.action = "blocked" }' \
  --query 'events[].message' \
  --output text

# Create CloudWatch alarms for firewall events
aws cloudwatch put-metric-alarm \
  --alarm-name firewall-high-drop-rate \
  --namespace AWS/NetworkFirewall \
  --metric-name DroppedPackets \
  --dimensions Name=FirewallName,Value=production-firewall \
  --statistic Sum \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 10000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789:security-alerts

# Monitor firewall throughput
aws cloudwatch get-metric-statistics \
  --namespace AWS/NetworkFirewall \
  --metric-name Packets \
  --dimensions Name=FirewallName,Value=production-firewall \
  --start-time $(date -u -v-1H '+%Y-%m-%dT%H:%M:%S') \
  --end-time $(date -u '+%Y-%m-%dT%H:%M:%S') \
  --period 300 \
  --statistics Sum \
  --output table

Best Practices for Production

Network Firewall is a critical security control that requires careful planning, testing, and monitoring. Here are key practices for production deployments.

Security and Operational Recommendations

Practice	Why	How
Deploy in all AZs	Avoid cross-AZ asymmetric routing	Firewall subnet per AZ, AZ-specific routes
Start with alert mode	Avoid blocking legitimate traffic	Use alert action before switching to drop
Use strict rule order	Predictable rule evaluation	Set STRICT_ORDER in stateful engine options
Enable all log types	Forensics and compliance	Alert + Flow logs to CloudWatch and S3
Use managed rule groups	Stay current on threat signatures	Subscribe to AWS managed threat rules
Test changes in staging	Prevent production outages	Separate firewall in staging VPC

AWS Managed Rule Groups

AWS provides managed stateful rule groups that include curated threat intelligence signatures, updated automatically. These include rules for known malware domains, botnet command-and-control servers, and common attack patterns. Using managed rule groups alongside your custom rules provides baseline protection with minimal configuration effort. Check the AWS Marketplace for additional third-party rule groups from security vendors.

AWS Network Firewall provides essential network security capabilities that go far beyond what security groups and NACLs offer. Deploy it at VPC perimeters for deep packet inspection, domain-based filtering, and intrusion prevention. Start in alert-only mode, analyze the logs to tune your rules, then switch to blocking mode once you are confident in your rule set. Combine with AWS Firewall Manager for centralized policy management across multiple accounts in an AWS Organization.

Getting Started with AWS AWS Batch Guide Amazon Cognito Guide

Key Takeaways

1Network Firewall adds deep packet inspection, domain filtering, and IPS beyond Security Groups and NACLs.
2Suricata-compatible rules enable custom intrusion detection and prevention signatures.
3TLS inspection decrypts and inspects outbound HTTPS traffic for threats and policy violations.
4Proper VPC route table configuration is critical to avoid traffic bypassing the firewall.

Frequently Asked Questions

How does Network Firewall differ from Security Groups?

Security Groups provide basic stateful port/IP filtering at the instance level. Network Firewall adds deep packet inspection at the application layer, including domain name filtering, Suricata-compatible IPS rules, and TLS inspection. Use both together: Network Firewall at the VPC edge for perimeter security, Security Groups at the instance level for least-privilege access.

What is the performance impact of Network Firewall?

Network Firewall adds minimal latency (typically < 1ms) for stateless rules. Stateful inspection adds slightly more latency depending on rule complexity. TLS inspection has the highest performance impact due to decryption/re-encryption. Network Firewall scales automatically with traffic volume. Monitor the DroppedPackets and PassedPackets metrics to track throughput.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.