一家电子商务公司使用 Amazon SNS 将订单消息发送到仓库应用程序处理的本地 HTTPS 端点。有些订单消息未被接收。解决方案架构师必须保留未送达的消息，并对其进行长达 14 天的分析，同时将开发工作量降至最低。哪种解决方案符合这些要求？

正确答案是配置一个 Amazon SNS 死信队列，其目标为 Amazon Simple Queue Service (Amazon SQS)，保留期为 14 天。当 SNS 无法将消息成功发送到订阅端点时，死信队列 (DLQ) 会捕获这些未送达的消息。将 SQS 队列作为 DLQ 目标，可以存储这些消息长达 14 天（SQS 的最大保留期），以便后续分析。这满足了保留未送达消息和分析的要求，且开发工作量最低，因为 SNS DLQ 是内置功能。 将 Amazon Kinesis Data Stream 作为 DLQ 目标不合适，因为 Kinesis Data Stream 主要用于实时数据流处理，其数据保留期通常为 1-7 天（最长 365 天，但通常不用于此目的），且查询未送达消息的复杂性更高。在应用程序和 Amazon SNS 之间添加 SQS 队列会改变现有架构，增加开发工作量，并且可能引入额外的延迟。将 Amazon DynamoDB 作为 DLQ 目标虽然可以存储数据，但需要额外的配置和管理（例如 TTL 属性），并且查询未送达消息不如 SQS 直观，增加了开发和运维复杂性。