Do network acls block inter-subnet traffic as well?

I have VMs placed in different AZs on AWS. In order to be able to do this, you need a subnet in each AZ.

If I'm creating a network acl for the entire setup (ie to be associated with all subnets) do I need to specify allow rules from all the subnet CIDR ranges? If I don't, will the network acl block inter-subnet traffic based on my port rules?

I'm assuming they will...but want confirmation.

I believe the answer from Ron is correct, but does not answer your question.

If you have instances in multiple subnets and your instances need to communicate your NACLs need to account for this with allow rules. I haven't tested this, but I've worked with AWS a long time and I'm fairly sure this is the way it works.

Interestingly, security groups are a firewall that can be thought of as around each network interface. So if you want instances in a security group to communicate you need a rule to allow ingress from the security group to itself.

Answers to comments in questions:

Ports You only need to open ports 80 / 443 on your web server security group. The 1024 - 65535 part is ephemeral ports, which you should read up on if you want to understand them. Start with Wikipedia but then move on to something easier to understand if you need to.

AWS Inspector This page says the following

The Amazon Inspector agent initiates all communication with the Amazon Inspector service. This means that the agent must have an outbound network path to public endpoints so that it can send telemetry data. For example, the agent might connect to arsenal..amazonaws.com, or the endpoint might be an Amazon S3 bucket at s3.dualstack..amazonaws.com. Make sure to replace with the actual AWS Region where you are running Amazon Inspector. For more information, see AWS IP Address Ranges. Because all connections from the agent are established outbound, it is not necessary to open ports in your security groups to allow inbound communications to the agent from Amazon Inspector.

In general, it is recommended that you leave Network ACLs at their default "Allow All" settings and instead use Security Groups for network security.

A NACL represents a traditional router that sites between subnets, controlling what traffic goes in/out of the subnet. NACL rules are stateless, meaning that they need to be defined in both directions. NACLs only apply to traffic going between subnets.

Security Groups are a new innovation in cloud computing. They are a firewall on each individual resource in the VPC (more accurately, on each Elastic Network Interface). This allows much more fine-grained security control. Rules are stateful, meaning that that requests sent out will automatically allow a response to come in.

Security Groups can also reference each other. For example, consider an Amazon EC2 instance and an Amazon RDS database. A security group can be placed on the EC2 instance allowing incoming web traffic. A security group can be placed on the RDS instance allowing incoming SQL queries only from the security group associated with the EC2 instance. This is much more precise than NACL rules.

The bottom line is:

• Always use Inbound Security Groups to secure resources
• Optionally limit Outbound Security Groups (since you can typically trust apps running on an instance)
• Never change NACL rules unless you have a very specific security need, such as creating a DMZ