AWS Lambda经URL/API Gateway调用时无DynamoDB权限排查

• 现有一组可正常读写DynamoDB表的Lambda函数，近期新建的Lambda仅实现对配套DynamoDB表的putItem操作
• 控制台内置测试功能调用新函数可成功执行，通过Function URL或API Gateway触发时抛出权限相关错误
• 已在Lambda「配置 > 权限」页确认函数配置了对应DynamoDB访问权限，与正常运行的旧函数逐项比对配置无差异
• 错误日志参考：
• Lambda权限配置页参考：

首先明确核心权限逻辑差异：Lambda控制台内置测试调用时，会使用当前登录控制台的IAM用户身份生成临时凭证，最终生效权限是当前登录用户权限 + Lambda执行角色权限的并集；而Function URL、API Gateway触发时，Lambda仅使用自身绑定执行角色的权限，不会叠加控制台身份权限，这是两类触发方式表现不一致的最常见诱因。可按以下优先级排查：

1. 执行角色基础配置校验 #

• 打开Lambda绑定的执行角色对应的IAM控制台页面，检查信任策略（Trust Policy）是否将lambda.amazonaws.com配置为可信主体，且正确配置sts:AssumeRole操作的放行规则，不要额外添加仅允许控制台来源调用的条件限制
• 检查角色是否配置了权限边界（Permissions boundary）：若新角色误配置了权限边界，限制了公网触发链路的DynamoDB访问权限，就会出现控制台可用、触发调用报错的问题
• 检查角色是否挂载了显式Deny策略：部分自动生成的角色会添加aws:CalledVia类条件判断，若条件中未放行API Gateway、Function URL的调用链路，会直接拦截对应请求

2. DynamoDB相关权限细项校验 #

• 不要仅确认策略包含dynamodb:PutItem动作，重点核对策略中Resource字段的ARN是否完全匹配新建DynamoDB表的完整ARN，常见错误为复制旧函数策略时未修改ARN中的表名、区域、账号ID字段
• 若DynamoDB表配置了表级资源策略，检查表策略是否存在显式拒绝规则：很多人配置表策略时会添加来源条件判断，漏放API Gateway、Function URL触发场景下的Lambda服务主体访问权限
• 若DynamoDB表使用自定义KMS CMK密钥加密，需确认Lambda执行角色已配置该密钥的kms:GenerateDataKey、kms:Decrypt权限：控制台测试时会复用当前登录用户的KMS权限，公网触发时仅校验Lambda角色权限，缺失KMS权限时同样会抛出DynamoDB访问拒绝错误，极易被误判为缺少DynamoDB动作权限

3. 触发链路的身份传递校验 #

• 若使用API Gateway触发，检查是否配置了身份覆盖规则：比如开启IAM认证、自定义授权器时，若配置了错误的角色传递规则，会导致Lambda实际运行时使用的执行身份不是你预期的、带DynamoDB权限的角色
• 若使用Function URL触发，检查认证类型配置：如果认证类型设为AWS_IAM，调用时传入的IAM身份权限会和Lambda执行角色权限合并，若调用身份存在DynamoDB相关的显式Deny策略，会直接覆盖Lambda角色的Allow规则

4. 快速定位根因的操作方法 #

• 在Lambda代码中临时添加日志，打印运行时的process.env.AWS_ROLE_ARN、SDK初始化时使用的身份ARN，确认公网触发时实际使用的执行角色和预期一致
• 使用IAM策略模拟器排查：选择Lambda绑定的执行角色，选择dynamodb:PutItem操作，填入新DynamoDB表的ARN，模拟Lambda服务主体发起调用，模拟器会直接返回拦截请求的具体策略、具体条件
• 筛选对应时间点的CloudTrail事件日志，找到失败的PutItem事件记录，查看事件中的errorMessage字段，会明确标注权限拒绝的具体原因，是缺少动作权限、缺少KMS权限还是资源策略拦截

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