AWS Network Firewall

AWS Network Firewall is a managed service that provides network-level filtering and intrusion prevention for Amazon Virtual Private Clouds (VPCs). It is designed to protect your VPC from malicious traffic, enforce network segmentation, and meet compliance requirements. Unlike security groups (stateful instance-level firewalls) or network ACLs (stateless subnet-level firewalls), AWS Network Firewall offers deep packet inspection (DPI), intrusion prevention system (IPS) capabilities, and domain filtering. It is a stateful firewall that can inspect traffic in all directions: ingress, egress, and between subnets.

The service exists because traditional security groups and network ACLs lack advanced threat detection. Security groups cannot inspect application-layer content, and network ACLs are stateless and limited to basic IP/port rules. AWS Network Firewall fills this gap by providing a centralized, scalable firewall that integrates with AWS services like AWS WAF, AWS Shield, and Amazon GuardDuty.

AWS Network Firewall operates by intercepting traffic at the VPC level. It is deployed in a dedicated firewall subnet within your VPC. You create a firewall endpoint (a VPC endpoint) that serves as the entry and exit point for traffic. The firewall uses a firewall policy, which contains a set of rule groups that define how to handle traffic.

To create a firewall via AWS CLI:

aws network-firewall create-firewall \
    --firewall-name my-firewall \
    --firewall-policy-arn arn:aws:network-firewall:us-east-1:123456789012:firewall-policy/my-policy \
    --vpc-id vpc-12345678 \
    --subnet-mappings SubnetId=subnet-12345678

To create a firewall policy:

aws network-firewall create-firewall-policy \
    --firewall-policy-name my-policy \
    --firewall-policy "StatelessDefaultActions=[\"aws:pass\"],StatelessFragmentDefaultActions=[\"aws:pass\"]"

To add a stateful rule group:

aws network-firewall create-rule-group \
    --rule-group-name my-suricata-rules \
    --type STATEFUL \
    --capacity 100 \
    --rules "alert tcp any any -> any any (msg:\"test\"; sid:1;)"

Verification commands:

aws network-firewall describe-firewall --firewall-name my-firewall
aws network-firewall list-firewalls
aws network-firewall describe-firewall-policy --firewall-policy-arn <arn>

Stateless rule groups contain rules that define a 5-tuple match and an action: aws:pass, aws:drop, aws:forward_to_sfe. The aws:forward_to_sfe action sends the packet to the stateful rule engine. Stateless rules are evaluated in order of priority (lower number = higher priority). If no rule matches, the default stateless action is taken (set in the firewall policy). The default actions can be aws:pass or aws:drop or aws:forward_to_sfe. For fragmented packets, you can also set a default fragment action.

Stateful rule groups use Suricata rules. They can be of two types: - Pass: Allow traffic. - Drop: Block traffic. - Alert: Log traffic but allow.

Stateful rules are processed after stateless rules that forward to stateful. The stateful engine maintains connection state. For TCP, it tracks SYN, SYN-ACK, ACK, and FIN/RST. For UDP, it tracks source/destination. The engine can reassemble TCP streams for deep inspection.

Stateful rule groups can include domain filtering rules. These rules match against fully qualified domain names (FQDNs) in TLS SNI or HTTP Host headers. They do not perform DNS resolution. Example Suricata rule:

pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:"example.com"; msg:"Allowed domain"; sid:2;)

AWS Network Firewall scales automatically based on traffic. It uses multiple Availability Zones for high availability. You can deploy one firewall per VPC, but you can have multiple firewalls across VPCs. The service supports up to 100,000 rules in a firewall policy (combined capacity). Throughput limits vary by instance type (not user-selectable; AWS manages). For high throughput, ensure you have sufficient capacity in your firewall policy (capacity is a soft limit that can be increased via support).

A financial services company must restrict outbound traffic from a VPC containing sensitive customer data. They need to block known malicious domains and prevent data exfiltration. They deploy AWS Network Firewall in a dedicated firewall subnet. They create a stateful rule group with Suricata rules that drop traffic to domains listed on a threat intelligence feed (e.g., from Proofpoint or AWS Marketplace). They also create a stateless rule group that allows only specific ports (80, 443) to the internet. The firewall policy has a default stateless action of drop. In production, they monitor alert logs for attempted connections to malicious domains. A common misconfiguration is forgetting to update the route table for the private subnets to point to the firewall endpoint, causing traffic to bypass the firewall. They also need to ensure that the firewall subnet has a route to the internet via a NAT Gateway if they want to inspect traffic from private subnets.

A healthcare organization needs to isolate development, test, and production environments within a single VPC. They use AWS Network Firewall to inspect traffic between subnets. They create a firewall policy with stateless rules that allow traffic between specific subnet CIDRs only on required ports (e.g., SSH from admin subnet to all, HTTP from web to app). They also attach a stateful rule group with IPS signatures from an AWS Marketplace partner (e.g., Trend Micro). The firewall logs all inter-subnet traffic. A common issue is that the firewall's stateful engine can cause latency for high-throughput applications like database replication; they mitigate this by creating stateless allow rules for trusted traffic to bypass stateful inspection. They also ensure that the route tables for each subnet have a route to the firewall endpoint for the other subnets' CIDRs.

A large enterprise uses AWS Organizations with hundreds of accounts. They deploy AWS Network Firewall in a central security account using AWS Firewall Manager. They create a common firewall policy with corporate-wide rules (e.g., block all traffic to known command-and-control IPs). They then apply this policy to all VPCs in member accounts. This ensures consistent security posture. Performance considerations: with many VPCs, the number of firewalls can grow. They use tagging to organize firewalls. A common pitfall is that Firewall Manager can only apply policies to VPCs that have a firewall already deployed; they must first create the firewall in each VPC via automation. They also need to ensure that the firewall subnets in each account have proper routing.