An ecommerce company uses Amazon SNS to send order messages to an on-premises HTTPS endpoint that the warehouse application processes. Some order messages were not received. A solutions architect must retain undelivered messages and analyze them for up to 14 days with the LEAST development effort. Which solution meets these requirements?

The correct solution is to configure an Amazon SNS dead-letter queue (DLQ) with an Amazon SQS target and a 14-day retention period. When SNS messages fail to be delivered to a subscriber (like the on-premises HTTPS endpoint), they are sent to the configured DLQ. SQS is a natural fit for a DLQ because it's a message queuing service designed to hold messages reliably. SQS allows configuring a message retention period of up to 14 days, directly meeting the requirement to retain messages for that duration. This approach requires minimal development effort as it's a configuration change within SNS and SQS. Incorrect options: Kinesis Data Stream is not a suitable DLQ target for SNS; SNS DLQs only support SQS queues. Placing an SQS queue between the application and SNS would require modifying the application to publish to SQS first, then SQS to SNS, which is more development effort and not how SNS DLQs work for undelivered messages. DynamoDB is a NoSQL database, not a message queue. While it can store data with a TTL, it's not the intended or most efficient service for handling undelivered messages from SNS, and SNS DLQs do not directly support DynamoDB as a target.