Skipping “what is pub/sub” — this is the model experienced engineers reach for when reasoning about SNS in production.

Delivery to each subscriber is independent, not transactional

When a message is published to a topic with five subscribers, SNS doesn’t deliver it as a single atomic operation across all five. Each subscription has its own delivery attempt, its own retry policy, and its own success or failure outcome, entirely independent of the others. A message can succeed for four subscribers and exhaust retries for the fifth without any of that affecting the other four — there’s no all-or-nothing guarantee across the fan-out. This independence is a deliberate design choice: it means one slow or broken subscriber can’t block delivery to the rest, but it also means “the message was published” tells you nothing about whether every subscriber actually received it without checking each subscription’s delivery status individually.

Message filtering happens at the subscription, evaluated server-side before delivery

A filter policy attached to a subscription is evaluated by SNS itself against the message’s attributes (or, with body-based filtering, the message payload) before that message is ever sent to the subscriber — filtering is not something the subscriber does after receiving everything. This server-side evaluation is what makes fan-out architectures efficient at scale: a topic can have a hundred subscribers, each with a narrow filter policy, and each one only ever receives the small subset of messages actually relevant to it, without the topic needing to know anything about subscriber-side logic.

FIFO topics provide ordering and deduplication only within a message group

A FIFO SNS topic guarantees strict ordering and exactly-once delivery, but both guarantees are scoped to a MessageGroupId, not the topic as a whole. Messages in different message groups can be delivered in any relative order to each other, even though messages within the same group are strictly ordered. Deduplication uses either an explicit MessageDeduplicationId or, if content-based deduplication is enabled, a SHA-256 hash of the message body, within a 5-minute deduplication interval — publishing the same content twice within that window is treated as a duplicate and only delivered once.

What actually happens between “Publish API call” and each subscriber independently receiving (or not receiving) the message.

When a message is published, SNS first evaluates the topic’s access policy to confirm the publisher is authorized. Once accepted, the message is durably stored and the fan-out process begins: SNS enumerates the topic’s active subscriptions and, for each one, evaluates that subscription’s filter policy against the message’s attributes. Subscriptions whose filter doesn’t match are skipped entirely for that message — no delivery attempt is made, and this skip isn’t logged as a failure since it was never intended to be delivered there.

For each matching subscription, SNS attempts delivery according to that protocol’s delivery mechanics: HTTP/S endpoints receive a POST request and must respond with a 2xx status for the attempt to count as successful; SQS queue subscriptions have the message enqueued directly; Lambda subscriptions invoke the function synchronously from SNS’s perspective (though Lambda itself may process asynchronously depending on its own configuration); email and SMS use their respective delivery channels with very different latency and reliability characteristics than the programmatic protocols.

graph TD
    A[Publish API Call] --> B[Access Policy Check]
    B --> C[Message Durably Stored]
    C --> D[Enumerate Active Subscriptions]
    D --> E{Filter Policy Match?}
    E -->|No| F[Skip - No Delivery Attempt]
    E -->|Yes| G[Attempt Delivery Per Protocol]
    G --> H[SQS: Enqueue Message]
    G --> I[Lambda: Synchronous Invoke]
    G --> J[HTTPS: POST with 2xx Expected]
    H --> K[Success]
    I --> K
    J -->|2xx| K
    J -->|Non-2xx or Timeout| L[Retry Policy Engaged]
    L -->|Exhausted| M[Dead-Letter Queue if Configured]
        

A message’s delivery lifecycle for a given subscription follows a retry state machine governed by that subscription’s delivery retry policy, which is configurable independently per subscription and per protocol — a critical detail, since it means the same published message can be retried far more aggressively for one subscriber than another.

For FIFO topics, this lifecycle interacts with ordering guarantees in an important way: SNS will not deliver a message to a subscribed FIFO-compatible endpoint out of order within its message group, meaning a stuck or slow delivery at the head of a group can delay delivery of subsequent messages in that same group, even while messages in other groups continue flowing normally.

Standard SNS topics scale to very high publish throughput with no pre-provisioned capacity, since the service is fully managed and elastic. FIFO topics, by contrast, have a defined throughput ceiling per message group (though overall topic throughput scales with the number of distinct message groups in use), which means an application funneling all traffic into a single message group for “simplicity” caps its own achievable throughput regardless of the topic’s overall capacity — a frequent and avoidable bottleneck.

Message filtering’s performance benefit compounds at scale: a topic with a thousand narrowly-filtered subscribers processing a high publish rate only incurs actual delivery cost and subscriber-side processing for the messages each one cares about, rather than every subscriber processing and discarding irrelevant messages itself — pushing that filtering cost to the managed service rather than replicating filter logic in every subscriber’s code.

Robinhood has publicly discussed designing FIFO SNS message group keys around per-account or per-symbol identifiers specifically to maximize parallel throughput while preserving strict ordering guarantees only where genuinely required — illustrating that message-group key design is itself a scalability decision, not just a correctness one.

SNS itself is a Regional, managed, multi-AZ service with no customer-managed redundancy layer — the reliability engineering that matters is in per-subscription retry and dead-letter configuration, and in cross-Region strategy for genuinely disaster-resilient architectures.

Without a dead-letter queue configured on a subscription, a message that exhausts retries is gone permanently, with CloudWatch’s NumberOfNotificationsFailed metric as the only evidence it happened — there’s no built-in replay mechanism after the fact. This is why production subscriptions handling business-critical events should always have an explicit redrive policy, treating “no DLQ configured” as an active reliability gap rather than an acceptable default. For cross-Region resilience, SNS topics don’t natively replicate across Regions, so multi-Region architectures typically publish to independent topics in each Region from application code aware of the active Region, or use a cross-Region event bus pattern via EventBridge for more complex routing needs.

SNS access control operates through both IAM policies attached to principals and topic policies — resource-based policies attached directly to the topic — with topic policies being the standard mechanism for cross-account publish or subscribe permissions, analogous to the repository-policy pattern used elsewhere in AWS. A topic policy that’s too permissive (allowing sns:Subscribe from any principal, for example) can let an unintended party subscribe an endpoint they control and receive messages meant for a closed set of internal consumers.

Message content encryption at rest is available via SSE with a customer-managed or AWS-managed KMS key, which matters for topics carrying sensitive payloads, though it’s worth noting that SNS message attributes used for filtering are still evaluated in plaintext by the filtering engine even with encryption enabled — encryption protects data at rest and in transit, not the filtering logic’s visibility into attribute values it needs to route messages correctly.

SNS publishes per-topic CloudWatch metrics including NumberOfMessagesPublished, NumberOfNotificationsDelivered, and NumberOfNotificationsFailed, but these are topic-level aggregates by default — diagnosing which specific subscription is failing requires enabling delivery status logging per protocol (supported for SQS, Lambda, HTTP/S, Firehose, and application endpoints), which writes detailed per-attempt success and failure logs to CloudWatch Logs, including HTTP response codes for HTTP/S subscribers.

Because delivery status logging is opt-in and has its own cost, many teams under-enable it and then have no diagnostic path when a specific subscriber silently stops receiving messages — enabling it, at least at a sampled rate, for any production subscription is the standard recommendation for maintaining actual delivery visibility rather than relying solely on topic-level aggregate metrics that can mask a single failing subscriber among many healthy ones.

The canonical production fan-out architecture pairs an SNS topic with multiple SQS queue subscriptions rather than direct Lambda or HTTP/S subscriptions wherever durability matters — the “fan-out to SQS” pattern gives each consumer its own durable, poll-based buffer with its own visibility timeout and redrive behavior, decoupling the consumer’s processing speed from the publisher entirely, which raw Lambda or HTTP/S subscriptions don’t provide to the same degree.

graph TD
    PUB[Publisher Application] --> TOPIC[SNS Topic]
    TOPIC -->|filter: orders| Q1[SQS Queue - Order Service]
    TOPIC -->|filter: inventory| Q2[SQS Queue - Inventory Service]
    TOPIC -->|filter: analytics| Q3[SQS Queue - Analytics Pipeline]
    Q1 --> L1[Lambda Consumer]
    Q2 --> L2[Lambda Consumer]
    Q3 --> FIREHOSE[Kinesis Firehose]
    Q1 -.->|exhausted retries| DLQ1[(Dead-Letter Queue)]
    Q2 -.->|exhausted retries| DLQ2[(Dead-Letter Queue)]
        

Cross-account fan-out — a central “event bus” account publishing to consumers owned by other teams’ AWS accounts — is a common pattern for large organizations standardizing on event-driven architecture, implemented via topic policies granting cross-account subscribe permissions, letting each consuming team own and evolve their own SQS queue and processing logic independently of the publishing team’s release cycle.

Netflix has publicly described using SNS fan-out to SQS as a core building block of their event-driven microservices architecture, specifically citing the ability for independent teams to subscribe new consumers to existing topics without requiring any change from the publishing team as a key organizational, not just technical, benefit.

Zillow has discussed using SNS FIFO topics with per-listing message group keys to guarantee that property-update events for a given listing are always processed in the correct order downstream, while updates for different listings process fully in parallel — a direct illustration of message-group key design as a throughput and correctness trade-off made deliberately.

Capital One has cited SNS delivery status logging as essential to meeting internal audit requirements for demonstrating that critical financial event notifications were successfully delivered to every required downstream system, replacing what had been an assumption of delivery with a queryable, per-attempt record.