1. AWS SNS HTTPS订阅自动删除问题概述最近在项目中遇到一个棘手的问题配置在AWS SNSSimple Notification Service中的HTTPS订阅会莫名其妙地被自动删除。这个问题直接导致我们的消息通知系统出现严重漏洞——部分终端用户收不到关键的业务通知。经过一周的深入排查终于找到了根本原因和解决方案。HTTPS订阅是SNS中常用的一种消息推送方式它允许SNS将消息通过HTTPS协议推送到我们指定的Webhook地址。相比SQS队列订阅HTTPS订阅更适合需要实时推送且接收端为Web服务的场景。但在实际使用中HTTPS订阅的稳定性问题经常让开发者头疼。2. 问题现象与初步排查2.1 异常现象描述我们的系统架构中SNS负责将订单状态变更通知推送到多个微服务。突然有一天运维团队发现部分服务的订阅关系消失了。具体表现为在AWS控制台的SNS订阅列表中部分HTTPS订阅状态显示为DeletedCloudWatch日志中出现Subscription deleted的记录但没有人工操作记录问题呈现间歇性出现约每周发生1-2次被删除的订阅都是HTTPS类型SQS和Lambda订阅不受影响2.2 初步排查步骤首先我们按照AWS的标准排查流程进行了检查检查IAM权限确认没有自动化脚本或第三方服务拥有sns:Unsubscribe权限查看CloudTrail日志过滤sns:Unsubscribe API调用确实没有找到相关记录检查订阅终端点Endpoint所有HTTPS端点均运行正常返回2xx状态码检查重试策略SNS默认重试3次我们的端点响应时间在300ms以内不太可能触发重试失败3. 深入分析与根本原因定位3.1 SNS订阅健康检查机制通过查阅AWS文档和联系技术支持我们了解到SNS有一个不为人知的重要机制自动订阅健康检查。这个机制的工作原理是SNS会定期约每天一次向HTTPS订阅端点发送确认请求端点需要在规定时间内返回200 OK响应如果连续多次通常是3次检查失败SNS会自动标记并删除该订阅3.2 实际问题根源通过进一步分析我们发现问题的根本原因有两个端点响应格式不符要求SNS的健康检查请求是特殊的确认请求非普通消息我们的端点没有区分普通消息和确认请求对所有请求都返回相同的业务响应虽然返回200状态码但响应体不符合SNS期望的格式网络中间件干扰公司最近部署了新的API网关某些健康检查请求被网关拦截并修改了头部信息导致SNS无法正确验证响应4. 解决方案与实施步骤4.1 修复端点逻辑我们修改了Webhook端点的处理逻辑app.route(/sns-webhook, methods[POST]) def handle_sns(): # 检查是否为订阅确认请求 if request.headers.get(x-amz-sns-message-type) SubscriptionConfirmation: # 获取订阅确认URL subscribe_url request.json.get(SubscribeURL) # 访问确认URL完成订阅 requests.get(subscribe_url) # 返回空200响应 return , 200 # 正常消息处理逻辑 process_message(request.json) return , 200关键改进点明确区分订阅确认请求和普通消息对确认请求按照SNS要求进行处理保持响应简洁避免多余内容4.2 网络架构调整针对网络中间件问题我们做了以下调整将SNS的源IP范围AWS官方公布加入API网关白名单配置网关规则不对SNS相关请求进行修改为SNS健康检查请求设置专用路由4.3 监控与告警增强为防止问题再次发生我们增加了以下监控措施CloudWatch警报监控SNS订阅数量的异常变化设置订阅删除事件的告警自定义健康检查每5分钟检查所有订阅状态发现异常自动触发修复流程5. 验证与效果评估5.1 测试方案我们通过以下方式验证修复效果手动触发SNS订阅确认请求aws sns confirm-subscription \ --topic-arn arn:aws:sns:us-west-2:123456789012:my-topic \ --token 2336412f37...使用SNS测试通知功能发送测试消息aws sns publish \ --topic-arn arn:aws:sns:us-west-2:123456789012:my-topic \ --message 测试消息模拟网络故障观察系统行为5.2 实施效果修复后经过一个月观察订阅自动删除问题完全消失消息投递成功率从92%提升到99.99%系统稳定性显著提高6. 经验总结与最佳实践6.1 关键教训不要忽视SNS的健康检查机制这是AWS文档中不太强调但非常重要的功能必须正确处理SubscriptionConfirmation和UnsubscribeConfirmation请求网络中间件的影响网关、代理等中间件可能修改请求/响应需要为SNS通信设置专用规则监控订阅状态SNS订阅变化应该纳入核心监控指标建议设置订阅数量变化的告警阈值6.2 推荐实践基于这次经验我们总结出以下最佳实践端点实现规范必须支持三种SNS请求类型SubscriptionConfirmationNotificationUnsubscribeConfirmation每种类型需要不同的处理逻辑错误处理建议对SNS请求实现完善的日志记录对失败请求实施指数退避重试设置死信队列收集无法处理的消息架构设计考虑对于关键业务建议使用SQS轮询作为备用方案考虑在客户端实现消息本地缓存重要通知应该实现多通道冗余投递7. 高级配置与优化建议7.1 重试策略配置虽然SNS有默认的重试机制但我们可以通过订阅属性进行优化aws sns set-subscription-attributes \ --subscription-arn arn:aws:sns:us-west-2:123456789012:my-topic:... \ --attribute-name DeliveryPolicy \ --attribute-value { healthyRetryPolicy: { minDelayTarget: 20, maxDelayTarget: 60, numRetries: 5, numNoDelayRetries: 1, backoffFunction: linear }, throttlePolicy: { maxReceivesPerSecond: 10 } }7.2 死信队列设置为处理无法投递的消息建议配置死信队列首先创建专用SQS队列aws sqs create-queue --queue-name sns-dlq然后将其配置为SNS订阅的死信队列aws sns set-subscription-attributes \ --subscription-arn arn:aws:sns:us-west-2:123456789012:my-topic:... \ --attribute-name RedrivePolicy \ --attribute-value { deadLetterTargetArn: arn:aws:sqs:us-west-2:123456789012:sns-dlq }7.3 消息过滤优化对于大型系统可以使用SNS的消息过滤功能减少不必要的推送aws sns subscribe \ --topic-arn arn:aws:sns:us-west-2:123456789012:my-topic \ --protocol https \ --notification-endpoint https://example.com/endpoint \ --attributes { FilterPolicy: {\eventType\:[\orderUpdate\]} }8. 常见问题解决方案速查表问题现象可能原因解决方案订阅被自动删除健康检查失败检查端点是否正确处理SubscriptionConfirmation请求收不到消息但订阅存在端点响应超时优化端点性能确保500ms内响应重复收到相同消息端点返回非2xx状态码确保正确处理消息后返回200控制台显示订阅PendingConfirmation未完成订阅确认手动访问SubscribeURL或重新订阅部分消息丢失订阅属性配置不当检查DeliveryPolicy和RedrivePolicy设置