延迟影响分析
范围：VPC Lattice 服务 / 资源 API 和 AWS Gateway API Controller；请确认所选版本及已安装的 CRD。 最后更新：2026 年 9 月 13 日
本文涵盖的内容
- 为什么迁移到 Lattice 会同时引入增加和降低延迟的因素
- 为什么哪一侧占主导取决于环境，无法预先预测
- 应测量哪些内容、如何测量，以便得到答案：PoC 测量矩阵
首先：本文不提供具体数值
延迟影响因工作负载而异。代理处理、网络路径、连接复用、签名、凭证刷新和策略评估都可能改变结果。本章没有提供任何 Lattice 延迟测量数据，因此既不宣称影响幅度，也不保证延迟一定朝某个方向变化。
具体哪一侧占主导，取决于许多因素，例如当前 Envoy sidecar 消耗多少节点 CPU、请求有多短（固定开销所占比例）、是否使用 keepalive、是否启用 IAM Auth，以及有多少请求跨越可用区。不同组织的这些条件各不相同。
因此，本文的结论是“测量它”，正文则说明“要测量什么才能得到答案”。以下先按影响方向和幅度整理各项因素，再给出用于隔离这些因素的测量矩阵。
增加延迟的因素
1. 增加一次 VPC 网络转发
AS-IS 状态下，调用方的 Envoy 会直接连接接收方 Pod IP。如果 Pod 位于同一节点，流量不会离开 veth pair，也不会经过网卡。TO-BE 状态下，目标地址是 Lattice link-local 地址，流量会先经过 VPC 内的 Lattice ingress endpoint，再到达最终目标。
这一差异对过去在同一节点上的 Pod-to-Pod 通信影响最大。AS-IS 时，路径可以在内核中完成；现在则需要离开节点、经过 Lattice，再返回节点。作为参考基线，Pod 网络基准测试测得同节点 RTT 为 0.040 ms、同可用区不同节点为 0.339 ms、跨可用区为 0.544 ms。如果任何调用路径依赖同节点局部性，该路径受影响最大。
2. SigV4 签名与验证开销
启用 IAM Auth 后，每个请求会增加两项计算：
- 调用方签名会增加规范化和签名计算。Lattice 要求使用
UNSIGNED-PAYLOAD；不要把通用负载哈希当作 Lattice 签名所必需的工作进行基准测试。 - Lattice 侧的验证和已启用的策略评估也会增加处理工作。请测量完整路径，不要假设每项操作固定耗时多少。
实际成本可能不在加密本身，而在于凭证获取路径。使用临时凭证时，配置好的 provider 会缓存并刷新凭证；IRSA 使用 STS，而 EKS Pod Identity 使用节点代理和 EKS Auth。若请求需要等待凭证获取或刷新，就会受到相应延迟影响。该因素会影响 p50、p99 还是更少见的样本，取决于刷新频率和工作负载；因此要记录 provider / 缓存行为及刷新前后的延迟分布（见文档 03）。
如果通过出站代理签名，还需计入多经过一次代理的成本。
3. 可能跨可用区转发
不要假设 Lattice 一定会选择调用方所在可用区内的 Target。如果 AS-IS 使用了感知可用区的路由或拓扑感知提示，将流量固定在某个可用区中，就必须单独确认该优化迁移后是否仍然有效。
::: note 有文档记录的 AZ 行为 AWS 描述了服务 / 资源地址返回给客户端时的 AZ affinity，并在该 AZ 不可用时提供替代方案。后端 Target 仍可能跨越多个 AZ；目标组文档说明采用轮询路由。这并不能保证后端与调用方在同一 AZ。请在 PoC 中测量实际的 Target 放置位置。
另外，从计费角度来看，通过 Lattice 传输的跨 AZ 流量不会产生额外的 AZ 间费用，而是包含在数据处理费用中。因此，这次迁移中的跨 AZ 传输会影响延迟，但不会增加账单费用。 :::
4. TLS 握手模式变化
在 AS-IS 中，Envoy 之间的 mTLS 连接是长期连接。握手费用只支付一次，之后多个请求都会通过该连接传输。
在 TO-BE 中，连接建立的位置和频率都会发生变化。新连接会产生建立连接的开销；使用 TLS 时还会产生 TLS 握手开销。引用的 HTTP Pod 基准测试中，禁用 keepalive 后，同 AZ p50 从 0.461 增至 1.079 ms，跨 AZ p50 从 0.704 增至 1.517 ms。这些测量仅说明该配置中的连接复用效果，并没有单独测出 TLS / Lattice 成本，也不能证明连接复用比经过代理更重要。
因此，迁移时必须审查应用的 HTTP 客户端设置（连接池大小、keepalive、空闲超时）。这不是 Lattice 的固有特性，而是客户端配置问题；以前代理负责管理连接，此问题因此未显现，迁移后才浮现出来。
降低延迟的因素
1. 代理转发从两次减少为一次
AS-IS 中，单个请求会经过代理两次：一次经过调用方 Envoy（路由决策、发起 mTLS、指标），另一次经过接收方 Envoy（终止 mTLS、授权、指标）。每次转发都要经历完整的用户空间接收—处理—发送过程。
在此示例路径中，这会移除两次由客户管理的 sidecar 转发。但由于 Lattice 内部实现、签名代理和网络路由都发生了变化，不能据此保证端到端延迟一定降低。
2. Envoy sidecar 的 CPU 争用消失
这是实践中最容易被低估的因素。
每个 Pod 都有一个 Envoy sidecar，并消耗节点 CPU。当节点面临 CPU 压力时，Envoy 进程会等待调度，这段等待时间会直接增加请求延迟。其典型特征是平均延迟几乎看不出差异，但尾部延迟明显上升。大多数请求会立即获得调度；部分请求则会等待数毫秒到几十毫秒。
移除 sidecar 后，这类争用也会消失。因此，在 Pod 密度高且 CPU 资源有限的集群中，p99 可能改善。同时，每个节点也会释放更多 CPU 和内存，从而为提高 Pod 密度留出空间。
3. 配置收敛行为改变
AWS 负责管理 Lattice 数据平面，但控制器协调、endpoint 注册、健康检查和策略传播仍需要时间。AWS 文档说明，身份验证策略更新可能需要几分钟。应测量收敛和发布行为，不要假设传播延迟会消失。
因素总结：影响方向及其表现位置
| 因素 | 方向 | 体现的指标 | 加剧影响的条件 |
|---|---|---|---|
| 增加 VPC 网络转发 | 延迟增加 | p50 和 p99 | 同节点 / 同 AZ 流量占比高 |
| SigV4 签名 / 验证 | 延迟增加 | p50 略有影响，凭证刷新会影响 p99 | 启用 IAM Auth，请求较短 |
| 跨 AZ 转发 | 延迟增加 | p50、p99 | 依赖感知 AZ 的路由 |
| TLS 握手模式变化 | 延迟增加 | p50、p99 | 未启用 keepalive，连接池未调优 |
| 移除 sidecar | 可能改善 | p50、p99 | 取决于移除的工作、签名路径和网络拓扑 |
| 消除 Envoy CPU 争用 | 延迟改善 | p99 | 节点面临 CPU 压力 |
| 配置收敛 | 必须测量 | 变更期间的可用性 / 延迟 | 控制器、目标健康状态和策略传播 |
本表的关键点是p50 和 p99 的影响因素组合不同。增加延迟的因素（例如新增路径）可能主导 p50；改善因素（例如消除 CPU 争用）则可能主导 p99。只看平均值会掩盖这种结构。
PoC 测量矩阵
若要分别观测这些因素，应沿不同维度拆分测量。
测量维度
| 维度或输出 | 取值 | 目的和限制 |
|---|---|---|
| 百分位数 | p50、p99 | 描述中心和尾部延迟；因果归因需要额外控制 |
| AZ 放置 | 同 AZ / 跨 AZ | 在记录调用方和所选目标位置的同时比较配置路径 |
| IAM Auth | 在获准的隔离测试中开启 / 关闭 | 观察签名、凭证和策略评估的综合影响 |
AZ 放置和身份验证模式是配置维度；p50 / p99 是每次运行都会得到的两个输出，并非独立实验。应进行多次条件匹配的运行，在可行时随机安排顺序，并同时报告错误率 / 吞吐量和延迟。
测量表模板
| 配置 | 同 AZ p50 | 同 AZ p99 | 跨 AZ p50 | 跨 AZ p99 |
|---|---|---|---|---|
| AS-IS：App Mesh（基线） | ||||
| TO-BE：Lattice，IAM Auth 关闭 | ||||
| TO-BE：Lattice，IAM Auth 开启 |
开启 / 关闭身份验证的差值是在这些条件下签名、凭证处理和已启用策略评估所产生的综合影响。App Mesh / Lattice 之间的差值还包括代理、路由、TLS 和其他配置变更。没有额外控制时，这两个差值都无法识别某个纯粹的因果因素。
必须同时记录的条件
仅记录数值会使后续分析无法进行。还应记录以下内容：
| 项目 | 原因 |
|---|---|
| keepalive 使用情况和连接池设置 | 如前所述，其影响可能超过一次代理转发。若不同对照组的设置不同，结果便不可比较 |
| 请求 / 响应负载大小 | 会改变固定开销的相对权重。请求越短，固定开销看起来越大 |
| 负载水平（RPS）和并发数 | 接近配额时，行为可能发生变化 |
| 运行期间的节点实例类型和节点 CPU 利用率 | 用于解释 CPU 争用效应的依据。在 AS-IS 运行中，还应单独记录 Envoy 容器的 CPU 用量 |
| AS-IS sidecar 资源 requests / limits | 用于判断是否发生过节流 |
| 测量工具及其设置 | 例如 fortio、wrk2、k6 等；不同工具的百分位计算方法不同 |
| 时间戳、区域和 AZ | 用于复现 |
测量设计中常被遗漏的方面
首先，分别记录冷启动和预热后的状态。如果凭证或连接尚未缓存，第一个请求可能包含凭证获取和连接建立的时间。凭证获取路径由 provider 决定；只有对 TLS 连接才会执行 TLS 建立过程；每个“首次请求”都不会直接调用 STS 或执行 TLS 握手。预热后测量稳态，并使用 provider、缓存和传输状态单独记录首个请求的延迟。对于 Lambda 或经常扩缩容的服务等频繁冷启动的工作负载，两种情况都要评估。
其次，确保样本数量足以让 p99 有意义。请求数量太少时，p99 只是噪声。在稳定负载下，应使用数万次请求后采集的数值。
第三，考虑调用链深度。单跳测量有助于隔离因素，但实际用户延迟是整条调用链的总和。每增加一跳 Lattice 都会累积开销，因此还应选择最长的真实调用路径并进行端到端测量。这一视角也与计费直接相关（见文档 06）。
第四，直接观测 Lattice 跳点的能力有限。Lattice 不会生成 trace span，因此需要将客户端测量与 Lattice 访问日志关联起来。请将启用访问日志纳入测量计划。
结论
- 本章提供的是测量设计，不包含 Lattice 延迟实测数据，也不保证性能会有所改善。
- p50 可能变差，而 p99 可能变好。只看平均值会掩盖这种结构。
- keepalive 和连接池设置的影响可能超过代理转发变化。迁移时必须审计客户端配置。
- 通过多次条件匹配的运行比较 AZ / 身份验证配置；每次运行都要报告 p50 / p99、失败数和吞吐量。
下一篇：深入了解 IAM 身份验证流程，介绍 SigV4 开销的组成部分及其凭证依赖。
参考资料
- Pod 网络基准测试：同节点 / 同 AZ / 跨 AZ RTT 测量及 keepalive 影响
- Amazon VPC Lattice 定价：跨 AZ 费用包含在数据处理费用中
- Amazon VPC Lattice 访问日志
- 监控 Amazon VPC Lattice
链接的 Pod 基准测试是另一项工作负载的基线。其 HTTP keepalive 数值并不是 TLS 握手或 Lattice 本身的测量结果。