Skip to content

AWS SQS & SNS — Messaging Services

AWS provides two core messaging services for decoupling application components:

  • SQS (Simple Queue Service) — Message queue for point-to-point communication
  • SNS (Simple Notification Service) — Pub/sub topic-based messaging for fan-out

In Azure terms: SQS ≈ Azure Storage Queues / Azure Service Bus Queue, SNS ≈ Azure Service Bus Topics / Event Grid


SQS is a fully managed message queue that decouples producers from consumers. Producers send messages; consumers poll and process them at their own pace.

TypeDescription
Standard QueueAt-least-once delivery, best-effort ordering, nearly unlimited throughput
FIFO QueueExactly-once delivery, strict ordering, up to 3,000 messages/second
ConceptDescription
MessageThe data payload (up to 256 KB; use S3 + pointer for larger)
Visibility TimeoutHow long a received message is hidden from other consumers (default 30s)
Dead Letter Queue (DLQ)Receives messages that failed processing after N attempts
Message Retention1 minute to 14 days (default 4 days)
Long PollingConsumer waits up to 20s for a message — reduces empty responses and cost
Delay QueueDelay delivery of new messages by 0–900 seconds
Producer → Queue → Consumer picks up (message hidden)
↓ Processing succeeds → Delete message
↓ Processing fails × N → Move to DLQ
Terminal window
# Create a standard queue
aws sqs create-queue --queue-name my-queue
# Send a message
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123456789/my-queue \
--message-body "Hello from SQS"
# Receive messages (long poll)
aws sqs receive-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123456789/my-queue \
--wait-time-seconds 10 \
--max-number-of-messages 5
# Delete a message after processing
aws sqs delete-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123456789/my-queue \
--receipt-handle "abc123..."

SNS is a fully managed pub/sub messaging service. Publishers send messages to a Topic, and SNS fans out to all subscribers simultaneously.

Subscriber TypeUse Case
SQSFan out to multiple queues for parallel processing
LambdaTrigger serverless functions
HTTP/HTTPSWebhooks to external services
Email / Email-JSONNotifications to people
SMSText messages to phones
Mobile PushiOS (APNs), Android (FCM), Fire OS notifications
Amazon Kinesis Data FirehoseStream data to S3, Redshift, etc.
Order Service
↓ publishes to SNS Topic
├─→ SQS Queue → Inventory Lambda (update stock)
├─→ SQS Queue → Email Lambda (send confirmation)
└─→ SQS Queue → Analytics Lambda (log event)

This pattern decouples services while ensuring each consumer gets every message.

Terminal window
# Create a topic
aws sns create-topic --name my-topic
# Subscribe an email
aws sns subscribe \
--topic-arn arn:aws:sns:us-east-1:123456789:my-topic \
--protocol email \
--notification-endpoint user@example.com
# Subscribe an SQS queue
aws sns subscribe \
--topic-arn arn:aws:sns:us-east-1:123456789:my-topic \
--protocol sqs \
--notification-endpoint arn:aws:sqs:us-east-1:123456789:my-queue
# Publish a message
aws sns publish \
--topic-arn arn:aws:sns:us-east-1:123456789:my-topic \
--message "Order #1234 placed" \
--subject "New Order"

ScenarioUse
Worker processing jobs from a queueSQS
Fan out one event to many systemsSNS
Fan out + durable queuing per consumerSNS → SQS (fan-out pattern)
Email/SMS alertsSNS
Guaranteed exactly-once delivery + orderingSQS FIFO
Rate limiting / buffering before processingSQS

FeatureAWSAzure
Basic queueSQS StandardAzure Storage Queue
Enterprise queueSQS FIFOAzure Service Bus Queue
Pub/Sub topicsSNSAzure Service Bus Topics
Event-driven routingSNS + EventBridgeAzure Event Grid
Streaming (high-throughput)Amazon KinesisAzure Event Hubs