Amazon SQS Queue
Does ZopNight manage Amazon SQS Queue?
Amazon SQS bills per million API requests, and every 64 KB of payload counts as 1 request, including receives that return nothing. ZopNight tracks 90 days of SQS queue depth and messages-sent metrics and attributes per-queue cost; no SQS recommendation fires today, because an unused queue already bills nothing.
Rules that fire on Amazon SQS Queue
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, metrics, cost tracking, and recommendations only. |
Amazon Simple Queue Service (SQS) provides managed message queues billed per million requests. Cost scales with request volume, including empty-receive polling, so chatty consumers against idle queues generate avoidable charges.
Requests are the only meter
SQS bills per million API requests, and SendMessage, ReceiveMessage, and DeleteMessage all count equally. Each 64 KB chunk of payload is metered as one request, so a 256 KB message counts as 4. FIFO queues bill a higher per-million rate than standard queues. There is no charge for a queue existing and none for messages sitting in it; a queue nobody touches costs nothing.
The empty receive problem
A ReceiveMessage call that returns nothing bills exactly like one that returns 10 messages. A consumer fleet short-polling an idle queue several times a second generates millions of billable requests a month for zero throughput. Long polling, with WaitTimeSeconds set up to its 20-second maximum, collapses that request volume by an order of magnitude, which makes it the single highest-leverage SQS setting.
What waste looks like here
Abandoned queues still polled around the clock by consumers of services that were retired. Short-polling loops nobody ever tuned, paying for the polling rather than the messages. And retry storms, where a failing message cycles through receive-and-return indefinitely, quietly multiplying request counts.
Queue metrics and attribution
Queues are discovered every 6 hours via Resource Explorer 2. Hourly CloudWatch metrics from the SQS namespace (queue depth and messages sent) run with a 90-day lookback, and per-queue cost comes from Cost Explorer or CUR 2.0. ZopNight raises no SQS recommendation today: the idle-queue rule (RC-181) is retired, and empty receives are not collected, so the polling check below is a manual one. Queues have no stop state and need none: an idle, unpolled queue already bills zero, so remediation is always about fixing consumers, not the queue.
The polling tell in the console
SQS console, then Queues. On a queue’s Monitoring tab, compare the empty-receives chart against messages received; that one comparison shows whether the queue’s bill is traffic or polling.