Custom network ACLs for your VPC
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.
Each network ACL includes a default inbound rule and a default outbound rule whose rule number is an asterisk (*). 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.
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 * rule for IPv4 traffic ultimately denies the packet.
| Rule # | 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 |
|
ALLOW |
Allows inbound SSH traffic from your home network's public IPv4 address range (over the internet gateway). |
140 |
Custom TCP |
TCP |
|
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 |
|
::/0 |
ALLOW |
Allows inbound return IPv6 traffic from the internet (for requests that originate in the subnet). |
* |
All traffic |
All |
All |
0.0.0.0/0 |
DENY |
Denies all inbound IPv4 traffic not already handled by a preceding rule (not modifiable). |
* |
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 # | 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 |
|
|
ALLOW |
Allows outbound responses to SSH traffic from your home network. |
140 |
Custom TCP |
TCP |
|
0.0.0.0/0 |
ALLOW |
Allows outbound IPv4 responses to clients on the internet (for example, serving webpages). |
145 |
Custom TCP |
TCP |
|
::/0 |
ALLOW |
Allows outbound IPv6 responses to clients on the internet (for example, serving webpages). |
* |
All traffic |
All |
All |
0.0.0.0/0 |
DENY |
Denies all outbound IPv4 traffic not already handled by a preceding rule. |
* |
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:
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.
