如何在 AWS Lambda 中正确使用临时凭证生成 S3 预签名 URL

本文详解为何 Lambda 中调用 getSignedUrl 时会意外继承函数执行角色权限，而非你显式传入的 Cognito 临时凭证权限，并指出关键遗漏项------sessionToken 的缺失导致凭证失效，最终使预签名 URL 权限降级。 本文详解为何 lambda 中调用 `getsignedurl` 时会意外继承函数执行角色权限，而非你显式传入的 cognito 临时凭证权限，并指出关键遗漏项------`sessiontoken` 的缺失导致凭证失效，最终使预签名 url 权限降级。在 AWS Lambda 函数中，通过 Cognito Identity Pool 获取临时安全凭证（AccessKeyId、SecretKey 和 SessionToken），再将其注入 S3Client 以生成具备特定权限的 S3 预签名 URL（Presigned URL），是一种常见且推荐的无状态授权模式。然而，许多开发者遇到一个隐蔽却关键的问题：生成的 URL 访问时返回 403 AccessDenied，除非将本应作用于临时凭证的 IAM 策略（如 s3:GetObject）也附加到 Lambda 执行角色上。这看似违背设计预期------预签名 URL 的权限应完全由签名所用凭证的权限决定，而非 Lambda 角色。根本原因在于：你传入 S3Client 的凭证对象不完整，导致 SDK 自动回退（fallback）至 Lambda 执行角色的默认凭证链。AWS SDK v3 要求使用临时凭证（如来自 GetCredentialsForIdentity 的响应）时，必须同时提供三项字段：accessKeyIdsecretAccessKeysessionToken而你的初始化代码中遗漏了 sessionToken：const s3Client = new S3Client({ region: region, credentials: { // 注意：此处应为小写 'credentials'，非 'Credentials' accessKeyId: accessKey, secretAccessKey: secretKey, // ? 缺少 sessionToken → SDK 将忽略该凭证对象 }});由于 sessionToken 缺失，SDK 认为该凭证无效，继而跳过它，转而从环境变量、EC2 metadata 或 Lambda execution role 中自动加载默认凭证（即 Lambda 角色）。此时 getSignedUrl 实际使用的是 Lambda 角色的权限签名，因此只有当该角色拥有对应 S3 权限时，URL 才能生效------这也解释了你观察到的"策略必须绑定到 Lambda 角色"的现象。 唱鸭 音乐创作全流程的AI自动作曲工具，集 AI 辅助作词、AI 自动作曲、编曲、混音于一体