AWS IoT对接Lambda的MQTT消息投递可靠性及SQS作用咨询

1. IoT Core 入站消息交付到 Lambda 的风险说明 #

确实存在交付失败的可能性，常见触发原因包括 Lambda 并发额度被占满触发节流、Lambda 执行逻辑持续报错、IoT 规则调用 Lambda 的权限配置错误、消息负载超出 Lambda 调用大小限制等。
AWS 官方默认的重试策略是 IoT Core 调用 Lambda 失败后最多重试 3 次，未配置错误动作的情况下，重试失败的消息会被直接丢弃。

2. Lambda 向设备发送出站 MQTT 消息的风险说明 #

也存在投递失败的可能性，常见触发原因包括设备长时间离线、MQTT QoS 配置为 0（发后即忘）、Lambda 调用 IoT Core Publish API 时触发限流/权限报错/网络波动、设备超过 1 小时未上线拉取 QoS1/QoS2 离线消息（IoT Core 离线消息最长保留 1 小时）等。

轻量可靠性优化方案（无过度设计） #

入站消息侧（IoT Core → Lambda）优化 #

• 优先给 IoT Core 规则配置错误动作，直接把调用 Lambda 失败的消息转发到 SQS 死信队列，后续按需触发重推或者人工排查，不需要额外新增中间层，成本和运维量极低。
• 若对入站消息零丢失要求极高，可以调整规则动作，先把所有入站消息推到 SQS 标准队列，再由 Lambda 消费 SQS，消息最长可在 SQS 中留存 14 天，即使 Lambda 长时间故障也不会丢失数据。

出站消息侧（Lambda → 设备）优化 #

SQS 完全适用这个场景，属于成本极低的轻量方案：

• 所有待发送到设备的消息先写入 SQS 标准队列，配置 Lambda 消费该队列
• Lambda 拿到消息后调用 IoT Core Publish API，MQTT QoS 选择 1（至少一次投递），只要收到 IoT Core 返回的成功响应，再删除 SQS 中的对应消息
• 若调用 Publish 报错、超时未拿到响应，不要删除 SQS 消息，SQS 到达可见性超时时间后会自动把消息放回队列重新消费
• 给 SQS 配置死信队列（DLQ），比如累计重试 5 次都失败的消息转入 DLQ 单独处理，不会阻塞正常队列的消费
• 可选补充：数据库内留存待发消息记录，监听设备上线生命周期事件触发兜底重推，和 IoT Core 离线消息能力形成双重保障。

上述方案适配日均千万级以下的消息规模，不需要额外引入 Kafka、分布式状态存储等复杂组件，符合不过度设计的要求。

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