# Control subnet traffic with network access control lists
Network ACLs

A *network access control list (ACL)* allows or denies specific inbound or outbound traffic at the subnet level. You can use the default network ACL for your VPC, or you can create a custom network ACL for your VPC with rules that are similar to the rules for your security groups in order to add an additional layer of security to your VPC.

There is no additional charge for using network ACLs.

The following diagram shows a VPC with two subnets. Each subnet has a network ACL. When traffic enters the VPC (for example, from a peered VPC, VPN connection, or the internet), the router sends the traffic to its destination. Network ACL A determines which traffic destined for subnet 1 is allowed to enter subnet 1, and which traffic destined for a location outside subnet 1 is allowed to leave subnet 1. Similarly, network ACL B determines which traffic is allowed to enter and leave subnet 2.

![\[A VPC with two subnets and a network ACL for each subnet.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/network-acl.png)


For information about the differences between security groups and network ACLs, see [Compare security groups and network ACLs](infrastructure-security.md#VPC_Security_Comparison).

**Topics**
+ [

## Network ACL basics
](#nacl-basics)
+ [

# Network ACL rules
](nacl-rules.md)
+ [

# Default network ACL for a VPC
](default-network-acl.md)
+ [

# Custom network ACLs for your VPC
](custom-network-acl.md)
+ [

# Path MTU Discovery and network ACLs
](path_mtu_discovery.md)
+ [

# Create a network ACL for your VPC
](create-network-acl.md)
+ [

# Manage network ACL associations for your VPC
](network-acl-associations.md)
+ [

# Delete a network ACL for your VPC
](delete-network-acl.md)
+ [

# Example: Control access to instances in a subnet
](nacl-examples.md)

## Network ACL basics


The following are the basic things to know about network ACLs before you begin.

**Network ACL associations**
+ Each subnet in your VPC must be associated with a network ACL. If you don't explicitly associate a subnet with a network ACL, the subnet is automatically associated with the [default network ACL](default-network-acl.md).
+ You can create a [custom network ACL](custom-network-acl.md) and associate it with a subnet to allow or deny specific inbound or outbound traffic at the subnet level.
+ You can associate a network ACL with multiple subnets. However, a subnet can be associated with only one network ACL at a time. When you associate a network ACL with a subnet, the previous association is removed.

**Network ACL rules**
+ A network ACL has inbound rules and outbound rules. There are [quotas (or limits) to the number of rules you can have per network ACL](amazon-vpc-limits.md#vpc-limits-nacls). Each rule can either allow or deny traffic. Each rule has a number from 1 to 32766. We evaluate the rules in order, starting with the lowest numbered rule, when deciding whether allow or deny traffic. If the traffic matches a rule, the rule is applied and we do not evaluate any additional rules. We recommend that you start by creating rules in increments (for example, increments of 10 or 100) so that you can insert new rules later on, if needed.
+ We evaluate the network ACL rules when traffic enters and leaves the subnet, not as it is routed within a subnet.
+ NACLs are *stateless*, which means that information about previously sent or received traffic is not saved. If, for example, you create a NACL rule to allow specific inbound traffic to a subnet, responses to that traffic are not automatically allowed. This is in contrast to how security groups work. Security groups are *stateful*, which means that information about previously sent or received traffic is saved. If, for example, a security group allows inbound traffic to an EC2 instance, responses are automatically allowed regardless of outbound security group rules.

**Limitations**
+ There are quotas (also known as limits) for network ACLs. For more information, see [Network ACLs](amazon-vpc-limits.md#vpc-limits-nacls).
+ Network ACLs can't block DNS requests to or from the Route 53 Resolver (also known as the VPC\$12 IP address or AmazonProvidedDNS). To filter DNS requests through the Route 53 Resolver, you can enable [Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html).
+ Network ACLs can't block traffic to the Instance Metadata Service (IMDS). To manage access to IMDS, see [Configure the instance metadata options](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) in the *Amazon EC2 User Guide*.
+ Network ACLs do not filter traffic destined to and from the following:
  + Amazon Domain Name Services (DNS)
  + Amazon Dynamic Host Configuration Protocol (DHCP)
  + Amazon EC2 instance metadata
  + Amazon ECS task metadata endpoints
  + License activation for Windows instances
  + Amazon Time Sync Service
  + Reserved IP addresses used by the default VPC router

# Network ACL rules


You can add or remove rules from the default network ACL, or create additional network ACLs for your VPC. When you add or remove rules from a network ACL, the changes are automatically applied to the subnets that it's associated with.

The following are the parts of a network ACL rule:
+ **Rule number**. Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it's applied regardless of any higher-numbered rule that might contradict it.
+ **Type**. The type of traffic; for example, SSH. You can also specify all traffic or a custom range.
+ **Protocol**. You can specify any protocol that has a standard protocol number. For more information, see [Protocol Numbers](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). If you specify ICMP as the protocol, you can specify any or all of the ICMP types and codes.
+ **Port range**. The listening port or port range for the traffic. For example, 80 for HTTP traffic.
+ **Source**. [Inbound rules only] The source of the traffic (CIDR range).
+ **Destination**. [Outbound rules only] The destination for the traffic (CIDR range).
+ **Allow/Deny**. Whether to *allow* or *deny* the specified traffic.

For example rules, see [Example: Control access to instances in a subnet](nacl-examples.md).

## Considerations

+ There are quotas (also known as limits) for the number of rules per network ACLs. For more information, see [Amazon VPC quotas](amazon-vpc-limits.md).
+ When you add or delete a rule from an ACL, any subnets that are associated with the ACL are subject to the change. The changes take effect after a short period.
+ If you add a rule using a command line tool or the Amazon EC2 API, the CIDR range is automatically modified to its canonical form. For example, if you specify `100.68.0.18/18` for the CIDR range, we create a rule with a `100.68.0.0/18` CIDR range.
+ You might want to add a deny rule in a situation where you must open a wide range of ports, but there are certain ports within the range that you want to deny. Be sure to give the deny rule a lower number than the rule that allows the wider range of port traffic.
+ If you add and delete rules from a network ACL at the same time, be careful. If you delete inbound or outbound rules and then add more new entries than are allowed (see [Amazon VPC quotas](amazon-vpc-limits.md), the entries selected for deletion are removed and new entries *are not added*. This can cause unexpected connectivity issues and prevent access to and from your VPC.

# Default network ACL for a VPC
Default network ACL

Your virtual private cloud (VPC) automatically comes with a default network ACL. A default network ACL is configured to allow all traffic to flow in and out of the subnets with which it is associated. Each network ACL also includes rules where the rule number is an asterisk (\$1). These rules ensure that if a packet doesn't match any of the other numbered rules, it's denied.

You can modify a default network ACL by adding rules or removing the default numbered rules. You can't delete a rule where the rule number is an asterisk.

**Default inbound rules**  
The following table shows the default inbound rules for a default network ACL. The rules for IPv6 are added only if you create the VPC with an associated IPv6 CIDR block or associate an IPv6 CIDR block with the VPC. However, if you've modified the inbound rules of a default network ACL, we do not add the rule that allows all inbound IPv6 traffic when you associate an IPv6 block with the VPC.


| Rule \$1 | Type | Protocol | Port range  | Source | Allow/Deny | 
| --- | --- | --- | --- | --- | --- | 
|  100  | All IPv4 traffic |  All  |  All  | 0.0.0.0/0 |  ALLOW  | 
|  101  |  All IPv6 traffic  |  All  |  All  |  ::/0  |  ALLOW  | 
|  \$1  | All traffic |  All  |  All  | 0.0.0.0/0 |  DENY  | 
|  \$1  |  All IPv6 traffic  |  All  |  All  |  ::/0  |  DENY  | 

**Default outbound rules**  
The following table shows the default outbound rules for a default network ACL. The rules for IPv6 are added only if you create the VPC with an associated IPv6 CIDR block or associate an IPv6 CIDR block with the VPC. However, if you've modified the outbound rules of a default network ACL, we do not add the rule that allows all outbound IPv6 traffic when you associate an IPv6 block with the VPC.


| Rule \$1 | Type | Protocol | Port range | Destination | Allow/Deny | 
| --- | --- | --- | --- | --- | --- | 
|  100  | All traffic |  All  |  All  | 0.0.0.0/0 |  ALLOW  | 
|  101  |  All IPv6 traffic  |  All  |  All  |  ::/0  |  ALLOW  | 
|  \$1  | All traffic |  All  |  All  | 0.0.0.0/0 |  DENY  | 
|  \$1  |  All IPv6 traffic  |  All  |  All  |  ::/0  |  DENY  | 

# Custom network ACLs for your VPC
Custom network ACLs

You can create a custom network ACL and associate it with a subnet to allow or deny specific inbound or outbound traffic at the subnet level. For more information, see [Create a network ACL for your VPC](create-network-acl.md).

Each network ACL includes a default inbound rule and a default outbound rule whose rule number is an asterisk (\$1). These rules ensure that if a packet doesn't match any of the other rules, it's denied.

You can modify a network ACL by adding or removing rules. You can't delete a rule where the rule number is an asterisk.

For every rule that you add, there must be an inbound or outbound rule that allows response traffic. For more information about how to select the appropriate ephemeral port range, see [Ephemeral ports](#nacl-ephemeral-ports).

**Example inbound rules**  
The following table shows example inbound rules for a network ACL. The rules for IPv6 are added only if the VPC has an associated IPv6 CIDR block. IPv4 and IPv6 traffic are evaluated separately. Therefore, none of the rules for IPv4 traffic apply to IPv6 traffic. You can add IPv6 rules next to the corresponding IPv4 rules, or add the IPv6 rules after the last IPv4 rule.

As a packet comes to the subnet, we evaluate it against the inbound rules of the network ACL that is associated with the subnet, starting with the lowest numbered rule. For example, suppose there is IPv4 traffic destined for the HTTPS port (443). The packet doesn't match rule 100 or 105. It matches rule 110, which allows the traffic into the subnet. If the packet had been destined for port 139 (NetBIOS), it wouldn't match any of the numbered rules, so the \$1 rule for IPv4 traffic ultimately denies the packet.


| Rule \$1 | Type | Protocol | Port range | Source | Allow/Deny | Comments | 
| --- | --- | --- | --- | --- | --- | --- | 
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | ALLOW |  Allows inbound HTTP traffic from any IPv4 address.  | 
| 105 | HTTP | TCP | 80 | ::/0 | ALLOW |  Allows inbound HTTP traffic from any IPv6 address.  | 
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | ALLOW |  Allows inbound HTTPS traffic from any IPv4 address.  | 
| 115 | HTTPS | TCP | 443 | ::/0 | ALLOW | Allows inbound HTTPS traffic from any IPv6 address. | 
| 120 | SSH | TCP | 22 | *192.0.2.0/24* | ALLOW |  Allows inbound SSH traffic from your home network's public IPv4 address range (over the internet gateway).  | 
| 140 | Custom TCP | TCP | *32768-65535* | 0.0.0.0/0 | ALLOW |  Allows inbound return IPv4 traffic from the internet (for requests that originate in the subnet).  | 
| 145 | Custom TCP | TCP | *32768-65535* | ::/0 | ALLOW |  Allows inbound return IPv6 traffic from the internet (for requests that originate in the subnet).  | 
| \$1 | All traffic | All | All | 0.0.0.0/0 | DENY |  Denies all inbound IPv4 traffic not already handled by a preceding rule (not modifiable).  | 
| \$1 | All traffic | All | All | ::/0 | DENY |  Denies all inbound IPv6 traffic not already handled by a preceding rule (not modifiable).  | 

**Example outbound rules**  
The following table shows example outbound rules for a custom network ACL. The rules for IPv6 are added only if the VPC has an associated IPv6 CIDR block. IPv4 and IPv6 traffic are evaluated separately. Therefore, none of the rules for IPv4 traffic apply to IPv6 traffic. You can add IPv6 rules next to the corresponding IPv4 rules, or add the IPv6 rules after the last IPv4 rule.


| Rule \$1 | Type | Protocol | Port range | Destination | Allow/Deny | Comments | 
| --- | --- | --- | --- | --- | --- | --- | 
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | ALLOW | Allows outbound IPv4 HTTP traffic from the subnet to the internet. | 
| 105 | HTTP | TCP | 80 | ::/0 | ALLOW | Allows outbound IPv6 HTTP traffic from the subnet to the internet. | 
| 110 | HTTPS | TCP | 443 | 0.0.0.0/0 | ALLOW | Allows outbound IPv4 HTTPS traffic from the subnet to the internet. | 
| 115 | HTTPS | TCP | 443 | ::/0 | ALLOW | Allows outbound IPv6 HTTPS traffic from the subnet to the internet. | 
| 120 | Custom TCP | TCP | *1024-65535* | *192.0.2.0/24* | ALLOW |  Allows outbound responses to SSH traffic from your home network.  | 
| 140 | Custom TCP | TCP | *32768-65535* | 0.0.0.0/0 | ALLOW | Allows outbound IPv4 responses to clients on the internet (for example, serving webpages). | 
| 145 | Custom TCP | TCP | *32768-65535* | ::/0 | ALLOW | Allows outbound IPv6 responses to clients on the internet (for example, serving webpages).  | 
| \$1 | All traffic | All | All | 0.0.0.0/0 | DENY | Denies all outbound IPv4 traffic not already handled by a preceding rule. | 
| \$1 | All traffic | All | All | ::/0 | DENY | Denies all outbound IPv6 traffic not already handled by a preceding rule. | 

## Ephemeral ports


The example network ACL in the preceding section uses an ephemeral port range of 32768-65535. However, you might want to use a different range for your network ACLs depending on the type of client that you're using or with which you're communicating.

The client that initiates the request chooses the ephemeral port range. The range varies depending on the client's operating system. 
+ Many Linux kernels (including the Amazon Linux kernel) use ports 32768-61000.
+ Requests originating from Elastic Load Balancing use ports 1024-65535.
+ Windows operating systems through Windows Server 2003 use ports 1025-5000.
+ Windows Server 2008 and later versions use ports 49152-65535.
+ A NAT gateway uses ports 1024-65535.
+ AWS Lambda functions use ports 1024-65535.

For example, if a request comes into a web server in your VPC from a Windows 10 client on the internet, your network ACL must have an outbound rule to enable traffic destined for ports 49152-65535. 

If an instance in your VPC is the client initiating a request, your network ACL must have an inbound rule to enable traffic destined for the ephemeral ports specific to the operating system of the instance. 

In practice, to cover the different types of clients that might initiate traffic to public-facing instances in your VPC, you can open ephemeral ports 1024-65535. However, you can also add rules to the ACL to deny traffic on any malicious ports within that range. Ensure that you place the deny rules earlier in the table than the allow rules that open the wide range of ephemeral ports.

## Custom network ACLs and other AWS services


If you create a custom network ACL, be aware of how it might affect resources that you create using other AWS services.

With Elastic Load Balancing, if the subnet for your backend instances has a network ACL in which you've added a *deny* rule for all traffic with a source of either `0.0.0.0/0` or the subnet's CIDR, your load balancer can't carry out health checks on the instances. For more information about the recommended network ACL rules for your load balancers and backend instances, see the following:
+ [Network ACLs for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html)
+ [Network ACLs for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#network-acls)
+ [Network ACLs for your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-vpc-network-acls.html)

## Troubleshoot reachability issues


Reachability Analyzer is a static configuration analysis tool. Use Reachability Analyzer to analyze and debug network reachability between two resources in your VPC. Reachability Analyzer produces hop-by-hop details of the virtual path between these resources when they are reachable, and identifies the blocking component otherwise. For example, it can identify missing or misconfigured network ACL rules.

For more information, see the [Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/).

# Path MTU Discovery and network ACLs
Path MTU Discovery

Path MTU Discovery is used to determine the path MTU between two devices. The path MTU is the maximum packet size that's supported on the path between the originating host and the receiving host. 

For IPv4, when a host sends a packet that's larger than the MTU of the receiving host or that's larger than the MTU of a device along the path, the receiving host or device drops the packet, and then returns the following ICMP message: `Destination Unreachable: Fragmentation Needed and Don't Fragment was Set` (Type 3, Code 4). This instructs the transmitting host to split the payload into multiple smaller packets, and then retransmit them. 

The IPv6 protocol does not support fragmentation in the network. When a host sends a packet that's larger than the MTU of the receiving host or that's larger than the MTU of a device along the path, the receiving host or device drops the packet, and then returns the following ICMP message: `ICMPv6 Packet Too Big (PTB)` (Type 2). This instructs the transmitting host to split the payload into multiple smaller packets, and then retransmit them. 

If the maximum transmission unit (MTU) between hosts in your subnets is different, or your instances communicate with peers over the internet, you must add the following network ACL rule, both inbound and outbound. This ensures that Path MTU Discovery can function correctly and prevent packet loss. Select **Custom ICMP Rule** for the type and **Destination Unreachable**, **fragmentation required, and DF flag set** for the port range (type 3, code 4). If you use traceroute, also add the following rule: select **Custom ICMP Rule** for the type and **Time Exceeded**, **TTL expired transit** for the port range (type 11, code 0). For more information, see [Network maximum transmission unit (MTU) for your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html) in the *Amazon EC2 User Guide*.

# Create a network ACL for your VPC
Create a network ACL

The following tasks show you how to create a network ACL, add rules to the network ACL, and then associate the network ACL with a subnet.

**Topics**
+ [

## Step 1: Create a network ACL
](#CreateACL)
+ [

## Step 2: Add rules
](#Rules)
+ [

## Step 3: Associate a subnet with a network ACL
](#NetworkACL)
+ [

## (Optional) Manage network ACLs using Firewall Manager
](#nacls-using-firewall-manager)

## Step 1: Create a network ACL


You can create a custom network ACL for your VPC. The initial rules for a custom network ACL block all inbound and outbound traffic. Your new custom network ACL is not associated with a subnet by default and must be explicitly associated with subnets.

**To create a network ACL using the console**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**.

1. Choose **Create network ACL**.

1. (Optional) For **Name**, enter a name for your network ACL.

1. For **VPC**, select the VPC.

1. (Optional) For **Tags**, choose **Add tag** and then enter a tag key and a tag value.

1. Choose **Create network ACL**.

**To create a network ACL using the command line**
+ [create-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-network-acl.html) (AWS CLI)
+ [New-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NetworkAcl.html) (AWS Tools for Windows PowerShell)

## Step 2: Add rules


You can add rules that allow or deny inbound or outbound traffic.

We process the rules in order, starting with the rule with the lowest number. We recommend that you leave gaps between the rule numbers (such as 100, 200, 300), rather than using sequential numbers (101, 102, 103). This makes it easier add a new rule without having to renumber the existing rules.

If you're using the Amazon EC2 API or a command line tool, you can't modify rules. You can only add and delete rules. If you're using the Amazon VPC console, you can modify the entries for existing rules. The console removes the existing rule and adds a new rule for you. If you need to change the order of a rule in the ACL, you must add a new rule with the new rule number, and then delete the original rule.

**To add rules to a network ACL using the console**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**.

1. Select the network ACL.

1. To add an inbound rule, do the following:

   1. Choose the **Inbound rules** tab.

   1. Choose **Edit inbound rules**, **Add new rule**.

   1. Enter a rule number that is not already in use, a type, protocol, port range, source, and whether to allow or deny the traffic. For some types, we fill in the protocol and port for you. If you are prompted for a port range, enter a port number or a port range (for example, 49152-65535).

      To use a protocol that's not listed, choose **Custom Protocol** for the type and then select the protocol. For more information, see [IANA Protocol Numbers](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).

   1. Choose **Save changes**.

1. To add an outbound rule, do the following:

   1. Choose the **Outbound rules** tab.

   1. Choose **Edit outbound rules**, **Add new rule**.

   1. Enter a rule number that is not already in use, a type, protocol, port range, source, and whether to allow or deny the traffic. For some types, we fill in the protocol and port for you. If you are prompted for a port range, enter a port number or a port range (for example, 49152-65535).

      To use a protocol that's not listed, choose **Custom Protocol** for the type and then select the protocol. For more information, see [IANA Protocol Numbers](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).

   1. Choose **Save changes**.

**To add a rule to a network ACL using the command line**
+ [create-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-network-acl-entry.html) (AWS CLI)
+ [New-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2NetworkAclEntry.html) (AWS Tools for Windows PowerShell)

**To replace a rule in a network ACL using the command line**
+ [replace-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-entry.html) (AWS CLI)
+ [Set-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclEntry.html) (AWS Tools for Windows PowerShell)

**To delete a rule from a network ACL using the command line**
+ [delete-network-acl-entry](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl-entry.html) (AWS CLI)
+ [Remove-EC2NetworkAclEntry](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NetworkAclEntry.html) (AWS Tools for Windows PowerShell)

## Step 3: Associate a subnet with a network ACL


To apply the rules of a network ACL to a particular subnet, you must associate the subnet with the network ACL. You can associate a network ACL with multiple subnets. However, a subnet can be associated with only one network ACL. Any subnet that is not associated with a particular ACL is associated with the default network ACL by default.

**To associate a subnet with a network ACL**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**, and then select the network ACL.

1. In the details pane, on the **Subnet Associations** tab, choose **Edit**. Select the **Associate** check box for the subnet to associate with the network ACL, and then choose **Save**.

## (Optional) Manage network ACLs using Firewall Manager


AWS Firewall Manager simplifies your network ACL administration and maintenance tasks across multiple accounts and subnets. You can use Firewall Manager to monitor accounts and subnets in your organization and to automatically apply the network ACL configurations that you've defined. Firewall Manager is particularly useful when you want to protect your entire organization, or if you frequently add new subnets that you want to automatically protect from a central administrator account.

With a Firewall Manager network ACL policy, using a single administrator account, you can configure, monitor, and manage the minimum rule sets that you want to have defined in the network ACLs that you use across your organization. You specify which accounts and subnets in your organization are within scope of the Firewall Manager policy. Firewall Manager reports the compliance status of the network ACLs for in-scope subnets, and you can configure Firewall Manager to automate the remediation of noncompliant network ACLs.

For more information, see the following resources in the *AWS Firewall Manager Developer Guide*:
+ [AWS Firewall Manager prerequisites](https://docs.aws.amazon.com/waf/latest/developerguide/fms-prereq.html)
+ [Setting up AWS Firewall Manager network ACL policies](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html)
+ [Using network ACL policies with Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/network-acl-policies.html)

# Manage network ACL associations for your VPC
Manage network ACL associations

Each subnet is associated with one network ACL. When you first create a subnet, it is associated with the default network ACL for the VPC. You can create a custom network ACL and associate it with one or more subnets, replacing the previous network ACL association.

**Topics**
+ [

## Describe your network ACL associations
](#describe-network-acl-association)
+ [

## Change the subnets associated with a network ACL
](#DisassociateNetworkACL)
+ [

## Change the network ACL associated with a subnet
](#ChangeNetworkACL)

## Describe your network ACL associations


You can describe the network ACL that's associated with a subnet and you can also describe which subnets are associated with a network ACL.

**To describe the network ACL associated with a subnet using the console**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Subnets**.

1. Select the subnet.

1. Select the **Network ACL** tab.

**To describe the network ACL associated with a subnet using the AWS CLI**  
Use the following [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) command to list the network ACL associated with the specified subnet.

```
aws ec2 describe-network-acls --filters Name=association.subnet-id,Values=subnet-0d2d1b81e0bc9c6d4 --query NetworkAcls[*].NetworkAclId
```

The following is example output.

```
[
    "acl-03701d1f82d8c3fd6"
]
```

**To describe the subnets associated with a network ACL using the console**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**.

1. Select the network ACL.

1. Select the **Subnet associations** tab.

**To describe the subnets associated with a network ACL using the AWS CLI**  
Use the following [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) command to list the subnets associated with the specified network ACL.

```
aws ec2 describe-network-acls --network-acl-ids acl-060415a18fcc9afde --query NetworkAcls[*].Associations[].SubnetId
```

The following is example output.

```
[
    "subnet-0d2d1b81e0bc9c6d4",
    "subnet-0e990c67809773b19",
    "subnet-0eb17d85f5dfd33b1",
    "subnet-0e01d500780bb7468"
]
```

## Change the subnets associated with a network ACL


You can disassociate a custom network ACL from a subnet. After you disassociate a subnet from a custom network ACL, we automatically associate it with the default network ACL for the VPC. The changes take effect after a short period of time.

**To change the subnets associated with a network ACL**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**.

1. Select the network ACL.

1. Choose **Actions**, **Edit subnet associations**.

1. Remove the subnet from **Selected subnets**.

1. Choose **Save changes**.

## Change the network ACL associated with a subnet


You can change the network ACL that's associated with a subnet. For example, when you create a subnet, it is initially associated with the default network ACL for the VPC. If you create a custom network ACL, you apply the network ACL rules by associating the network ACL with one or more subnets.

After you change the network ACL for a subnet, the changes take effect after a short period of time.

**To change the network ACL associated with a subnet**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Subnets**.

1. Select the subnet.

1. Choose **Actions**, **Edit network ACL association**.

1. For **Network ACL ID**, select the network ACL to associate with the subnet, and review the inbound and outbound rules for the selected network ACL.

1. Choose **Save**.

**To replace a network ACL association using the command line**
+ [replace-network-acl-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-association.html) (AWS CLI)
+ [Set-EC2NetworkAclAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclAssociation.html) (AWS Tools for Windows PowerShell)

# Delete a network ACL for your VPC
Delete a network ACL

When you are finished with a network ACL, you can delete it. You can't delete a network ACL if there are subnets associated with it. You can't delete the default network ACL.

**To remove subnet associations from a network ACL using the console**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**. The **Associated with** column indicates the number of subnets associated with each network ACL. This column is `-` if there are no associated subnets.

1. Select the network ACL.

1. Choose **Actions**, **Edit subnet associations**.

1. Remove the subnet associations.

1. Choose **Save changes**.

**To describe your network ACLs, including associations, using the command line**
+ [describe-network-acls](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-acls.html) (AWS CLI)
+ [Get-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2NetworkAcl.html) (AWS Tools for Windows PowerShell)

**To replace a network ACL association using the command line**
+ [replace-network-acl-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-network-acl-association.html) (AWS CLI)
+ [Set-EC2NetworkAclAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2NetworkAclAssociation.html) (AWS Tools for Windows PowerShell)

**To delete a network ACL using the console**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, choose **Network ACLs**.

1. Select the network ACL.

1. Choose **Actions**, **Delete network ACLs**.

1. When prompted for confirmation, enter **delete** and then choose **Delete**.

**To delete a network ACL using the command line**
+ [delete-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl.html) (AWS CLI)
+ [Remove-EC2NetworkAcl](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2NetworkAcl.html) (AWS Tools for Windows PowerShell)

# Example: Control access to instances in a subnet


In this example, instances in the subnet can communicate with each other, and are accessible from a trusted remote computer in order to perform administrative tasks. The remote computer might be a computer in your local network, as shown in the diagram, or it might be an instance in a different subnet or VPC. The network ACL rules for the subnet, and the security group rules for the instances, allow access from the IP address of your remote computer. All other traffic from the internet or other networks is denied.

![\[Using a security group and an NACL\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/nacl-example-diagram.png)


Using a network ACL gives you the flexibility to change the security groups or security group rules for your instances while relying on the network ACL as a backup layer of defense. For example, if you accidentally update the security group to allow inbound SSH access from anywhere, but the network ACL allows access only from the IP address range of the remote computer, then the network ACL denies inbound SSH traffic from any other IP addresses.

## Network ACL rules


The following are example inbound rules for the network ACL associated with the subnet. These rules apply to all instances in the subnet.


| Rule \$1 | Type | Protocol | Port range | Source | Allow/Deny | Comments | 
| --- | --- | --- | --- | --- | --- | --- | 
| 100 | SSH | TCP | 22 | 172.31.1.2/32 | ALLOW | Allow inbound traffic from the remote computer. | 
| \$1 | All traffic | All | All | 0.0.0.0/0 | DENY | Deny all other inbound traffic. | 

The following are example outbound rules for the network ACL associated with the subnet. Network ACLs are stateless. Therefore, you must include a rule that allows responses to the inbound traffic.


| Rule \$1 | Type | Protocol | Port range | Destination | Allow/Deny | Comments | 
| --- | --- | --- | --- | --- | --- | --- | 
| 100 | Custom TCP | TCP | 1024-65535 | 172.31.1.2/32 | ALLOW | Allows outbound responses to the remote computer. | 
| \$1 | All traffic | All | All | 0.0.0.0/0 | DENY | Denies all other outbound traffic. | 

## Security group rules


The following are example inbound rules for the security group associated with the instances. These rules apply to all instances associated with the security group. A user with the private key for the key pair associated with the instances can connect to the instances from the remote computer using SSH.


| Protocol type | Protocol | Port range | Source | Comments | 
| --- | --- | --- | --- | --- | 
| All traffic | All | All | sg-1234567890abcdef0 | Allow communication between the instances associated with this security group. | 
| SSH | TCP | 22 | 172.31.1.2/32 | Allow inbound SSH access from the remote computer. | 

The following are example outbound bound rules for the security group associated with the instances. Security groups are stateful. Therefore, you don't need a rule that allows responses to inbound traffic.


| Protocol Type | Protocol | Port range | Destination | Comments | 
| --- | --- | --- | --- | --- | 
| All traffic | All | All | sg-1234567890abcdef0 | Allow communication between the instances associated with this security group. | 

## Differences between network ACLs and security groups


The following table summarizes the basic differences between network ACLs and security groups.


| Characteristic | Network ACL | Security group | 
| --- | --- | --- | 
| Level of operation | Subnet level | Instance level | 
| Scope | Applies to all instances in the associated subnets | Applies to all instances associated with the security group | 
| Rule type | Allow and deny rules | Allow rules only | 
| Rule evaluation | Evaluates rules in ascending order until a match for the traffic is found | Evaluates all rules before deciding whether to allow traffic | 
| Return traffic | Must be explicitly allowed (stateless) | Automatically allowed (stateful) |