Mục Lục

Control traffic to subnets using 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.

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 VPCs, 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.

For more information about the differences between security groups and network ACLs, see
Compare security groups and network ACLs.

Network ACL basics

The following are the basic things that you need to know about network ACLs:

Your VPC automatically comes with a modifiable default network ACL. By default, it
allows all inbound and outbound IPv4 traffic and, if applicable, IPv6 traffic.
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.
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.
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.
A network ACL has inbound rules and outbound rules. 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.
Network ACLs are stateless, which means that responses to allowed inbound traffic are
subject to the rules for outbound traffic (and vice versa).

There are quotas (also known as limits) for the number of network ACLs per VPC and the
number of rules per network ACL. For more information, see Amazon VPC quotas.

Note

Network ACLs cannot block DNS requests to or from the Route 53 Resolver, sometimes referred to
as the ‘VPC+2 IP address’ (see What is Amazon Route 53
Resolver? in the Amazon Route 53 Developer Guide), or the ‘AmazonProvidedDNS’. If you wish to filter DNS requests
through the Route 53 Resolver, you can enable Route 53 Resolver DNS Firewall (see Route
53 Resolver DNS Firewall in the Amazon Route 53 Developer
Guide).

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. 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.

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.

Default network ACL

The 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 a rule whose rule number
is an asterisk. This rule ensures that if a packet doesn’t match any of the other numbered
rules, it’s denied. You can’t modify or remove this rule.

The following is an example default network ACL for a VPC that supports IPv4 only.

Inbound
Rule #
Type
Protocol
Port range
Source
Allow/Deny

100

All IPv4 traffic

All

0.0.0.0/0

ALLOW

All IPv4 traffic

All

0.0.0.0/0

DENY

Outbound
Rule #
Type
Protocol
Port range
Destination
Allow/Deny

100

All IPv4 traffic

All

0.0.0.0/0

ALLOW

All IPv4 traffic

All

0.0.0.0/0

DENY

If you create a VPC with an IPv6 CIDR block or if you associate an IPv6 CIDR block with
your existing VPC, we automatically add rules that allow all IPv6 traffic to flow in and out
of your subnet. We also add rules whose rule numbers are an asterisk that ensures that a
packet is denied if it doesn’t match any of the other numbered rules. You can’t modify or
remove these rules. The following is an example default network ACL for a VPC that supports
IPv4 and IPv6.

Note

If you’ve modified your default network ACL’s inbound rules, we do not automatically add
an allow rule for inbound IPv6 traffic when you associate
an IPv6 block with your VPC. Similarly, if you’ve modified the outbound rules, we do not
automatically add an allow rule for outbound IPv6
traffic.

Inbound
Rule #
Type
Protocol
Port range
Source
Allow/Deny

100

All IPv4 traffic

All

0.0.0.0/0

ALLOW

101

All IPv6 traffic

All

::/0

ALLOW

All traffic

All

0.0.0.0/0

DENY

All IPv6 traffic

All

::/0

DENY

Outbound
Rule #
Type
Protocol
Port range
Destination
Allow/Deny

100

All traffic

All

0.0.0.0/0

ALLOW

101

All IPv6 traffic

All

::/0

ALLOW

All traffic

All

0.0.0.0/0

DENY

All IPv6 traffic

All

::/0

DENY

Custom network ACL

The following table shows an example of a custom network ACL for a VPC that supports IPv4
only. It includes rules that allow HTTP and HTTPS traffic in (inbound rules 100 and 110).
There’s a corresponding outbound rule that enables responses to that inbound traffic (outbound
rule 140, which covers ephemeral ports 32768-65535). For more information about how to select
the appropriate ephemeral port range, see Ephemeral ports.

The network ACL also includes inbound rules that allow SSH and RDP traffic into the
subnet. The outbound rule 120 enables responses to leave the subnet.

The network ACL has outbound rules (100 and 110) that allow outbound HTTP and HTTPS
traffic out of the subnet. There’s a corresponding inbound rule that enables responses
to that outbound traffic (inbound rule 140, which covers ephemeral ports 32768-65535).

Note

Each network ACL includes a default rule whose rule number is an asterisk. This rule
ensures that if a packet doesn’t match any of the other rules, it’s denied. You can’t modify
or remove this rule.

Inbound
Rule #
Type
Protocol
Port range
Source
Allow/Deny
Comments

100

HTTP

TCP

0.0.0.0/0

ALLOW

Allows inbound HTTP traffic from any IPv4 address.

110

HTTPS

TCP

443

0.0.0.0/0

ALLOW

Allows inbound HTTPS traffic from any IPv4 address.

120

SSH

TCP

192.0.2.0/24

ALLOW

Allows inbound SSH traffic from your home network’s public IPv4 address range
(over the internet gateway).

130

RDP

TCP

3389

192.0.2.0/24

ALLOW

Allows inbound RDP traffic to the web servers 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 (that is, for requests that
originate in the subnet).

This range is an example only. For more information about how to select the
appropriate ephemeral port range, see Ephemeral ports.

All traffic

All

0.0.0.0/0

DENY

Denies all inbound IPv4 traffic not already handled by a preceding rule (not
modifiable).

Outbound
Rule #
Type
Protocol
Port range
Destination
Allow/Deny
Comments

100

HTTP

TCP

0.0.0.0/0

ALLOW

Allows outbound IPv4 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.

120
SSH

TCP

1024-65535

192.0.2.0/24

ALLOW

Allows outbound 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 outbound IPv4 responses to clients on the internet (for example, serving
webpages to people visiting the web servers in the subnet).

This range is an example only. For more information about how to select the
appropriate ephemeral port range, see Ephemeral ports.

All traffic

All

0.0.0.0/0

DENY

Denies all outbound IPv4 traffic not already handled by a preceding rule (not
modifiable).

As a packet comes to the subnet, we evaluate it against the inbound rules of the ACL that
the subnet is associated with (starting at the top of the list of rules, and moving to
the bottom). Here’s how the evaluation goes if the packet is destined for the HTTPS port
(443). The packet doesn’t match the first rule evaluated (rule 100). It does match the
second rule (110), which allows the packet into the subnet. If the packet had been
destined for port 139 (NetBIOS), it doesn’t match any of the rules, and the * rule
ultimately denies the packet.

You might want to add a deny rule in a situation where
you legitimately need to open a wide range of ports, but there are certain ports within the
range that you want to deny. Just make sure to place the deny rule earlier in the table than the rule that allows the wide range of port
traffic.

You add allow rules depending on your use case. For
example, you can add a rule that allows outbound TCP and UDP access on port 53 for DNS
resolution. For every rule that you add, ensure that there is a corresponding inbound or
outbound rule that allows response traffic.

The following table shows the same example of a custom network ACL for a VPC that has an
associated IPv6 CIDR block. This network ACL includes rules for all IPv6 HTTP and HTTPS
traffic. In this case, new rules were inserted between the existing rules for IPv4 traffic.
You can also add the rules as higher number rules after the IPv4 rules. IPv4 and IPv6 traffic
are separate, and therefore none of the rules for the IPv4 traffic apply to the IPv6
traffic.

Inbound
Rule #
Type
Protocol
Port range
Source
Allow/Deny
Comments

100

HTTP

TCP

0.0.0.0/0

ALLOW

Allows inbound HTTP traffic from any IPv4 address.

105

HTTP

TCP

::/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

192.0.2.0/24

ALLOW

Allows inbound SSH traffic from your home network’s public IPv4 address range
(over the internet gateway).

130

RDP

TCP

3389

192.0.2.0/24

ALLOW

Allows inbound RDP traffic to the web servers 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 (that is, for requests that
originate in the subnet).

This range is an example only. For more information about how to select the
appropriate ephemeral port range, see Ephemeral ports.

145

Custom TCP
TCP
32768-65535
::/0
ALLOW

Allows inbound return IPv6 traffic from the internet (that is, for requests that
originate in the subnet).

This range is an example only. For more information about how to select the
appropriate ephemeral port range, see Ephemeral ports.

All traffic

All

0.0.0.0/0

DENY

Denies all inbound IPv4 traffic not already handled by a preceding rule (not
modifiable).

All traffic

All

::/0

DENY

Denies all inbound IPv6 traffic not already handled by a preceding rule (not
modifiable).

Outbound
Rule #
Type
Protocol
Port range
Destination
Allow/Deny
Comments

100

HTTP

TCP

0.0.0.0/0

ALLOW

Allows outbound IPv4 HTTP traffic from the subnet to the internet.

105

HTTP

TCP

::/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.

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 to people visiting the web servers in the subnet).

This range is an example only. For more information about how to select the
appropriate ephemeral port range, see Ephemeral ports.

145

Custom TCP

TCP

32768-65535

::/0

ALLOW

Allows outbound IPv6 responses to clients on the internet (for example, serving
webpages to people visiting the web servers in the subnet).

This range is an example only. For more information about how to select the
appropriate ephemeral port range, see Ephemeral ports.

All traffic

All

0.0.0.0/0

DENY

Denies all outbound IPv4 traffic not already handled by a preceding rule (not
modifiable).

All traffic

All

::/0

DENY

Denies all outbound IPv6 traffic not already handled by a preceding rule (not
modifiable).

For more examples, see Recommended rules for VPC scenarios.

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 Network ACLs for Load Balancers in a
VPC in the User Guide for Classic Load Balancers.

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 type of
instance (Amazon Linux, Windows Server 2008, and so on).

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.

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 in the
Amazon EC2 User Guide for Linux Instances.

Work with network ACLs

The following tasks show you how to work with network ACLs using the Amazon VPC console.

Determine network ACL associations

You can use the Amazon VPC console to determine the network ACL that’s associated with a
subnet. Network ACLs can be associated with more than one subnet, so you can also determine
which subnets are associated with a network ACL.

To determine which network ACL is associated with a subnet

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Subnets, and then select the
subnet.

The network ACL associated with the subnet is included in the Network
ACL tab, along with the network ACL’s rules.

To determine which subnets are associated with a network ACL

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs. The
Associated With column indicates the number of associated subnets
for each network ACL.
Select a network ACL.
In the details pane, choose Subnet Associations to display the
subnets that are associated with the network ACL.

Create a network ACL

You can create a custom network ACL for your VPC. By default, a network ACL that you
create blocks all inbound and outbound traffic until you add rules, and is not associated
with a subnet until you explicitly associate it with one.

To create a network ACL

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs.
Choose Create Network ACL.
In the Create Network ACL dialog box, optionally name your
network ACL, and select the ID of your VPC from the VPC list. Then
choose Yes, Create.

Add and delete rules

When you add or delete a rule from an ACL, any subnets that are associated with the ACL
are subject to the change. You don’t have to terminate and relaunch the instances in the
subnet. The changes take effect after a short period.

Important

Be very careful if you are adding and deleting rules at the same time. Network ACL rules define which
types of network traffic can enter or exit your VPCs. If you delete inbound or outbound
rules and then add more new entries than are allowed in Amazon VPC quotas, the entries selected for deletion will be removed
and new entries will not be added. This could cause unexpected connectivity issues and
unintentionally prevent access to and from your VPCs.

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

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs.
In the details pane, choose either the Inbound Rules or
Outbound Rules tab, depending on the type of rule that you need
to add, and then choose Edit.
In Rule #, enter a rule number (for example, 100). The rule
number must not already be in use in the network ACL. We process the rules in order,
starting 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.
Select a rule from the Type list. For example, to add a rule
for HTTP, choose HTTP. To add a rule to allow all TCP traffic,
choose All TCP. For some of these options (for example, HTTP), we
fill in the port for you. To use a protocol that’s not listed, choose Custom
Protocol Rule.
(Optional) If you’re creating a custom protocol rule, select the protocol’s
number and name from the Protocol list. For more
information, see IANA
List of Protocol Numbers.
(Optional) If the protocol you selected requires a port number, enter the port
number or port range separated by a hyphen (for example, 49152-65535).
In the Source or Destination field
(depending on whether this is an inbound or outbound rule), enter the CIDR range that
the rule applies to.
From the Allow/Deny list, select ALLOW to
allow the specified traffic or DENY to deny the specified
traffic.
(Optional) To add another rule, choose Add another rule, and
repeat steps 4 to 9 as required.
When you are done, choose Save.

To delete a rule from a network ACL

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs, and then select
the network ACL.
In the details pane, select either the Inbound Rules or
Outbound Rules tab, and then choose Edit.
Choose Remove for the rule you want to delete, and then choose
Save.

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

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs, and then select
the network ACL.
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.

Disassociate a network ACL from a subnet

You can disassociate a custom network ACL from a subnet. When the subnet has been
disassociated from the custom network ACL, it is then automatically associated with the
default network ACL.

To disassociate a subnet from a network ACL

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs, and then select
the network ACL.
In the details pane, choose the Subnet Associations tab.
Choose Edit, and then deselect the
Associate check box for the subnet. Choose
Save.

Change a subnet’s network ACL

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. You might want to
instead associate it with a custom network ACL that you’ve created.

After changing a subnet’s network ACL, you don’t have to terminate and relaunch the
instances in the subnet. The changes take effect after a short period.

To change a subnet’s network ACL association

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Subnets, and then select the
subnet.
Choose the Network ACL tab, and then choose
Edit.
From the Change to list, select the network ACL to associate
the subnet with, and then choose Save.

Delete a network ACL

You can delete a network ACL only if there are no subnets associated with it. You can’t
delete the default network ACL.

To delete a network ACL

Open the Amazon VPC console at
https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Network ACLs.
Select the network ACL, and then choose Delete.
In the confirmation dialog box, choose Yes, Delete.

API and command overview

You can perform the tasks described on this page using the command line or an API.
For more information about the command line interfaces and a list of available APIs,
see Working with Amazon VPC.

Create a network ACL for your VPC

create-network-acl (AWS CLI)
New-EC2NetworkAcl (AWS Tools for Windows PowerShell)

Describe one or more of your network ACLs

describe-network-acls (AWS CLI)
Get-EC2NetworkAcl (AWS Tools for Windows PowerShell)

Add a rule to a network ACL

create-network-acl-entry (AWS CLI)
New-EC2NetworkAclEntry (AWS Tools for Windows PowerShell)

Delete a rule from a network ACL

delete-network-acl-entry (AWS CLI)
Remove-EC2NetworkAclEntry (AWS Tools for Windows PowerShell)

Replace an existing rule in a network ACL

replace-network-acl-entry (AWS CLI)
Set-EC2NetworkAclEntry (AWS Tools for Windows PowerShell)

Replace a network ACL association

replace-network-acl-association (AWS CLI)
Set-EC2NetworkAclAssociation (AWS Tools for Windows PowerShell)

Delete a network ACL

delete-network-acl (AWS CLI)
Remove-EC2NetworkAcl (AWS Tools for Windows PowerShell)

Example: Control access to instances in a subnet

In this example, instances in your subnet can communicate with each other, and are
accessible from a trusted remote computer. The remote computer might be a computer in your
local network or an instance in a different subnet or VPC. You use it to connect to your
instances to perform administrative tasks. Your security group rules and network ACL rules
allow access from the IP address of your remote computer (172.31.1.2/32). All other traffic
from the internet or other networks is denied. This scenario gives you the flexibility to
change the security groups or security group rules for your instances, and have the network
ACL as the backup layer of defense.

Using a security group and an NACL

The following is an example security group to associate with the instances. Security groups are stateful.
Therefore you don’t need a rule that allows responses to inbound traffic.

Inbound
Protocol Type
Protocol
Port range
Source
Comments

All traffic
All
All
sg-1234567890abcdef0
All instances associated with this security group can communicate with each other.

SSH
TCP
22
172.31.1.2/32
Allows inbound SSH access from the remote computer.

Outbound
Protocol Type
Protocol
Port range
Destination
Comments

All traffic
All
All
sg-1234567890abcdef0
All instances associated with this security group can communicate with each other.

The following is an example network ACL to associate with the subnets for the instances.
The network ACL rules apply to all instances in the subnet. Network ACLs are stateless. Therefore,
you need a rule that allows responses to inbound traffic.

Inbound
Rule #
Type
Protocol
Port range
Source
Allow/Deny
Comments

100
SSH
TCP
22
172.31.1.2/32
ALLOW
Allows inbound traffic from the remote computer.

*
All traffic
All
All
0.0.0.0/0
DENY
Denies all other inbound traffic.

Outbound
Rule #
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.

*
All traffic
All
All
0.0.0.0/0
DENY
Denies all other outbound traffic.

If you accidentally make your security group rules too permissive, the network ACL in this
example continues to permit access only from the specified IP address. For example, the following
security group contains a rule that allow inbound SSH access from any IP address. However, if you
associate this security group with an instance in a subnet that uses the network ACL, only other
instances within the subnet and your remote computer can access the instance, because the network
ACL rules deny other inbound traffic to the subnet.

Inbound
Type
Protocol
Port range
Source
Comments

All traffic
All
All
sg-1234567890abcdef0
All instances associated with this security group can communicate with each other.

SSH
TCP
22
0.0.0.0/0
Allows SSH access from any IP address.

Outbound
Type
Protocol
Port range
Destination
Comments

All traffic
All
All
0.0.0.0/0
Allows all outbound traffic.

Recommended rules for VPC scenarios

You can follow the processes in Scenarios to implement common scenarios for
Amazon VPC. Each scenario in that section includes recommended network ACL rules. If you implement these scenarios as described in the documentation, you use the default
network access control list (ACL) which allows all inbound and outbound traffic. If you need
an additional layer of security, you can create a network ACL and add rules.