AWS Lambda调用AppSync Mutation遇IAM授权错误求排查方案

针对你遇到的Not Authorized to access createSensorData on type Mutation错误，可以从以下几个方向排查：

1. 检查Lambda执行角色的权限 #

• 确认Lambda的执行角色拥有AppSync GraphQL操作的权限：
  • 打开IAM控制台，找到Lambda对应的角色，查看附加的策略是否包含类似以下的权限：

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "appsync:GraphQL",
          "Resource": "arn:aws:appsync:${REGION}:${ACCOUNT_ID}:apis/${API_ID}/*"
        }
      ]
    }
    

  • 检查是否存在拒绝策略（比如权限边界、组织SCP）限制了该角色的AppSync访问权限。

2. 验证AppSync API的IAM授权配置 #

• 登录AppSync控制台，进入你的API，在设置页面确认已启用IAM作为授权模式之一。
• 再次核对生成的Schema中Mutation的@aws_iam指令，确保没有拼写错误（指令必须是小写的@aws_iam）。

3. 检查Lambda中签名请求的正确性 #

• 确认签名时的service参数为appsync（你的代码中已设置，但需确保没有拼写错误）。
• 在Lambda handler中添加日志，打印签名后的请求头，验证Authorization和x-amz-date等签名字段是否正确生成：

  console.log('Signed request headers:', signed.headers);
  

• 尝试用Postman手动构造签名请求测试：使用AWS Signature Version 4签名，指定service为appsync，发送相同的Mutation，看是否能成功，以此排除代码层面的问题。

4. 核对Schema的@auth规则细节 #

• 你使用的allow: private规则允许已认证的实体（IAM角色、Cognito用户）访问，但需确认：
  • 没有在规则中添加额外的conditions或ownerField限制（你的配置中没有，可忽略）。
  • 不存在其他冲突的@auth规则（比如deny类型的规则）。

5. 启用调试工具定位问题 #

• 开启AppSync的CloudWatch日志：在AppSync控制台设置页面，将日志级别设为ALL，然后重新执行Lambda，查看CloudWatch日志中详细的授权拒绝原因，日志会明确指出是权限缺失、签名错误还是规则不匹配。
• 使用IAM Access Analyzer：扫描Lambda执行角色，检查是否存在权限配置错误或外部限制。
• 简化测试场景：创建一个仅包含IAM授权的极简类型（比如Test @model @auth(rules: [{allow: private, provider: iam}]) {id: ID!}），用Lambda执行对应的createTest Mutation，验证是否能成功，排除多授权模式（IAM+User Pools）的冲突。

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