在AWS中配置策略与角色，实现API Gateway直连DynamoDB

我太懂你这种不想靠“试错碰运气”搞权限的心情了——AWS的IAM策略要是没捋透底层逻辑，要么报错卡半天，要么不小心留了安全隐患，确实得把每一步的权限逻辑掰明白再动手。下面我就把API Gateway直接对接DynamoDB所需的核心权限配置拆解清楚，帮你补上那些教程里默认跳过的关键细节：

1. 首先得给API Gateway准备一个「执行角色」 #

这个角色是API Gateway用来调用DynamoDB的身份凭证，核心是要让API Gateway有权限“扮演”这个角色。你需要给角色配置信任关系策略，内容如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "apigateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

简单说就是告诉AWS：允许API Gateway服务来使用这个角色。

2. 给角色赋予DynamoDB的操作权限 #

接下来要给这个角色加权限策略，明确它能对DynamoDB做什么操作。假设你是要把API请求数据写入DynamoDB，策略可以这么写：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:UpdateItem" // 如果你需要更新数据就加上，否则只留PutItem
      ],
      "Resource": "arn:aws:dynamodb:你的AWS区域:你的账号ID:table/你的目标表名"
    }
  ]
}

这里一定要遵循最小权限原则：只给需要的动作（比如只写就不要加读权限），资源ARN要精确到具体表，别用通配符偷懒。

3. 在API Gateway里关联这个角色 #

最后一步是在API Gateway的集成配置里绑定这个角色：

• 把集成类型选成「AWS Service」
• 服务选「DynamoDB」，动作选你需要的（比如PutItem）
• 在「执行角色」字段填入刚才创建的角色ARN
• 别忘了配置映射模板，把API的请求体转换成DynamoDB能识别的格式，举个简单的例子：

{
  "TableName": "你的目标表名",
  "Item": {
    "requestId": { "S": "$context.requestId" }, // 用API网关的请求ID当主键示例
    "payload": { "S": "$input.json('$')" } // 把整个请求体存成字符串
  }
}

模板里的字段类型（比如S代表字符串、N代表数字）必须和你DynamoDB表的Schema完全匹配，不然会报错。

几个容易踩的权限坑 #

• 信任关系里的Principal必须是apigateway.amazonaws.com，写错一个字母都不行
• 不要给角色加dynamodb:*这种全权限，万一API Gateway被滥用后果很严重
• 资源ARN里的区域和账号ID要和你的DynamoDB表完全一致，跨区域会直接权限拒绝

要是你找到的那个Stack Overflow问题里有具体的报错或者特殊场景，也可以把细节贴出来，我帮你针对性分析~

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