通过Amplify从Secrets Manager访问秘钥时遇CredentialsProviderError问题

核心排查方向 #

Amplify Gen2托管的NextJS服务器端代码不会自动注入AWS凭证，哪怕服务角色权限到位，也得确保凭证提供者的配置逻辑正确。

具体修复步骤 #

1. 规范SecretsManagerClient初始化代码 #

AWS SDK v3默认会走默认凭证链，不要手动指定凭证参数，否则会覆盖默认逻辑。检查你的客户端初始化代码：

import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";

// 只指定区域，不要加任何凭证相关配置
const client = new SecretsManagerClient({
  region: "你的AWS区域" // 必须和Secrets Manager所在区域一致
});

2. 检查服务角色的信任关系 #

光加权限没用，得确保Amplify服务能合法使用这个角色：

1. 打开IAM控制台，找到你的Amplify应用服务角色（名称一般是amplify-<应用ID>-<环境>-serviceRole格式）
2. 查看信任关系，确认包含以下语句：

{
  "Effect": "Allow",
  "Principal": {
    "Service": "amplify.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

如果没有就补上，不然Amplify没法调用这个角色的权限。

3. 改用Amplify托管Secrets（更简单的方案） #

你之前用Amplify Hosting>Secrets没成功，大概率是读取方式不对。Amplify托管的Secrets会直接注入成环境变量，服务器端代码可以直接用process.env读取：

1. 在Amplify控制台的Hosting>Secrets里添加SES密钥（比如SES_ACCESS_KEY_ID和SES_SECRET_ACCESS_KEY）
2. 服务器端action里直接读取：

const sesAccessKey = process.env.SES_ACCESS_KEY_ID;
const sesSecretKey = process.env.SES_SECRET_ACCESS_KEY;

这种方式比Secrets Manager更适配Amplify Gen2，还能避开凭证链问题。

4. 确认CloudWatch日志权限生效 #

虽然你加了日志策略，但要确保角色能写入对应日志组：
Amplify应用的日志组一般是/aws/amplify/<应用ID>/<环境>，给角色添加上以下权限：

{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "arn:aws:logs:<区域>:<账号ID>:log-group:/aws/amplify/<应用ID>/<环境>:*"
}

这样错误日志才能正常记录，方便后续排查。

总结 #

优先用Amplify托管Secrets的方案，适配性最好。如果一定要用Secrets Manager，重点盯紧角色信任关系和SDK初始化逻辑，别手动干预凭证加载流程。

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