安全组与网络ACL是分层协作关系：ACL管子网级流量进出，安全组管实例级通信控制；ACL作无状态“大闸”限制子网间访问，安全组作有状态“门禁”细化实例间授权，二者协同实现纵深防御。
安全组和网络 ACL 不是互斥工具，而是分层协作的关系：安全组管“实例能不能通”，网络 ACL 管“子网能不能过”。要真正做好公网与私网隔离，关键在于把两者用在各自最擅长的位置，形成纵深防御。
明确分工：谁管边界，谁管实例
公网与私网的隔离，本质是控制流量跨域流动。网络 ACL 天然适合做第一道防线——它绑定在子网（交换机）上，能直接阻断整个子网对外网的访问，或限制私网子网之间互通。比如：
- 将面向公网的 Web 层子网，通过网络 ACL 显式拒绝所有非 80/443 的入站流量，并禁止出站到敏感私有网段（如数据库子网）
- 将数据库子网的网络 ACL 入方向设为仅允许应用子网 CIDR，出方向默认拒绝，彻底切断其主动外连能力
- 对完全不需公网访问的后台服务子网，网络 ACL 出方向直接拒绝 0.0.0.0/0，从源头封死外发可能
安全组补位：细化实例级通信策略
网络 ACL 是无状态、粗粒度的，它不识别连接上下文；而安全组是有状态的，能自动放行响应包。因此，在网络 ACL 已划清子网边界的前提下，安全组应聚焦于实例间的精确授权：
- Web 服务器安全组：只开放 80/443 入站（来源为 0.0.0.0/0），出站允许访问应用子网某端口
- 应用服务器安全组：入站只允许 Web 子网和负载均衡器 IP，出站只允许数据库子网指定端口
- 数据库服务器安全组：入站严格限定为应用子网 IP + 端口，禁用 ICMP、SSH 等管理协议外的全部入站
这样即使某台实例被攻陷，攻击者也无法绕过安全组规则横向移动到同子网其他实例。
协同避坑：注意无状态与有状态的配合逻辑
网络 ACL 无状态，意味着你必须双向显式放行。例如，若允许应用子网访问数据库子网的 3306 端口，不仅要配置数据库子网 ACL 的入方向规则（源=应用子网，目的端口=3306），还要配置其出方向规则（目的=应用子网，源端口=3306），否则响应包会被丢弃。
而安全组无需配返回规则——它自动放行响应。所以实际部署中建议：
- 网络 ACL 做“大闸”：只放通必要子网间通信，其余全拒；规则条目尽量少，优先级清晰
- 安全组做“门禁”：在已允许的通信路径内，再按实例角色细粒度控制端口和源IP
- 避免重复放行：比如网络 ACL 已允许 Web→App，安全组就不要再开放 Web→0.0.0.0/0，否则削弱隔离效果
实战建议：从默认拒绝起步
新建网络 ACL 时，不要依赖默认规则。立即添加两条兜底规则：
- 入方向最后一条：拒绝所有源地址，协议任意，端口任意
- 出方向最后一条：拒绝所有目的地址，协议任意，端口任意
然后在前面插入白名单规则。安全组同样建议关闭默认出站放行，改为按需开通——尤其对数据库、缓存等高敏实例，出站只允许业务必需的目标和端口。这种“默认拒绝+显式授权”模式，才是公网与私网真正隔离的落地基础。
