Cargando...
Cargando...
Fully managed push-based messaging that fans out to millions of subscribers instantly
Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and serverless applications. It uses a push model where messages are delivered to all subscribed endpoints simultaneously — including Lambda, SQS, HTTP/S, email, SMS, and mobile push. SNS is the go-to service when you need one message to trigger many downstream consumers at the same time (fan-out).
Fan-out notifications and alerts to multiple heterogeneous endpoints simultaneously using a push-based pub/sub model — no consumer polling required
Use When
Avoid When
Standard Topics (at-least-once, best-effort ordering)
Default topic type; highest throughput; fan-out to all endpoint types
FIFO Topics (exactly-once, strict ordering)
Only supports SQS FIFO subscribers; 300 TPS limit
Message Filtering (attribute-based per subscription)
Reduces noise; subscribers define JSON filter policies
Message Filtering (body-based)
Must be explicitly enabled; allows filtering on message body content
Dead Letter Queue (DLQ) per subscription
Separate from SQS queue DLQ; captures failed deliveries to a specific subscriber
Server-Side Encryption (SSE) with KMS
Encrypts messages at rest; KMS key rotation supported
VPC Endpoints (PrivateLink)
Publish to SNS from within VPC without internet gateway
Cross-account topic access
Via resource-based policy on the SNS topic
Cross-region subscriptions
SNS topics are regional; SQS queues in another region cannot subscribe directly — use cross-region SQS + Lambda workaround or EventBridge
Mobile Push Notifications (ADM, APNS, FCM, Baidu, WNS)
Requires platform application and device token registration
SMS (Transactional and Promotional)
Transactional = higher priority; Promotional = lower cost, lower priority
Email / Email-JSON subscriptions
Requires manual subscription confirmation; not suitable for programmatic consumption
HTTP/HTTPS endpoint subscriptions
Requires endpoint confirmation handshake; supports retry with backoff
Lambda subscriptions
SNS invokes Lambda synchronously; Lambda DLQ handles failures independently
SQS subscriptions (fan-out)
Most common pattern for durable fan-out; SQS buffers messages for consumer polling
Kinesis Data Firehose subscriptions
Enables direct SNS → Firehose → S3/Redshift/OpenSearch pipeline
Message Archiving / Replay
SNS does not natively support message replay; use SQS or Kinesis for replay capability
PublishBatch API
Publish up to 10 messages per API call; reduces cost and latency
Data Protection Policies (PII masking)
Detect and mask/block sensitive data in transit
Delivery Status Logging (to CloudWatch)
Supported for Lambda, SQS, HTTP/S, mobile push; not for email/SMS by default
Resource-based access policy
Controls who can publish/subscribe to the topic
Tag-based access control
Supports AWS resource tags for IAM conditions
Fan-out with Durable Buffering
high freqSNS topic fans out to multiple SQS queues. Each queue independently buffers messages for its consumer. This is the canonical pattern for decoupled, resilient event-driven architectures. Ensures no message loss even if downstream consumers are temporarily unavailable.
Serverless Event Processing
high freqSNS pushes messages directly to Lambda functions. Lambda is invoked asynchronously from SNS's perspective but synchronously within the invocation. Use DLQ on Lambda or subscription-level DLQ for failure handling. Common for real-time processing without infrastructure management.
Operational Alerting
high freqCloudWatch Alarms publish to SNS topics when metric thresholds are breached. SNS then notifies ops teams via email/SMS or triggers automated remediation via Lambda. The foundational AWS monitoring pattern.
Fan-out + Async Processing
high freqSNS → multiple SQS queues → Lambda consumers. Each Lambda function processes its queue independently. Provides fan-out, durability, rate limiting (via SQS visibility timeout), and retry logic. The gold-standard serverless pipeline.
S3 Event Notifications via SNS
high freqS3 can publish bucket events (ObjectCreated, ObjectRemoved, etc.) directly to SNS topics. SNS then fans out to SQS queues and Lambda functions. Preferred over direct S3 → Lambda when multiple consumers need the same event.
Direct Streaming to Data Lake
medium freqSNS subscriptions can deliver directly to Kinesis Data Firehose, enabling real-time data ingestion to S3, Redshift, or OpenSearch without intermediate Lambda. Reduces operational overhead for streaming analytics pipelines.
Compliance and Audit Notifications
medium freqCloudTrail delivers log files to S3 and optionally notifies an SNS topic upon each log delivery. Enables real-time audit workflows and compliance monitoring triggers.
Configuration Change Notifications
medium freqAWS Config streams configuration changes and compliance evaluations to an SNS topic. Enables automated remediation workflows when resources drift from desired state.
Event Routing to Notification Layer
medium freqEventBridge rules route specific events to SNS topics for human notification or simple fan-out. EventBridge handles complex filtering and routing; SNS handles delivery to heterogeneous endpoints. Use EventBridge when event sources are diverse; use SNS directly when the producer controls the publish.
SNS FIFO + SQS FIFO for Ordered Fan-out
medium freqSNS FIFO topics deliver ordered, deduplicated messages to SQS FIFO queues. Use when downstream processing must respect strict event ordering (e.g., financial transactions, inventory updates). Remember: FIFO SNS only supports SQS FIFO subscribers.
SNS = PUSH (producer pushes to subscribers). SQS = PULL (consumers poll the queue). This distinction drives almost every SNS vs SQS architecture decision on the exam.
The canonical fan-out pattern is SNS → multiple SQS queues (not SNS → multiple Lambda functions directly). SQS adds durability, retry, and rate control that Lambda alone cannot provide. When an exam question mentions 'reliable fan-out' or 'no message loss', choose SNS+SQS.
SNS FIFO topics ONLY support SQS FIFO queue subscribers. They cannot deliver to Lambda, HTTP, email, or SMS. If an exam scenario requires ordered delivery to Lambda, the answer is SNS FIFO → SQS FIFO → Lambda (via SQS trigger).
SNS does NOT persist messages. If a subscriber endpoint is down, the message is gone (for most endpoint types). To prevent message loss, always place an SQS queue between SNS and your consumers. This is why 'durable messaging' questions always involve SQS, not SNS alone.
SNS pushes, SQS polls — never swap them. Fan-out = SNS → multiple SQS queues for durability. If a question mentions 'reliable' or 'no message loss', the answer requires SQS, not SNS alone.
SNS FIFO topics ONLY deliver to SQS FIFO queues — period. No Lambda, no HTTP, no email, no SMS. If ordered delivery to Lambda is needed: SNS FIFO → SQS FIFO → Lambda (event source mapping).
Elastic Beanstalk worker environments poll SQS — NOT SNS. SNS cannot serve as a work queue for background job processing. Workers pull; SNS pushes. These are architectural opposites.
Message filtering is done at the SNS subscription level using JSON filter policies on message attributes. This means the publisher sends one message; SNS decides which subscribers receive it based on attributes. This reduces SQS queue noise and Lambda invocation costs without any code changes on the consumer side.
When a CloudWatch Alarm fires, it publishes to an SNS topic. SNS can then email an ops team AND trigger a Lambda for auto-remediation simultaneously. This fan-out capability is why SNS sits at the center of most AWS monitoring architectures.
Dead Letter Queues (DLQs) exist at two levels in SNS-based architectures: (1) SNS subscription-level DLQ captures messages that SNS failed to deliver to a specific subscriber; (2) SQS queue-level DLQ or Lambda DLQ captures processing failures after delivery. Know which layer is failing to choose the right DLQ.
For mobile push notifications, SNS uses Platform Application Endpoints (one per device). You must register each device's token with SNS to get an endpoint ARN. This scales to millions of devices — a key exam scenario for mobile app backends.
SNS message size limit is 256 KB. For larger payloads, use the SNS Extended Client Library (Java) or manually store the payload in S3 and send the S3 object reference in the SNS message. This is the same pattern as SQS Extended Client Library.
EventBridge vs SNS decision rule: Use EventBridge when you need content-based routing from many AWS services with rich filtering and schema registry. Use SNS when your application directly publishes notifications and needs simple fan-out to heterogeneous endpoints (email, SMS, Lambda, SQS). They are complementary, not mutually exclusive.
S3 event notifications can go directly to SNS, SQS, or Lambda. Choose SNS when you need the same S3 event delivered to multiple consumers simultaneously (fan-out). Choose SQS when you need one consumer with guaranteed processing. Choose Lambda when you need immediate serverless processing with one consumer.
SMS spend limit defaults to $1/month per account. This is a soft spending cap, not a message count limit. For any production SMS use case, this must be increased via Service Quotas. Exam scenarios about SMS delivery failures at scale often trace back to this limit.
Common Mistake
SNS and SQS are interchangeable — both are messaging services, so either can solve the same problem
Correct
SNS is a push-based pub/sub notification service (one-to-many, no persistence). SQS is a pull-based queue (one-to-one or one-to-few, with persistence up to 14 days). They solve fundamentally different problems and are most powerful when used together (SNS fan-out → SQS queues).
This is the #1 most tested SNS concept. Exam questions deliberately describe a scenario that sounds like it could use either service. The key discriminators are: (1) Does the message need to survive consumer downtime? → SQS. (2) Does one event need to trigger multiple independent consumers? → SNS. (3) Do consumers poll at their own pace? → SQS. (4) Must delivery be immediate and pushed? → SNS.
Common Mistake
SNS FIFO topics can fan out to Lambda, HTTP endpoints, email, and SMS just like Standard topics — FIFO just adds ordering
Correct
SNS FIFO topics ONLY support Amazon SQS FIFO queues as subscribers. No Lambda, no HTTP, no email, no SMS. This is a hard architectural constraint, not a configuration option.
Candidates assume FIFO is a superset of Standard. It is not — it trades subscriber flexibility for ordering guarantees. If an exam question requires ordered delivery to Lambda, the correct path is SNS FIFO → SQS FIFO → Lambda (event source mapping), not SNS FIFO → Lambda directly.
Common Mistake
Using SNS alone is sufficient for reliable, durable message delivery in a distributed system
Correct
SNS does not persist messages. If a subscriber (Lambda, HTTP endpoint) is unavailable when SNS attempts delivery, the message is lost after retry exhaustion. For durability, always pair SNS with SQS. SQS retains messages for up to 14 days and retries independently.
This misconception causes candidates to choose SNS-only architectures for scenarios requiring guaranteed delivery. The exam tests this by describing subscriber downtime scenarios and asking what happens to in-flight messages. Answer: with SNS alone, they are lost; with SNS+SQS, they are retained in the queue.
Common Mistake
Message filtering in SNS requires the subscriber's application code to filter out irrelevant messages after receiving them
Correct
SNS subscription filter policies are applied by SNS itself before delivery. Subscribers only receive messages that match their filter policy — no irrelevant messages are delivered, and no consumer-side filtering code is needed.
This matters architecturally because filter policies reduce cost (fewer Lambda invocations, less SQS traffic) and simplify consumer code. Exam questions test whether candidates know filtering happens at the SNS layer, not the consumer layer.
Common Mistake
Amazon SNS is the right service for Elastic Beanstalk worker environment tiers that process background jobs from a queue
Correct
Elastic Beanstalk worker environments use SQS (not SNS) to receive work. The worker tier polls an SQS queue. SNS is push-based and cannot serve as the work queue for a worker environment. Additionally, .NET on Windows Server Elastic Beanstalk does NOT support the worker environment tier at all.
This is a documented top misconception from real exam questions. Candidates confuse SNS (push notifications) with SQS (queue for worker polling). The Elastic Beanstalk worker tier is specifically designed around SQS polling, not SNS subscriptions.
Common Mistake
EventBridge and SNS are redundant — if you use EventBridge, you don't need SNS
Correct
EventBridge and SNS are complementary. EventBridge excels at routing events from many AWS services based on complex content-based rules. SNS excels at fan-out delivery to heterogeneous endpoint types (email, SMS, mobile push, HTTP, Lambda, SQS) that EventBridge cannot natively target as richly. Many architectures use EventBridge for routing and SNS as an EventBridge target for notification fan-out.
Exam questions test the boundary between these services. Key differentiator: EventBridge has 90+ native AWS service integrations as sources and supports schema registry; SNS supports more delivery endpoint types (SMS, email, mobile push) that EventBridge cannot directly target.
SNS = 'Send Notifications Simultaneously' — one publish, many endpoints notified at once
SNS FIFO subscriber rule: 'FIFO Fans Only SQS FIFO' — no other endpoint types allowed
Push vs Pull: 'SNS Shoves, SQS Sits' — SNS pushes to you; SQS waits for you to pull
Fan-out recipe: 'SNS bakes the cake, SQS plates it for each guest' — SNS distributes, SQS holds each copy safely
Durability check: 'No SQS? No Safety' — SNS alone drops messages if subscriber is down
DLQ layers: 'Subscription DLQ = delivery failure; Queue/Lambda DLQ = processing failure' — two different failure points, two different DLQs
CertAI Tutor · SAA-C03, SAP-C02, DVA-C02, DEA-C01, DOP-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons