嘿，我来帮你捋捋这个问题——用STS角色访问DynamoDB时踩坑太常见了，咱们从代码到IAM权限一步步排查：

一、先补全你的代码逻辑 #

你当前的代码只完成了AssumeRole获取临时凭证的步骤，但还没把这些凭证用来初始化DynamoDB客户端，这大概率是问题根源之一。完整的流程应该是这样的：

import boto3
def lambda_handler(event, context):
    sts_client = boto3.client('sts')
    # 调用AssumeRole获取临时凭证
    assumedRoleObject = sts_client.assume_role(
        RoleArn="arn:aws:iam::012345678910:role/test_role",
        RoleSessionName="AssumeRoleSession1"
    )
    # 从响应中提取临时密钥、密钥ID和会话令牌
    credentials = assumedRoleObject['Credentials']
    # 用临时凭证初始化DynamoDB客户端
    dynamodb_client = boto3.client(
        'dynamodb',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken']
    )
    # 示例：执行一个DynamoDB操作（按需替换成你的业务逻辑）
    try:
        response = dynamodb_client.get_item(
            TableName='YourTargetTableName',
            Key={'id': {'S': 'sample-id'}}
        )
        return {'statusCode': 200, 'body': response}
    except Exception as e:
        return {'statusCode': 500, 'body': str(e)}

如果跳过了初始化DynamoDB客户端的步骤，Lambda会默认用自身执行角色的权限去访问DynamoDB，自然会触发权限报错。

二、IAM权限配置是重灾区，要检查两个角色 #

这部分是90%的人会踩的坑，得同时检查Lambda执行角色和被Assume的test_role：

• Lambda执行角色：必须拥有sts:AssumeRole权限，允许它去调用目标test_role。给执行角色附加这样的策略：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::012345678910:role/test_role"
        }
    ]
}

• 被Assume的test_role：
  1. 信任策略必须允许你的Lambda执行角色来assume它，信任策略配置如下：

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Principal": {
                  "AWS": "arn:aws:iam::012345678910:role/你的Lambda执行角色ARN"
              },
              "Action": "sts:AssumeRole"
          }
      ]
  }
  

  2. 必须拥有访问目标DynamoDB表的权限，比如给它附加这样的策略（按需调整操作和表ARN）：

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "dynamodb:GetItem",
                  "dynamodb:PutItem",
                  "dynamodb:Scan"
                  // 按需添加你需要的DynamoDB操作
              ],
              "Resource": "arn:aws:dynamodb:你的AWS区域:012345678910:table/你的目标表名"
          }
      ]
  }
  

三、针对具体报错的快速修复 #

如果已经完成上面的步骤还是报错，对应错误信息直接定位：

• AccessDeniedException：要么Lambda执行角色没sts:AssumeRole权限，要么test_role的信任策略没放开，要么test_role缺少DynamoDB操作权限，挨个排查就行。
• InvalidClientTokenId：临时凭证过期或无效——STS临时凭证默认有效期1小时，最长可设为12小时，如果Lambda执行时间较长，记得在凭证过期前重新调用AssumeRole刷新。
• ResourceNotFoundException：检查DynamoDB表的ARN是否正确，同时确保Lambda初始化DynamoDB客户端时指定的区域和表所在区域一致（如果没指定区域，会默认用Lambda所在区域）。

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