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.

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.

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.

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