Security Group（安全组）和 NACL（Network ACL）是 AWS 提供的最基础的网络安全机制，都是用来控制流量的防火墙，但工作方式有本质区别。很多人配置 VPC 时会忽略 NACL，只使用 Security Group，这在某些场景下会留下安全隐患。
一句话定位
- Security Group：附着在实例（EC2 / RDS / ALB）上的虚拟防火墙，控制单个实例的出入流量
- NACL：附着在子网上的防火墙，控制整个子网的出入流量，子网内所有实例都受其约束
两者可以共存——流量到达一个 EC2 实例时，先经过 NACL（子网级）检查，再经过 SG（实例级）检查，两道关卡都通过才算放行。
核心区别
| 对比项 | Security Group | NACL |
|---|---|---|
| 作用范围 | 实例级别（绑定到 ENI） | 子网级别（整个子网生效） |
| 规则类型 | 仅支持 Allow（默认全 Deny） | 支持 Allow + Deny |
| 状态性 | 有状态 | 无状态 |
| 规则评估 | 全部规则一并评估 | 按规则号从小到大评估 |
| 适用场景 | 精细化实例级访问控制 | 子网边界的全局黑白名单 |
有状态 vs 无状态 —— 最关键的区别
这是两者最本质的区别，也是实际配置中最容易出错的地方。
Security Group 有状态：如果允许了入站流量，回包自动放行，不需要配置出站规则。
1
2
3
入站：允许 0.0.0.0/0 访问 80 端口
↓
用户请求 → EC2 → 回包给用户 ✅（自动放行，不需要额外规则）
NACL 无状态：允许了入站流量后，还需要明确配置出站规则允许回包，否则回包被丢弃。
1
2
3
4
5
6
入站规则：允许 0.0.0.0/0 访问 80 端口
出站规则：❌ 没有放行临时端口 → 回包被丢弃！
正确的 NACL 配置：
入站规则 #100：允许 0.0.0.0/0 80 端口
出站规则 #100：允许 0.0.0.0/0 1024-65535 端口（回包使用的临时端口）
这就是为什么很多人在配了 NACL 后发现网络不通——只配了入站允许但忘记配出站回包规则。NACL 不会像 SG 那样自动处理回包。
Deny 规则的独特价值
Security Group 只支持 Allow 规则，所有没有显式 Allow 的流量默认被拒绝。但有时你需要明确拒绝某些流量，而放行其他所有流量——这只有 NACL 能做到。
1
2
3
NACL 示例：屏蔽特定攻击来源
入站规则 #1：Deny 1.2.3.4/32（已知攻击 IP）
入站规则 #2：Allow 0.0.0.0/0 （放行其他所有流量）
NACL 的规则按编号从小到大依次评估，一旦匹配就应用该规则，不再继续评估。
实际配置建议
Security Group 做精细控制：每个应用角色（ALB、前端、后端、数据库）各建一个 SG，后端 SG 只允许来自 ALB SG 的入站。使用安全组引用而非 IP 段，让规则随实例自动更新。
NACL 做子网边界防护：在子网级别配置基础的黑白名单。推荐至少配置两条规则：
Public 子网 NACL： | 规则 | 方向 | 类型 | 源/目标 | 端口 | 说明 | |——|——|——|———|——|——| | 100 | 入站 | Allow | 0.0.0.0/0 | 80, 443 | 放行 HTTP/HTTPS | | 100 | 出站 | Allow | 0.0.0.0/0 | 1024-65535 | 放行临时端口回包 |
Private 子网 NACL： | 规则 | 方向 | 类型 | 源/目标 | 端口 | 说明 | |——|——|——|———|——|——| | 100 | 入站 | Allow | 10.0.0.0/8 | 全部 | 仅允许内网流量 | | 100 | 出站 | Allow | 0.0.0.0/0 | 全部 | 出站不限制 |
NACL 是免费服务，配置简单但覆盖整个子网，适合做第一道防线。
一句话总结
SG 有状态、仅 Allow、实例级——做精细化应用层控制。NACL 无状态、支持 Deny、子网级——做子网边界层防护。两者叠加构成”纵深防御”。