多租户场景下共用同一SQS队列时如何实现消费者侧消息隔离

原生receive-message接口的attribute-name参数确实不支持按消息属性过滤消息，要满足租户间消息绝对隔离的需求，可采用以下几种成熟方案： #

方案一：按租户拆分专属SQS队列（强隔离首选） #

这是隔离性最高、最稳妥的实现方案，完全满足「租户绝对无法查看其他租户消息」的要求：

• 生产者发送消息时，根据消息属性中的tenant-id直接路由到对应租户专属的SQS队列
• 为每个租户的消费者身份单独配置IAM权限，仅授予对应专属队列的sqs:ReceiveMessage、sqs:DeleteMessage等必要权限，完全禁止访问其他租户的队列
• 租户消费者直接轮询自有专属队列即可，不需要做任何额外过滤逻辑，性能也最优
• 适用场景：租户数量可控，不会超过当前AWS区域下SQS队列配额（默认配额为10000个/区域，可提交工单申请上调）

方案二：SNS+SQS组合搭配消息过滤规则（租户数量大时首选） #

如果租户数量特别多，拆分大量SQS队列不符合成本或者配额要求，可以采用这个方案，隔离性和方案一一致：

• 生产者统一将消息发送到公共SNS主题，发送时将tenant-id作为消息属性携带
• 为每个租户创建专属SQS队列，再将该队列订阅到公共SNS主题，订阅时配置消息过滤规则，仅匹配对应tenant-id的消息。SNS侧会自动完成消息过滤，只有匹配规则的消息才会被推送到对应租户的专属队列，不匹配的消息会直接被过滤掉
• 租户消费者同样仅持有自有专属队列的访问权限，轮询自有队列即可拿到仅属于自己租户的消息

不推荐方案：单队列+消费者侧过滤 #

如果强制使用单队列实现，消费者收到消息后可以先判断消息属性中的tenant-id，如果不属于当前租户就立即将消息的可见性超时设置为0，放回队列。但这个方案完全不符合题目的强隔离要求：租户消费者实际上已经获取到了其他租户的消息内容，存在数据泄露风险，仅适合隔离要求极低的内部场景，不建议在多租户生产环境使用。 #

所有方案都需要配合严格的IAM权限管控，禁止给租户消费者授予超出自身访问范围的权限，从权限层面避免越权访问风险。

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