安全组负责实例级别的虚拟防火墙管控，网络访问控制列表（NACL）负责子网级别的进出站流量管控，两者一个有状态、一个无状态，是云上网络安全的两道不同防线。
安全组和网络ACL各管什么职责边界先说清
很多人第一次接触云环境时,会把安全组和网络ACL搞混，因为它们的名字都带“安全”二字，界面里又都是配规则，但搞清楚它们各自负责什么，是设计云上网络架构的第一课。
安全组的管控对象：实例自身的出入站规则
安全组是挂在弹性网卡或云服务器实例上的虚拟防火墙,它管控的是一条流量的“最后一公里”流量到达实例之前，或者从实例发出之后，先过安全组这一关。
它的核心逻辑是：
- 实例级防护：每一台云服务器至少属于一个安全组，规则直接作用于该实例的弹性网卡
- 默认拒绝：安全组规则只允许特定流量通过，未显式放行的流量全部丢弃
- 有状态特性：如果一条出站请求被允许，那么对应的回包流量无论入站规则如何都会被自动放行
- 规则合并生效：一个实例可以挂多个安全组，多个安全组规则按叠加逻辑生效，先匹配先放行
安全组适合管控的典型场景包括：只允许特定IP访问服务器的22端口、只允许应用层通过特定端口互相通信、限制数据库实例只允许来自应用服务器安全组的访问。
网络ACL的管控边界：子网的全盘过滤
网络访问控制列表（NACL）则是对整个子网边界进行流量管控的“大门”，它不关心子网里具体是哪台实例，只根据流量进出子网的方向做判断。
它的核心逻辑是：
- 子网级防护：一个子网必须关联一个NACL，同一个NACL可以复用于多个子网
- 无状态特性：入站和出站规则完全独立，允许入站不等同于允许回包，需要分别配置
- 有序优先级：规则按编号从小到大依序匹配，命中一条规则后立即结束判断
- 默认全放行：AWS等主流云平台默认创建的NACL放行所有流量，自定义NACL初始则全部拒绝
网络ACL适合管控的典型场景：整体拦截某个攻击源IP段的所有访问、统一限制子网对外访问的公网端口、在子网层面对入站流量做粗粒度的地区或运营商维度过滤。
安全组和网络ACL有什么区别从有状态与无状态说起
两者最本质的分水岭就是状态性,行业共识认为，大部分配置失误和故障排查难题，都源于对这两个特性的理解偏差。
有状态与无状态的判断差异
安全组是有状态的,比如你在安全组里只配置了出站允许访问外部网络的HTTPS（端口443），没有配置任何入站规则，那么当外部网站的响应数据返回时，安全组会自动识别这是之前出站请求的回包，予以放行，这极大简化了配置量，因为不需要为每一次出站通信反向添加入站规则。
网络ACL是无状态的,假设你在子网的出站规则里允许了访问外网443端口，那么这个请求的响应流量进入子网时，需要在入站规则里单独放行，通常做法是入站规则里放行源端口443的高位临时端口段，否则请求发得出去，回包进不来，表现为“网络通但页面打不开”。
这套差异在排查问题时非常关键,安全组规则条数少但类型灵活，网络ACL规则条数多但逻辑直观，二者搭配使用时，流量必须同时通过两道关卡才能实际到达目标实例。
规则冲突时谁说了算
当安全组和网络ACL同时配置了规则时,只要其中任何一层拒绝了流量，最终结果就是拒绝，也就是说，规则交集生效必须两者都允许，请求才能通过。
业内专家指出,这在实际运维中常造成一种“隐身丢包”的困扰：实例的安全组已经放行了来源IP，但子网的网络ACL没有放行，流量在进入子网时就被丢弃，实例侧面看不到任何安全组拦截记录，排查时很容易陷入死角。
补充对比：从设计目标看两者分工
| 维度 | 安全组 | 网络访问控制列表 |
|---|---|---|
| 作用层级 | 实例/弹性网卡 | 子网 |
| 状态性 | 有状态 | 无状态 |
| 默认策略 | 默认拒绝 | 默认放行或全拒（取决于创建方式） |
| 规则优先级 | 规则合并，无先后编号 | 编号从小到大依次匹配 |
| 适用场景 | 精细访问控制、应用间通信 | 子网整体防护、批量封禁IP段 |
安全组与网络ACL怎么选择按场景对号入座
选型不是二选一,而是组合搭配设计，最理想的做法是用网络ACL做粗粒度的边界管控，用安全组做细粒度的实例防护，但在不同场景下，侧重点有明确差异。
高安全等级场景：双层都要配
对数据库、核心业务服务这类资产，建议两层都启用规则限制，网络ACL在子网层级先拦截掉不信任的IP段，安全组在实例层级再做端口精准管控，即使有一层规则配置失误，另一层也能兜底拦截。
经典三层架构场景：分层管控可显著简化规则维护
Web层、应用层、数据库层分别放在不同子网时，可以在各子网的网络ACL上限制相邻层的访问端口，在安全组上限制具体的服务器实例，比如数据库子网的网络ACL只放行应用层子网网段的3306端口，数据库实例的安全组再进一步只放行应用服务器安全组ID，这样即便新增一台应用服务器，也无需修改数据库安全组规则。
成本敏感型场景：安全组优先
个人开发环境、测试环境或流量较小的生产环境，可以只用安全组完成全部管控，因为安全组有状态，配置量更小，逻辑更简单，无需额外维护入站出站两条规则链，AWS免费层内的所有实例都可以使用安全组，不产生额外费用。
安全组与网络ACL的规则配置实操指南
具体操作时,两者的配置入口和规则字段有相似之处，但细节差异会影响最终效果。
安全组规则配置步骤
- 登录云控制台,进入VPC服务下的“安全组”页面
- 点击创建安全组,选择所属VPC
- 添加入站规则：填写类型（如SSH、HTTP、自定义TCP）、来源（可以是IP地址、CIDR网段或其他安全组ID）、端口范围
- 添加出站规则：填写目的地和端口，默认情况可放行全部出站流量
- 将安全组关联到目标实例（在实例详情页的网络设置中选择）
需要注意：修改安全组规则是即时生效的，不需要重启实例，出站规则与入站规则是独立的两张表，修改其中一张不影响另一张。
网络ACL规则配置步骤
- 进入VPC控制台的“网络ACL”页面，创建新的ACL
- 在入站规则中按编号从小到大填写规则,编号数字越小优先级越高
- 每条规则需要指定协议、端口范围、源IP或CIDR，以及允许/拒绝动作
- 在出站规则中同样配置对应方向的规则
- 将ACL关联到需要管控的子网
配置网络ACL时建议留出规则间隔（比如每隔10或20编号），方便后续插入新规则时无需重建整张表。
典型故障排查路径
当业务流量异常时,按以下步骤定位是安全组还是网络ACL的问题：
- 在实例上用
curl或telnet测试目标端口连接，确认从实例内部能否访问 - 检查实例安全组的入站规则,确认来源IP是否在放行范围内
- 检查子网关联的NACL规则,确认入站和出站都有对应放行条目
- 特别注意NACL的无状态特性,检查回包方向规则是否存在
- 用云平台提供的流量日志功能分析被拒流量的方向,判断是哪一层阻断
很多情况下,安全组和网络ACL表现出的症状是相同的，但日志记录的位置不同，从子网边界到实例网卡，逐层向下排查是最可靠的思路。
云上安全的最终兜底建议
安全组和网络访问控制列表不是竞争关系,而是协同防御体系中的两个环，安全组适合做精细的实例级控制，网络ACL适合做粗粒度的子网边界防护，一个成熟的生产环境，应当是“外松内紧”还是“外紧内松”，取决于业务的可达性要求，但有一点是确定的不配置网络ACL的子网，相当于把大门口完全敞开；不配置安全组的实例，相当于把房间门完全敞开，两者不是二选一，而是都该配好。
安全组和网络ACL有什么区别常见问题解答
Q：安全组和网络ACL可以只配其中一个吗？
可以，云平台默认允许只用安全组进行管控，这也是大多数中小型项目的默认形态，但子网未关联自定义ACL时，默认ACL会放行所有流量，此时子网边界毫无拦截能力，全部依赖实例自身的安全组规则，若安全组规则存在遗漏，流量将直接触达实例。
Q：修改安全组或网络ACL规则后，对已建立的连接有什么影响？
安全组规则变更会立即作用于所有新建连接，已建立的存量连接在AWS上通常不受影响（因为被识别为已建立的会话），但网络ACL的规则修改对所有流量即时生效，包括存量连接，且无状态特性决定了回包方向的规则也必须允许，否则现有连接会被直接掐断。