DEV Community

Tejas Shinkar
Tejas Shinkar

Posted on

AWS SNS + SQS Hands-On Lab

#aws #cloud #devops #sideprojects

Two practical exercises covering SNS fan-out with SQS/DLQ, and CloudWatch alarm notifications delivered through SNS.

SNS → SQS Fan-Out with Retry and Dead-Letter Queue

Objective

Build an order-event messaging flow where SNS publishes an event to an SQS queue, then deliberately leave a message unprocessed to observe SQS retries and its eventual move to a dead-letter queue.

Architecture 

Publisher
   │
   ▼
SNS Topic
 order-events
   │
   ▼
SQS: order-processing-queue
   │
   ├── processed successfully → deleted
   │
   └── maxReceiveCount (3) exceeded
             │
             ▼
     SQS DLQ: order-processing-dlq
Enter fullscreen mode Exit fullscreen mode

Resources created:

  • SNS Topic: order-events
  • SQS main queue: order-processing-queue — Standard type, 30s visibility timeout, 4-day retention, 20s receive wait time, DLQ order-processing-dlq, maxReceiveCount = 3
  • SQS DLQ: order-processing-dlq

Step 1 — Build the Queue and Topic

Created the DLQ (order-processing-dlq), then the main queue (order-processing-queue) configured to use that DLQ with maxReceiveCount = 3. Created the SNS topic (order-events) and subscribed the main queue to it using the SQS subscription protocol. Verified the queue policy allowed SNS to deliver messages: principal sns.amazonaws.com, action sqs:SendMessage, restricted to source ARN order-events — so only that specific topic can publish into the queue.

Step 2 — Fan-Out Test

Published a test order event to SNS:

{
  "orderId": "ORD-1001",
  "customer": "Tejas",
  "amount": 2499,
  "status": "created"
}
Enter fullscreen mode Exit fullscreen mode

The message appeared in order-processing-queue, confirming SNS → SQS delivery.

Step 3 — Receive-Count / DLQ Test

The message was polled repeatedly without being deleted, to observe the retry-to-DLQ behavior:

Receive #1 → not deleted → visibility timeout expires → Receive #2 → not deleted → Receive #3 → maxReceiveCount reached → message moved to DLQ

The message then appeared in order-processing-dlq, showing a receive count of 4 once polled there — that count reflects its full receive history on the main queue plus the DLQ, not that SNS published it four times.

Result

SNS → SQS delivery confirmed. SQS receive → not deleted → retried → maxReceiveCount reached → moved to DLQ, confirmed end to end.

Key Practical Takeaways

  • Receiving an SQS message does not automatically delete it.
  • A consumer should delete a message only after successful processing.
  • Visibility timeout gives the consumer time to complete processing.
  • Repeated unsuccessful processing can be isolated in a DLQ.
  • SNS decouples the publisher from downstream consumers.
  • The SQS queue policy can restrict which SNS topic can send messages.

CloudWatch CPU Alarm → SNS Email Notifications

Objective

Create a CloudWatch alarm that monitors EC2 CPU utilization and sends an SNS notification to multiple confirmed email subscriptions when the threshold is exceeded.

Architecture 

EC2 Instance
   │ CPUUtilization metric
   ▼
CloudWatch Alarm
 ec2-high-cpu-alert
   │ threshold breached → ALARM
   ▼
SNS Topic: cloudwatch-alerts
   │
   ├── Email 1 (confirmed)
   └── Email 2 (confirmed)
Enter fullscreen mode Exit fullscreen mode

Resources created:

  • SNS Topic: cloudwatch-alerts, with two confirmed email subscriptions
  • CloudWatch Alarm: ec2-high-cpu-alert — metric CPUUtilization, statistic Average, 1-minute period, condition > 10%

Step 1 — Verify SNS Delivery Independently

Before involving CloudWatch, a direct test message was published straight to cloudwatch-alerts. Both confirmed email addresses received it, proving SNS delivery worked on its own — so any later failure could be isolated to the alarm side rather than the notification side.

Step 2 — Trigger the Alarm

The alarm started in OK once CloudWatch had sufficient data. CPU load was then generated and later stopped:

# Generate load
for i in {1..4}; do yes > /dev/null & done

# Stop load
pkill yes
Enter fullscreen mode Exit fullscreen mode

CPU crossed the 10% threshold and the alarm state changed to ALARM.

Result

EC2 CPU > 10% → CloudWatch Alarm → ALARM → SNS cloudwatch-alerts → Email 1 ✅ → Email 2 ✅

Both confirmed subscriptions received the notification, verifying the full path from metric breach to alarm state change to SNS fan-out to multiple recipients.

Key Practical Takeaways

  • SNS works well as a notification fan-out layer for operational alerts.
  • Testing SNS separately helps isolate notification-delivery issues from alarm configuration.
  • CloudWatch alarms depend on evaluated metric datapoints before changing state.
  • A controlled CPU-load test is enough to validate the alarm end-to-end.

Practical Completion

Practical Result
SNS → SQS fan-out ✅ Verified
SQS retry / visibility behavior ✅ Verified
SQS → DLQ after repeated receives ✅ Verified
CloudWatch CPU alarm ✅ Verified
CloudWatch → SNS notification ✅ Verified
Multiple email recipients ✅ Verified

Top comments (0)