Which solutions will meet this requirement?
(Choose two.)
Replace the RDS Multi-AZ DB instance with an Amazon DynamoDB table.
Configure an Amazon Simple Queue Service (Amazon SQS) queue as a destination of the Lambda function.
Configure an Amazon Simple Queue Service (Amazon SQS) dead-letter queue for the SNS topic.
Subscribe an Amazon Simple Queue Service (Amazon SQS) queue to the SNS topic. Configure the Lambda function to process messages from the SQS queue.
Replace the SNS topic with an Amazon EventBridge event bus. Configure an EventBridge rule on the new event bus to invoke the Lambda function for each event.
Explanations:
Amazon DynamoDB is not suitable for processing SNS notifications in this scenario. While DynamoDB is a good choice for fast, scalable NoSQL data storage, it doesn’t address the issue of message durability or queueing.
Configuring an SQS queue as the Lambda function destination does not prevent the loss of messages. If the Lambda function fails or the RDS instance is unavailable, messages would still be lost unless an SQS dead-letter queue or an intermediary queue is used.
Configuring an SQS dead-letter queue (DLQ) for the SNS topic ensures that messages are not lost when they can’t be processed. If the Lambda function fails, the messages are placed in the DLQ for later analysis and reprocessing.
Subscribing an SQS queue to the SNS topic ensures messages are durable and can be processed by the Lambda function once the database is available. Using SQS decouples the SNS notification delivery and the Lambda processing, allowing for retry mechanisms if the Lambda fails or the RDS instance is down.
Replacing SNS with EventBridge changes the event delivery model, but this doesn’t inherently address the loss of messages. EventBridge may be more suitable for different event-driven architectures, but does not address the direct need for durable message processing as SNS and SQS would.