AWS SQS vs SNS — Silent Loss Under Lambda Throttling

Modern applications rarely do one thing at a time. A user places an order and suddenly you need to charge their card, send a confirmation email, update inventory, notify the warehouse, and log an audit trail — all reliably, even if your email service crashes at 2 a.m. That's the problem AWS SQS and SNS were built to solve. They decouple the parts of your system so that a failure in one place doesn't cascade everywhere.

Without messaging services like these, you'd wire services together with direct HTTP calls. Service A calls Service B, which calls Service C. If B is slow, A waits. If C is down, the whole chain breaks. SQS introduces a buffer — a durable queue that holds messages until a consumer is ready to process them. SNS takes a different angle: it lets one event instantly fan out to dozens of subscribers without the publisher needing to know who they are.

By the end of this article you'll know the architectural difference between a queue and a publish-subscribe topic, how to wire SQS and SNS together for a real fan-out pattern, what dead-letter queues are and why you desperately need them, and exactly when to reach for each service in your next cloud project.

SQS — The Durable Message Queue That Saves Your System at 2 A.M.

SQS (Simple Queue Service) is a fully managed message queue. A producer drops a message into the queue, and one or more consumers poll the queue and process messages at their own pace. The key word is 'one' — by default each message is delivered to exactly one consumer. This is point-to-point messaging.

Why does that matter? Because it gives you back-pressure handling for free. If your order-processing service is overwhelmed, messages just pile up in the queue safely. The queue acts as a shock absorber between the part of your system that generates work and the part that does the work.

There are two flavours. Standard queues give you maximum throughput with at-least-once delivery and best-effort ordering — meaning a message might appear twice (rare, but plan for it). FIFO queues guarantee exactly-once processing and strict order, but cap you at 3,000 messages per second with batching. Choose FIFO when order actually matters — financial transactions, state machines. Choose Standard everywhere else.

Messages live in the queue for up to 14 days. The visibility timeout is the other critical setting: after a consumer picks up a message, it becomes invisible to other consumers for that window. If your Lambda or EC2 worker crashes mid-process, the message reappears and gets retried. That's your built-in retry mechanism.

Long polling is the single most impactful cost-saving setting. Always set WaitTimeSeconds=20 in your receive_message calls. Without it, your consumer uses short polling — it returns immediately even if no messages exist. You pay per API call, so a quiet queue will cost you thousands of empty calls. Long polling holds the connection for up to 20 seconds, waiting for a message. On a queue that gets one message per minute, long polling cuts your API calls by 95%.

import boto3
import json
import time

# --- PRODUCER: Order Service drops a new order into the queue ---

sqs_client = boto3.client('sqs', region_name='us-east-1')

ORDER_QUEUE_URL = 'https://sqs.us-east-1.amazonaws.com/123456789012/order-processing-queue'

def place_order(order_id: str

SNS — The Pub/Sub Megaphone That Notifies Everyone at Once

SNS (Simple Notification Service) works on the publish-subscribe model. You publish one message to a Topic, and SNS fans it out simultaneously to every subscriber — SQS queues, Lambda functions, HTTP endpoints, email addresses, mobile push notifications. The publisher has zero knowledge of who's listening. Adding a new subscriber doesn't touch the publisher at all.

This is the architectural superpower. Imagine your user-signup event needs to trigger a welcome email, a CRM record creation, a Slack notification to your growth team, and an analytics event. With SNS, your Auth service publishes one 'UserRegistered' message and walks away. Four independent services consume it in parallel.

Message filtering is what takes SNS from useful to essential. Instead of every subscriber receiving every message on a topic, you attach a filter policy to a subscription. Your EU payments service can subscribe to the 'transactions' topic but only receive messages where region=EU. This keeps each service focused on what it actually cares about.

SNS does not store messages. If a subscriber is down when the message arrives, that message is gone unless the subscriber is an SQS queue (which durably stores it). That's the most important SNS limitation to internalise — and it leads directly to the most powerful pattern: SNS + SQS fan-out.

SNS delivery logging is a critical debugging tool that most teams don't enable. It publishes delivery attempts, failures, and throttling events to CloudWatch Logs. When messages go missing, this is the first place to look. Enable it on every production SNS topic.

import boto3
import json

sns_client = boto3.client('sns', region_name='us-east-1')

USER_EVENTS_TOPIC_ARN = 'arn:aws:sns:us-east-1:123456789012:user-lifecycle-events'

def publish_user_registered_event(user_id: str

Dead-Letter Queues and the SNS+SQS Fan-Out Pattern — Production Essentials

Two patterns separate a toy cloud setup from a production-grade one: dead-letter queues (DLQs) and the SNS+SQS fan-out architecture. You need to understand both.

A DLQ is just another SQS queue. You configure it on your main queue and set maxReceiveCount — say, 3. If a message fails processing 3 times, SQS automatically moves it to the DLQ instead of retrying forever or silently dropping it. Your team gets alerted, investigates the poisoned message, and the rest of your queue keeps flowing normally. Without a DLQ, one bad message can block your queue or create an infinite retry storm.

The fan-out pattern solves SNS's biggest weakness — no durability. The rule is: never subscribe a Lambda directly to SNS in production if message loss is unacceptable. Instead, subscribe an SQS queue to the SNS topic. The queue durably catches every message. Your Lambda then polls the queue. You get SNS's broadcasting power AND SQS's durability and retry logic together. This is the architectural backbone of most event-driven AWS systems.

The code example below wires both patterns together with IaC-style Boto3 calls, showing exactly how a DLQ connects to a main queue.

Monitoring the DLQ: Set a CloudWatch alarm on ApproximateNumberOfMessages > 0 on your DLQ. A message in the DLQ means your consumer failed to process it after maxReceiveCount attempts. That's a bug — it shouldn't be ignored or silently deleted. Your on-call should get a page.

import boto3
import json

sqs_client = boto3.client('sqs', region_name='us-east-1')
sns_client = boto3.client('sns', region_name='us-east-1')


def create_queue_with_dlq(main_queue_name: str

SQS vs SNS vs EventBridge — A Three-Way Decision Table

When you need more than basic pub/sub or queuing, AWS EventBridge enters the picture. It's not a replacement for SQS or SNS — it sits above them, offering a central event bus with advanced routing, schema registry, and integration with third-party SaaS events. Here's a decision table to clarify when to pick each:

When to pick EventBridge over SNS: - You need complex content-based filtering (e.g., "order.total > 100 and order.region != 'US'") - You want to ingest events from third-party SaaS providers (GitHub, Shopify, etc.) - You need event replay for debugging or disaster recovery - You want automatic schema discovery to generate strongly typed code

When to stick with SNS+SQS: - You need FIFO ordering or exactly-once processing (EventBridge doesn't support FIFO) - Your throughput is very high and you want the lowest per-message cost - You need 14-day message retention (EventBridge max is 3 days for custom events) - You need the simplicity of a direct queue (SQS) without event bus complexity

The rule of thumb: SNS+SQS covers 80% of event-driven use cases. EventBridge is worth the extra cost and complexity when you need its advanced routing, third-party integration, or replay capabilities.

Pros and Cons of SQS and SNS

Every service has trade-offs. Here's a clear-eyed look at what SQS and SNS do well, and where they fall short.

SQS — Advantages - Durable 14-day message storage with automatic retries via visibility timeout - At-least-once delivery (Standard) or exactly-once (FIFO) - Unlimited throughput with Standard queues - Built-in dead-letter queue support - Low cost per API request, especially with long polling - Supports batch operations (up to 10 messages per receive, 10 per send)

SQS — Disadvantages - No built-in fan-out one-to-many (you need SNS for that) - Consumer must poll the queue, adding latency and cost if not optimized - Max message size 256 KB (need S3 large-payload solution for bigger) - Ordering only guaranteed with FIFO (limited throughput) - No content-based server-side filtering

SNS — Advantages - Instant pub/sub fan-out — one message reaches all subscribers simultaneously - Multiple subscriber types (SQS, Lambda, HTTP, email, SMS, mobile push) - Server-side filter policies reduce unnecessary deliveries - No polling overhead for subscribers (push-based) - Simple pricing per publish, not per subscriber

SNS — Disadvantages - Messages are NOT stored — if subscriber is down, message is lost - Limited retries (3 attempts only for HTTP/Lambda subscribers) - No ordering guarantees - Max message size 256 KB - No DLQ for failed deliveries (must use SQS subscriber to get retries) - Filtering limited to message attributes (not body content)

The real insight: SNS's biggest disadvantage (no durability) is also its greatest advantage when paired with SQS. The combination covers each service's weakness. Never use SNS alone for critical events always buffer with SQS.

Pricing Comparison — Standard vs FIFO, Per-Million Request Costs

Understanding cost at scale is critical. Here's the pricing breakdown for SQS, SNS, and the common patterns.

SQS Pricing (as of 2026)

Notes on SQS requests: - A “request” is any API call: SendMessage, ReceiveMessage, DeleteMessage, ChangeMessageVisibility, etc. - Long polling (WaitTimeSeconds=20) counts as one request per 20-second call, even if the response is empty. - Batch operations count as one request per batch of up to 10 messages.

SNS Pricing (as of 2026)

Notes on SNS delivery: - Each subscriber receives a copy of the message. If you have 5 SQS subscribers and publish 1 million messages, you pay for 1 million publishes + 5 million deliveries = $3.00 ($0.50 + $2.50). - For FIFO topics, the higher publish price reflects the ordering guarantee.

Comparison Scenario: Fan-out to 3 SQS queues Assume 10 million messages per month.

• SNS+SQS fan-out: 10M publishes = $5.00. 30M deliveries = $15.00. SQS request cost: 10M sends to each queue = 30M send requests = $12.00. Consumer polling: ~3.6M receive calls with long polling (10M messages / 10 batch size * 3.6 polls per message) = $1.44. Total: ~$33.44.

• Direct Lambda subscriptions: 10M publishes = $5.00. Lambda invocations free if using async invocation? Actually, SNS to Lambda is free beyond the publish cost. But you risk message loss (see production incident above). Not recommended for critical data.

• EventBridge bus: 10M events ingested = $10.00. 30M deliveries to 3 rules = $30.00. Total: $40.00.

Cost-saving tips: 1. Always use long polling on SQS consumers to reduce empty receive requests. 2. Batch send messages to SQS (up to 10 per request) to cut send costs by 90%. 3. Use SNS standard for high-volume fan-out; FIFO only when ordering is required. 4. Monitor SQS API usage with CloudWatch metrics. Set budgets and alarms.

Pricing is subject to change. Check the official AWS pricing page for the latest figures.

When to Consider Amazon MQ Instead of SQS or SNS

Amazon MQ is a fully managed message broker service that supports industry-standard protocols: MQTT, AMQP, STOMP, OpenWire, and JMS. It's the cloud version of Apache ActiveMQ and RabbitMQ. When should you reach for it instead of SQS/SNS?

Amazon MQ is the right choice when: - You're migrating an existing on-premises application that already uses JMS, AMQP, or MQTT. Rewriting everything to use SQS/SNS would be too risky or time-consuming. - You need advanced message routing beyond what SNS offers — like topics with wildcards, virtual topics, or message selectors (JMS). - You need transactional messaging across multiple queues (e.g., send to queue A and queue B atomically). - You need lower latency for real-time communication. SQS has a polling model that introduces latency; Amazon MQ's push-based delivery can be faster for time-sensitive workloads. - Your application requires specific features like scheduled messages, delayed delivery, message groups with flexible ordering, or custom dead-letter strategies at the broker level.

Amazon MQ is NOT the right choice when: - You want fully serverless, no infrastructure management. Amazon MQ requires you to manage broker instances (though it automates patching and failover). SQS and SNS are fully serverless. - Your throughput needs are extremely high. SQS Standard scales to unlimited. Amazon MQ is limited by the broker instance size (max 1000+ connections per broker, but instance types have limits). - Your payload size is small (under 256 KB). SQS and SNS handle this natively without needing message chunking. - You need exactly-once processing. SQS FIFO provides this; Amazon MQ requires idempotent consumers and broker-level deduplication, which is not as straightforward.

Cost comparison: Amazon MQ instances start at around $30/month for a small broker and increase with size. In contrast, SQS and SNS pay-per-use costs are negligible for low volume but grow linearly. Above about 100 million messages per month, Amazon MQ may become cheaper than SQS's API request costs, but only if you use the broker efficiently.

Decision rule: Use SQS/SNS for cloud-native applications where serverless is a priority. Use Amazon MQ for migrations, when you need JMS/AMQP compatibility, or when you require advanced broker-level features. If you're starting from scratch and don't have a legacy protocol requirement, SQS+SNS is almost always the simpler, more cost-effective choice.

Infrastructure as Code — Terraform SNS+SQS Fan-Out Setup

provider "aws" {
  region = "us-east-1"
}

# --- SNS Topic ---
resource "aws_sns_topic" "order_events" {
  name = "order-lifecycle-events"
}

# --- Main SQS Queue (consumer will poll this) ---
resource "aws_sqs_queue" "order_processing_queue" {
  name                       = "order-processing-queue"
  visibility_timeout_seconds = 60
  delay_seconds              = 0

  # Enable long polling on the queue level (overridden by consumer settings)
  receive_wait_time_seconds = 20

  # Attach Dead-Letter Queue
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.order_dlq.arn
    maxReceiveCount     = 3
  })
}

# --- Dead-Letter Queue (DLQ) ---
resource "aws_sqs_queue" "order_dlq" {
  name                       = "order-processing-dlq"
  message_retention_seconds  = 1209600  # 14 days
}

# --- SQS Queue Policy: allow SNS to send messages ---
resource "aws_sqs_queue_policy" "allow_sns" {
  queue_url = aws_sqs_queue.order_processing_queue.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowSNSToSendToSQS"
        Effect = "Allow"
        Principal = {
          Service = "sns.amazonaws.com"
        }
        Action   = "sqs:SendMessage"
        Resource = aws_sqs_queue.order_processing_queue.arn
        Condition = {
          ArnEquals = {
            "aws:SourceArn" = aws_sns_topic.order_events.arn
          }
        }
      }
    ]
  })
}

# --- Subscribe the SQS queue to the SNS topic ---
resource "aws_sns_topic_subscription" "fanout" {
  topic_arn = aws_sns_topic.order_events.arn
  protocol  = "sqs"
  endpoint  = aws_sqs_queue.order_processing_queue.arn

  # Enable raw message delivery — the SQS message body is your JSON, no SNS wrapper
  filter_policy = ""   # Add a JSON filter if needed, e.g., jsonencode({event_type = [\"order_placed\"]})\n\n  depends_on = [\n    aws_sqs_queue_policy.allow_sns\n  ]\n}\n\n# --- CloudWatch Alarm: monitor DLQ depth ---\nresource \"aws_cloudwatch_metric_alarm\" \"dlq_alarm\" {\n  alarm_name          = \"order-dlq-not-empty\"\n  comparison_operator = \"GreaterThanThreshold\"\n  evaluation_periods  = 1\n  metric_name         = \"ApproximateNumberOfMessagesVisible\"\n  namespace           = \"AWS/SQS\"\n  period              = 300\n  statistic           = \"Maximum\"\n  threshold           = 0\n  alarm_description   = \"This alarm fires when any message lands in the DLQ. Investigate immediately.\"\n  dimensions = {\n    QueueName = aws_sqs_queue.order_dlq.name\n  }\n  alarm_actions = []  # Add SNS topic ARN for notifications here\n}\n\n# --- (Optional) FIFO version (requires .fifo suffix) ---\n# resource \"aws_sqs_queue\" \"order_fifo\" {\n#   name                        = \"order-processing-queue.fifo\"\n#   fifo_queue                  = true\n#   content_based_deduplication = true\n#   visibility_timeout_seconds  = 60\n#   receive_wait_time_seconds   = 20\n# }\n\noutput \"sns_topic_arn\" {\n  value = aws_sns_topic.order_events.arn\n}\n\noutput \"sqs_queue_url\" {\n  value = aws_sqs_queue.order_processing_queue.id\n}\n\noutput \"dlq_queue_url\" {\n  value = aws_sqs_queue.order_dlq.id\n}",
        "output": "Apply complete! Resources: 6 added.\n\nOutputs:\n\nsns_topic_arn = \"arn:aws:sns:us-east-1:123456789012:order-lifecycle-events\"\nsqs_queue_url = \"https://sqs.us-east-1.amazonaws.com/123456789012/order-processing-queue\"\ndlq_queue_url = \"https://sqs.us-east-1.amazonaws.com/123456789012/order-processing-dlq\""
      }