我之前遇到过几乎一模一样的情况——API Gateway集成延迟和Lambda实际执行时长之间存在莫名的差值，已经排除冷启动但就是找不到根因，分享几个我当时踩过的坑和排查方向：

• 检查API Gateway集成配置的细节
  首先确认你用的是Lambda代理集成还是自定义集成。如果是自定义集成，哪怕你觉得映射模板逻辑简单，也可能隐藏着开销——比如复杂的VTL模板处理大请求体时，会在API GW侧消耗额外时间，这部分会算在integrationLatency里，但不会体现在Lambda的执行日志里。我当时临时切换成代理集成测试，差值直接从15ms降到了3ms，后来优化了模板逻辑就解决了。另外，把API GW阶段的日志详细程度调到最高，能看到集成阶段的请求转换、头部处理等细分耗时，说不定能抓到隐藏的开销点。

• 深挖网络层面的潜在瓶颈
  如果你的Lambda部署在VPC内，API GW需要通过VPC链接访问它，那VPC链接的配置是重点排查对象：

  • 检查子网的网络性能：是不是选了低负载的AZ？有没有子网的带宽瓶颈？可以对比不同AZ的请求差值，看是否有明显差异。
  • 确认安全组和NACL规则：有没有不必要的端口限制或者流量过滤？有时候过于严格的规则会导致数据包排队，增加延迟。
  • 查看Lambda的ENI状态：虽然预置并发会保持ENI活跃，但偶尔会出现ENI的网络栈延迟，你可以在CloudWatch里看Lambda的NetworkErrors指标，有没有异常波动。

• 用CloudWatch指标做交叉对比
  不要只看单条日志的数值，拉取一段时间的指标做对比：

  • 对比API GW的IntegrationLatency和Lambda的Duration的平均值、百分位数（比如p95、p99），看这个差值是稳定存在还是偶尔出现。如果是偶尔出现，大概率是AWS内部的流量调度波动，比如区域内的临时负载高峰。
  • 确认ProvisionedConcurrencyUtilization指标是否始终接近100%或者在你设置的阈值内，有时候就算配置了预置并发，极端情况下还是会有极少数请求落到未预置容器（虽然你说没溢出，但还是可以确认下）。

• 排查请求负载的影响
  测试一个空请求或者极小负载的请求，看差值会不会缩小。如果请求体较大，API GW向Lambda传输数据的时间会全部算在集成延迟里，而Lambda的Duration是从代码开始执行时才计时，这部分传输时间就是差值的来源。我之前遇到过一个案例，用户上传1MB的JSON请求，这部分传输就占了12ms的差值。

• AWS内部服务波动的排查
  去AWS控制台的Health Dashboard看看，排查时间段内有没有API GW或者Lambda的服务事件。就算没有公开的事件，区域内的局部网络波动也可能导致服务间通信延迟，这种情况一般是临时的，可以换个时间段测试看差值是否消失。

我当时的最终根因是Lambda所在VPC的子网有轻度网络拥堵，调整了子网路由并优化了API GW的映射模板后，差值降到了5ms以内，符合预期。

内容的提问来源于stack exchange，提问作者Kris