Amplify中Lambda访问GraphQL生成的DynamoDB表报权限错误及配置疑问

当前配置流程中的明确错误 #

• 代码层硬编码了错误的DynamoDB表名：Amplify通过@model装饰器生成的真实表名带有随机哈希和环境后缀，和代码里写的PublicTable完全不匹配，硬编码的表名根本不是云端实际存在的资源。
• Lambda响应结构不符合API Gateway代理集成的要求：当前返回的对象只包含body字段，缺少statusCode、跨域响应头这些必须的字段，就算权限打通也可能返回502错误。
• 权限绑定错位：在创建REST API关联Lambda的流程中临时配置的资源访问权限，在部分Amplify版本下会漏配到Lambda执行角色上，导致Lambda角色本身没有对应DynamoDB表的操作权限。

为什么已配置访问权限却依然报错 #

这里是Amplify的底层规则叠加操作疏漏导致的：

1. 权限是资源级精确匹配的：向导里看到的Public:@model(appsync)是逻辑层面的资源别名，实际云端的表是名字为Public-<随机字符串>-<环境名>的DynamoDB表，对应唯一的ARN。向导生成的IAM策略只会授权访问这个真实ARN的对应操作，不会泛化匹配所有带"Public"前缀的表。
2. 流程漏洞导致权限漏绑：在amplify add api的REST API创建流程中临时给Lambda加资源权限，旧版本Amplify有时会把这部分权限绑定到AppSync的服务角色上，而非Lambda的执行角色，这也是报错中Lambda角色没有dynamodb:Scan权限的直接原因。
3. 硬编码表名的错位放大了问题：代码里写死的PublicTable和真实表名不匹配，请求指向的资源标识和权限策略的覆盖范围完全对不上，最终触发AccessDenied拦截。

正确的访问方式 #

不需要硬编码任何表名或者ARN，直接读取Amplify自动注入的环境变量即可，修正后的Lambda代码参考：

/* Amplify Params - DO NOT EDIT
    API_MYPROJECT_GRAPHQLAPIIDOUTPUT
    API_MYPROJECT_PUBLICTABLE_ARN
    API_MYPROJECT_PUBLICTABLE_NAME
    ENV
    REGION
Amplify Params - DO NOT EDIT */

const AWS = require("aws-sdk");
const region = process.env.REGION

AWS.config.update({ region });
const docClient = new AWS.DynamoDB.DocumentClient();

// 直接读取环境变量中的真实表名，不做硬编码
const params = {
    TableName: process.env.API_MYPROJECT_PUBLICTABLE_NAME
}

async function listItems(){
    try {
      const data = await docClient.scan(params).promise()
      return data
    } catch (err) {
      return err
    }
}

exports.handler = async (event) => {
    try {
        const data = await listItems()
        // 补全API Gateway要求的标准响应结构
        return {
          statusCode: 200,
          headers: {
            "Access-Control-Allow-Origin": "*",
            "Content-Type": "application/json"
          },
          body: JSON.stringify(data)
        }
      } catch (err) {
        return {
          statusCode: 500,
          body: JSON.stringify({ error: err.message })
        }
    }
};

代码修改完成后，再执行amplify update function，选择listPublic函数，重新勾选对Public表的read权限，最后执行amplify push同步配置到云端。此时环境变量中的表名、Lambda角色的权限范围、实际的DynamoDB表三者标识完全对齐，即可正常访问数据。

自动生成的环境变量的实际作用 #

所有API_<项目名>_<模型名>_<属性>开头的环境变量，都是Amplify在构建阶段自动把云资源的元信息注入到Lambda运行时的配置，不需要手动维护，具体用途：

• API_MYPROJECT_PUBLICTABLE_NAME：自动注入当前环境下Public模型对应的真实DynamoDB表名，就是报错里看到的带哈希后缀的那个表，替代手动硬编码的表名，避免不同环境（dev/test/prod）下表名不一致的问题。
• API_MYPROJECT_PUBLICTABLE_ARN：注入这个表的完整ARN资源标识，如果需要在代码里做资源级校验、或者配置更细粒度的访问规则，可以直接调用这个值，不用手动拼接ARN字符串。
• API_MYPROJECT_GRAPHQLAPIIDOUTPUT：注入项目下AppSync GraphQL API的唯一ID，如果后续需要在Lambda里直接调用GraphQL接口（而非直接读DynamoDB表），可以用这个ID构造正确的API端点和签名请求。
• ENV：注入当前部署的环境名（比如当前的dev环境），用来做多环境隔离的逻辑判断。
• REGION：注入当前资源部署的AWS区域，避免硬编码区域导致跨区域访问延迟或者权限不匹配。

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