AWS安全组SG原理与最佳实践：应用层连接跟踪器详解-尧图网络科技

1. 这不是防火墙，是应用层流量的“门禁管理员”

很多人第一次接触 AWS 安全组（Security Group，简称 SG）时，下意识会把它当成传统网络设备里的防火墙——毕竟都带个“安全”俩字，都能拦流量。但这个类比错得离谱，而且错得非常危险。我见过太多团队在生产环境里因为这个误解，花三天时间排查一个本该三分钟解决的连通性问题：Web 服务明明健康检查通过，用户却打不开页面；数据库连接池持续告警，但 telnet 到端口又完全正常。最后发现，问题既不在代码里，也不在服务器上，而是在安全组规则里——他们把 SG 当成了状态无关的包过滤器，却忘了它本质是个有状态的应用层连接跟踪器。

SG 的核心逻辑，和 iptables 的-m state --state ESTABLISHED,RELATED是一脉相承的，但它更激进、更彻底。它不关心单个数据包的源 IP 和目的端口是否匹配规则，它只关心这个数据包是不是某个“已建立连接”的一部分。举个最直白的例子：当你从本地电脑 SSH 连接到一台 EC2 实例时，你的出站请求（SYN 包）必须匹配 SG 的入站规则（允许 TCP 22 端口），而实例返回的 SYN-ACK 和后续所有 ACK、数据包，哪怕它们的目的 IP 是你本地的私有地址段（比如 192.168.1.100），SG 也会无条件放行——因为它认得这是刚才那个连接的“回程”。这种“连接感知”能力，是 SG 和传统 ACL（访问控制列表）最根本的分水岭。ACL 是逐包检查的，像机场安检的 X 光机；SG 是看“登机牌”的，只要你是这趟航班的乘客，行李过检后，返程就直接走 VIP 通道。

这个特性直接决定了 SG 的设计哲学：入站规则定义“谁可以发起连接”，出站规则定义“我可以主动连接谁”。它不提供“拒绝”语义，只提供“允许”语义。这意味着，一个新创建的 SG，默认就是“全拒”状态——没有入站规则，任何外部流量都无法抵达关联的资源；但它的出站规则默认是“全放”，即允许实例主动访问互联网上的任何地址和端口。这个默认行为看似宽松，实则是 AWS 对云原生应用架构的深刻理解：现代应用绝大多数时候是“主动出击型”的（调用 API、拉取配置、上报日志），而不是“被动守株待兔型”的（等待外部请求）。所以，SG 的安全模型是“最小化入站，合理化出站”，而不是传统网络里那种“入站出站都要严防死守”。

关键词“AWS”、“Amazon VPC”、“SG”、“安全组”、“网络流量”在这里绝不是空洞的标签。它们共同指向一个具体、高频、且极易踩坑的实操场景：在 VPC 内部，如何让 Web 层、应用层、数据库层之间，只开放必要的、精确到端口和协议的通信通道，同时杜绝任何横向越权访问？比如，一个典型的三层架构中，负载均衡器需要能访问 Web 服务器的 80/443 端口，Web 服务器需要能访问应用服务器的 8080 端口，而应用服务器则需要能访问数据库的 3306 端口。但 Web 服务器绝对不能直接访问数据库，应用服务器也绝对不能被负载均衡器以外的任何东西访问。这种精细的、基于角色的流量控制，正是 SG 最擅长也最应该被正确使用的战场。它不是用来防御 DDoS 的，也不是用来做 NAT 的，它的唯一使命，就是在 VPC 这个“虚拟数据中心”内部，为每一个计算单元（EC2、RDS、ECS 任务等）贴上一张精准的“通信许可证”。

2. 规则设计的底层逻辑：为什么“引用安全组”比“写死 IP”强十倍

在动手配置 SG 规则之前，必须先破除一个根深蒂固的思维定式：不要用 CIDR 块（如 10.0.1.0/24）或单个 IP（如 10.0.1.10）来定义源/目标，除非你有万不得已的理由。我见过太多项目，初期图省事，直接在 Web 服务器的 SG 入站规则里写上Source: 10.0.2.0/24（应用服务器子网），结果当业务增长，需要把应用服务器迁移到另一个可用区、另一个子网，甚至拆分成多个微服务集群时，整个网络策略就得推倒重来。每一次变更，都伴随着对数十个 SG 的手动修改、测试、回滚，其痛苦程度不亚于给正在运行的飞机更换引擎。

真正优雅、可维护、符合云原生理念的方案，是“引用安全组”（Referencing Security Groups）。它的原理极其简单：当你在规则中指定Source: sg-0abcdef1234567890（一个应用服务器的 SG ID）时，AWS 并不是去查这个 SG 关联了哪些实例，然后把那些实例的私有 IP 汇总成一个列表。它做的是更底层、更高效的事情——它把这个规则和那个 SG 的“身份”绑定在一起。只要目标实例属于sg-0abcdef1234567890，无论它的 IP 是 10.0.2.10、10.0.2.11，还是未来动态分配的 10.0.3.50，这个连接都会被允许。这背后是 AWS 底层网络栈的深度集成，它让 SG 规则具备了“服务发现”的能力，而无需你部署 Consul 或 etcd。

我们来对比一下两种方式在真实场景中的表现：

对比维度	使用 CIDR 块 (10.0.2.0/24)	引用安全组 (sg-xxxx)
变更成本	需要修改所有引用该 CIDR 的 SG 规则。如果 Web、API、Worker 层都依赖此子网，可能涉及 5-10 个 SG。	只需确保应用服务器实例关联正确的 SG。规则本身零修改。
安全性	子网内所有实例（包括临时调试用的 Bastion 主机、未及时下线的测试实例）都自动获得访问权限，违背最小权限原则。	权限精确到“实例所属的安全组”，只有明确打了标签、关联了该 SG 的实例才拥有访问权。
弹性伸缩	自动扩缩容（Auto Scaling）时，新加入的实例 IP 在 CIDR 范围内，自动获得权限——这看似方便，实则埋下隐患（如新实例未完成安全加固就被暴露）。	新实例必须显式关联目标 SG 才能获得权限，强制将“网络授权”与“实例生命周期管理”绑定，流程更可控。
跨可用区支持	CIDR 是子网级概念，不同可用区的子网 CIDR 必然不同，无法用一个规则覆盖多 AZ 部署。	SG 是 VPC 级资源，一个 SG ID 可以被跨 AZ 的所有实例引用，天然支持高可用架构。

这个选择背后，是云时代基础设施管理范式的转变：从管理“IP 地址”转向管理“服务身份”。就像你在 Kubernetes 里不会用kubectl get pods -o wide查到 IP 再去配网络策略，而是用Service名称或Pod标签来定义 NetworkPolicy 一样，在 AWS 上，sg-xxxx就是你的服务标识符。我建议在项目初始化阶段，就为每一类角色定义清晰的 SG 命名规范，例如sg-prod-web-lb、sg-prod-app-api、sg-prod-db-mysql。这些名字不仅是标识，更是文档，是团队沟通的通用语言。当你在会议里说“请确保sg-prod-app-api的出站规则允许访问sg-prod-db-mysql的 3306 端口”，所有人都能立刻理解其含义，而不需要打开控制台去查一堆数字 ID。

提示：引用安全组时，有一个关键限制必须牢记——只能引用同一 VPC 内的安全组，或者与该 VPC 建立了 VPC 对等连接（VPC Peering）或 Transit Gateway 连接的其他 VPC 中的安全组。它不能跨账户直接引用（除非使用 Resource Sharing），也不能引用 Internet Gateway 或 NAT Gateway 的地址。这是一个设计上的边界，明确了 SG 的职责范围：它只负责 VPC 内部及受控互联网络的精细化访问控制，而非广域网边界防护。

3. 动手实验：从零搭建一个咖啡馆的三层应用网络策略

现在，让我们把理论付诸实践。假设我们要为一家名为“CloudBrew”的线上咖啡馆搭建一个可扩展、高可用的 Web 应用。根据 AWS 最佳实践，我们将采用经典的三层架构：前端由 Application Load Balancer（ALB）承载，中间层是部署在 Auto Scaling Group 中的 EC2 实例（运行 Node.js 应用），后端是 Amazon RDS for MySQL 数据库实例。整个架构部署在 us-east-1 区域，跨越两个可用区（us-east-1a 和 us-east-1b），以实现高可用。

3.1 环境准备与基础网络规划

首先，我们需要在 VPC 中规划好子网。这不是随意画几个框，而是有严格逻辑的：

Public Subnets (for ALB)：在 us-east-1a 和 us-east-1b 各创建一个公有子网（例如subnet-0a1b2c3d和subnet-0e5f6g7h），并将其关联到 VPC 的 Internet Gateway（IGW）。ALB 必须部署在这里，因为它需要接收来自公网的 HTTP/HTTPS 流量。
Private Subnets (for EC2 & RDS)：同样在 us-east-1a 和 us-east-1b 各创建一个私有子网（例如subnet-0i1j2k3l和subnet-0m4n5o6p），并将它们关联到同一个 NAT Gateway（部署在公有子网中）。EC2 实例和 RDS 实例必须部署在这里，确保它们没有公网 IP，无法被直接访问，只能通过 ALB 或内部服务调用。

这个网络拓扑是安全的基石。ALB 是唯一的“大门”，所有流量必须先经过它，再分发到后端。而 EC2 和 RDS 则躲在“内院”里，只接受来自“大门”或“内院邻居”的访问。

3.2 安全组的创建与规则配置（核心步骤）

接下来，我们逐一创建并配置三个核心安全组。记住，每一步都要问自己：“这个规则，是为了满足哪个具体的、不可替代的业务需求？”

创建`sg-cloudbrew-alb`

这是 ALB 的“身份证”。它的入站规则定义了谁可以访问咖啡馆的网站：

Rule 1 (HTTP)：Type: HTTP, Protocol: TCP, Port Range: 80, Source: 0.0.0.0/0
Rule 2 (HTTPS)：Type: HTTPS, Protocol: TCP, Port Range: 443, Source: 0.0.0.0/0

这两条规则是 ALB 的“门面”，必须开放给全世界。它的出站规则保持默认（全放），因为 ALB 需要能主动向后端 EC2 实例发起健康检查和流量转发。

创建`sg-cloudbrew-web`

这是 Web 服务器的“身份证”。它的规则设计体现了“最小权限”原则：

入站规则：Type: Custom TCP, Protocol: TCP, Port Range: 80, Source: sg-cloudbrew-alb
这是最关键的规则。它明确告诉 AWS：“只允许来自 ALB 安全组的流量访问我的 80 端口。” 注意，这里Source填的是 ALB 的 SG ID，而不是 ALB 的 DNS 名或 IP。ALB 本身没有关联 SG，但它的目标组（Target Group）所指向的 EC2 实例，必须关联这个sg-cloudbrew-web。这样，ALB 发起的健康检查（GET /health）和用户请求，才能顺利抵达 Web 服务器。
出站规则：Type: Custom TCP, Protocol: TCP, Port Range: 8080, Source: sg-cloudbrew-app
这条规则定义了 Web 服务器的“行动自由”：它只能主动连接到sg-cloudbrew-app安全组的 8080 端口。这确保了 Web 层不会意外地、错误地去调用数据库或其他无关服务。

创建`sg-cloudbrew-app`

这是应用服务器的“身份证”。它的规则进一步收紧了访问链路：

入站规则：Type: Custom TCP, Protocol: TCP, Port Range: 8080, Source: sg-cloudbrew-web
这形成了一个清晰的单向调用链：ALB → Web → App。App 层只接受来自 Web 层的请求，拒绝一切来自 ALB 直接的、或来自数据库的、或来自公网的访问。
出站规则：Type: Custom TCP, Protocol: TCP, Port Range: 3306, Source: sg-cloudbrew-db
同样，App 层的“行动自由”被限定为只能连接数据库的 3306 端口。

创建`sg-cloudbrew-db`

这是数据库的“身份证”，也是整个链条中最敏感的一环，必须极度谨慎：

入站规则：Type: MySQL/Aurora, Protocol: TCP, Port Range: 3306, Source: sg-cloudbrew-app
这是唯一一条入站规则，且必须如此！数据库绝不应该对 Web 层、ALB、甚至对公网开放。它只信任来自sg-cloudbrew-app的连接。这条规则是数据安全的生命线。
出站规则：保持默认（全放）。数据库通常需要连接 AWS 的 CloudWatch 进行监控指标上报，或连接 Secrets Manager 获取凭据，这些服务的端点是动态的，无法用固定 CIDR 表达，因此保留默认出站是合理且安全的。

3.3 关联资源与最终验证

规则配置完毕后，最后一步是将它们“贴”到对应的资源上：

将sg-cloudbrew-alb关联到 ALB 的目标组（Target Group）所配置的 EC2 实例上（注意：ALB 本身不关联 SG，是它的后端实例关联）。
将sg-cloudbrew-web关联到 Web 层 EC2 实例的网络接口（Network Interface）上。
将sg-cloudbrew-app关联到应用层 EC2 实例的网络接口上。
将sg-cloudbrew-db关联到 RDS 实例的 DB 安全组（DB Security Group）上。

验证环节至关重要，不能只靠“感觉”。我推荐一套标准化的连通性测试清单：

从公网测试：用浏览器访问 ALB 的 DNS 名，应能成功加载咖啡馆首页（HTTP 200）。
从 Web 层测试：SSH 登录一台 Web 层 EC2 实例，执行curl -v http://<app-server-private-ip>:8080/health，应返回成功响应。再执行curl -v http://<db-private-ip>:3306，应超时失败（证明 Web 无法直连 DB）。
从 App 层测试：SSH 登录一台 App 层 EC2 实例，执行mysql -h <db-endpoint> -u admin -p，应能成功连接数据库。再执行curl -v http://<web-server-private-ip>:80，应超时失败（证明 App 无法反向调用 Web）。
从数据库测试：登录 RDS 控制台，查看最近的连接日志，确认所有连接来源 IP 都属于 App 层 EC2 实例的私有 IP 段。

这套测试不仅验证了功能，更验证了网络策略的“隔离性”。它确保了即使某一层的应用代码存在漏洞，攻击者也无法轻易地“跳转”到其他层进行横向移动。这才是 SG 作为应用层网络控制器的真正价值所在。

4. 高级技巧与避坑指南：那些 AWS 文档里没明说的经验

在无数次的生产环境排障和架构评审中，我总结出了一些关于 SG 的“潜规则”和“血泪教训”，它们往往不会出现在官方文档的显眼位置，却是决定项目成败的关键细节。

4.1 “出站全放”默认值的双刃剑效应

官方文档说，新创建的 SG 默认出站规则是“允许所有 IPv4 和 IPv6 流量”。这句话本身没错，但它掩盖了一个重要的上下文：这个“全放”只对 EC2 实例有效，对 RDS、Elasticache 等托管服务，其出站行为是由服务自身策略和 VPC 网络路径共同决定的。例如，一个 RDS 实例，即使它的 SG 出站规则是全放，它也无法直接访问公网上的任意网站，因为它所在的私有子网没有路由指向 IGW。它的出站流量，必须经过 NAT Gateway，而 NAT Gateway 的安全组（如果有的话）和网络 ACL（Network ACL）才是真正的守门人。

因此，当你发现一个 EC2 实例无法访问某个外部 API 时，排查顺序应该是：

检查 EC2 实例的 SG 出站规则（是否被误删或限制）。
检查 EC2 实例所在子网的路由表（是否有一条指向 NAT Gateway 的 0.0.0.0/0 路由）。
检查 NAT Gateway 所在的公有子网的路由表（是否有一条指向 IGW 的 0.0.0.0/0 路由）。
检查 NAT Gateway 所在的公有子网的网络 ACL（是否允许出站的 ephemeral 端口范围，通常是 1024-65535）。

这个排查链路，比单纯盯着 SG 规则要长得多。我曾经在一个项目里，花了整整一天时间，就因为忽略了第 2 步——子网路由表里那条指向 NAT Gateway 的路由被误删了，导致所有出站请求都石沉大海。SG 规则完美无缺，但网络路径已经断了。

4.2 安全组规则数量的隐形天花板

AWS 对每个安全组的规则数量有硬性限制：默认是 60 条，其中入站和出站规则分别计算。听起来很多，但在一个复杂的微服务网格中，很容易触达。比如，一个服务需要调用 10 个下游服务，每个服务需要开放 3 个端口（HTTP、gRPC、Metrics），光是出站规则就需要 30 条。再加上入站规则、健康检查端口、管理端口……60 条很快就会见底。

更隐蔽的陷阱是“规则膨胀”。当你使用“引用安全组”时，每一条引用规则，无论它引用的是一个 SG 还是十个 SG，在 AWS 的计数里，都只算作一条规则。但如果你为了“灵活”，在同一个 SG 里为每一个下游服务的每一个端口都单独写一条规则（Source: sg-downstream-1, Port: 8080；Source: sg-downstream-2, Port: 8080；Source: sg-downstream-1, Port: 9090…），那么规则数量会呈指数级增长。

解决方案是“聚合”。为同一类服务创建一个“聚合安全组”。例如，创建sg-downstream-apis，然后将所有需要被调用的 API 服务的实例都关联到这个 SG。这样，上游服务只需要一条规则：Source: sg-downstream-apis, Port: 8080。这不仅节省了规则配额，更提升了策略的可读性和可维护性。它把“服务发现”的责任，从网络层（SG）移交给了编排层（如 ECS Service Discovery 或 EKS Service），这是一种更现代、更解耦的设计。

4.3 “过期规则”的幽灵与自动化清理

AWS 文档提到了“过期规则”（Expired Rules）的概念：当你引用了一个 VPC 对等连接（VPC Peering）中的安全组，而这个对等连接被删除后，该引用规则就会变成“过期”。它依然存在于你的 SG 配置中，但不再生效，且会在控制台中被标记为灰色。

这个“过期”状态本身不是问题，但问题是，它会一直躺在那里，直到你手动删除。想象一下，一个大型企业，有上百个 VPC，通过 Transit Gateway 互联。当某个业务线下线，其 VPC 被拆除，所有引用该 VPC 内 SG 的规则都会变成“过期”。如果不加清理，这些幽灵规则会污染你的 SG 配置，让审计变得异常困难，也让新来的工程师一头雾水。

我的经验是，将 SG 规则的生命周期管理，纳入 CI/CD 流水线。使用 Terraform 或 AWS CloudFormation 来定义所有的 SG 和规则。当一个 VPC 被销毁时，相关的 CloudFormation Stack 会被删除，所有由它创建的、引用了该 VPC SG 的规则，也会被自动、干净地移除。这是一种“声明式”的基础设施管理，它让网络策略的变更，和应用代码的发布一样，变得可预测、可追溯、可回滚。手动在控制台里点点点，永远无法支撑起一个大规模、高频率迭代的云环境。

5. 性能、监控与故障排查：当流量真的卡住了

SG 本身是一个无状态的、内核级的过滤器，它的性能损耗几乎可以忽略不计。一个配置了 50 条规则的 SG，其处理延迟依然是微秒级的。因此，当你遇到“网络慢”、“连接超时”这类问题时，第一反应绝不应该是怀疑 SG 的性能，而应该立即启动一套结构化的排查流程。SG 更像是一个“开关”，它要么全开，要么全关，极少出现“半开”的中间态。

5.1 排查流程：从宏观到微观的五步法

我给自己和团队制定了一套标准的“SG 故障排查五步法”，它被证明能快速定位 95% 以上的连通性问题：

确认资源状态与关联：登录 AWS 控制台，进入 EC2 服务，找到目标实例，点击“安全组”标签页。确认该实例确实关联了你认为它应该关联的那个 SG。这是一个低级但高频的错误——开发人员在测试环境创建了一个新实例，忘记关联 SG，或者关联错了 SG。
检查规则语法与逻辑：仔细阅读目标 SG 的入站和出站规则。重点检查：
- 方向是否正确？你想测试的是 A 访问 B，那么你需要检查的是 B 的入站规则（A 是否在 Source 列表中），而不是 A 的出站规则。
- 协议和端口是否匹配？Web 服务监听的是 8080，但规则里写的却是 80？或者规则是 TCP，但你的测试工具（如nc）用的是 UDP？
- Source/Destination 是否精确？你写的是0.0.0.0/0，但实际想测试的是来自特定 IP 的流量？或者你引用了一个 SG，但那个 SG 里并没有你期望的实例？
验证网络路径：使用VPC Flow Logs。这是 AWS 提供的终极武器。它会记录流经 VPC 中每个网络接口（ENI）的每一个连接的详细信息，包括action（ACCEPT/REJECT）、status（OK/FAILED）、srcaddr、dstaddr、srcport、dstport。开启 Flow Logs 后，你可以在 CloudWatch Logs 中搜索特定的源 IP 和目的端口组合。如果看到大量REJECT日志，且status是FAILED，那就 100% 是 SG 规则在拦截。如果看到ACCEPT日志，但连接依然不通，那问题一定出在 SG 之外（如应用进程未监听、防火墙软件、路由表）。
检查网络 ACL（NACL）：NACL 是子网级别的、无状态的防火墙，它位于 SG 之前。一个常见的误区是，认为配置了 SG 就万事大吉，而忽略了 NACL。NACL 的规则是按编号顺序执行的，一旦匹配到一条DENY规则，后续所有规则都不再检查。因此，务必检查目标子网的 NACL，确保其入站和出站规则中，有明确的ALLOW规则覆盖了你所需的端口和协议，并且这些ALLOW规则的编号，要小于任何可能存在的DENY规则。
检查路由表：这是最容易被忽视的一步。一个实例要能访问另一个实例，不仅需要 SG 放行，还需要网络知道“怎么走”。检查源实例所在子网的路由表，确认有一条路由能将目的 IP（如另一个子网的 CIDR）导向正确的下一跳（如本地Local、VPC 对等连接pcx-xxxx、Transit Gatewaytgw-xxxx）。如果这条路由不存在，数据包会在源子网就被丢弃，SG 根本没有机会看到它。

5.2 监控：用 CloudWatch 指标预见风险

虽然 SG 本身不产生性能瓶颈，但它产生的REJECT事件，却是系统健康状况的绝佳晴雨表。AWS CloudWatch 为每个 SG 提供了两个关键指标：

AllowCount: 被 SG 允许的连接数。
RejectCount: 被 SG 拒绝的连接数。

我强烈建议为所有关键业务的 SG 创建 CloudWatch Alarm。例如，为sg-cloudbrew-db设置一个 Alarm：当RejectCount在 5 分钟内超过 100 次时，触发告警。这通常意味着：

有恶意扫描器在暴力探测数据库端口。
应用层的连接池配置错误，导致大量无效的、重复的连接请求。
某个上游服务的代码 bug，产生了错误的数据库连接字符串。

一个健康的、配置正确的 SG，其RejectCount应该是零，或者是一个极低的、稳定的数值（如偶尔的健康检查探针失败）。任何突然的、剧烈的RejectCount峰值，都是一个强烈的信号，提示你该去检查应用日志和代码了。这比等到用户投诉“网站打不开”再开始排查，要主动得多，也专业得多。

注意：RejectCount指标是“聚合”指标，它统计的是被拒绝的连接尝试次数，而不是被拒绝的数据包数量。一个 TCP 连接建立过程（三次握手）会产生多个数据包，但只算作一次连接尝试。因此，这个指标的粒度非常合适，它直接反映了应用层的连接行为，而不是底层的网络噪声。

6. 架构演进：当你的咖啡馆开遍全球

随着 CloudBrew 咖啡馆业务的扩张，它不再满足于单一区域的服务。它需要在欧洲（eu-west-1）和亚太（ap-southeast-1）也开设“分店”，为当地用户提供低延迟的访问体验。这时，网络架构就必须升级，而 SG 的角色也随之进化。

6.1 多区域架构下的 SG 策略

在多区域（Multi-Region）架构中，SG 的“本地化”特性成为一把双刃剑。每个区域的 VPC 是完全独立的，sg-xxxx在 us-east-1 和 eu-west-1 中是两个完全不同的资源，ID 也完全不同。这意味着，你无法在 us-east-1 的 Web 层 SG 中，直接引用 eu-west-1 的数据库 SG。

此时，传统的“引用 SG”模式失效了，我们必须回归到更基础的网络原语：CIDR 块。但这次，我们引用的不再是 VPC 内部的私有 CIDR，而是对等连接（Peering）或 Transit Gateway 连接后，对方 VPC 的 CIDR 块。

例如，当 us-east-1 的 VPC 与 eu-west-1 的 VPC 建立了 VPC Peering 后，你需要在 us-east-1 的sg-cloudbrew-web中添加一条新的入站规则：

Type: Custom TCP, Protocol: TCP, Port Range: 8080, Source: 10.100.0.0/16（假设 eu-west-1 VPC 的 CIDR 是 10.100.0.0/16）

这条规则的含义是：“允许来自欧洲区域 VPC 内所有实例的 8080 端口访问”。它牺牲了“服务身份”的精确性，换来了跨区域的连通性。这是一种必要的妥协，但也带来了新的挑战：权限粒度变粗了。现在，eu-west-1 VPC 里的任何一个实例，只要它能路由到 us-east-1，就能访问你的 Web 层。因此，在多区域架构中，你必须在应用层（如 API Gateway 的授权、服务网格的 mTLS）上，叠加更细粒度的身份认证和授权，来弥补网络层 SG 的“粗粒度”缺陷。

6.2 从 SG 到服务网格：下一代流量控制的演进

对于一个刚刚起步的咖啡馆网站，SG 是完美的、足够用的工具。但当 CloudBrew 发展成一个拥有数十个微服务、每天处理百万级订单的平台时，仅靠 SG 就显得力不从心了。SG 的规则是静态的、全局的，它无法区分“来自订单服务的请求”和“来自报表服务的请求”，只要它们都来自同一个sg-order-service，SG 就一视同仁。

这时，就需要引入更高级的流量管理工具——服务网格（Service Mesh），如 AWS App Mesh。App Mesh 在每个服务实例旁注入一个轻量级的代理（Envoy），所有进出该实例的流量都必须经过这个代理。代理可以根据请求的 HTTP Header、Path、Method，甚至是 JWT Token 中的 Claims，来执行动态的路由、重试、熔断、加密等策略。

SG 和 App Mesh 的关系，不是替代，而是分层协作：