SNS vs SQS vs SES — Messaging Trio

The trio

	SNS	SQS	SES
Type	Pub/sub (push)	Queue (pull)	Email service
Mental model	Bulletin board	Job queue (RabbitMQ’s queue half)	Mail server API
Direction	One msg → MANY subscribers	One msg → ONE consumer	Send/receive email
Channels	HTTP, SMS, email, Lambda, SQS, mobile push (APNS/FCM)	Poll by consumers	SMTP/API
Persistence	None (fire-and-forget)	Up to 14 days + DLQ	Deliverability handled
Cost	Per publish	Per request	$0.10/1000 emails

Mental models (confirmed correct)

SNS = notification fan-out — push/SMS/email, many subscribers
    = mobile push (APNS iOS, FCM Android) + SMS + email from one publish
    = NOT per-user inbox (no read/unread) — pair with DB for in-app notifications

SQS = queue — async jobs, ONE consumer per message
    = RabbitMQ's queue, but NOT RabbitMQ's exchanges
    = AWS splits RabbitMQ: SQS (queue) + SNS (fanout/exchange)

SES = transactional email — welcome, password reset, receipts, verification links
    = auth flows: Cognito (users) → SES (reset/verify emails)

SNS → SQS combo (most common pattern)

Publisher → SNS topic → SQS queue A (consumer A)
                       → SQS queue B (consumer B)
                       → Lambda
                       → SES (email)

SNS = fan-out + SQS = buffering/persistence. Each consumer gets independent copy.

RabbitMQ mapping

RabbitMQ exchange  → SNS topic
RabbitMQ binding   → SNS subscription
RabbitMQ queue     → SQS queue
RabbitMQ consumer  → SQS consumer

Exam facts

SNS = pub/sub fan-out (text + email + HTTP + Lambda + SQS + push)
SQS = queue, one consumer, decoupling, up to 14 days
SES = email only (send + receive), deliverability features
“send text AND email from distributed apps” → SNS
“decouple services / buffer spikes” → SQS
“transactional email (welcome/reset/receipts)” → SES
Trap: SES sends email; SNS ALSO targets email — SNS = notifications to many subscribers, SES = email service with deliverability

[[aws/index]]
[[aws/lambda-usage/index]]