My sqs queue is getting 1 million message per day (eg, number of message sent), and number of empty message received is about 2.5 million per day, so I imagine 1 month is around 105 million message total, but amazon billing says its 255 million request a month.

How is requested counted in sqs?

Is each command count as 2 request?

  • 1
    Sending a message will be a request. Polling for new messages to process will be a request. Marking a message as finished with deleteMessage will be a request. So, yes, your average message will be at least two requests. – ceejayoz May 27 '18 at 21:36
  • Two things to consider: long polling and batching. You can receive 10 messages at once then delete them as batches. Might reduce your count / costs. – Tim May 27 '18 at 21:48

Every API interaction is billed as a quantity of ceil(payload_size_kb / 64kb) requests, so each request (send, receive, empty receive) is billed as a number of requests ranging from 1 to 4 (256kb is the maximum payload).

See https://aws.amazon.com/sqs/pricing/#request_pricing.

If you have 2.5M empty receives per day, then you either have a very large number of consumers, or you are not using long polling. You should definitely be using long polling. I've never encountered a case where it was not appropriate.

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 ReceiveMessage request) and false empty responses (when messages are available but aren't included in a response).


Long Polling is sometimes misunderstood, since the queue parameter are called things like Receive Message Wait Time and WaitTimeSeconds and this is occasionally misinterpreted to mean the consumer will wait or be delayed by this many seconds... but this is not the case. This is only the amount of time the consumer waits when 0 message are available. When a message is available, it is still returned immediately. If the queue is empty and a consumer is, say, 7 seconds into a 20 second long poll when the next message arrives, the consumer does not wait for the remaining 13 seconds. The new message is returned immediately.

You will almost always want to use long polling, and use the maximum possible value of 20 seconds. This value should really have been the default, and a consumer wanting anything else should have been required to specify it.

If your consumers can handle multiple messages at a time, increasing the number of messages requested to the maximum value of 10 will also reduce the number of billable requests. Again, setting this value to more than 1 will not increase the amount of wait time. If fewer than max messages are available, the number available is returned immediately, when long polling. You only wait when the available messages are 0.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.