配置权限策略后部署到ECS的应用访问SQS Queue仍被拒绝

1 优先确认ECS角色配置是否正确 #

这是90%以上同类问题的根因，很多开发者会混淆ECS的两类角色：

• ECS任务执行角色（Task Execution Role）：仅用于ECS服务层面的操作，比如拉取ECR镜像、读取Secrets Manager/Parameter Store的配置、推送日志到CloudWatch，业务代码不会使用该角色的权限。
• ECS任务角色（Task Role）：是ECS容器内运行的代码默认使用的身份，你需要把SQS的读写权限、以及后续提到的其他必要权限绑定到这个角色上，而不是任务执行角色。

2 你的代码存在隐藏Bug #

当前的分支判断逻辑存在疏漏：

if(!String.IsNullOrEmpty(appSettings.AwsProfile))
{
    var credentialProfileStoreChain = new CredentialProfileStoreChain();
    AWSCredentials credentials;
    // 此处未判断TryGet的返回值
    credentialProfileStoreChain.TryGetAWSCredentials(appSettings.Aws.Profile, out credentials);
    return new AmazonSQSClient(credentials, sqsConfig);
}

如果ECS部署环境中不小心注入了非空的AwsProfile配置（比如环境变量、配置文件误写），就会进入这个分支，但ECS容器内根本没有对应的本地凭证配置，TryGetAWSCredentials会返回false，credentials为空值，此时初始化客户端会使用默认的匿名凭证，自然会被拒绝访问。
建议修改逻辑：只有TryGetAWSCredentials返回true的时候才走该分支，否则回退到默认凭证链逻辑。

3 其他需要核对的权限点 #

即使你确认任务角色已经绑定了SQS权限，还要检查以下配置：

• SQS队列的资源策略：如果队列配置了自定义资源策略，需要明确允许任务角色ARN访问对应操作，不要仅限制了本地开发用的IAM用户。
• KMS权限：如果你的SQS队列开启了服务端加密（SSE-KMS），除了SQS本身的权限，还要给任务角色授予对应KMS密钥的kms:Decrypt、kms:GenerateDataKey权限，否则也会触发访问拒绝。
• VPC端点限制：如果你是通过VPC端点访问SQS，需要检查VPC端点的策略是否允许任务角色访问目标队列。

4 快速验证方法 #

你可以在ECS运行的代码中加入临时日志，调用STS的GetCallerIdentity接口，打印当前身份的ARN，就能直接确认代码实际使用的身份是否为你预期的任务角色：

var stsClient = new AmazonSecurityTokenServiceClient();
var identity = await stsClient.GetCallerIdentityAsync(new GetCallerIdentityRequest());
Console.WriteLine($"Current identity: {identity.Arn}");

如果打印出来的ARN不是你配置的任务角色，就说明凭证链获取的身份有误，再顺着这个方向排查即可。

另外你部署分支的初始化写法是符合AWS .NET SDK规范的，默认会走SDK的标准凭证提供链，在ECS环境下会自动读取容器内的ECS_CONTAINER_CREDENTIALS_RELATIVE_URI环境变量获取任务角色的临时凭证，不需要额外配置。

内容的提问来源于stack exchange，提问作者A Horse From Belgrade