网络ACL（Access Control List）是在虚拟交换机上生效的规则，对经交换机跨子网的流量进行访问控制，与安全组结合使用可以达到纵深防御的效果。
安全风险
安全组是实例维度的（确切说是网卡维度），规定实例应该允许/禁止什么网络访问行为，考虑实例本身的业务属性和安全需求。网络ACL是子网维度的，规定跨子网通信应该允许/禁止什么网络访问行为，考虑子网的业务属性和安全需求。安全组实现了灵活的、细粒度的网络访问控制能力，结合网络ACL可以做有益补充。通过网络ACL规则叠加防护，可以避免实例忘记加入安全组或安全组规则误配置带来的网络风险。
流量进入VPC网络会先到达交换机，网络ACL相较于安全组、云防火墙会更加前置，入方向流量先用网络ACL过滤掉非法流量，有助于节省后面的处理资源。对于出公网流量先到达交换机再到公网出口，出方向流量先用网络ACL过滤掉不必要流量，有助于节省公网出口带宽。
最佳实践：使用网络ACL对安全组规则做补充
背景和挑战
在云计算环境中，我们常常会遇到需要打通多个VPC（Virtual Private Cloud）的场景，以实现业务的互联互通。例如，我们有两个独立的VPC：
VPC1 (10.200.0.0/16): 部署了需要访问VPC2资源的应用。
VPC2 (10.1.0.0/16): 承载了多种业务实例，网络环境复杂。
初期，VPC2为了开发的便利性和业务的快速上线，其内部的安全组规则配置较为宽松，存在一些安全隐患。例如，部分安全组对整个10.0.0.0/8网段开放了端口，甚至一些仅用于内部访问的ECS实例也配置了对所有来源 (0.0.0.0/0) 开放的规则。
当通过VPC对等连接（VPC Peering Connection）将VPC1和VPC2打通，旨在让VPC1中的服务能访问VPC2内10.1.38.0/24集群的80端口时，这些潜在的安全风险便会暴露出来。仅仅为目标集群（10.1.38.0/24）配置精确的安全组规则是远远不够的。因为对等连接实际上是将VPC1的10.200.0.0/16网段和VPC2的10.1.0.0/16网段部分或全部互联，VPC2中其他配置不当的实例和服务，也可能因此意外地暴露给VPC1，造成安全漏洞。
解决方案：使用网络ACL加固边界安全
为了解决上述问题，并建立一个清晰、可靠的安全边界，我们可以在VPC2负责与VPC1对接的交换机上配置网络ACL。网络ACL作为一种无状态的包过滤工具，作用于子网级别，能够在流量进入或离开子网时进行过滤，可以将其理解为VPC子网的“防火墙”。通过它，我们可以实现比安全组更宏观、更前置的安全控制。
具体的配置策略如下：
默认拒绝: 首先，在网络ACL中设置一条默认规则，拒绝所有来自VPC1网段 (10.200.0.0/16) 的入站流量，以及所有去往VPC1的出站流量。这建立了一个安全的基线，确保在没有明确许可的情况下，两个VPC之间无法通信。
精确允许: 然后，再添加更高优先级的规则，明确允许VPC1 (10.200.0.0/16) 与VPC2中目标集群 (10.1.38.0/24) 之间通过80端口进行双向通信。
入站规则: 允许源地址为10.200.0.0/16，目标地址为10.1.38.0/24，协议为TCP，端口为80的流量进入。
出站规则: 允许源地址为10.1.38.0/24，目标地址为10.200.0.0/16，协议为TCP，使用临时端口范围的流量出去（响应流量）。
通过这种方式，交换机会首先通过网络ACL过滤掉所有非法的访问请求，只有被明确允许的合法流量才会被转发到子网内的ECS实例。这样，即便某些ECS实例自身绑定的安全组规则存在缺陷，也不会暴露给VPC1，从而极大地提升了跨VPC通信的安全性。