1. 安全边界工程导论

在 AWS 上谈“安全边界”，很多团队的第一反应是安全组（Security Group）和网络 ACL（NACL）。它们确实重要，但它们解决的是“实例与子网级别的放行与拒绝”，而不是“整个 VPC 出口与入口的深度检查”。当业务需要统一管控南北向流量、按域名或 TLS SNI 做过滤、对出站流量做入侵检测与防御、并保留可审计日志时，就需要引入托管型虚拟防火墙——AWS Network Firewall。

本节先建立一张“边界地图”：谁在哪一层、管什么流量、依据什么做判断、留下什么证据。理解这张地图，后续的规则组设计、路由牵引、日志排障才有落脚点。

一、AWS Network Firewall 是什么，放在哪里

AWS Network Firewall 是一项区域级（Regional）的托管防火墙服务。它在 VPC 中通过“防火墙端点（Firewall Endpoint）”落地，端点以 ENI 形式出现在你指定的子网里。流量要经过防火墙，必须由路由表把流量“牵引”到防火墙端点所在的 VPC 端点，再由防火墙按策略放行、丢弃或告警。它不是一个可以随意旁挂的软件，而是需要与子网路由、网关端点、NAT 网关等一起设计的网络组件。

它的策略由三部分组成：无状态规则组（Stateless Rule Group）做快速五元组匹配与优先级处理；有状态规则组（Stateful Rule Group）做连接跟踪与深度检查，支持 5 元组、域名列表、Suricata 兼容规则；防火墙策略（Firewall Policy）把规则组按顺序组合，并定义默认动作（放行或丢弃）。此外还有日志配置，可把告警、流日志、丢弃日志发送到 CloudWatch Logs、S3 或 Kinesis Data Firehose。

二、与安全组、NACL、WAF 的分工

安全组是实例级别的有状态虚拟防火墙，只支持允许规则，默认拒绝入站、允许出站；NACL 是子网级别的无状态规则，支持允许与拒绝，按编号顺序匹配。它们擅长“粗粒度放行”，但不具备应用层识别、域名过滤、入侵特征匹配能力。AWS WAF 则工作在 HTTP/HTTPS 第 7 层，保护 ALB、CloudFront、API Gateway 等入口，关注 SQL 注入、XSS、Bot 等 Web 攻击，不处理任意 TCP/UDP 流量。

Network Firewall 的定位介于两者之间：它处理 VPC 级别的南北向与部分东西向流量，能看 3～7 层，能做域名与 TLS SNI 过滤、IPS 特征检测，并统一输出日志。它不是用来替代安全组的，而是补上“VPC 边界统一检查”这一层。

三、核心价值：统一检查、集中策略、可审计

Network Firewall 的价值可以概括为三点。第一，统一检查点：把原本分散在各子网、各实例的出入口流量收敛到 VPC 边界，避免“每个实例各自放行”的碎片化。第二，集中策略：通过防火墙策略把无状态与有状态规则组合，支持域名白名单、TLS SNI 过滤、Suricata 规则，实现“只允许访问必要域名、阻断已知恶意特征”。第三，可审计：告警日志、流日志、丢弃日志可分别投递，便于事后追溯与合规取证。

一个常见的教学示例：某业务 VPC 需要允许应用访问 *.amazonaws.com 与 pypi.org，其余出站域名一律阻断。做法是：在防火墙策略中配置一条有状态域名列表规则，动作设为 ALLOW，域名列表包含上述两项；再配置默认动作 DROP。路由表把 0.0.0.0/0 指向防火墙端点，流量先经防火墙再出 NAT 网关。验证时观察 CloudWatch 中的 alert 日志是否出现被阻断的域名，以及 flow 日志中允许连接的记录。

四、典型部署场景

场景一：集中式出站检查。多个业务 VPC 通过 Transit Gateway 汇聚到安全 VPC，安全 VPC 中部署 Network Firewall，统一做域名过滤与 IPS。场景二：入站防护。在面向公网的 VPC 中，Internet Gateway 之后、负载均衡之前放置防火墙端点，对入站流量做特征检测。场景三：东西向分段。在需要隔离的生产与开发 VPC 之间，通过防火墙策略限制跨 VPC 访问的端口与协议。

五、边界工程的第一条原则

安全组和 NACL 是“必须有的基础放行”，WAF 是“应用层入口防护”，Network Firewall 是“VPC 边界的深度检查与统一策略”。三者不是替代关系，而是分层协作。工程上要避免两个极端：一是只用安全组，导致出站域名无法管控；二是把所有流量都塞进防火墙却不设计路由，导致流量绕过检查点。理解本节的分层地图，后续的规则组、路由牵引、日志排障才能落在正确的位置上。