ASP.NET Core+Cognito应用部署后IAM凭证获取失败，求管理方案

这个问题我之前帮团队排查过好几次，本质是开发环境和生产部署环境的凭证获取机制完全不同：开发时你依赖本地AWS Toolkit的默认配置文件（存在~/.aws/credentials或Windows的C:\Users\<你的用户名>\.aws\credentials），但部署到AWS资源上后，应用会默认尝试从EC2实例元数据服务（IMDS）拉取凭证——如果你的部署资源没关联正确的IAM角色，就会抛出这个错误。

下面是生产环境中最推荐的凭证管理方案，按优先级排序：

1. 给AWS部署资源关联IAM角色（首选方案） #

这是AWS官方最推崇的安全实践，完全不需要手动管理凭证：

• 如果部署在EC2：创建一个IAM角色，给它附加访问Cognito所需的细粒度权限（比如cognito-idp:AdminInitiateAuth、cognito-idp:AdminGetUser，避免用过度宽泛的AmazonCognitoPowerUser），然后把这个角色关联到你的EC2实例。应用会自动通过IMDS获取临时、自动轮换的凭证，不需要任何额外配置。
• 如果部署在ECS/Fargate：给任务定义附加IAM执行角色，同样配置好Cognito权限即可。
• 如果部署在Elastic Beanstalk：在环境配置的"实例角色"选项中指定刚才创建的IAM角色。

好处：凭证自动轮换、无硬编码风险、权限可精准控制，完全符合AWS安全规范。

2. 用AWS Secrets Manager/Parameter Store存储凭证（非AWS托管环境适用） #

如果你的应用部署在非AWS服务器（比如自建VM、本地IDC），绝对不要把凭证硬编码到代码或配置文件里：

• 将AWS访问密钥ID和秘密访问密钥存储到Secrets Manager中，然后在ASP.NET Core启动时通过SDK拉取这些凭证。
• 示例配置（借助AWSSDK.Extensions.NETCore.Setup包）：

  // Program.cs
  builder.Services.AddDefaultAWSOptions(builder.Configuration.GetAWSOptions());
  // 自定义配置提供者从Secrets Manager加载凭证
  builder.Configuration.AddAwsSecretsManager(secretId: "你的Cognito凭证密钥ID");
  builder.Services.AddAWSService<IAmazonCognitoIdentityProvider>();
  

3. 绝对禁止的操作 #

• 不要把本地的.aws/credentials文件提交到版本控制系统（Git等）。
• 不要硬编码凭证到appsettings.json、环境变量或代码中（临时测试除外）。
• 不要给IAM用户分配过度宽泛的权限，始终遵循最小权限原则。

快速排查步骤 #

如果已经配置了IAM角色仍报错，可以在部署的资源上做简单验证：

• 在EC2实例上执行aws sts get-caller-identity，查看当前凭证对应的角色是否正确，权限是否包含Cognito操作。
• 检查IAM角色的信任策略，确保允许当前部署资源（比如EC2、ECS）扮演该角色。

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