如何验证APIGW的Lambda Authorizer授权策略缓存是否正常生效

APIGW的Lambda Authorizer缓存的核心运行逻辑是：在ReauthorizeEvery设定的有效期内，相同授权凭证（你当前配置为从Authorization请求头提取）的请求，不会再触发后端Authorizer Lambda的调用，直接复用之前缓存的授权策略。所有验证都围绕这个逻辑设计：

最准确的验证方式：监控Authorizer Lambda的实际调用情况 #

这是没有歧义的金标准：

• 先在你的Authorizer Lambda的入口逻辑加一行简单日志，比如每次被触发时打印当前时间和接收到的token值，类似逻辑：

  def lambda_handler(event, context):
      # 原有授权逻辑之前加埋点
      print(f"Authorizer invoked at {time.time()}, token={event.get('authorizationToken')}")
      # 原有授权判断逻辑...
  

• 用一个有效token第一次调用你的受保护业务API，确认CloudWatch上能看到刚才打印的埋点日志，且API正常返回授权通过的响应
• 在远小于3600秒的窗口期内（比如测试间隔几分钟），用完全相同的token值重复调用至少5次同一个受保护端点
• 再次查看Lambda的CloudWatch日志：如果从第一次调用之后再也没有新的Authorizer触发日志，就说明缓存完全生效，后续请求全部走缓存判断，没有调用Lambda
• 反向验证：换一个新的有效token调用，应该能看到新的埋点日志；等3600秒的缓存窗口期过了之后，再用最初的同一个token调用，会重新触发一次Authorizer的日志。

无代码修改的辅助验证方式 #

如果不想改动Lambda代码，也可以通过APIGW的访问日志侧面验证：

• 提前开启APIGW的CloudWatch访问日志，确保日志包含integrationLatency字段
• 第一次用同一个token调用API，记录这次的集成时延数值
• 窗口期内重复用同一个token发请求，对比后续请求的时延：缓存生效的情况下，后续请求的时延会比第一次低80%以上——因为第一次要跨服务调用Lambda（通常几十到几百毫秒），后续读缓存是APIGW本地操作，时延只有几毫秒
• 注意：这个方法受网络波动影响，只能作为辅助参考，不能作为最终判定依据。

测试时容易踩的坑 #

• 不要为了测试故意修改无关的请求头/查询参数：APIGW的授权缓存键只由你配置的Identity来源值（这里就是Authorization头的内容）生成，只要这个值不变，不管其他参数怎么改，都会命中缓存
• 如果测试时发现同一个token在窗口期内频繁触发Lambda调用，先去APIGW控制台核对Authorizer的实际配置：确认ReauthorizeEvery值确实是3600，避免SAM部署时配置更新没生效、沿用了旧的配置值
• 注意APIGW的授权缓存是按服务节点独立存储的，不是全局同步的，私网端点的请求路由通常是固定的，正常测试不会出现缓存不命中的情况，除非刚好请求被路由到了冷节点。

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