SQS queues with no traffic have no bill to reclaim
What does ZopNight detect here?
An SQS queue bills $0.40 per million requests with no standing charge, so a queue sending zero messages already costs $0, and queue depth of 0 never proved idleness anyway, since a well-drained busy queue reads the same. ZopNight therefore retired this rule in place; it abstains on every queue.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-181 |
| Category | idle |
| Severity | low |
| Metric | none — pure configuration read |
| Source | sqs_idle.go |
Where it applies
Queue depth was the wrong idle signal
An earlier version of this rule keyed idleness on ApproximateNumberOfMessages reading zero.
That gauge answers “how many messages are sitting here right now”, and for a healthy queue the
answer is usually zero: consumers drain it as fast as producers fill it. Depth of zero across
a whole month describes the busiest, best-tuned queues in a fleet just as well as abandoned
ones. The old detection was therefore a false positive on every efficiently-drained queue,
and it recommended deleting them.
The honest throughput axes for a queue
Whether anything uses a queue is a throughput question, not a depth question. The rule’s
declared metrics now name the real axes from the queue counters SQS reports to CloudWatch: NumberOfMessagesSent and
NumberOfMessagesReceived, each needing to sit near zero (below a small floor, not exactly
zero) over at least 30 days before “idle” would be a fair claim. One of those axes,
the receive-side counter, is not yet harvested by ZopNight’s aggregator; the declaration
keeps the fetch wiring honest so the gap is visible rather than papered over.
Why an idle queue bills nothing
Even with perfect throughput-based detection, the finding would have no dollar attached. SQS
charges about $0.40 per million requests, the first million per month free, and nothing at
all for a queue that just exists. Zero traffic means zero billable requests means a $0 line
item. ZopNight’s cost findings must be concrete or absent, so Evaluate returns nil on every
input. The rule is retired in place. Its category was also corrected from orphan (which is
exempt from the low-savings filter, and so had let $0 findings through) to idle.
Checking queue traffic with CloudWatch
aws cloudwatch get-metric-statistics \ --namespace AWS/SQS --metric-name NumberOfMessagesSent \ --dimensions Name=QueueName,Value=my-queue \ --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \ --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \ --period 86400 --statistics SumRepeat with NumberOfMessagesReceived for the consume side. Flat zeros on both is a queue
nothing talks to.
If you still want to delete a queue
Do it for clarity, not savings. Before deleting, check for Lambda event source mappings and SNS subscriptions that target the queue, and whether it serves as a dead-letter queue for another one; a DLQ is supposed to be silent until something goes wrong, which makes it the classic false catch of any manual cleanup pass.