# How AWS Network Firewall works
<a name="how-it-works"></a>

AWS Network Firewall is a stateful, managed, network firewall and intrusion detection and prevention service for Amazon Virtual Private Cloud (Amazon VPC). You can combine Network Firewall with services and components that you use with your VPC, for example an internet gateway, a NAT gateway, a VPN, or a transit gateway. For information about managing your Amazon Virtual Private Cloud VPC, see the [Amazon Virtual Private Cloud User Guide](https://docs.aws.amazon.com/vpc/latest/userguide). You need a VPC to use Network Firewall. 

The firewall protects the subnets within your VPC by filtering traffic going between the subnets and locations outside of your VPC. The following example figure depicts the placement of a firewall in a very simple architecture. 

![\[An AWS Region has a VPC in a single Availability Zone with an internet gateway. A VPC spans the Region and contains a Network Firewall firewall subnet and a customer subnet. The firewall subnet is between the customer subnet and an internet gateway and is filtering traffic in both directions.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/arch-igw-simple.png)


To enable the firewall's protection, you modify your Amazon VPC route tables to send your network traffic through the Network Firewall firewall endpoints. For information about managing route tables for your VPC, see [Route tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) in the *Amazon Virtual Private Cloud User Guide*. 

# Firewall components in AWS Network Firewall
<a name="firewall-components"></a>

The AWS Network Firewall firewall runs stateless and stateful traffic inspection rules engines. The engines use rules and other settings that you configure inside a firewall policy. 

You install the firewall endpoints on a per-Availability Zone basis in your VPC. For each Availability Zone where you want to use the firewall, you choose a subnet to host the primary firewall endpoint. As needed, you can create VPC endpoint associations to provide additional subnets as firewall endpoints. 

A firewall endpoint can protect any subnet in your VPC except for the one in which it's located. 

You manage Network Firewall firewalls with the following central components. 
+ **Rule group** – Holds a reusable collection of criteria for inspecting traffic and for handling packets and traffic flows that match the inspection criteria. For example, you can choose to drop or pass a packet or all packets in a traffic flow based on the inspection criteria. Some rule groups fully define the behavior and some use lower-level rules that provide more detail. Rule groups are either stateless or stateful. For more information about rule groups and rules, see [Managing your rule groups](rule-groups.md).
+ **Firewall policy** – Defines a reusable set of stateless and stateful rule groups, along with some policy-level behavior settings. The firewall policy provides the network traffic filtering behavior for a firewall. You can use a single firewall policy in multiple firewalls. For more information about firewall policies, see [Firewall policies](firewall-policies.md).
+ **Firewall** – Connects the inspection rules in the firewall policy to the primary VPC that the rules protect. Each firewall requires one firewall policy. The firewall additionally defines settings like how to log information about your network traffic and the firewall's stateful traffic filtering. For more information about firewalls, see [Firewalls and firewall endpoints](firewalls.md).
+ **VPC endpoint association** – Implements a firewall's protections in additional firewall endpoints. For more information, see [Firewalls and firewall endpoints](firewalls.md).

# High-level steps for implementing AWS Network Firewall
<a name="firewall-high-level-steps"></a>

To install and use an AWS Network Firewall firewall in your Amazon Virtual Private Cloud VPC, you configure the firewall components and your VPC's subnets and route tables in the following high-level steps. 
+ **Configure the primary VPC subnets for your firewall endpoints** – In the primary VPC where you'll use the firewall, in each Availability Zone where you want a firewall endpoint, create a subnet specifically for use by Network Firewall. A firewall endpoint can't protect applications that run in the same subnet, so reserve these subnets for exclusive use by the firewall. The subnets that you use for your primary firewall endpoints must belong to a single AWS Region and must be in different Availability Zones within the Region. 

  Network Firewall is available in the Regions listed at [AWS service endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html). 

  For information about managing subnets in your VPC, see [VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) in the *Amazon Virtual Private Cloud User Guide*. 
+ **Create the firewall** – Create a Network Firewall firewall and provide it with the specifications for each of your firewall subnets. Network Firewall creates a firewall endpoint in each subnet that you specify, available to monitor and protect the resources for the subnets whose traffic you send through it. 
+ **Configure the firewall policy** – Define the firewall policy for your firewall by specifying its rule groups and other behavior that you want the firewall to provide. 
+ **Modify your VPC route tables to include the firewall** – Using Amazon VPC ingress routing enhancements, change your routing tables to route traffic through the Network Firewall firewall. These changes must insert the firewall between the subnets that you want to protect and outside locations. The exact routing that you need to do depends on your architecture and its components. 

  For information about managing route tables for your VPC, see [Route tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) in the *Amazon Virtual Private Cloud User Guide*. 

After you implement a firewall, you can expand its protections to additional VPCs and to multiple subnets within a single Availability Zone for any VPC. To do this, you manage the VPCs, subnets, and route tables as described in the previous high level steps, but you create the firewall endpoints in VPC endpoint associations, using the firewall that you've already defined. For more information about managing firewalls and VPC endpoint associations, see [Firewalls and firewall endpoints in AWS Network Firewall](firewalls.md).

# Firewall behavior in AWS Network Firewall
<a name="firewall-behavior"></a>

This section describes how AWS Network Firewall virtual firewalls behave and protect your VPC from attacks. You define and create a firewall, then use it to monitor and protect your subnets. The firewall monitors incoming and outgoing traffic and allows it to pass or drops it, according to your specifications. The firewall only allows packets to pass that pass inspection. 

**Network Firewall monitors and controls traffic to and from your protected subnets**  
The following figure shows the basic interaction of your firewall with traffic coming into your customer subnet and with traffic going out from your customer subnet.

![\[The figure shows a firewall subnet directly above a customer subnet. Inside the firewall subnet is a rules engines container for packet inspection. From above the left half of the firewall subnet, a vertical grey arrow labeled "incoming packets" points down to the rules engines inside the firewall subnet. From the left side of the rules engines, a horizontal red arrow labeled "drop incoming" points left to a large red X that sits outside the firewall subnet. From the bottom left of the rules engine, a vertical green arrow labeled "pass" points down from the firewall subnet rules engines to the customer subnet. From the upper right of the customer subnet, a grey arrow labeled "outgoing packets" points up to the rules engines in the firewall subnet. From the right side of the rules engines, a horizontal red arrow labeled "drop ourgoing" points right to a large red X that sits outside the firewall subnet. From the top right of the rules engine, a vertical green arrow labeled "pass" points up from the rules engines to outside the firewall subnet.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/firewall-pass-drop.png)


**Topics**
+ [Network Firewall stateless and stateful rules engines](firewall-rules-engines.md)
+ [How AWS Network Firewall filters network traffic](firewall-policy-processing.md)

# Network Firewall stateless and stateful rules engines
<a name="firewall-rules-engines"></a>

AWS Network Firewall uses two rules engines to inspect packets. The engines inspect packets according to the rules that you provide in your firewall policy. 

The following figure shows the processing flow for packets coming through the firewall. First the stateless engine inspects the packet against the configured stateless rules. Depending on the packet settings, the stateless inspection criteria, and the firewall policy settings, the stateless engine might drop a packet, pass it through to its destination, or forward it to the stateful rules engine. The stateful engine inspects packets in the context of their traffic flow, using the configured stateful rules. The stateful engine either drops packets or passes them to their destination. Stateful engine activities are recorded in the firewall's logs, if logging is configured. The stateful engine sends alerts for dropped packets and can optionally send them for passed packets. 

![\[The figure shows a firewall stateless engine, which inspects packets against stateless rules, and a firewall stateful engine, which inspects traffic flows against stateful rules. The stateless engine sits above and to the left of the stateful engine. One vertical grey arrow points down to the stateless engine from above. The stateless engine and the stateful engine each have a vertical green arrow labeled "pass" that comes from the bottom of the engine, joins the green arrow from the other engine and points down to the bottom of the figure. From the right side of the stateless engine, a grey arrow labeled "forward to stateful" points out and down to the stateful engine. Each engine also has a horizontal red arrow labeled "drop" that points right from the right side of the engine to a large red X. The stateful engine also has arrows indicating an alert that's sent with drop and an optional alert that's sent with pass.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/firewall-stateless-stateful.png)


The stateless and stateful rules inspection engines operate in different ways: 
+ **Stateless rules engine** – Inspects each packet in isolation, without regard to factors such as the direction of traffic, or whether the packet is part of an existing, approved connection. This engine prioritizes the speed of evaluation. It takes rules with standard network connection attributes. The engine processes your rules in the order that you prioritize them and stops processing when it finds a match. 

  Network Firewall stateless rules are similar in behavior and use to Amazon VPC network access control lists (ACLs).
+ **Stateful rules engine** – Inspects packets in the context of their traffic flow, allows you to use more complex rules, and allows you to log network traffic and to log Network Firewall firewall alerts on traffic. Stateful rules consider traffic direction. The stateful rules engine might delay packet delivery in order to group packets for inspection. By default, the stateful rules engine processes your rules in the order of their action setting, with pass rules processed first, then drop, then alert. The engine stops processing when it finds a match. 

  The stateful engine takes rules that are compatible with Suricata, an open source intrusion prevention system (IPS). Suricata provides a standard rule-based language for stateful network traffic inspection. For more information about Suricata, see [Working with stateful rule groups in AWS Network Firewall](stateful-rule-groups-ips.md) and the [Suricata website](https://suricata.io/). 

  Network Firewall stateful rules are similar in behavior and use to Amazon VPC security groups. By default, the stateful rules engine allows traffic to pass, while the security groups default is to deny traffic. 

Whether you use only one of these engines or a combination depends on your specific use case. 

# How AWS Network Firewall filters network traffic
<a name="firewall-policy-processing"></a>

When AWS Network Firewall inspects a packet, it evaluates the packet against the rules in the policy's stateless rule groups first, using the stateless rules engine. Then, depending on that inspection and on other settings in the policy, it might evaluate the packets against the rules in the policy's stateful rule groups, using the stateful rules engine. 

**1. Stateless rules engine**  
Network Firewall evaluates each packet against the firewall policy's stateless rules until it finds a match or exhausts all of the stateless rules. Network Firewall evaluates the rule groups in the order that they are prioritized in the policy, starting from the lowest setting. Within each rule group, Network Firewall evaluates the rules in the order that they are prioritized in the rule group, starting from the lowest setting. When you create a stateless rule group, you set the priority of the rules in the rule group. When you create a firewall policy, you set the priority of the stateless rule groups in the policy. For more information, see [Working with stateless rule groups in AWS Network Firewall](stateless-rule-groups-standard.md) and [Firewall policies in AWS Network Firewall](firewall-policies.md).

When Network Firewall finds a match, it handles the packet according to the matching rule's configuration. You configure a stateless rule to pass the packet through, drop it, or forward it to your stateful rules. Additionally, you can configure a stateless rule to perform a custom action, for example you can publish metrics for the packet to Amazon CloudWatch. For more information, see [Defining rule actions in AWS Network Firewall](rule-action.md).

**2. Default stateless rule actions**  
If a packet doesn't match any stateless rule, Network Firewall performs the firewall policy's default stateless rule action for full packet or UDP packet fragment, depending on the packet type. Network Firewall only applies the fragment action setting to UDP packet fragments, and silently drops packet fragments for other protocols. The options for these actions settings are the same as for stateless rules. For more information, see [Defining rule actions in AWS Network Firewall](rule-action.md).

**3. Stateful rules engine**  
When Network Firewall forwards a packet to the stateful engine for inspection, it inspects each packet against the stateful rule groups, in the context of the packet's traffic flow. You can configure a stateful rule to pass the packet through, with or without an alert, or drop it and send an alert. Alerts require logging to be configured for the firewall. 

The Suricata stateful rules engine controls how the stateful rules in your firewall policy are processed. The engine evaluates the packet's traffic flow against the conditions in the policy's stateful rules until it finds a match or exhausts all of the rules. When the engine finds a match, it handles the packet according to the rule's configuration. By default, the Suricata stateful rules engine orders rule processing according to the rule action setting, processing first the rules with pass action, then drop, then alert. For more information, see [Managing evaluation order for Suricata compatible rules in AWS Network Firewall](suricata-rule-evaluation-order.md) and the [Suricata Action-order documentation](https://suricata.readthedocs.io/en/suricata-7.0.8/configuration/suricata-yaml.html#action-order). 

Depending on the Suricata compatible rules that you provide, the stateful engine might perform deep packet inspection of your traffic. Deep packet inspection works on the payload data within your packets, rather than on the header information. 

For more information about stateful rules, see [Managing your own rule groups in AWS Network Firewall](rule-groups.md).

# Route table configurations for AWS Network Firewall
<a name="route-tables"></a>

To include the Network Firewall firewall in your Amazon Virtual Private Cloud VPC, you modify the VPC route tables so that the traffic that you want the firewall to filter passes through the firewall endpoints. Exactly how you do this depends on your architecture and the traffic that you want to filter. For example, to filter all traffic between an internet gateway and your customer subnets, you redirect incoming traffic from the internet gateway and outgoing traffic from the customer subnets through the firewall endpoint.

For information about managing route tables for your VPC, see [Route tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) in the *Amazon Virtual Private Cloud User Guide*.

For descriptions of common architectures for AWS Network Firewall, with example route table configurations, see [AWS Network Firewall example architectures with routing](architectures.md).

# Avoiding asymmetric routing with AWS Network Firewall
<a name="asymmetric-routing"></a>

Network Firewall doesn’t support asymmetric routing. Use the guidance that follows to prevent asymmetric routing in your network traffic where you use Network Firewall. 

In Network Firewall, asymmetric routing occurs when both request network traffic and its related response network traffic are not routed to the same Network Firewall endpoint. In order for Network Firewall to properly process traffic, the traffic must be routed to the Network Firewall endpoint in both directions.

The following are considerations to keep in mind to prevent asymmetric routing:
+ **Centralized deployment model** - If your firewall uses a centralized deployment model:
  + On the Transit Gateway which is on the inspection VPC of the firewall, use the Transit Gateway appliance mode to keep the traffic request and response flows on the same Network Firewall endpoint. For information about configuring the Transit Gateway appliance mode, see [AWS Transit Gateway traffic flow and asymmetric routing](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/transit-gateway-asymmetric-routing.html).
  + Configure your Transit Gateway route tables to route both forward and return direction traffic via your firewall attachment.
+ **Decentralized deployment model** - If your firewall is deployed in a decentralized deployment model inspecting internet-bound traffic from an internet gateway, use a route table with an Internet Gateway [edge association](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables:~:text=virtual%20private%20gateway.-,Edge%20association,-%E2%80%94A%20route%20table ) to route inbound traffic through the Network Firewall endpoint, in addition to an outbound route in the application subnet.
+ **NAT gateway** - If Network Firewall is downstream of your Network address translation (NAT) Gateway, make sure that the NAT gateway's subnet routes traffic through the Network Firewall endpoint. For information about using NAT gateway with Network Firewall, see the following resources:
  + [Architecture with an internet gateway and a NAT gateway using AWS Network Firewall](arch-igw-ngw.md)
  + [Using the NAT gateway with AWS Network Firewall for centralized egress](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/using-nat-gateway-with-firewall.html)
  + [How do I set up AWS Network Firewall with a NAT gateway?](https://aws.amazon.com/premiumsupport/knowledge-center/network-firewall-set-up-with-nat-gateway/)
+ **Stateless rules** - If your Network Firewall firewall uses stateless rules:
  + Be aware that unidirectional `pass` rules can create asymmetric forwarding when the policy’s stateless default action is **forward to stateful rules**.
  + Ensure that your stateless rules forward traffic symmetrically to the stateful engine using the **forward to stateful rule groups** action. Often this means writing pairs of rules to match both forward and return direction traffic. For information about the foward to stateful rule groups option, see [Creating a firewall policy in AWS Network Firewall](firewall-policy-creating.md). The following example shows a pair of rules that match both forward and return direction traffic:  
![\[A pair of rules is shown in the console with mirrored source and destination ports.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/paired-rule.png)

# AWS Network Firewall example architectures with routing
<a name="architectures"></a>

This section provides a high-level view of simple architectures that you can configure with AWS Network Firewall and shows example route table configurations for each. For additional information and examples, see [Deployment models for AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/). 

**Note**  
For information about managing route tables for your VPC, see [Route tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) in the *Amazon Virtual Private Cloud User Guide*.

**Unsupported architectures**  
The following lists architectures and traffic types that Network Firewall doesn't support:
+ VPC peering.
+ Inspection of AWS Global Accelerator traffic.
+ Inspection of AmazonProvidedDNS traffic for Amazon EC2.

**Topics**
+ [Simple single zone architecture with an internet gateway using AWS Network Firewall](arch-single-zone-igw.md)
+ [Multi zone architecture with an internet gateway using AWS Network Firewall](arch-two-zone-igw.md)
+ [Architecture with an internet gateway and a NAT gateway using AWS Network Firewall](arch-igw-ngw.md)

# Simple single zone architecture with an internet gateway using AWS Network Firewall
<a name="arch-single-zone-igw"></a>

This topic provides a high-level view of a simple VPC configuration using an internet gateway and AWS Network Firewall. It describes the basic route table modifications that are required to use the firewall. 

**Single zone architecture with internet gateway and no firewall**  
The following figure depicts a simple VPC configuration with a single customer subnet, and no firewall. The VPC has an internet gateway for internet access. All incoming and outgoing traffic routes through the internet gateway to the subnet.

![\[An AWS Region is shown with a single Availability Zone. The Region also has an internet gateway, which has arrows out to and in from an internet cloud. Inside the Region, spanning part of the Availability Zone, is a VPC. Inside the VPC is a customer subnet. One arrow shows traffic going between the customer subnet and the internet gateway.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/no-network-firewall-igw-simple.png)


**Single zone architecture with internet gateway and the Network Firewall firewall**  
The following figure depicts a simple VPC configuration with the firewall and the subnet association in place. The VPC has an internet gateway for internet access. All incoming and outgoing traffic for the VPC routes through the firewall.

![\[An AWS Region is shown with a single Availability Zone. The Region also has an internet gateway, which has arrows out to and in from an internet cloud. Inside the Region, spanning part of the Availability Zone, is a VPC. Inside the VPC is a customer subnet. One arrow shows traffic going between the customer subnet and the firewall subnet. Another arrow shows traffic going between the firewall subnet and the internet gateway.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/arch-igw-simple.png)


To include the firewall in your Amazon Virtual Private Cloud VPC, you need to modify the VPC route tables so that traffic between the customer subnets and the internet passes through the firewall, for both incoming and outgoing traffic. 

**Note**  
For information about managing route tables for your VPC, see [Route tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) in the *Amazon Virtual Private Cloud User Guide*.

**Example route tables in the single zone architecture with no firewall**  
The following figure depicts the route tables that provide the correct flow of traffic for a single Availability Zone without a firewall: 

![\[An AWS Region is shown with a single Availability Zone. The Region has an internet gateway, which has arrows leading out to and in from an internet cloud. Inside the Region, spanning part of the Availability Zone, is a VPC. Inside the Availability Zone, the VPC has a customer subnet. The VPC address range is 10.0.0.0/16. The address range for the customer subnet is 10.0.2.0/24. The route tables are listed for the internet gateway and the subnet. For the customer subnet, the route table directs traffic inside the VPC to local, and directs all other traffic to the internet gateway.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/no-network-firewall-igw-with-route-tables.png)


In the preceding figure, the route tables enforce the following traffic flows: 
+ **Internet gateway route table** – Routes traffic that's destined for the customer subnet (range `10.0.2.0/24`) to `local`. The customer subnet shows the private IP address range behind the publicly assigned address. The subnet has public addresses assigned, which are either auto-generated or assigned via Elastic IP address. Within a VPC, only private IP addresses are used for communication. 
+ **Customer subnet route table** – Routes traffic that's destined for anywhere inside the VPC (`10.0.0.0/16`) to the local address. Routes traffic that's destined for anywhere else (`0.0.0.0/0`) to the internet gateway (`igw-1232`). 

**Example route tables in the single zone architecture with the firewall**  
The following figure depicts the same installation with the Network Firewall firewall added and the route tables changed to include the firewall. The route tables direct traffic between the customer subnet and the internet gateway through the firewall endpoint: 

![\[An AWS Region is shown with a single Availability Zone. The Region has an internet gateway, which has arrows leading out to and in from an internet cloud. Inside the Region, spanning part of the Availability Zone, is a VPC. Inside the Availability Zone, the VPC has a firewall subnet and a customer subnet. The VPC address range is 10.0.0.0/16. The address range for the customer subnet is 10.0.2.0/24. The route tables are listed for the internet gateway and each of the two subnets. The route table for the internet gateway directs incoming traffic for the customer subnet to its firewall subnet. For the customer subnet, the route table directs traffic inside the VPC to local, and directs all other traffic to the firewall subnet. For the firewall subnet, the route table directs traffic inside the VPC to the local, and directs all other traffic to the internet gateway.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/arch-igw-with-route-tables.png)


In the preceding figure, the route tables enforce the following traffic flows: 
+ **Internet gateway route table** – Routes traffic that's destined for the customer subnet (range `10.0.2.0/24`) to the firewall subnet (named `vpce-4114` in the figure). The customer subnet shows the private IP address range behind the publicly assigned address. The subnet has public addresses assigned, which are either auto-generated or assigned via Elastic IP address. Within a VPC, only private IP addresses are used for communication. 
+ **Firewall subnet route table** – Routes traffic that's destined for anywhere inside the VPC (`10.0.0.0/16`) to the local address. Routes traffic that's destined for anywhere else (`0.0.0.0/0`) to the internet gateway (`igw-1232`). 
+ **Customer subnet route table** – Routes traffic that's destined for anywhere inside the VPC (`10.0.0.0/16`) to the local address. Routes traffic that's destined for anywhere else (`0.0.0.0/0`) to the firewall subnet (`vpce-4114`). 

  Before the firewall inclusion, the customer subnet route table routed the `0.0.0.0/0` traffic to `igw-1232`.

# Multi zone architecture with an internet gateway using AWS Network Firewall
<a name="arch-two-zone-igw"></a>

This topic provides a high-level view of a simple two zone VPC configuration using an internet gateway and AWS Network Firewall. It describes the basic route table modifications that are required to use the Network Firewall firewall.

**Two zone architecture with internet gateway and the Network Firewall firewall**  
The following figure depicts a Network Firewall configuration for a VPC that spans multiple Availability Zones. In this case, each Availability Zone that the VPC spans has a firewall subnet and a customer subnet. The VPC has an internet gateway for internet access. All incoming traffic for the VPC routes to the firewall in the same Availability Zone as the destination customer subnet. All outgoing traffic routes through the firewalls. 

![\[An AWS Region is shown with a two Availability Zones. The Region also has an internet gateway, which has arrows out to and in from an internet cloud. Inside the Region, spanning parts of each Availability Zone, is a VPC. Inside the VPC, each Availability Zone holds a firewall subnet and a customer subnet. In each zone, one arrow shows traffic going between the customer subnet and the firewall subnet. Each firewall subnet has an arrow between it and the single internet gateway.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/arch-igw-2az-simple.png)


**Route tables in the two zone architecture with the firewall**  
The following figure depicts a VPC configuration with two Availability Zones. Each zone has its own Network Firewall firewall, which provides monitoring and protection for the subnets in the zone. You can expand this configuration to any number of zones in your VPC.

![\[An AWS Region is shown with two Availability Zones. The Region has an internet gateway, which has arrows leading out to and in from an internet cloud. Inside the Region, and spanning the two Availability Zones, is a VPC. In each Availability Zone, the VPC has a firewall subnet and a customer subnet. The VPC address range is 10.0.0.0/8. The address ranges for the customer subnets are 10.0.0.0/16 and 10.1.0.0/16. The route tables are listed for the internet gateway and for each of the four subnets. The route table for the internet gateway directs incoming traffic for the two customer subnets to their relative firewall subnets. For each customer subnet, the route table directs traffic inside the VPC to local, and directs all other traffic to its relative firewall subnet. For each firewall subnet, the route table directs traffic inside the VPC to local, and directs all other traffic to the internet gateway.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/arch-igw-2az-with-route-tables.png)


In the preceding figure, the route tables enforce similar traffic flows to the single Availability Zone model, with the primary difference being the splitting of incoming traffic by the internet gateway, to accommodate the two different customer subnets: 
+ **Internet gateway route table** – Routes traffic that's destined for each customer subnet (range `10.0.2.0/24` or `10.0.3.0/24`) to the firewall subnet in the same Availability Zone (`vpce-4114` or `vpce-5588`, respectively).
+ **Firewall subnet route tables** – Route traffic that's destined for anywhere inside the VPC (`10.0.0.0/16`) to the local address. Route traffic that's destined for anywhere else (`0.0.0.0/0`) to the internet gateway (`igw-1232`). These are identical to the route table for the firewall subnet in the single Availability Zone. 
+ **Customer subnet route tables** – Route traffic that's destined for anywhere inside the VPC (`10.0.0.0/16`) to the local address. Route traffic that's destined for anywhere else (`0.0.0.0/0`) to the firewall subnet in the same Availability Zone (`vpce-4114` for zone AZ1 and `vpce-5588` for zone AZ2). 

# Architecture with an internet gateway and a NAT gateway using AWS Network Firewall
<a name="arch-igw-ngw"></a>

You can add a network address translation (NAT) gateway to your AWS Network Firewall architecture, for the areas of your VPC where you need NAT capabilities. AWS provides NAT gateways decoupled from your other cloud services, so you can use it in your architecture only where you need it. This can help you reduce load and load costs. For information about NAT gateways, see [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) in the *Amazon Virtual Private Cloud User Guide*.

The following figure depicts a VPC configuration for Network Firewall with an internet gateway and a NAT gateway. 

![\[VPC configuration showing internet gateway, firewall subnet, NAT gateway subnet, and customer subnet with IP ranges.\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/arch-igw-natgw.png)