为什么我的.NET Lambda API部署后无法正常操作DynamoDB？

1. 首要问题：AWS凭证获取逻辑不适配Lambda运行环境 #

你当前的代码用BasicAWSCredentials硬读取DYNAMODB_ACCESS_KEY、DYNAMODB_SECRET_KEY两个环境变量生成凭证，AWS Lambda默认不会自动注入这两个环境变量，本地运行时你提前配置了对应变量所以运行正常，部署到Lambda后读取到的是空值，导致DynamoDB客户端初始化失败，卡在Table.LoadTable步骤。

• 优化方案：直接使用Lambda自带的执行角色权限，不需要手动传入凭证，修改DynamoDB客户端初始化逻辑即可：

// 错误写法：手动传入BasicAWSCredentials
// AmazonDynamoDBClient client_ = new AmazonDynamoDBClient(_connection, RegionEndpoint.USEast2);

// 正确写法：Lambda会自动读取执行角色的权限，不需要手动传凭证
AmazonDynamoDBClient client_ = new AmazonDynamoDBClient(RegionEndpoint.USEast2);

同时可以删除构造函数里读取环境变量生成_connection的冗余代码。

2. 必须配置Lambda执行角色的DynamoDB操作权限 #

就算你解决了凭证问题，也需要给Lambda绑定的执行角色添加对应DynamoDB表的操作权限，权限策略示例如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem",
                "dynamodb:UpdateItem",
                "dynamodb:GetItem",
                "dynamodb:Query",
                "dynamodb:Scan",
                "dynamodb:DeleteItem",
                "dynamodb:DescribeTable"
            ],
            "Resource": "arn:aws:dynamodb:us-east-2:<你的AWS账号ID>:table/TblUsers_"
        }
    ]
}

• 注意替换策略里的AWS账号ID，确保资源ARN和你的实际DynamoDB表匹配。

3. 其他排查项 #

• 确认DynamoDB表TblUsers_确实部署在us-east-2区域，和你代码里写死的区域一致
• 确认Lambda部署的区域和DynamoDB表区域一致，跨区域调用可能因为网络配置导致访问失败
• 去AWS控制台CloudWatch日志组里找到对应Lambda的日志，查看具体报错信息，你代码里已经打印了异常信息，日志里可以直接定位具体故障点

内容的提问来源于stack exchange，提问作者Camilo Ortúzar