Message Retention and Reliability

5 minutes 5 Questions

AWS Simple Notification Service (SNS) provides message retention and reliability features to ensure the delivery and processing of messages in a timely and dependable manner. SNS guarantees at-least-once delivery of messages to subscribers, meaning that messages will not be lost during transit, even in the event of failures or network issues. In case of a delivery failure, SNS utilizes retries with exponential backoff and jitter to resubmit the message multiple times, helping to increase the likelihood of successful delivery. For the Amazon SQS, Lambda, and Application protocols, SNS retains messages for up to 14 days, providing ample time for the subscriber to process the message. For other protocols, like SMS, Email, and HTTP, the retention period is shorter, and message delivery is attempted for a finite duration depending on the specific protocol. By providing these reliability features, SNS ensures developers can build resilient and fault-tolerant applications.

Understanding Message Retention and Reliability in AWS SNS

AWS SNS Message Retention and Reliability
Message Retention and Reliability in AWS SNS (Simple Notification Service) are vital components of Amazon's push messaging service. They govern how long messages are stored if they can't be delivered immediately and the mechanisms that ensure messages are reliably delivered to subscribers.

Importance
The retention period gives your system enough time to process the messages, even during an outage. On the other hand, reliability measures prevent message loss, ensuring every subscriber in the SNS Topic receives the message.

How It Works
When a message can't be delivered on the first try, SNS uses a 'back-off function' to deliver the message multiple times before discarding it. AWS SNS message retention lifespan is by default 4 days. If the message isn't delivered successfully within this period, it's deleted.

Exam Tips
When answering questions, remember that AWS SNS by default retries message delivery up to 100 times over 20 hours for HTTP/HTTPS and 3 times (immediately) for other protocols. Redundancy across multiple SNS topics is key for high reliability and understand that adjusting the retention period might be necessary depending on your application's requirements.

Test mode:

Exam (Timed)

Practice (With explanations)

Start practice test

Question 1

A company's application needs to process messages from an Amazon SNS topic. Some messages are failing, and the team needs a way to capture and analyze them. What approach should they take?

Create an Amazon Kinesis Data Stream for failed messages Create a Dead Letter Queue (DLQ) and attach it to the Amazon SNS topic Enable long polling for the Amazon SNS topic Increase the visibility timeout of the topic

Correct Answer: Create a Dead Letter Queue (DLQ) and attach it to the Amazon SNS topic

The correct answer is to create a Dead Letter Queue (DLQ) and attach it to the Amazon SNS topic. This will capture failed messages, allowing analysis and debugging. Increasing the visibility timeout, enabling long polling, and enabling retry policies are SQS features not applicable to SNS. Creating a Kinesis Data Stream or an S3 bucket for failed messages requires custom implementation and is not the best solution.

Question 2

An online voting application is using Amazon SQS to store votes in a queue for processing. The application owner is worried about deduplication and wants to prevent votes from being processed twice. Which configuration should they use?

Enable Content-Based Deduplication on a FIFO Queue Enable Short Polling Enable Content-Based Deduplication on a Standard Queue Enable Long Polling

Correct Answer: Enable Content-Based Deduplication on a FIFO Queue

The correct answer is to enable Content-Based Deduplication on a FIFO Queue, as it will remove duplicates using the message content. Enabling Content-Based Deduplication on a Standard Queue is not possible; it's only supported by FIFO Queues. Long and Short Polling don't provide deduplication functionality. High Visibility Timeout doesn't guarantee deduplication. DLQ captures failed messages and is not directly related to deduplication.

Question 3

A company is using Amazon SQS to manage a queue of messages to be processed by a fleet of EC2 instances. They need to ensure that messages are processed exactly once and in the exact order they were sent. Which SQS type should they use?

Long Polling Short Polling Standard Queue FIFO Queue

Correct Answer: FIFO Queue

The correct answer is FIFO Queue because it guarantees exactly-once processing and maintains the order of messages. Standard Queue doesn't guarantee message ordering, and Short Polling, Long Polling, SNS Topic, and Dead Letter Queue are not relevant for this scenario.

Go Premium

AWS Certified Solutions Architect - Associate Preparation Package (2024)

More Message Retention and Reliability questions

4 questions (total)