miruky

Posted on Sep 2

Alarm on an Amazon SQS Backlog with CloudWatch

#aws #sqs #cloudwatch #tutorial

Introduction

Hi, I'm miruky.

ApproximateNumberOfMessagesVisible reports how many Amazon SQS messages are available for consumers to retrieve. A rising value is a practical backlog signal when producers are outpacing consumers or no consumer is running.

This Console run creates a Standard queue and a CloudWatch metric alarm with a one-minute period. One queued payload moves the alarm from OK to In alarm; receiving and deleting it returns the metric below the threshold and the alarm to OK.

SQS publishes its standard queue metrics to CloudWatch without a separate metric charge. CloudWatch alarms and SQS requests have their own current pricing terms, so check both pricing pages before applying the settings outside this small validation.

1. Create and activate a Standard queue

This validation uses us-east-1, whose Region display name is United States (N. Virginia). The SQS queue, metric, and alarm all remain there.

The header confirms United States (N. Virginia) while the SQS Console is in English. This fixes the Region shared by the queue, metric, and alarm.

Open Amazon SQS and search for the exact generated name miruky-aaptabgtgqjvqmsx. The result should be empty before this validation creates the queue.

The exact filter for miruky-aaptabgtgqjvqmsx returns no queue. That empty result establishes the resource boundary before creation.

Choose Create queue, select Standard, enter miruky-aaptabgtgqjvqmsx, and keep the default delivery settings and SQS-managed server-side encryption.

The next image vertically stacks the type-and-name area with the encryption area from the same create-queue form. Nothing between those two areas changes the settings shown here.

The form visibly pairs Standard with miruky-aaptabgtgqjvqmsx and the default SQS-managed encryption. No delivery setting or dead-letter queue is added.

Open Send and receive messages, send the fixed body metric-seed, then receive and delete it. These operations activate the queue and provide CloudWatch with an empty baseline before the alarm experiment begins.

The next image stacks the identifier-excluded body crop with the deletion result from that same controlled receive. Message identifiers and receipt details are excluded.

The received message body is exactly metric-seed. Deleting it leaves the active queue with no visible backlog before the alarm is created.

SQS publishes metrics for active queues at one-minute intervals. A newly activated queue can take up to 15 minutes to appear in CloudWatch, so wait for the queue dimension rather than recreating the resource.

2. Select the visible-message metric

Open CloudWatch, choose All metrics, select SQS, and then choose Queue Metrics. Search for miruky-aaptabgtgqjvqmsx and select ApproximateNumberOfMessagesVisible.

The selected row combines ApproximateNumberOfMessagesVisible with miruky-aaptabgtgqjvqmsx. This binds the alarm to the generated queue's visible backlog.

Choose Select metric. Set the statistic to Maximum and the period to 1 minute; a maximum of at least one means a message was available for retrieval during that period.

The metric settings show Maximum and 1 minute. That combination records each period's observed maximum queue depth and therefore detects any period that reached at least one.

Use a static threshold and choose Greater/Equal with threshold 1. Under Additional configuration, set Datapoints to alarm to 1 out of 2 and choose Treat missing data as good (not breaching threshold).

The next image stacks the condition area with Additional configuration from the same alarm wizard page. No setting between those two areas changes the values shown here.

The condition shows Greater/Equal, threshold 1, 1 out of 2, and missing data treated as good. These four values determine both the trigger and recovery windows.

The M-out-of-N setting can react to one breaching minute without depending on a single one-minute evaluation window. Treating missing data as not breaching also prevents an inactive queue from becoming an alarm solely because SQS stopped publishing metrics.

3. Create the alarm without an external action

On the notification step, remove the alarm action for this validation. The article observes state changes in CloudWatch and does not create an SNS topic or send a notification to an email address.

The next image stacks the empty notification card with the final review's No actions result from the same alarm configuration.

The notification step shows no configured action. This keeps the validation limited to the alarm state and avoids creating a topic or contacting an address.

Enter the generated alarm name miruky-trzxgmdimxfnpnvk, leave the description empty, review the metric and threshold, and create the alarm.

The next image stacks the metric, condition, and alarm-name sections from that single final review page.

The review shows miruky-trzxgmdimxfnpnvk with the visible-message metric and fixed threshold. No action is listed in the final configuration.

Open the alarm and wait until its state is OK. A newly created alarm may initially be unevaluated while CloudWatch gathers its first result.

The alarm state reaches OK while the queue has no visible message. This is the baseline before the backlog message is sent.

4. Trigger the backlog alarm

Return to the queue and send one message with the body backlog-demo. Leave it unreceived for this step; receiving changes its state from available to in flight, so it no longer contributes to this backlog metric.

The send form and confirmation identify the fixed body backlog-demo. Leaving it unreceived keeps it in the visible-message metric.

Wait for the next one-minute metric publication and CloudWatch evaluation. The alarm should move to In alarm after at least one of its two evaluated periods has a maximum visible count of 1 or more.

The alarm state shows In alarm while the graph contains a breaching visible-message point. This is the first observed transition driven by queue backlog.

The SQS metric is approximate because the service is distributed, so it is appropriate for operational decisions rather than an exact transactional count. A production threshold should reflect normal arrival rate, consumer capacity, and the time a backlog can remain without violating a service objective.

5. Process the message and watch recovery

Open Send and receive messages, poll for backlog-demo, select it, and choose Delete. Receiving moves the queued item into its visibility-timeout window; deletion prevents it from returning afterward.

The next image stacks the identifier-excluded body crop with the deletion result from that same controlled receive. Message and receipt identifiers are excluded.

The selected message body is backlog-demo, and the deletion confirmation removes it from the queue. Only this fixed test payload is selected for deletion.

Return to the CloudWatch alarm and wait for two non-breaching one-minute periods to replace the breaching point in the evaluation window. The alarm should return to OK while the queue-depth line is below the threshold.

The alarm returns to OK after the breaching point leaves the two-period window. The graph now reflects the empty visible backlog.

Wrap-up

The queue state drove both alarm transitions. One queued payload breached Maximum at or above 1, and deleting it produced enough non-breaching data for CloudWatch to recover the alarm.

For production monitoring, a threshold of one is usually too sensitive. Tune the M-out-of-N window and threshold from observed traffic, and consider pairing backlog depth with the SQS oldest-message-age metric when delay matters more than raw count.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community