不可修改API端点时Lambda如何指定访问目标S3存储对象

核心思路：所有改动做增量兼容，不调整现有API的原有入参、出参、默认逻辑，老服务调用时完全感知不到变化，仅给React侧新增可选的标识传递通道。

• 优先方案：自定义请求头透传
  这是对现有请求侵入性最低的方案，完全不会改动请求URL、请求体结构。

  1. 先在API Gateway侧给现有API配置自定义请求头透传规则，放开自定义头的拦截，头名建议取辨识度高、不会和现有业务头冲突的名称，比如X-Target-JSON-Key
  2. Lambda函数内增加兼容判断逻辑：如果请求携带该自定义头，就取头里的值作为要访问的S3对象键；如果没携带该头，直接走原有逻辑读取默认的JSON文件，和重构前的行为完全一致。核心逻辑示例：

  // 原有默认读取的S3文件键，保持和之前逻辑一致
  const DEFAULT_S3_KEY = 'default-dataset.json'
  // 从请求头取目标文件标识，注意API Gateway透传的头名默认会转小写
  const targetS3Key = event.headers?.['x-target-json-key'] || DEFAULT_S3_KEY
  

  3. React侧切换侧边栏选项时，在请求拦截器或者单次请求配置里，把当前选中的JSON文件对应的S3键值放到该自定义头里传递即可，老服务调用时不会携带这个头，完全不受影响。

• 备选方案1：特殊命名的查询参数
  如果网关配置自定义头有限制，可以选这个方案。注意查询参数名必须足够特殊，绝对不会和现有业务参数重名，比如用__s3_file_key这类带前后双下划线的命名。

  1. API Gateway侧配置该查询参数的透传
  2. Lambda内增加判断：如果URL携带该查询参数就用参数值作为S3对象键，没带就走默认逻辑，示例：

  const targetS3Key = event.queryStringParameters?.__s3_file_key || DEFAULT_S3_KEY
  

  3. React侧请求时把选中的文件键拼到URL查询参数里即可，老请求不会携带这个特殊参数，行为和之前完全一致。

• 备选方案2：新增同源路由绑定同一个Lambda
  如果连请求参数、请求头都不想碰原有路由，可以在API Gateway里给现有Lambda额外绑定新的路由规则，比如原有路由是/api/data保持不动，新增路由/api/dataset/{fileKey}指向同一个Lambda函数。
  Lambda内判断请求路径是否带fileKey路径参数，有就用参数值读对应S3文件，没有（也就是走原有老路由的请求）就走默认逻辑。React侧切换侧边栏时直接调用新路由即可，老路由完全不动，不会影响其他服务。

必要的安全校验 #

不管选哪个方案，必须在Lambda里加S3键白名单校验，只允许访问侧边栏公开的那几个JSON文件，避免恶意传参遍历、读取S3桶内的其他敏感文件，示例：

const ALLOWED_S3_KEYS = [
  'default-dataset.json',
  'sales-2024.json',
  'operation-logs.json'
]
if (!ALLOWED_S3_KEYS.includes(targetS3Key)) {
  return {
    statusCode: 403,
    body: JSON.stringify({ msg: 'invalid target file' })
  }
}

另外记得提前给Lambda绑定的IAM角色补充所有待访问S3对象的s3:GetObject权限，避免换文件后报权限错误。配置完成后先调用原有接口做回归测试，确认返回结果和改动前完全一致再上线新功能。

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