SNS-Themen und Fan-out-Architektur

Amazon Simple Notification Service (SNS) ist ein vollständig verwalteter Pub/Sub-Messaging-Service. Publisher senden Nachrichten an ein SNS-Topic, und SNS stellt diese Nachrichten sofort allen Subscribern zu. Im Gegensatz zu SQS (Pull-basiert) ist SNS Push-basiert – Nachrichten werden an Subscriber zugestellt, sobald sie veröffentlicht wurden. Dadurch eignet sich SNS ideal, um Ereignisse gleichzeitig an mehrere nachgelagerte Systeme zu verteilen.

Wie SQS verfügt auch SNS über zwei Topic-Typen: Standard topics bieten eine Zustellreihenfolge nach dem Best-Effort-Prinzip, mindestens einmalige Zustellung und nahezu unbegrenzten Durchsatz. Sie können Nachrichten an SQS, Lambda, HTTP-Endpunkte, E-Mail, SMS und Mobile Push zustellen. FIFO topics garantieren eine strikt eingehaltene Reihenfolge und genau einmalige Zustellung, allerdings nur an FIFO-SQS-Subscriber. FIFO topics unterstützen mit Batching bis zu 3.000 Nachrichten pro Sekunde und werden verwendet, wenn die Reihenfolge von Ereignissen über mehrere Subscriber hinweg erhalten bleiben muss.

SNS unterstützt mehrere protokollbasierte Subscriber-Typen:

• SQS: dauerhaftes Queuing (am häufigsten für asynchrone Verarbeitung)
• Lambda: direkte Invocation (aus Sicht von SNS synchron)
• HTTP/HTTPS: Webhook-Zustellung an externe Endpunkte
• Email / Email-JSON: Benachrichtigung von Personen
• SMS: Zustellung von Textnachrichten
• Mobile Push: FCM, APNs über Platform Applications
• Firehose: Stream zu S3 oder Redshift über Kinesis Data Firehose

Fan-out ist das zentrale SNS-Muster: Sie veröffentlichen eine Nachricht in einem Topic, und SNS stellt sie gleichzeitig allen Subscribern zu. Beispielsweise kann ein Ereignis zu einer neuen Bestellung an Folgendes verteilt werden: eine SQS-Warteschlange für die Abwicklung im Lager, eine weitere SQS-Warteschlange für die Bestandsaktualisierung, eine Lambda-Funktion zur Betrugserkennung und ein E-Mail-Abonnement für das Betriebsteam. Jeder Subscriber verarbeitet das Ereignis unabhängig, ohne Kopplung zwischen den einzelnen Subsystemen. Dies ist deutlich skalierbarer als ein einzelner Consumer, der die Weiterleitung an mehrere Systeme übernimmt.

Das empfohlene Muster kombiniert SNS und SQS: Sie veröffentlichen eine Nachricht in SNS, das sie an mehrere SQS-Warteschlangen verteilt. Dies bietet:

• Haltbarkeit: Wenn ein Consumer nicht verfügbar ist, werden Nachrichten in SQS zwischengespeichert
• Unabhängige Skalierung: Jeder Consumer verarbeitet Nachrichten in seinem eigenen Tempo
• Entkopplung: Neue Consumer abonnieren einfach SNS, ohne dass der Publisher geändert werden muss
• Widerstandsfähigkeit bei Wiederholungen: SQS stellt Visibility Timeout und DLQ bereit

Direkte Lambda-Subscriber verfügen nicht über die Pufferung von SQS. Daher ist SNS→SQS→Lambda das robustere dreistufige Muster.

Wenn SNS eine Nachricht nicht an einen Subscriber zustellen kann (der HTTP-Endpunkt gibt 5xx zurück, Lambda löst einen Fehler aus oder SQS ist nicht verfügbar), führt SNS die Zustellung nach einer Strategie mit exponentiellem Backoff erneut aus. Die Wiederholungsrichtlinien unterscheiden sich je nach Protokoll: HTTP-Endpunkte erhalten bis zu 4 sofortige Wiederholungen plus exponentielles Backoff über 23 Tage. Bei Lambda und SQS werden Wiederholungen durch deren eigene Wiederholungsmechanismen verwaltet. Konfigurieren Sie eine SNS Topic DLQ, um Nachrichten zu erfassen, bei denen alle Zustellungswiederholungen ausgeschöpft sind. So wird sichergestellt, dass keine Ereignisse unbemerkt verloren gehen.

Veröffentlichen Sie Nachrichten mit dem AWS SDK oder der CLI in SNS. Jede Nachricht kann einen Subject (für E-Mail), einen Message-Body (bis zu 256 KB) und Message Attributes für das Routing enthalten. Für verschiedene Subscriber-Typen (SQS, E-Mail oder Mobile) können Sie Message Structure verwenden, um für jedes Protokoll unterschiedliche Inhalte zu senden. JSON mit protokollspezifischen Schlüsseln ermöglicht es Ihnen, die Nutzlast an den jeweiligen Subscriber-Typ anzupassen.

Subscription filter policies ermöglichen es jedem Subscriber, basierend auf message attributes nur die für ihn relevanten Nachrichten zu empfangen. Ohne Filter empfangen alle Subscriber sämtliche veröffentlichten Nachrichten. Mit einer Filterrichtlinie legt ein Subscriber fest, für welche Attributwerte er sich interessiert. Beispielsweise abonniert eine Warteschlange für Bestellungen vom Typ „PREMIUM“ mit dem Filter {"orderType": ["PREMIUM"]}; eine Warteschlange für „STANDARD“ filtert nach ["STANDARD"]. Jeder Subscriber verarbeitet nur seine relevante Teilmenge, wodurch unnötige Verarbeitung reduziert wird.

SNS unterstützt direkte Mobile-Push-Benachrichtigungen an iOS-(APNs-) und Android-Geräte (FCM/GCM). Sie registrieren Gerätetoken als Platform-Endpoint-ARNs und veröffentlichen anschließend direkt an einen Endpunkt oder an ein Topic mit Platform-Application-Subscribern. Für direkte Benachrichtigungen an Geräte in großem Maßstab (Millionen von Geräten) kombinieren Sie SNS mit SQS fan-out: SNS leitet das Benachrichtigungsereignis an SQS weiter, und ein Worker-Service übernimmt die Auflösung von Token und die Zustellung in großem Maßstab.

Schützen Sie SNS-Nachrichten mit serverseitiger Verschlüsselung über AWS KMS. Dadurch werden Nachrichten im Ruhezustand innerhalb der SNS-Infrastruktur verschlüsselt. Die Zugriffskontrolle verwendet sowohl ressourcenbasierte Policies (wer Nachrichten im Topic veröffentlichen oder es abonnieren darf) als auch IAM policies. Damit ein S3-Bucket Benachrichtigungen in einem SNS-Topic veröffentlichen darf, gewähren Sie dem S3-Service-Prinzipal in der Ressourcen-Policy des Topics die Berechtigung sns:Publish. Beschränken Sie das Veröffentlichen stets auf autorisierte Quellen, um das Einschleusen nicht autorisierter Ereignisse zu verhindern.

SNS und SQS ergänzen einander und sind keine Alternativen. SNS (Push) dient dazu, mehrere Consumer sofort zu erreichen – verwenden Sie es, wenn mehrere Systeme auf ein Ereignis reagieren müssen. SQS (Pull) dient der zuverlässigen, dauerhaften Verarbeitung durch einen einzelnen Consumer mit Wiederholungen und DLQ – verwenden Sie es, wenn ein Consumer jede Nachricht genau einmal in seinem eigenen Tempo verarbeiten muss. Das SNS→SQS-Fan-out-Muster bietet beides: Broadcast-Zustellung durch SNS sowie dauerhafte Verarbeitung mit Wiederholungsmöglichkeit durch SQS. Diese Kombination kommt häufig in Prüfungsszenarien für SAA-C03 vor.

Testen Sie Ihr Verständnis der Konzepte für AWS Solutions Architect (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: SNS topics ermöglichen Push-basiertes Pub/Sub-Broadcasting an Subscriber wie SQS, Lambda, HTTP, SMS und E-Mail gleichzeitig. Die Fan-out-Architektur verwendet ein SNS-Topic, das mehrere SQS-Warteschlangen versorgt, um eine dauerhafte, unabhängig skalierbare Ereignisverarbeitung durch mehrere Consumer zu ermöglichen. Subscription filter policies reduzieren unnötige Verarbeitung, indem sie anhand von Message Attributes nur relevante Ereignisse an die jeweiligen Subscriber weiterleiten. Als Nächstes sehen wir uns die Nachrichtenfilterung in SQS und die Integration von SNS + SQS im Detail an.