背景与跨账号挑战
在将单体应用逐步重构为微服务时，团队常采用绞杀者模式，并将每个新服务部署在独立的 AWS 账号中，以获得强隔离、独立扩缩容与明确的所有权。然而，当旧单体与新服务分属不同账号时，如何对实时流量进行精确切片（例如将少量请求导向新服务观察表现，异常时快速回滚）成为难题。该问题包含两层：
- 跨账号连通：服务需跨账号发现并通信，且避免复杂的网络叠加或紧耦合配置。
- 加权流量控制：即使目标服务位于其他账号，也要能按精确百分比路由金丝雀流量。
VPC Lattice 本身的目标组限定在所属账号内，无法原生实现跨账号流量拆分，需要互补的请求级路由层。
解决方案概览
本文提出一种组合模式：使用 API Gateway 原生金丝雀发布 负责每请求权重决策，VPC Lattice 作为安全的服务网络连接底座，并借助一个无状态 Lambda 函数填补 API Gateway 到 Lattice 的调用鸿沟。详细架构参见 AWS 网络博客原文。
多账号网络连通基础
中央账号托管面向公网的 API Gateway，并可叠加 Cognito、CloudFront、Shield Advanced、WAF 等安全防护。工作负载账号承载后端应用（单体与新微服务）。VPC Lattice 通过共享服务网络将跨账号、跨 VPC 的服务连接起来，充当安全传输层，在服务端点实施零信任访问控制。服务通过托管 DNS 名称互访，无需 VPC 对等或 Transit Gateway。注意 Lattice 在此架构中不做金丝雀路由，仅提供连通与鉴权。
API Gateway 金丝雀路由层
API Gateway 同时承担公网入口与路由决策。REST API 接收请求后转给 VPC 内的 Lambda 转发器。其原生阶段（stage）金丝雀功能实现权重控制：基础阶段变量（如 latticeTarget: monolith）指向旧服务，canarySetting 块以特定比例覆盖该变量至新服务（如 payments）。API Gateway 自身对每请求做出调用决策。权重参数集中于 CanarySettings，回滚（设为 0）或晋升（趋近 100）仅需修改单一参数，下游基础设施无需变动。
代理层（Lambda 转发）
由于 API Gateway 作为托管区域服务无法直接访问仅能在关联 VPC 内解析的 Lattice 端点，引入无状态 Lambda 代理。API Gateway 经 Lambda 代理集成在每次请求时调用该函数，传入 HTTP 请求与阶段变量。函数读取目标值，映射为对应 Lattice 服务 DNS 名称并转发 HTTP 请求，若目标强制 IAM 鉴权则进行 SigV4 签名。函数 ENI 位于关联服务网络的 VPC 中，Route 53 Resolver 将 Lattice DNS 解析为数据面链路本地地址。该转发器不做权重判断，仅执行传输。
配置示例
以下为 API Gateway 阶段金丝雀配置节选，展示 10% 流量导向新服务：
{ "StageName": "prod", "Variables": { "latticeTarget": "monolith" }, "CanarySettings": { "percentTraffic": 10.0, "stageVariableOverrides": { "latticeTarget": "payments" } }}对读者的意义与技术解读
对于运维与 SRE 团队，该架构示范了如何利用云厂商托管组件替代自建服务网格控制面，以较低运维负担实现跨账号灰度发布。在迁移核心业务时，细粒度流量切片能显著降低故障爆炸半径；结合实时监控与告警，可达成高可用性 SLA。此外，将路由逻辑上移集中于 API Gateway，使得网络传输层（Lattice）保持简洁，符合关注点分离原则。在混合云或多云环境中，类似思路也可借鉴：用边缘或入口层做权重，用服务网络做连通，避免跨边界的复杂路由代码。