Cloud / Amazon Simple Notification Service (Amazon SNS) Interview questions

Amazon Simple Notification Service (SNS) is a fully managed publish/subscribe messaging service that lets one producer broadcast a single message to many independent subscribers at once. A publisher sends a message to an SNS topic, and SNS delivers a copy of that message to every endpoint currently subscribed to it.

Subscribers can be Amazon SQS queues, AWS Lambda functions, HTTP/S endpoints, email addresses, SMS numbers, or mobile push endpoints. Because the publisher never talks directly to subscribers, new consumers can be added or removed without touching the producer's code.

SNS is commonly used for application alerts, system notifications, and fan-out patterns where several downstream services need to react to the same event at the same time.

Amazon SNS is built around a small set of components that work together to move a message from a producer to many consumers.

A single topic can have any number of subscriptions across different protocols, and each subscription can carry its own filter policy so it only receives messages relevant to it.

A topic is the logical access point that publishers send messages to and that subscribers attach their endpoints to. It's identified by an Amazon Resource Name (ARN), and creating a topic is what generates that ARN.

Once a topic exists, any number of subscriptions can be attached to it across different protocols - for example one SQS queue, one Lambda function, and one email address can all subscribe to the same topic simultaneously.

A single publish call to the topic results in SNS attempting delivery to every currently confirmed subscription, independent of how many subscribers exist.

A subscription is what turns a topic into an actual delivery target. It ties together a protocol (such as SQS, Lambda, HTTP/S, email, or SMS), an endpoint address for that protocol, and an optional filter policy.

Without a subscription, a topic has nowhere to deliver messages - publishing to an empty topic simply succeeds with no downstream effect. Each subscription is managed independently, so one subscriber's failure or removal doesn't affect delivery to the others.

Every subscription also gets its own ARN once confirmed, which is what later API calls use to update its filter policy, redrive policy, or delivery preferences without touching the topic itself.

SNS supports several delivery protocols so the same topic can reach very different kinds of consumers.

• Amazon SQS - delivers into a queue for asynchronous processing
• AWS Lambda - invokes a function directly with the message
• HTTP/HTTPS - posts the message to a webhook endpoint
• Email / Email-JSON - sends a formatted or raw JSON email
• SMS - sends a text message to a phone number
• Mobile push - delivers to APNs, FCM, or ADM device endpoints
• Kinesis Data Firehose - streams messages into a delivery stream

Each protocol has its own delivery guarantees and retry behavior, so the right choice depends on how the receiving system needs to consume the message.

A topic can be created through the console, the AWS CLI, an SDK, or infrastructure-as-code tools like CloudFormation or Terraform. At minimum you need a name; you can also set encryption, delivery policies, and tags at creation time.

aws sns create-topic --name order-events

The call returns a TopicArn, which is what publishers and subscribers reference afterward. For a FIFO topic, the name must end in .fifo and content-based deduplication or explicit deduplication IDs need to be planned for up front.

Subscribing links an endpoint to an existing topic using the subscribe API, specifying the topic ARN, the protocol, and the endpoint address.

aws sns subscribe   --topic-arn arn:aws:sns:us-east-1:123456789012:order-events   --protocol sqs   --notification-endpoint arn:aws:sqs:us-east-1:123456789012:order-queue

For protocols like email and HTTP/S, the subscription starts in "PendingConfirmation" status until the endpoint owner confirms it by clicking a link or responding to a confirmation token - this prevents someone from subscribing an endpoint they don't control.

SQS and Lambda subscriptions skip that manual confirmation step because ownership is already proven through the caller's IAM permissions on the target resource, so those subscriptions typically go straight to "Confirmed".

A standard topic is the default SNS topic type, built for maximum throughput and availability. It offers at-least-once delivery, which means a message might occasionally be delivered more than once, and it does not guarantee that messages arrive in the order they were published.

Standard topics support all delivery protocols, including HTTP/S, email, SMS, and mobile push, making them the right choice for most notification and alerting use cases where strict ordering isn't required.

They're also the default when creating a topic through the console or CLI without specifying a FIFO type, and they scale to a much higher publish rate than FIFO topics since messages don't need to wait for a serialized sequence.

A FIFO (First-In-First-Out) topic preserves the exact order messages were published in and supports exactly-once delivery to its subscribers, at the cost of lower throughput than a standard topic. FIFO topic names must end with the .fifo suffix.

Messages are grouped by a message group ID; ordering is guaranteed within a group, and different groups can be processed independently. Currently, SNS FIFO topics can only deliver to Amazon SQS FIFO queues as subscribers.

Standard FIFO throughput is capped per API action, though a high-throughput mode is available to raise that ceiling for workloads that publish across many distinct message groups.

Fan-out means a single message published once to a topic is delivered in parallel to every subscribed endpoint, letting one event trigger several independent workflows without the publisher coordinating any of them.

flowchart LR
    P[Publisher] --> T((SNS Topic))
    T --> Q1["SQS Queue - Billing"]
    T --> Q2["SQS Queue - Shipping"]
    T --> L["Lambda - Analytics"]

A common example is an order-placed event published once, then simultaneously routed to a billing queue, a shipping queue, and an analytics function - each system reacts to the same event on its own schedule.

SNS offers two topic types, and choosing between them comes down to whether ordering and duplicate-free delivery matter more than raw throughput.

Most notification and alerting workloads use standard topics; FIFO is reserved for cases like order processing or financial events where sequence and duplicate avoidance are business-critical. The topic type is fixed at creation time and can't be converted later, so it's worth deciding up front rather than migrating a live topic.

Publishing sends a message body, and optionally a subject and message attributes, to a topic ARN. SNS then attempts delivery to every matching subscription.

aws sns publish   --topic-arn arn:aws:sns:us-east-1:123456789012:order-events   --message "Order 4821 has shipped"   --subject "Shipping Update"

Message attributes can be attached as key-value metadata alongside the body; they're what subscription filter policies evaluate, so a subscriber only receives messages whose attributes match its policy.

A single message body is limited to 256 KB, and a publish can carry up to 10 message attributes - anything larger or more detailed than that generally needs to be stored elsewhere (such as S3) with only a reference passed through SNS.

Message filtering lets each subscription define a filter policy so it only receives the subset of messages published to a topic that it actually cares about, instead of every message going to every subscriber.

{
  "event_type": ["order_shipped", "order_cancelled"],
  "region": [{"prefix": "us-"}]
}

SNS evaluates the policy against a message's attributes (or body, if body-based filtering is enabled) before attempting delivery; a non-matching message is simply skipped for that subscription, reducing unnecessary invocations and cost downstream.

A subscription with no filter policy attached is the default state and simply receives every message published to the topic, so filtering is opt-in per subscriber rather than something that has to be explicitly disabled elsewhere.

SNS Mobile Push lets an application send notifications directly to iOS, Android, and Fire OS devices by acting as a single interface over the underlying push gateways - Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM), and Amazon Device Messaging (ADM).

A platform application is created for each push service, device tokens from the app are registered as platform endpoints, and messages published to those endpoints (directly or via a topic) are translated into the correct payload format for each gateway.

SNS is designed to plug into a wide range of AWS services as either a source of events or a delivery target.

• Amazon SQS - fan-out into queues for buffered processing
• AWS Lambda - event-driven function invocation
• Amazon CloudWatch - alarm state changes published as notifications
• Amazon Kinesis Data Firehose - streaming messages into S3, Redshift, or OpenSearch
• AWS Step Functions - publishing status updates or approval requests
• Amazon S3 - bucket event notifications routed through SNS

This breadth is what makes SNS a common glue layer between otherwise unrelated AWS services.

SNS and SQS solve different messaging problems and are often used together rather than as alternatives to each other.

A very common pattern combines both: SNS fans a single event out to several SQS queues, each consumed independently at its own pace. That combination gets the low-latency push of SNS at the fan-out point and the durable, poll-based buffering of SQS at each individual consumer.

Both services route events, but they target different levels of routing complexity.

SNS tends to fit straightforward broadcast scenarios with a handful of known subscribers, while EventBridge fits event-driven architectures with many producers, many consumers, and rules that need to inspect deep event structure. It's also common to see the two combined, with EventBridge routing to an SNS topic when a step in the workflow still needs simple fan-out to email, SMS, or a small set of endpoints.

Message attributes carry structured, key-typed metadata (String, Number, or Binary) alongside the message body without requiring subscribers to parse the payload itself to make routing decisions.

They're the mechanism filter policies actually evaluate, so attaching attributes like event_type or priority lets different subscriptions on the same topic each receive only the messages relevant to them, cutting down on wasted invocations and processing for consumers that don't need every message.

Each attribute has a declared type - String, Number, or Binary - and a publish can carry up to 10 of them, so they're meant for compact routing metadata rather than as a substitute for the message body itself.

A filter policy is a JSON document attached to a specific subscription, not to the topic itself, so each subscriber can have its own independent filtering rules on the same topic.

{
  "event_type": ["payment_failed"],
  "amount": [{"numeric": [">", 100]}]
}

Within a single attribute key, listed conditions are treated as OR (any match qualifies); across different keys in the same policy, conditions are treated as AND (all keys must match). Supported condition types include exact values, prefixes, ranges, numeric comparisons, and "anything-but" exclusions.

SNS also supports scoping a policy to the message body instead of attributes, which is useful when the routing field already lives naturally inside the JSON payload rather than being duplicated into a separate attribute at publish time.

FIFO topics are the right call when the business logic breaks if messages are processed out of order or more than once - for example, applying account debits and credits, or updating an order's status through a strict sequence of states.

They should generally be paired with SQS FIFO queues as the subscriber, and messages need a consistent message group ID so related events (like "all events for order #4821") stay ordered relative to each other, even while unrelated groups are processed in parallel.

The trade-off is throughput: a standard topic can absorb far more publishes per second than a FIFO topic, so FIFO should be a deliberate choice for the specific data that truly needs it, not a default applied to every topic in a system.

SNS retries failed deliveries according to a per-protocol retry (delivery) policy, which defines phases of immediate retries, then a backoff phase with increasing delay, and finally a longer fixed-interval phase, up to a configurable number of attempts.

If every retry in the policy is exhausted and no dead-letter queue is configured on the subscription, the message is dropped and only visible through CloudWatch metrics like NumberOfNotificationsFailed. If a DLQ is configured, the message lands there instead of being lost.

The retry policy - number of retries per phase and backoff rate - can be customized per protocol at the topic level, so an HTTP endpoint known to be flaky can be given a more patient policy than a highly reliable Lambda function.

SNS doesn't send failed messages to a dead-letter queue automatically - a redrive policy pointing to an SQS queue has to be configured explicitly on the subscription that should use one.

{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789012:sns-dlq"
}

Once configured, any message that exhausts its delivery retries for that specific subscription is routed to the DLQ instead of being discarded, giving engineers a place to inspect and potentially replay failed notifications.

The DLQ itself needs a resource policy allowing the SNS service principal to send to it, separate from the redrive policy on the subscription - missing that queue-side permission is a common reason a configured DLQ never actually receives anything.

Deduplication in FIFO topics stops the same logical message from being processed twice if it's accidentally published more than once, which matters most when a publisher retries after a network timeout without knowing whether the first attempt actually succeeded.

SNS supports content-based deduplication, hashing the message body automatically, or an explicit MessageDeduplicationId supplied by the publisher. Either way, any duplicate arriving within a five-minute deduplication interval is silently dropped rather than delivered again.

This matters most for something like a payment-confirmation event, where a retried publish after a dropped network response could otherwise trigger a second charge or a second shipment if it reached consumers twice.

Both control access to SNS, but they attach to different sides of the request.

Cross-account access to a topic typically requires both to line up: the topic policy must allow the external account's principal, and that principal's IAM policy must allow the SNS action being called. Within a single account, IAM policies alone are often enough since there's no account boundary to cross.

Securing a topic layers several controls rather than relying on a single setting.

1. Attach a topic policy that names specific principals allowed to publish or subscribe, avoiding wildcard access.
2. Use IAM policies to enforce least privilege on which SNS actions internal roles can call.
3. Add condition keys such as aws:SourceArn to prevent the "confused deputy" problem when another service invokes SNS on a user's behalf.
4. Enable server-side encryption with a customer-managed KMS key for sensitive payloads.
5. Use an SNS VPC interface endpoint so traffic from private subnets never traverses the public internet.
6. Turn on delivery status logging so any unexpected publish or delivery pattern is visible in CloudWatch Logs rather than discovered later.

Server-side encryption (SSE) for SNS uses an AWS KMS customer master key (CMK) to encrypt the message body at rest. It's enabled by attaching a KMS key ID to the topic, either at creation or by updating an existing topic.

An important nuance: SSE encrypts the message body, but message attributes are not encrypted by SSE, so sensitive data shouldn't be placed in attributes if encryption-at-rest is a requirement. Callers publishing or subscribing also need kms:Decrypt and related KMS permissions in addition to their SNS permissions, and using a customer-managed key rather than the AWS-managed default gives finer control over who can use that key.

Push messaging means the sender actively delivers a message to the receiver as soon as it's ready, without the receiver asking for it. Pull messaging means the receiver has to poll a source to check whether anything new is waiting.

SNS is a push-based service: as soon as a message is published, SNS immediately attempts delivery to every subscriber. SQS, by contrast, is pull-based - consumers call ReceiveMessage to retrieve items whenever they're ready to process them. This is exactly why SNS-to-SQS fan-out is so common: SNS pushes instantly to the queue, and the queue lets the consumer pull at its own pace.

In a fan-out setup, one SNS topic has multiple SQS queues subscribed to it; each queue gets its own independent copy of every message that passes the topic's filter for that subscription, and each queue's consumers process at their own pace without affecting the others.

flowchart LR
    P["Order Service"] --> T((SNS Topic))
    T --> Q1["Billing Queue"]
    T --> Q2["Shipping Queue"]
    T --> Q3["Analytics Queue"]

A common setting to enable is raw message delivery, which sends the message body directly into the queue instead of wrapping it in SNS's default JSON envelope - this keeps the payload consumers process simpler and avoids double-parsing JSON.

When a Lambda function subscribes to an SNS topic, SNS invokes the function asynchronously for each matching message rather than the function pulling anything itself.

sequenceDiagram
    participant Pub as Publisher
    participant SNS as SNS Topic
    participant Fn as Lambda Function
    participant DLQ as Failure Destination
    Pub->>SNS: Publish message
    SNS->>Fn: Async invoke with Records payload
    Fn-->>SNS: Success or error
    SNS->>Fn: Retry (up to configured attempts) on error
    SNS-->>DLQ: Send to on-failure destination if retries exhausted

The event passed to the function contains an SNS-formatted Records array with the message and its attributes. If the function throws or times out, SNS retries the invocation a limited number of times before optionally routing the event to a configured on-failure destination.

Cost at scale is driven mostly by request count and cross-region/data transfer charges, so the main levers are reducing unnecessary requests and unnecessary fan-out.

1. Use PublishBatch to send up to 10 messages in a single API call instead of 10 separate publish calls.
2. Apply subscription filter policies so uninterested subscribers never receive (and never have to process) messages irrelevant to them.
3. Enable raw message delivery to SQS to shrink payload size and downstream parsing cost.
4. Reserve FIFO topics for cases that truly need ordering, since standard topics support much higher throughput at the same price point.
5. Monitor CloudWatch for repeated failed deliveries, since exhausted retries against a broken endpoint still consume request volume.

Working through undelivered notifications usually means checking the pipeline from subscription status down to endpoint reachability, in order.

1. Confirm the subscription status isn't stuck in "PendingConfirmation".
2. Check whether a subscription filter policy is excluding the message's attributes.
3. Review CloudWatch metrics such as NumberOfNotificationsFailed for that topic.
4. Enable delivery status logging to see per-attempt success/failure detail for the affected protocol.
5. Verify the topic and IAM policies aren't denying the publisher or the delivery role.
6. Check that an HTTP/S endpoint is actually returning a 200 status and hasn't been auto-disabled after repeated failures.
7. Check whether a dead-letter queue is configured and inspect it for the missing messages.

A platform application endpoint targets a single physical device, so publishing directly to an endpoint ARN is a one-to-one push to that one phone or tablet. A standard topic, by contrast, is one-to-many - a single publish reaches every current subscriber.

The two aren't mutually exclusive: a common pattern subscribes many platform endpoints to one topic, so a single publish to the topic fans out to every registered device at once, combining topic-level broadcast with device-level push.

This is how a "notify all users" feature is usually built: rather than looping through every device endpoint and publishing individually, the application publishes once to the topic and lets SNS handle delivering to each subscribed endpoint.

Direct service-to-service API calls create tight coupling: the caller must know the callee's address, handle its downtime, and be updated every time a new consumer needs the same event. SNS removes that coupling.

SNS is the better choice when an event needs to reach multiple consumers without the producer changing, when downstream consumers might be temporarily unavailable and shouldn't block the producer, or when new consumers will likely be added over time - subscribing to an existing topic requires no changes to the producer at all. Direct calls can still make sense for a synchronous request/response interaction where the caller genuinely needs an immediate answer back.

Delivery status logging records the outcome of each delivery attempt - success or failure, along with response codes and latency where applicable - to Amazon CloudWatch Logs, broken out per protocol (HTTP/S, Lambda, SQS, Firehose).

It's configured per topic with a sampling rate and an IAM role that grants SNS permission to write logs, and it's one of the most direct ways to debug why a specific subscriber isn't receiving messages, since it shows exactly what SNS attempted and what response it got back. Sampling can be set separately for successful and failed deliveries, so failures can be logged at 100 percent while successes are sampled lightly to control log volume.

Standard topics are architected for maximum throughput and availability, which means messages can be delivered through multiple parallel internal paths rather than a single serialized pipeline. That parallelism is what makes very high publish rates possible, but it also means two messages published in quick succession aren't guaranteed to arrive at a subscriber in the same order.

The same distributed design is why standard topics offer at-least-once rather than exactly-once delivery - occasional duplicates are the trade-off for speed and availability. Applications that must preserve order need a FIFO topic instead, which sacrifices some throughput specifically to enforce sequencing per message group.

When a message is published, SNS's control plane first resolves the current list of confirmed subscriptions on that topic. Each subscription is evaluated independently against its own filter policy to decide whether that particular subscriber should receive this message at all.

flowchart TD
    A["Publish call arrives"] --> B["Resolve subscription list"]
    B --> C{Filter policy match?}
    C -- No --> D["Skip this subscription"]
    C -- Yes --> E["Hand off to per-subscription delivery worker"]
    E --> F["Deliver via protocol: SQS, Lambda, HTTP/S, etc."]
    F -- Failure --> G["Retry per delivery policy"]
    G -- Exhausted --> H["Optional DLQ"]

For subscriptions that pass filtering, delivery is handed off to independent delivery paths per protocol, so a slow or failing HTTP endpoint doesn't block or delay delivery to a healthy SQS or Lambda subscriber on the same topic. Each subscription also retries failures according to its own delivery policy, entirely decoupled from every other subscription's outcome.

This independence is what makes fan-out reliable at scale: the publisher's single API call completes as soon as SNS accepts the message, while the actual per-subscriber delivery, retrying, and failure handling all happen asynchronously and in parallel behind the scenes.

A FIFO message's lifecycle starts with the publisher supplying a message group ID and either a content-based deduplication flag or an explicit deduplication ID.

flowchart TD
    A["Publish with MessageGroupId + DedupId"] --> B{Duplicate within 5-min window?}
    B -- Yes --> C["Message discarded silently"]
    B -- No --> D["Message enters its group's ordered sequence"]
    D --> E["Delivered in strict order to subscribed SQS FIFO queue"]
    E --> F["Next message in same group waits for prior delivery"]

SNS first checks the five-minute deduplication window; if a matching dedup ID or content hash was already seen, the new publish is silently discarded. Otherwise, the message is placed into the ordered sequence for its message group and delivered to the subscribed SQS FIFO queue only in that strict order - a message later in the group won't be delivered ahead of one still pending. Different message groups, however, are processed independently of one another, which is what allows overall throughput to scale even though ordering within any single group is strict.

At-least-once delivery means SNS guarantees a message will be delivered one or more times, but never guarantees exactly one delivery on standard topics. It achieves this through a configurable retry (delivery) policy that defines multiple phases: an immediate-retry phase with no delay, a backoff phase with exponentially increasing delay, and a final phase at a fixed maximum interval, continuing until the configured number of attempts is exhausted.

Because there's no deduplication layer on standard topics, a message can be delivered more than once if a subscriber's acknowledgment is lost or delayed even though the message actually arrived - so applications consuming from standard SNS topics need to be built to handle duplicate messages idempotently rather than assuming single delivery. This is a deliberate trade-off: guaranteeing exactly-once delivery would require coordination overhead that would slow down the very high-throughput case standard topics are optimized for.

SNS filter policies are primarily attribute-based: they match against the key-value message attributes attached to a publish call, with more limited support for filtering on the message body itself. Matching logic is scoped per subscription and uses OR-within-a-key, AND-across-keys semantics.

EventBridge's event pattern matching can reach arbitrarily deep into a JSON event body and route to many different target types from a single rule, making it the better fit when routing logic itself is the complex part of the architecture rather than just the fan-out.

SNS topics are regional resources with no built-in cross-region replication, so a DR strategy has to be built deliberately rather than assumed.

1. Provision an identical topic (same name, subscriptions, and policies) in a secondary region using infrastructure as code, so the two stay in sync as changes are made.
2. Choose active-active (publish to both regions' topics simultaneously) or active-passive (publish only to primary, with a failover mechanism that redirects publishers to the secondary topic ARN during an outage).
3. Ensure subscribers in the secondary region (queues, functions) are already deployed and warm, not created on-demand during a failure.
4. Use Route 53 health checks or application-level configuration to control which region's topic ARN producers use at any given time.
5. Regularly test the failover path, since an untested DR topic is a common source of surprises during a real incident.

Cross-account access starts with the topic owner (Account A) attaching a resource-based topic policy that explicitly grants a principal in Account B permission to publish or subscribe, often scoped with a condition like aws:SourceArn or organization ID for safety.

sequenceDiagram
    participant B as Account B (Subscriber)
    participant SNSA as Account A Topic
    participant QB as Account B SQS Queue
    B->>SNSA: Subscribe queue to topic (allowed by topic policy)
    Note over QB: Queue policy must also allow SNS to send
    SNSA->>QB: Deliver message across account boundary

Account B then subscribes its own resource - commonly an SQS queue - to the topic; that queue's own resource policy must separately grant the SNS topic's ARN permission to send messages into it, since permission has to be granted from both directions. Once both policies align, messages published in Account A flow through to Account B's subscriber without either side needing an IAM role that spans the account boundary.

Throughput within a single FIFO message group is inherently serialized, since ordering is only meaningful if one message waits for the last to be delivered - so the primary lever for scaling FIFO throughput is spreading messages across many message group IDs rather than trying to speed up one group.

1. Design message group IDs around a dimension that can be parallelized, such as customer ID or order ID, rather than a single shared group for everything.
2. Enable high-throughput mode, which removes the strict per-API-action throughput ceiling that applies to standard FIFO processing.
3. Use PublishBatch to send up to 10 messages per call, reducing per-request overhead.
4. Use content-based deduplication instead of manually generated IDs where possible, reducing publisher-side complexity without losing correctness.

An HTTP/S subscription's delivery policy defines several distinct retry phases rather than one flat retry count. Immediately after a failure, SNS retries a small number of times with no delay, on the assumption the failure might be transient.

If those immediate retries also fail, delivery enters a backoff phase where the delay between attempts grows, typically doubling up to a configured maximum, followed by a post-backoff phase that continues retrying at that fixed maximum interval for the remainder of the configured retry window. Throughout this process, each failed attempt (and its HTTP response code, if any) can be captured by delivery status logging. If every phase is exhausted without a successful 200 response and no dead-letter queue is configured on the subscription, the message is permanently dropped and is only visible afterward through CloudWatch failure metrics.

SNS itself has no built-in retention or replay capability - once a message is delivered (or fails permanently), it's gone from SNS's perspective. Archiving and replay have to be built as a separate subscribed pipeline.

1. Subscribe an SQS queue or a Kinesis Data Firehose delivery stream to the topic specifically for archiving purposes, separate from operational subscribers.
2. Have Firehose (or a Lambda consumer of the archive queue) write each message durably to Amazon S3, partitioned by date for easy retrieval.
3. To replay, read the archived messages back out of S3 and republish them to the original topic, or directly to the specific subscriber that needs to reprocess them.
4. Track a replay watermark (e.g., last-replayed timestamp) to avoid re-publishing the same archived batch twice.

This pattern effectively borrows the retention and replay characteristics SNS lacks from S3 and, if deeper replay semantics are needed, from Kinesis Data Streams instead.

A filter policy is a JSON object where each key corresponds to a message attribute name (or, with body-based filtering enabled, a path into the message body), and each key's value is an array of conditions.

{
  "event_type": ["order_shipped", "order_cancelled"],
  "priority": [{"anything-but": "low"}]
}

Within one key, the listed conditions are OR'd together - matching any one of them satisfies that key. Across different keys in the same policy, the logic is AND - every key present in the policy must be satisfied for the message to pass. Supported condition types include exact string or numeric matches, prefix matches, numeric ranges, existence checks, and "anything-but" exclusions.

Critically, this evaluation happens before SNS attempts delivery to that subscription at all - a non-matching message is never handed to the delivery worker for that subscriber, so filtering reduces both unnecessary network calls and unnecessary invocations downstream, rather than just hiding irrelevant messages after the fact.

Step Functions can call SNS directly as a task using the optimized integration arn:aws:states:::sns:publish, which lets a state machine publish a notification - for example, a human approval request or a status update - without needing a separate Lambda function just to make the API call.

The reverse direction is just as common: an SNS message triggers a Lambda function, and that function starts a Step Functions execution to run a longer, stateful workflow that wouldn't fit cleanly inside a single Lambda invocation. Together, this lets a fan-out event from SNS kick off orchestrated, multi-step processing while still letting the workflow itself notify other systems along the way.

A typical example is a state machine that reaches a manual-approval step, publishes an SNS notification containing an approval link, and then pauses using a task token until someone acts on it, at which point the workflow resumes exactly where it left off.

Neither is universally better - the right choice depends on how complex the routing logic is and how many independent event producers exist.

For a handful of known services that all need the same broadcast event, SNS with SQS subscribers is simpler to reason about and cheaper to run. As the number of event sources and the complexity of routing rules grows - especially across many teams or accounts - EventBridge's rule-based routing and schema tooling scale better without turning into a tangle of ad hoc filter policies.

Duplicates in a FIFO topic usually trace back to how deduplication IDs are generated or how the publisher handles ambiguous failures, rather than a bug in SNS itself.

1. Check whether the publisher generates a new random MessageDeduplicationId on every retry - if so, a retried publish after a timeout looks like a brand-new message to SNS, defeating deduplication entirely.
2. Switch to a deterministic deduplication ID (for example, a hash of a stable business key) so retries of the same logical event always produce the same ID.
3. Remember the deduplication window is five minutes - a genuine re-publish of the same business event outside that window will not be deduplicated by SNS.
4. Confirm the downstream SQS FIFO consumer is also idempotent, since deduplication at the SNS layer doesn't remove the need for safe reprocessing at the consumer.
5. Review publisher logs or CloudTrail for repeated Publish calls tied to the same business event to confirm where the duplication originates.

The lifecycle begins outside SNS, on the device itself, and only later involves SNS as the delivery layer.

flowchart TD
    A["App registers with APNs/FCM, gets device token"] --> B["App sends token to backend"]
    B --> C["Backend creates SNS platform endpoint"]
    C --> D["Publish to endpoint directly, or via a subscribed topic"]
    D --> E["SNS translates message to platform-specific payload"]
    E --> F["Gateway - APNs/FCM - delivers to device"]
    F -- Invalid token reported --> G["SNS marks endpoint disabled"]

Once the device has a token and SNS has created a platform endpoint ARN referencing it, a publish - either directly to that endpoint or to a topic the endpoint is subscribed to - gets translated by SNS into the specific JSON payload format each gateway expects, then handed off to APNs or FCM for actual delivery to the device.

If the gateway reports that a token is no longer valid (the app was uninstalled, for instance), SNS marks the corresponding endpoint as disabled rather than continuing to attempt delivery, and the application is expected to detect this and re-register the device the next time it's active.

SNS sits alongside SQS, EventBridge, Kinesis, and Amazon MQ in AWS's messaging portfolio, and its deliberately narrow feature set is itself a design choice rather than a limitation. It doesn't retain or replay messages the way Kinesis does, it doesn't offer deep content-based routing rules the way EventBridge does, and it doesn't provide the pull-based buffering and backpressure control that SQS does.

Instead, SNS focuses on doing one thing well: taking a single published message and pushing it, immediately and in parallel, to a set of subscribers. That narrowness is exactly what keeps it low-latency and simple to reason about, and it's why SNS is so often used as a building block combined with SQS, Lambda, or Kinesis rather than as a complete solution on its own.

This reflects AWS's broader architectural philosophy of composable, single-purpose primitives over one monolithic message broker that tries to do everything. Teams get to choose exactly the guarantees they need - ordering, retention, routing depth - by combining services, rather than accepting the overhead of a heavier system when only simple fan-out was ever required.