Skip to content

SYSTEM Cited by 4 sources

Amazon SNS

Amazon SNS (Simple Notification Service) is AWS's managed pub/sub fanout messaging service. Publishers post to a topic; subscribers (SQS queues, Lambda functions, HTTP endpoints, email, mobile push) each receive their own copy. Commonly paired with systems/aws-sqs as the fanout half of a topic → queue-per-consumer pipeline.

Role for this wiki

As external delivery channel for dead-man's-switch heartbeats (2026-05-05)

Distinct from the fanout / event-bus role: SNS here is used as a destination for continuous dead-man's-switch heartbeats from an internal observability stack. Airbnb's Observability team routes an always-firing Alertmanager alert to a dedicated SNS topic, and a CloudWatch rate alarm on the topic pages on-call when the message rate drops — i.e., when the internal pipeline that generates the heartbeat has broken. SNS's value here is being on a different control plane than the observability stack: a K8s-cluster or mesh incident does not affect SNS's ability to accept the heartbeat. See concepts/dead-mans-switch and patterns/heartbeat-absence-as-alert-trigger. This is the first canonical wiki disclosure of SNS in a meta-monitoring / external-watchdog-channel role.

SNS appears as the fanout primitive in AWS-native producer/consumer pipelines. The canonical shape is S3 event → SNS topic → SQS queue-per-consumer, letting each downstream subscriber control its own queue depth + retention without affecting others.

SNS/SQS pairs as anti-pattern at org scale

Per-integration SNS topics + SQS queues between services is a natural first step for introducing async decoupling, but Amazon Key explicitly names it as "implemented on an ad-hoc basis, lacking standardization and creating additional maintenance overhead". At fleet scale SNS/SQS pairs become pub/sub without governance — no shared schema registry, no content-based routing rules, no subscriber-provisioning scaffolding. EventBridge is AWS's answer for org-scale event-driven architectures: one bus with content-based routing rules + a schema registry + reusable subscriber constructs (patterns/single-bus-multi-account, patterns/reusable-subscriber-constructs, patterns/client-side-schema-validation). SNS remains the right primitive for narrower fanout pipelines (S3 event → SNS → SQS per consumer) and as an EventBridge target.

Seen in

Last updated · 542 distilled / 1,571 read