AWS SAP SNS fan-out filter policies and subscription protocols
One topic, many subscribers. Filters choose who hears. Protocol chooses how.
<!-- hal:authoritative:yaml -->
One topic can wake many workers. A filter policy decides which workers hear which events. Protocol choice decides how those workers receive.
§I. Frame
Last SAP fire on SoT taught Direct Connect resiliency and LAG (09-22). PrivateLink (09-07), Route53 failover (08-26), TGW RAM (08-14), and Organizations/SCPs (08-02) stay on their shelves. DOP StackSets (09-25) is not today's seat.
Today the exam grain is messaging fan-out. Bootcamp SAP sns.md: SNS is a regional pub/sub service; topics hold permissions and configuration; publishers send; subscribers receive; filters apply per subscriber; fan-out is a single topic with multiple SQS queue subscribers (and other protocols).
Ops today censuses PendingConfirmation and FilterPolicy on live subscriptions. Cert names the architecture those attributes sit inside.
§II. Fan-out shape
| Pattern | What you buy | Exam trap |
|---|---|---|
| SNS → many SQS queues | Durable buffers per consumer; each queue scales alone | Calling one shared queue "fan-out" |
| SNS → Lambda | Push invoke; good for light, fast handlers | Forgetting async retry / DLQ story on the function |
| SNS → HTTPS | Push to an external webhook | Skipping ConfirmSubscription and signature verification |
| SNS → SQS → Lambda | Buffer + poll; classic decouple | Treating the SQS hop as optional decoration when burst absorption matters |
Fan-out means one publish, many independent deliveries. Each subscription fails or succeeds on its own. A poison HTTPS endpoint does not stop the SQS subscriber on the same topic.
Payload ceiling stays 256 KB. For larger bodies, publish a pointer (S3 object key) and keep the SNS message small.
§III. Filter policies as the routing knife
Without a FilterPolicy, every confirmed subscriber receives every message. With a FilterPolicy, SNS evaluates attributes (or body fields) and skips non-matching subscribers.
FilterPolicyScope choices that show up on SAP designs:
- MessageAttributes (default) when your publishers already stamp typed attributes (
event,tier,region). - MessageBody when the useful keys live in JSON from EventBridge, SES, RDS, or a custom body schema.
Eventual consistency: filter policy changes can take up to 15 minutes to fully apply. Designs that flip filters and expect instant cutover fail the operational question even when the JSON is correct.
Contrast with SQS: an SQS redrive policy moves failed receives to a DLQ after maxReceiveCount. An SNS FilterPolicy never receives the message in the first place. Do not answer a fan-out selectivity question with a redrive policy.
§IV. Protocol census for the exam
Bootcamp lists HTTP(S), email (JSON), SQS, mobile push, SMS, and Lambda. Current Subscribe API also names application and firehose. Exam-useful splits:
- Need durable competing consumers → SQS subscription (often plus Lambda as a poller).
- Need immediate compute → Lambda subscription (watch concurrency and error handling).
- Need outside-AWS webhook → HTTPS, with confirmation and delivery policy / redrive for the HTTP subscription.
- Need human notify → email / SMS (confirmable; not a processing pipeline).
Cross-account: topic policies grant Subscribe to another account; PendingConfirmation still applies on confirmable protocols and on some cross-account SQS paths until the queue owner confirms.
SSE on the topic encrypts at rest for the service; it does not replace HTTPS in transit or signature checks on HTTP subscribers.
§V. Decision table (SAP stem → shape)
| Stem signal | Prefer |
|---|---|
| "One event, many independent backends, each with its own backlog" | SNS fan-out to SQS queues (+ optional per-queue filters) |
| "Only gold-tier orders to billing; all orders to analytics" | Same topic; FilterPolicy on the billing subscription |
| "Publisher sends EventBridge-shaped JSON, no message attributes" | FilterPolicyScope = MessageBody |
| "Webhook never receives after Subscribe" | PendingConfirmation / ConfirmSubscription, not a filter bug |
| "Must survive consumer downtime without dropping" | SNS → SQS (buffer), not SNS → Lambda alone |
§VI. What not to do
- Using a single SQS queue subscribed to SNS and calling it fan-out.
- Putting selectivity in the Lambda code when a FilterPolicy would drop the message earlier.
- Answering "multi-site DX HA" energy on a messaging stem (wrong domain; that was 09-22).
- Authoring a DOP Pipeline answer on an SAP messaging stem.
§VII. Close instruction
On a practice stem, name the topic, name each subscription protocol, and say whether a FilterPolicy (and which scope) belongs on that subscription. If the stem mentions a webhook that never fired, check confirmation before you redesign the topic. Tie the answer back to independent delivery: one bad subscriber must not imply the others failed.
Related
- Ops: SNS subscription census (same trio)
- Dev: enums and match for filter policy shapes (same trio)
- Prior SAP: Direct Connect resiliency
the study notes/certified-aws-solutions-architect-professional/09-containers-and-serverless/sns.md