AWS企业资质代办 AWS Security Group 与 Network ACL 的区别与应用：如何选择、配置与排错实战指南
用户搜索“AWS Security Group 与 Network ACL 的区别与应用”时，真正想解决的通常不是定义问题，而是部署过程中几个直接影响业务上线的决策：EC2 对外开放 80/443 端口时规则该加在哪一层；数据库放在私网后，应用连接不上到底是安全组还是子网 ACL 拦截；多台服务器位于同一个 VPC 时，如何既允许内部通信又避免端口暴露过多；为什么控制台里看起来都已经放行，但 SSH、RDP、MySQL 仍然连不上。
这篇文章直接围绕这些操作问题展开，不做泛泛解释，而是从 AWS 控制台配置、参数填写、规则设计、故障排查和业务场景选择几个角度，帮助你快速判断：哪些场景只改 Security Group 就够了，哪些场景必须配合 Network ACL，哪些情况下两者同时存在会导致误判。
先回答决策问题：到底选 Security Group 还是 Network ACL
如果你正在创建 EC2、RDS、ALB，绝大多数访问控制先从 Security Group 入手。它更适合实例级、服务级授权，例如只允许办公 IP 访问 Linux 的 22 端口，只允许 ALB 访问 Web 实例的 80 端口，只允许应用服务器访问 MySQL 3306。
如果你要做的是子网级统一限制，例如某个私有子网禁止某些来源网段、临时封禁异常流量来源、对整个子网设置粗粒度进出规则，这时才需要 Network ACL。它更适合“整段子网”的统一入口规则，而不是单台实例的精细授权。
| 实际需求 | 优先选择 | 原因 |
| 开放 EC2 的 22/80/443 | Security Group | 直接绑定实例，变更影响范围可控 |
| 只允许 ALB 访问应用服务器 | Security Group | 可直接按安全组引用授权 |
| 限制整个子网的出入站网段 | Network ACL | 规则作用于子网边界 |
| 临时阻断某批可疑公网来源 | Network ACL | 可快速在子网层拒绝 |
| 数据库只允许应用层访问 | Security Group | 按来源安全组授权更准确 |
| 已经放行端口但仍不通，需要排查网络层 | 两者都检查 | 常见问题是安全组放行但 NACL 拒绝返回流量 |
简化判断方法很实用：如果你在想“哪台实例能访问谁”，先看 Security Group；如果你在想“这个子网整体允许什么流量”，再看 Network ACL。
上线前准备：避免一开始就配错位置
在 AWS 控制台开始配置前，先确认以下前提，否则后续排错会浪费很多时间。
所需账号与权限
- 需要具有 VPC、EC2、Security Groups、Network ACLs 的查看和修改权限。
- 如果涉及 RDS，还需要具备 RDS 实例和 DB Subnet Group 的查看权限。
- 建议至少允许查看 Route Table、Internet Gateway、NAT Gateway，否则会误把路由问题当成安全组问题。
所需资源
- 一个已创建的 VPC。
- AWS企业资质代办 至少两个子网，推荐区分公有子网和私有子网。
- 一台测试 EC2，Linux 或 Windows 均可。
- 若验证数据库访问，准备一台 RDS MySQL 或自建 MySQL 实例。
- 一台本地终端，便于用 SSH、RDP、telnet、nc、curl 测试连通性。
前置检查项
| 检查项 | 如何确认 | 常见误区 |
| 实例是否有公网 IP | EC2 实例详情页查看 Public IPv4 | 没有公网 IP 却尝试从公网直接 SSH |
| 子网路由是否可出公网 | 检查 Route Table 是否有 0.0.0.0/0 指向 IGW 或 NAT | 把路由缺失误认为是安全组拦截 |
| 操作系统防火墙 | Linux 看 firewalld/iptables，Windows 看 Defender Firewall | AWS 已放行，但系统内仍然拦截 |
| 目标服务是否监听端口 | ss -lntp 或 netstat -ano | 端口未监听却反复修改安全组 |
实战一：用 Security Group 完成常见访问控制
下面用三个最常见场景说明如何在控制台中配置，并说明参数怎么填更稳妥。
场景 1：允许公网访问 Web 服务器
适用情况：你有一台 EC2 作为网站服务器，需要开放 80 和 443，同时限制 SSH 只允许办公 IP 登录。
操作路径：AWS 控制台 → EC2 → Security Groups → Create security group。
| 参数 | 示例填写 | 说明 |
| Security group name | sg-web-prod | 按环境命名，便于后续引用 |
| Description | web server for production | 写清用途，不要只写 test |
| VPC | 选择业务所在 VPC | 必须与实例同一 VPC |
入站规则建议如下：
| 类型 | 协议 | 端口 | 来源 | 用途 |
| HTTP | TCP | 80 | 0.0.0.0/0 | 网站访问 |
| HTTPS | TCP | 443 | 0.0.0.0/0 | HTTPS 访问 |
| SSH | TCP | 22 | 你的办公公网 IP/32 | 运维登录 |
注意事项：
- 不要把 22 端口直接开放给 0.0.0.0/0，除非是临时测试且已设置密钥和额外限制。
- 如果公网来源 IP 会变化，优先使用 VPN、堡垒机或 AWS Systems Manager Session Manager，而不是频繁改规则。
- 绑定安全组后，若仍无法访问，立刻检查实例所在子网是否关联了过严的 Network ACL。
场景 2：应用服务器访问数据库，不向公网开放 MySQL
这是 Security Group 最典型的正确用法。不要在数据库安全组里写来源 0.0.0.0/0，也不要按整个 VPC 网段粗放授权，直接引用应用服务器安全组最稳妥。
操作步骤：
- 创建应用服务器安全组 sg-app。
- 创建数据库安全组 sg-db。
- 在 sg-db 的入站规则中，添加 MySQL/Aurora，端口 3306，来源选择 sg-app。
- 将 sg-app 绑定到应用 EC2，将 sg-db 绑定到 RDS 或数据库 EC2。
这样配置后的好处是：以后应用服务器扩容，只要新实例继续绑定 sg-app，就能自动访问数据库，不需要每加一台实例就手工写一次 IP。
场景 3：只允许 ALB 转发到后端 EC2
这是很多用户配置错误最多的地方。正确方式不是在应用实例上对公网开放 80/443，而是只允许来自 ALB 安全组的访问。
| 组件 | 安全组配置 |
| ALB 安全组 sg-alb | 入站开放 80/443 给 0.0.0.0/0；出站允许到 sg-app 的 80 或 8080 |
| 应用实例安全组 sg-app | 入站只允许来源 sg-alb 的 80 或 8080；SSH 仅办公 IP |
这样即使用户知道应用实例公网 IP，也无法直接访问业务端口，只能通过负载均衡入口进入。
AWS企业资质代办 实战二：什么时候必须配置 Network ACL
如果你的目标是“给单台 EC2 放行端口”，不建议先碰 NACL。但以下几类场景，用 NACL 会更直接。
场景 1：对子网做统一阻断
AWS企业资质代办 例如某公有子网中有多台临时测试机，你希望整个子网不再允许某个可疑来源网段访问，可以在该子网关联的 Network ACL 中增加拒绝规则。
操作路径：VPC 控制台 → Network ACLs → 选择目标 NACL → Inbound rules / Outbound rules。
示例：拒绝来源 203.0.113.0/24 访问 22 端口。
| Rule # | Type | Protocol | Port Range | Source | Allow/Deny |
| 100 | SSH | TCP | 22 | 203.0.113.0/24 | Deny |
| 200 | ALL TCP | TCP | 0-65535 | 0.0.0.0/0 | Allow |
注意规则编号顺序，编号越小优先级越高。很多用户添加了 Deny，却把更宽泛的 Allow 放在前面，结果拒绝规则根本不生效。
场景 2：私有子网仅允许特定出站流量
如果你希望私有子网中的应用服务器只能访问 NAT、数据库或特定内部网段，可以通过 NACL 限制出站范围，避免测试机随意访问外部资源。
常见做法：
- 入站允许来自 VPC 内部网段的必要端口。
- 出站只允许到数据库子网、NAT 网关目标方向所需端口。
- AWS企业资质代办 为返回流量预留临时端口范围，避免连接建立后回包被拦截。
AWS企业资质代办 实际操作中最容易出错的是只写了目标服务端口，没有考虑客户端临时端口回流。结果表现为“能发起连接，但很快超时”。
场景 3：安全审计要求按子网分层隔离
一些企业会把 Web、App、DB 放在不同子网，并要求各层之间除必要端口外全部阻断。这时可以用 Security Group 负责精确授权，用 NACL 作为兜底限制。例如数据库子网的 NACL 只放行来自应用子网的 3306 和必要回包范围，其余全部拒绝。
一套可直接落地的组合方案
如果你正在做标准三层架构部署，推荐按下面方式组合，而不是只依赖其中一种。
| 层级 | 建议 | 原因 |
| 公网入口层 | ALB 用 Security Group 控制 80/443 | 便于业务端口管理 |
| 应用层 | EC2 安全组只允许 ALB 或堡垒机来源 | 防止绕过入口直连实例 |
| 数据库层 | RDS/DB 安全组仅允许应用层安全组访问 | 避免数据库暴露给整个 VPC 或公网 |
| 子网边界层 | Network ACL 做粗粒度限制和异常流量阻断 | 便于整段子网统一控制 |
这套组合的核心思路是：日常授权优先改 Security Group，NACL 保持简洁，只做少量明确限制。不要把大量细粒度业务规则堆到 NACL，否则后续排查非常困难。
不同用户场景下怎么配更合适
个人开发者
建议尽量少动 NACL，优先使用默认允许型 NACL，把控制重点放在 Security Group。常见方案是一台 Web 服务器开放 80/443，22 端口只对自己当前公网 IP 开放。这样配置简单，排查成本低。
企业用户
建议按环境拆分安全组，例如 sg-web-prod、sg-app-prod、sg-db-prod，不要多个系统共用一个“大而全”的安全组。NACL 只用于环境级隔离或审计要求，不要替代安全组做细粒度授权。
跨境业务
优先确认地域和可用区后再谈访问控制。很多跨境访问慢或连不上，不是安全组问题，而是源站区域延迟高、运营商链路抖动或中间防火墙限制。安全组上建议精确允许 HTTPS，结合 CloudFront 或加速入口，减少源站直接暴露。
网站应用
典型推荐是 ALB + Auto Scaling EC2 + RDS。ALB 安全组对公网开放，EC2 只允许来自 ALB 安全组，RDS 只允许来自应用安全组。NACL 保持简洁，避免误伤扩缩容后的实例通信。
数据库业务
数据库如果经常迁移、扩容或切换实例，强烈建议使用安全组引用，而不是依赖固定 IP 白名单。这样在数据库迁移、应用扩容时不会频繁改访问规则。
为什么规则都放行了还是连接失败：排错顺序
下面这个顺序最省时间，建议按层检查。
步骤 1：确认流量路径
你要先确定访问路径是公网直连、VPN、专线、VPC Peering、Transit Gateway，还是通过 ALB/NLB。路径不同，检查点不同。很多用户明明通过 ALB 访问，却一直去改实例公网规则。
步骤 2：检查 Security Group 是否绑对对象
最常见错误不是规则写错，而是安全组挂错实例、挂错 ENI、挂错 RDS。
步骤 3：检查 NACL 是否拦截回包
特别是 SSH、RDP、MySQL 建连后超时的情况，要重点核对子网 ACL 的出入站临时端口范围是否允许。若配置过于严格，建议临时放宽验证。
步骤 4：检查路由
无公网 IP 的私有实例不能直接从互联网访问；公有子网如果路由表没有指向 Internet Gateway，安全组再宽松也没用。
步骤 5：检查系统防火墙和服务监听
Linux 可执行以下命令：
AWS企业资质代办 ss -lntp
sudo firewall-cmd --list-ports
sudo iptables -S
Windows 可检查：
netstat -ano
Get-NetFirewallRule
如果服务根本没监听 0.0.0.0:3306 或 0.0.0.0:80，AWS 侧放行没有意义。
高频错误案例
错误 1：数据库安全组开放给整个 VPC 网段
表面上连接方便，实际上会让同 VPC 内无关实例也能探测数据库端口。更好的做法是仅允许应用安全组。
错误 2：把所有控制都写在 NACL
结果是新增一台实例、修改一个端口都要同时改多条规则，且容易因为编号顺序导致策略失效。
错误 3：忘记出站规则
很多用户只关心入站，但某些场景下出站也会影响业务，例如实例访问外部 API、yum/apt 更新、发送邮件、下载补丁。
错误 4：RDP 或 SSH 来源 IP 写错
本地宽带、公司出口或 VPN 切换后公网 IP 变化，原先 /32 白名单失效，表现为突然无法远程连接。
优化建议：不仅要能通，还要便于长期维护
AWS企业资质代办 安全优化
- 优先使用安全组引用，不要长期依赖大网段开放。
- 生产环境区分 Web、App、DB、Bastion 的安全组，不要混用。
- 对 22、3389 端口设置更严格来源限制，或改用 Session Manager。
- 对子网 NACL 只保留必要规则，避免复杂度过高。
性能优化
- 不要把访问慢误判成访问不通。先用 curl、nc、telnet 区分连接失败和响应慢。
- 跨可用区、跨区域访问数据库时，先测延迟再决定是否需要调整部署位置。
- 对高并发网站，尽量通过 ALB 统一入口，减少实例直接暴露。
成本优化
- 用安全组分层授权，避免为简单隔离额外引入不必要的网络设备。
- 减少因为误配导致的反复迁移、重建实例和停机排查成本。
- 测试环境使用更简单的规则集，生产环境再逐步加严。
稳定性优化
- 把安全组和 NACL 规则命名、用途、变更记录写清楚。
- 变更前先确认作用范围，尤其是关联到整个子网的 NACL。
- 上线前用一台测试机逐项验证 22、80、443、3306 等关键端口。
真正稳定的 AWS 网络访问控制，不是把规则写得越多越好，而是把实例级权限和子网级限制分层管理。对绝大多数业务来说，Security Group 负责精确授权，Network ACL 负责边界限制和应急阻断，这样最容易维护，也最不容易在故障时误判。
