新创建的SQS订阅因Subscription Principal导致消息投递异常

核心原因：AWS SNS订阅权限模型的隐性变更 #

AWS近期调整了SNS订阅的权限管控逻辑，新增的Subscription Principal字段用于指定允许接收订阅消息的主体身份，本质是强化了SNS到SQS的投递权限校验。之前手动创建订阅时AWS会默认赋予宽松权限，现在则要求明确指定Principal，否则会因权限不足导致消息投递失败。

解决办法 #

1. 对齐NServiceBus自动创建的Principal值 #

NServiceBus自动创建订阅时，会使用自身的IAM角色（或服务关联角色）作为Subscription Principal，你需要将手动创建的订阅该字段值修改为和自动创建的一致：

• 打开AWS SNS控制台，找到目标订阅
• 编辑订阅，将Subscription Principal设置为NServiceBus使用的IAM角色ARN（可从自动创建的订阅中复制）

2. 手动配置SQS的权限策略 #

如果无法修改Principal，可直接给目标SQS队列添加允许SNS主题投递的权限策略，示例如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:你的区域:账号ID:目标队列名称",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:sns:你的区域:账号ID:关联的SNS主题ARN"
        }
      }
    }
  ]
}

注意替换其中的区域、账号ID、队列和主题ARN。

3. 让NServiceBus接管手动资源的管理 #

如果后续还要扩展消息类型，建议将之前手动创建的队列/主题/订阅纳入NServiceBus的自动管理范围，避免手动操作带来的权限不一致问题：

• 在NServiceBus配置中指定对应资源的名称，让框架在启动时自动校验并修正权限配置

为什么之前没问题？ #

AWS在2024年初对SNS订阅的默认权限做了收紧，之前手动创建订阅时，AWS会自动给SQS添加允许所有SNS主题投递的权限（或默认填充合适的Principal），现在则要求用户明确指定，这就是你数月前操作正常、现在失败的原因。

内容的提问来源于stack exchange，提问作者Mr. Spock