Skipping the absolute basics — this chapter builds the mental model that the rest of this tutorial depends on.

The Coupling Problem SNS Solves

Without a pub/sub layer, a service that needs to notify five downstream systems ends up calling all five directly, which means it must know about all five, handle five sets of failures, and get rewritten every time a sixth system joins. SNS removes that coupling entirely: the publisher sends one message to a topic and never learns, or needs to learn, who or how many are subscribed underneath it.

You may likeAmazon VPC→

Topics, Subscriptions, and Protocols

A “topic” is the named channel a publisher sends messages to. A “subscription” binds one specific endpoint — an SQS queue, a Lambda function, an HTTP/S endpoint, an email address, an SMS number, or a mobile push endpoint — to that topic. The “protocol” simply describes which of those delivery mechanisms a given subscription uses, and a single topic can freely mix several protocols among its subscribers at once.

SNS’s architecture is a thin, highly available routing layer sitting between a publisher and a set of independent subscriber endpoints.

Standard vs. FIFO Topics

A standard topic optimizes for throughput and best-effort ordering, occasionally delivering a message more than once. A FIFO topic guarantees strict ordering and exactly-once delivery within a message group, at the cost of lower throughput — and critically, a FIFO topic can only fan out to FIFO SQS queues, not to Lambda, HTTP, email, or mobile endpoints directly.

The Access Policy and Delivery Layer

Every topic has a resource-based access policy controlling who may publish or subscribe to it. Once a message is accepted, SNS’s internal delivery layer pushes it out to every matching subscription concurrently, applying each subscription’s filter policy independently before deciding whether that particular subscriber should receive a copy at all.

flowchart TB
    A[Publisher] -->|Publish Message| B[SNS Topic]
    B --> C{Filter Policy Evaluation}
    C -->|Match| D[SQS Queue Subscriber]
    C -->|Match| E[Lambda Function Subscriber]
    C -->|Match| F[HTTPS Endpoint Subscriber]
    C -->|Match| G[Email / SMS Subscriber]
    C -->|No Match| H[Message Skipped for That Subscriber]
    D --> I[(Durable storage until consumed)]
        

Message Attributes as First-Class Routing Data

SNS messages carry a body plus a separate set of key-value message attributes. Filter policies are evaluated against those attributes, not the message body, which is why well-designed publishers always attach meaningful attributes such as event type or region rather than forcing subscribers to parse the body just to decide relevance.

Understanding what happens between a Publish call and a subscriber receiving a message explains most of SNS’s guarantees and limitations.

The Publish Call Is Synchronous, Delivery Is Not

When a publisher calls Publish, SNS synchronously confirms the message was accepted and durably stored inside the service; it does not wait for every subscriber to actually receive it. Delivery to each subscription happens asynchronously and independently afterward, which is why a publisher’s success response says nothing about whether any particular subscriber has processed the message yet.

sequenceDiagram
    participant Pub as Publisher
    participant SNS as SNS Topic
    participant SQS as SQS Subscriber
    participant Lam as Lambda Subscriber
    Pub->>SNS: Publish(message, attributes)
    SNS-->>Pub: Accepted (MessageId)
    par Fan-out
        SNS->>SQS: Deliver copy
        SNS->>Lam: Invoke with copy
    end
    SQS-->>SNS: Enqueued
    Lam-->>SNS: Processed / Retry on failure
        

Retry Behavior Differs by Protocol

SNS retries failed deliveries using a protocol-specific backoff policy: HTTP/S endpoints get a configurable retry policy with backoff, Lambda invocation failures are retried based on Lambda’s own asynchronous invocation retry behavior, and SQS deliveries almost never fail at the SNS layer since the queue simply durably stores whatever arrives.

Dead-Letter Queues Catch What Retries Cannot Fix

A subscription can be configured with a dead-letter queue, so that after retries are exhausted for that specific subscriber, the message is preserved for inspection instead of being silently dropped — a critical safety net for HTTP endpoints in particular, since those are the most likely to be temporarily unreachable.

Following one message from publish to final delivery clarifies how filtering and fan-out actually interact.

You may likeAWS Shield→

FIFO Ordering Is Scoped, Not Global

In a FIFO topic, ordering and deduplication are guaranteed only within the same message group ID, not across the entire topic. Two messages in different groups may still be delivered in either order relative to each other, which is an easy detail to miss when designing a FIFO-based workflow.

SNS’s simplicity and speed come with trade-offs that matter once a system depends on it for correctness, not just convenience.

SNS scales to extremely high publish rates, but a few design choices determine whether subscribers scale along with it.

Standard Topics Scale Nearly Without Limit

Standard topics are designed for very high throughput, automatically scaling the publish and delivery paths behind the scenes without the customer provisioning anything. The practical scaling ceiling is usually on the subscriber side — how fast a Lambda function or an HTTP endpoint can actually process the volume of fan-out it is receiving.

FIFO Throughput Is Group-Bound

Because ordering is enforced per message group, a FIFO topic’s real throughput ceiling for any single group is lower than its aggregate topic throughput. Spreading messages across more message groups, when business logic allows it, is the standard way to scale a FIFO-based workload.

SNS-to-SQS Fan-Out as a Scaling Pattern

Fanning a single SNS topic out to multiple SQS queues, each feeding a different downstream service at its own pace, is one of the most common scaling patterns in event-driven architectures — it lets each consumer scale its own processing independently, buffered by its own queue.

SNS is built to be highly available by default, but reliability of the overall workflow still depends on subscriber-side choices.

Multi-Availability-Zone by Design

SNS stores and routes messages redundantly across multiple Availability Zones within a Region as a managed service characteristic, so a single data-center-level failure does not threaten message durability inside the service itself.

Reliability Beyond SNS Depends on the Subscriber

SNS guarantees it will attempt delivery and retry per protocol, but true end-to-end reliability for anything mission-critical usually means pairing SNS with a durable subscriber like SQS, which persists the message until a consumer explicitly processes it, removing any dependency on that consumer being available at the exact moment of delivery.

Because a topic can broadcast sensitive events to many destinations, controlling who can publish and subscribe is central to using SNS safely.

Resource Policies Control Publish and Subscribe Rights

A topic’s access policy determines which principals can publish messages and which can create subscriptions against it. Left too permissive, any principal in an account — or worse, any AWS account — could publish arbitrary messages into a topic your systems trust, so this policy deserves the same scrutiny as any other resource-based policy.

Auditability by Default

Publish, subscribe, and topic management API calls are recorded automatically by CloudTrail, giving a queryable history of who created subscriptions and who published into a given topic — useful both for security review and for tracing an unexpected message back to its source.

Visibility into publish volume, delivery success, and failure patterns is what turns SNS from a black box into a debuggable system.

CloudWatch Metrics per Topic and Subscription

SNS automatically publishes metrics such as the number of messages published, the number of notifications delivered, and the number of failed deliveries, broken down per topic and, for some metrics, per subscription protocol — letting a team alarm on a rising failure rate before it becomes a customer-visible incident.

Delivery Status Logging

Delivery status logging can be enabled per protocol to capture successful and failed delivery attempts in CloudWatch Logs, including HTTP response codes for HTTP/S subscribers, which is often the fastest way to diagnose why a specific endpoint keeps failing.

SNS rarely stands alone — its real power shows up in how naturally it threads through the rest of an event-driven architecture.

You may likeAWS Outposts→

SNS Fan-Out to SQS

The classic fan-out pattern subscribes multiple SQS queues to a single SNS topic, so one published event durably reaches every downstream service’s own queue, each processed at its own pace without competing for the same messages.

Mobile Push and Direct-to-Device Notifications

SNS integrates directly with mobile push notification services, letting a single publish reach iOS, Android, and other device platforms through platform application endpoints, which is a common way applications drive real-time mobile notifications without maintaining separate integrations per platform.

Infrastructure as Code Integration

Topics, subscriptions, filter policies, and access policies are all ordinary AWS resources, meaning they belong in the same infrastructure-as-code stack as everything else — keeping fan-out topology under version control instead of being wired together manually in a console.

A handful of recurring decisions separate SNS-based systems that stay reliable from ones that quietly lose messages.

A short, practical checklist tends to prevent the majority of real-world SNS incidents.

SNS’s fan-out model becomes concrete once mapped onto the kind of event-driven architecture large platforms actually run.

Questions that come up repeatedly once teams move past introductory usage.

SNS pushes messages out to many subscribers the moment they are published, while SQS holds messages durably in a queue until a consumer pulls them — they are frequently combined rather than treated as alternatives.

Yes, that is exactly what filter policies are for — each subscription can specify which message attributes it cares about, and only matching messages are delivered to it.

Standard topics guarantee at-least-once delivery, meaning duplicates are possible; only FIFO topics provide exactly-once delivery within a message group.

SNS resolves the subscription list at publish time, so a subscription removed after that point simply does not affect deliveries already in progress for that message.

No, FIFO topics can only fan out to FIFO SQS queues; reaching Lambda from a FIFO topic requires the FIFO queue to trigger the function afterward.

If a dead-letter queue was configured on the failing subscription, the message is preserved there for inspection and manual or automated reprocessing.

SNS pricing is based on the number of requests and notifications delivered, so an idle topic with no publishes generates effectively no charge.

Amazon SNS earns its place at the center of event-driven architectures by solving the coupling problem cleanly: a publisher speaks once, and the topic takes on the entire responsibility of deciding who hears it and how. Its architecture of independent, per-subscription delivery explains both its speed and its at-least-once delivery trade-off, while filter policies keep fan-out efficient rather than noisy. Real reliability, though, is a joint responsibility — SNS attempts delivery and retries, but durable end-to-end guarantees usually require pairing it with SQS on the receiving end.

You may likeAmazon QLDB→