如何确保跨账号SNS主题-SQS订阅正常及相关监控与部署问题

问题1：如何监控SNS主题的订阅状态？ #

可行的监控方案 #

• 自定义Lambda+EventBridge轮询：这个方案务实且有效，无需复杂逻辑。通过EventBridge定时触发Lambda，调用SNS的list_subscriptions_by_topic API，检查目标跨账号SQS订阅的SubscriptionArn是否存在、状态是否为Confirmed。将检查结果作为自定义指标推送到CloudWatch，设置告警阈值（比如连续2次检查到订阅状态异常就触发告警）。
  • 权限配置注意：给Lambda授予SNS的ListSubscriptionsByTopic权限，以及CloudWatch的PutMetricData权限即可。
• 基于CloudWatch原生指标的告警：你提到的NumberOfMessagesPublished - NumberOfNotificationsDelivered差值告警，确实能快速发现消息未被投递的异常，但这个属于事后告警——触发时消息已经因无有效订阅被静默丢弃，无法直接恢复。所以这个指标适合配合备份机制使用。

消息丢失的补救措施 #

如果要解决消息恢复的问题，不能只靠监控，得提前做留存设计：

• 启用SNS消息存档：开启SNS主题的消息存档功能，所有发布到主题的消息会自动存储到指定S3桶，最长可保留90天。订阅失效或部署期间丢失的消息，都可以事后从S3存档中拉取恢复。
• 添加备份订阅：在SNS所在账号下创建一个备用SQS队列，订阅该主题。当跨账号主订阅失效时，消息会投递到备用队列，后续可以从这里恢复消息。注意给备用队列配置正确的权限，可定期清理过期消息以控制成本。

是否值得担忧？ #

值得。虽然你启用了资源删除保护，但订阅失效的风险不止于误删：比如跨账号信任关系变更（如SQS队列策略取消了SNS的投递权限）、订阅确认状态失效（极少但可能发生）等情况，都会导致消息静默丢失。监控能帮你及时发现异常，避免问题扩大。

问题2：是否需要担忧部署期间的订阅不可用问题？ #

需要，尤其是业务对消息可靠性要求较高时，但可以通过优化部署流程和配置降低风险：

部署期间可能导致不可用的场景 #

• 如果CDK部署涉及删除旧订阅后重建新订阅，中间会存在短暂的无订阅间隙，这段时间发布的消息会丢失。
• 如果部署修改了SNS或SQS的权限策略，可能导致订阅权限临时失效，消息投递失败。

缓解方案 #

• 调整CDK部署顺序：先确保跨账号SQS的队列策略配置完成（允许SNS所在账号投递），再创建或更新SNS订阅，最后启动依赖该订阅的业务服务。避免因权限未就绪导致订阅失效。
• 采用蓝绿式订阅部署：先创建新的订阅（比如临时备份订阅+新主订阅），确认新订阅状态正常、权限生效后，再删除旧订阅，完全消除部署间隙。
• 启用SNS消息存档：如问题1所述，部署期间的消息会被存档到S3，即使订阅不可用，也能事后恢复。
• 避免不必要的订阅变更：如果只是修改SNS主题的过滤策略等非订阅核心属性，AWS会实时更新，不会导致订阅不可用，无需担忧。

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