AWS Certified Solutions Architect - Associate: Reduce Pricing for Amazon SQS without Compromising Time | Provider: Amazon

How to Reduce Pricing for Amazon SQS without Compromising Time

Prev Question Next Question

Question

Your organization is using Amazon SQS as an enterprise message queuing platform.

100s of applications read the queues every few seconds to process the messages and delete them as soon as they are written into the queues.

Looking at the number of requests being sent to Amazon SQS APIs, your management is concerned about the pricing that will be incurred.

As an architect, how would you reduce pricing without compromising on time in this scenario? Please select 2 correct answers.

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Answer: B, C.

Option A is incorrect.

There is no such limitation on AWS SQS queues.

Option B is correct.

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html

Option C is correct.

Option D is not correct.

Short polling does not guarantee a return of the message, and you have to repeat the call until you receive the message.

That does not reduce any costs.

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html
Amazon SQS Long Polling Long polling helps reduce the cost of using Amazon SQS by eliminating the number of empty responses (when there are no messages available for a Receivelessage request) and false empty responses (when messages are available but aren't included in a response). For information about enabling long polling for a new or existing queue using the AWS Management Console or the AWS SDK for Java (and the CreateQueue, SetQueueAttributes, and ReceiveMessage actions), see the Configuring Long Polling for an Amazon SQS queue tutorial. For best practices, see Setting Up Long Polling. Long polling offers the following benefits: * Eliminate empty responses by allowing Amazon SQS to wait until a message is available in a queue before sending a response. Unless the connection times out, the response to the ReceiveMessage request contains at least one of the available messages, up to the maximum number of messages specified in the ReceiveMessage action. * Eliminate false empty responses by querying all—rather than a subset of Amazon SQ$ servers. Note You can confirm that a queue is empty when you perform a long poll and the ApproximateNumberOfMessagesDelayed, ApproximateNlumberOfMessagesNotVisible, and ApproximatelNumberOfMessagesVisible metrics are equal to 0 at least 1 minute after the producers stop sending messages (when the queue metadata reaches eventual consistency). For more information, see Available CloudWatch Metrics for Amazon SQS. * Return messages as soon as they become available.

Amazon Simple Queue Service (Amazon SQS) is a managed message queuing service that enables decoupling and scaling of distributed systems and applications. It is a cost-effective messaging service that can be used to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be available all the time.

In the given scenario, where hundreds of applications are reading and processing messages from SQS queues every few seconds, it is natural to expect a large number of requests being sent to Amazon SQS APIs, leading to cost concerns. To reduce pricing without compromising on time, the following options can be considered:

A. Once successfully written, Amazon SQS messages are only available after 1 minute. Ask applications to increase the delay between calls to 1 minute. This reduces the number of API calls made.

This option is not suitable in the given scenario as the applications need to process messages frequently and deleting messages as soon as they are processed is crucial to avoid message duplication and other issues. Increasing the delay between calls to 1 minute may lead to slower processing and reduced system performance.

B. Use Amazon SQS Long Polling.

Long Polling is a feature in Amazon SQS that allows applications to receive messages from a queue with reduced cost and increased efficiency. In Long Polling, an application can specify a WaitTimeSeconds parameter to receive messages only when they are available, reducing the number of empty responses and hence, the number of requests sent to SQS APIs. Long Polling can also reduce the cost by minimizing the use of Short Polling, which involves sending a request to SQS every few seconds to check if there are new messages.

C. Send DeleteMessage requests in batch.

In the given scenario, applications are deleting messages from SQS queues as soon as they are processed. Instead of sending individual DeleteMessage requests for each message, the applications can send DeleteMessageBatch requests to delete multiple messages in a single request, thereby reducing the number of requests sent to SQS APIs and hence, the cost incurred.

D. Use Amazon SQS Short Polling.

Short Polling is the default mode of operation in Amazon SQS, where an application sends a request to SQS every few seconds to check if there are new messages in the queue. Short Polling can lead to increased cost and reduced efficiency as it results in empty responses when there are no new messages, leading to unnecessary API requests. Hence, using Short Polling is not recommended in the given scenario.

To conclude, options B and C are the correct answers to reduce pricing without compromising on time in the given scenario. Option A is not suitable, and option D is not recommended.

Prev Question Next Question