What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Three changes account for most of the avoidable Amazon SQS request spend in typical workloads: turn on long polling so consumers stop making empty requests, use standard queues wherever FIFO ordering is not required, and retire queues that still have consumers polling them but no producers. Batching and dead-letter queues are useful supporting controls. None of these guarantees a fixed percentage saving, because the result depends on your request volume, your empty-poll rate, and the pricing in your Region.
Why empty receives add to your bill
Standard SQS pricing is based on API requests, and a ReceiveMessage call counts whether or not it returns a message. A consumer that checks an empty queue in a tight loop can generate a large volume of requests that deliver nothing. AWS documentation identifies two kinds of wasted response: an empty response, where no messages are available, and a false empty response, where messages exist but are not included in the reply.
AWS documentation states the point directly:
“Long polling helps reduce the cost of using Amazon SQS by reducing 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).”
Recommended Free Tools
Strategy 1: Enable long polling
A ReceiveMessage call with a WaitTimeSeconds value greater than zero uses long polling. The maximum wait is 20 seconds, and AWS recommends 20 seconds in most cases. Instead of returning immediately with nothing, the call holds open until a message arrives or the wait expires, which removes most of the empty requests a short-poll consumer would make.
#1 Best Overall
Set the wait time on the queue
- Open the Amazon SQS console, select your queue, and choose Edit.
- In the Configuration section, set Receive message wait time to 20 seconds, then save. This becomes the queue default for consumers that do not specify their own value.
- To set it from the command line, run the following, replacing the queue URL with your own:
aws sqs set-queue-attributes --queue-url https://sqs.us-east-1.amazonaws.com/111122223333/orders --attributes ReceiveMessageWaitTimeSeconds=20 - To override the value for a specific consumer, pass
WaitTimeSecondson each ReceiveMessage call. A per-call value takes precedence over the queue setting.
Check timeouts and latency before you deploy
- Your HTTP client’s read timeout must be longer than the wait time. If it is shorter, the client gives up before SQS responds and the consumer will retry in a loop that creates the very requests you were trying to remove.
- Long polling returns as soon as a message is available, so a long wait does not delay delivery of messages that are already waiting. The trade-off is that a worker blocked in a 20-second receive takes longer to shut down cleanly, and a consumer with strict response-time requirements may need a shorter value.
- Consumer concurrency still matters. Each worker holds its own open receive, so confirm that your connection pool and thread count can handle the held connections.
Strategy 2: Use standard queues unless you need FIFO semantics
Queue type is a correctness decision, not a cost setting. Keep a FIFO queue when consumers must process messages for the same entity in order and must not see duplicate processing. Move to a standard queue only when your application already tolerates out-of-order and repeated delivery, or when your code handles those cases reliably.
| Aspect | Standard queue | FIFO queue |
|---|---|---|
| Ordering | Not guaranteed; messages can arrive out of order | Guaranteed within a message group |
| Delivery behavior | At-least-once; duplicates are possible | Exactly-once processing, using a deduplication ID to suppress duplicate sends |
| Queue name | Any valid name | Must end in .fifo |
| Converting an existing queue | Not applicable | An existing standard queue cannot be converted in place; create a new FIFO queue and move producers and consumers to it |
Idempotent handlers and sequence checks in your own code can cover some duplicate and ordering problems. They are engineering work, however, and they are not a drop-in replacement for FIFO guarantees. Test the failure cases, such as a retried message arriving after its successor, before you switch a workload that depends on order.
Strategy 3: Retire idle queues that still have consumers
A queue that no longer receives messages but still has a consumer polling it keeps generating empty receives indefinitely. The cleanup is simple in principle, but deleting a queue is permanent and can break a process you did not know depended on it, so work through the checks below in order.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems- In the CloudWatch console, open Metrics, then All metrics, select SQS, and then Queue Metrics. Graph NumberOfEmptyReceives and NumberOfMessagesSent for each queue over a period of at least two weeks.
- Flag queues where empty receives continue at a steady rate while NumberOfMessagesSent stays at zero. That pattern suggests a consumer with no producer behind it.
- Identify the owner from resource tags and the consumer itself: a Lambda event source mapping, an ECS service, an EC2 worker, or a scheduled job. Confirm whether a producer exists in another account or service that writes to the queue without appearing in your metrics.
- Ask whether the queue is intentionally idle. Some queues wait for rare events, such as a quarterly job or a disaster-recovery path. Those should be documented and may deserve a different design, not deletion.
- Disable the consumer first and leave the queue in place for a defined period. If nothing fails and no owner objects, export or archive any messages you need, then delete the queue. Deleting a queue removes its messages permanently.
Supporting controls: batching and dead-letter queues
Batch message actions
Send, delete, and visibility-change actions each have a batch form, called SendMessageBatch, DeleteMessageBatch, and ChangeMessageVisibilityBatch. Each accepts up to 10 entries in one request, so a consumer that deletes ten processed messages can make one call instead of ten. ReceiveMessage has no separate batch operation; set MaxNumberOfMessages up to 10 to receive several messages in a single call.
Rank #3
- Are you an Architect? Are you looking for a Birthday Gift or Christmas Gift for Architect Lover, Builder, or Planner? This Construction Planner design is designed as the perfect gift for anyone who loves to plan and oversee the construction
- This Architect design is an exclusive novelty design. Grab this Architect design as a gift for Architectural Engineers, Real Estate Architects, Contractors, or Construction Workers. Perfect for anyone who loves to design and plan buildings.
- Hardcover journal with 240 line-ruled pages (120 sheets)
- Built-in elastic closure and ribbon bookmark
- Includes an expandable inner storage pocket and a pen holder
A batch can partially fail. Each response lists successful and failed entries separately, so check every entry and retry only the ones that failed. Batching also means accumulating messages before you send them, which adds latency, so weigh the request reduction against how quickly your application needs to act.
Cap retries with a dead-letter queue
When a consumer keeps failing on the same message, each retry is another receive and another processing attempt. AWS describes repeated retries of unprocessable messages in Lambda and SQS event-source workflows as a snowball anti-pattern that can amplify both work and cost. Set a redrive policy with maxReceiveCount on the source queue and point it at a dead-letter queue. The DLQ isolates poison messages so you can inspect them instead of cycling them through the consumer.
A dead-letter queue is a failure-isolation and recovery practice, not a discount. The DLQ itself generates requests and stores messages, and both are billed. Configure its retention and alarms according to how quickly your team needs to respond to failed messages.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Estimating your own savings
No single percentage applies to every queue, and older figures quoted for SQS costs may reflect different pricing or usage. Measure your own workload before and after each change:
- Pull the ReceiveMessage request volume and NumberOfEmptyReceives for a representative week.
- Calculate the empty-receive share as empty receives divided by total receives for each consumer group.
- Check the current Amazon SQS pricing page for your Region and convert the expected request reduction into cost using that rate.
- Change one control at a time, then compare the same metrics over a comparable period so you can attribute the difference.
Apply long polling first, since it changes the request pattern without altering application semantics. Queue-type changes, idle-queue removal, and batching all require application testing, so treat them as separate projects with their own rollback plans.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
