SQS-Nachrichtenfilterung und SNS- plus SQS-Integration

In einer Fan-out-Architektur ohne Filterung empfängt jeder SQS-Subscriber jede SNS-Nachricht. Wenn Ihr Topic Bestellereignisse für 10 verschiedene Produktkategorien veröffentlicht, ein Subscriber aber nur Elektronikbestellungen verarbeitet, empfängt er trotzdem Nachrichten zu Lebensmitteln und Kleidung und muss sie verwerfen. Dies verschwendet Rechenleistung, erhöht die Kosten und verursacht unnötige Last auf den Consumern. SNS subscription filter policies lösen dieses Problem, indem SNS selbst Nachrichten nur an die passenden Subscriber weiterleitet.

Eine filter policy ist ein JSON-Objekt, das auf ein SQS- oder Lambda-Abonnement angewendet wird. SNS prüft die Policy anhand der message attributes jeder Nachricht, bevor die Nachricht zugestellt wird. Stimmen die Message Attributes mit der Filterrichtlinie überein, wird die Nachricht zugestellt. Andernfalls überspringt SNS diesen Subscriber stillschweigend. Filterrichtlinien unterstützen den Abgleich von Zeichenketten, numerische Bereiche, Präfixabgleich sowie den Operator exists, um das Vorhandensein oder Fehlen eines Attributs zu prüfen.

Standardmäßig gleichen Filterrichtlinien message attributes (Metadaten) ab. Seit 2023 unterstützt SNS auch die payload-basierte Filterung (Body), indem der Geltungsbereich der Filterrichtlinie auf MessageBody gesetzt wird. Dadurch ist eine Filterung direkt im Message-Body anhand von JSON-Pfaden möglich, ohne dass Publisher Attribute hinzufügen müssen. Die Filterung des Bodys ist flexibler, setzt jedoch voraus, dass der Message-Body gültiges JSON enthält. Prüfen Sie stets, welcher Geltungsbereich zum Ausgabeformat Ihres Publishers passt.

Filterrichtlinien unterstützen neben dem einfachen Abgleich von Zeichenketten mehrere weitere Matching-Operatoren:

• Numeric: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} findet jede Zeichenkette, die mit diesem Präfix beginnt
• Anything-but: {"anything-but": ["CANCELLED"]} findet jeden Wert außer den aufgelisteten
• Exists: {"exists": true} findet den Wert, wenn das Attribut vorhanden ist; false, wenn es fehlt

Damit die Filterung funktioniert, muss der Publisher beim Veröffentlichen in SNS Message Attributes einschließen. Attribute sind Schlüssel-Wert-Paare mit einem Datentyp (String, Number, Binary). Der Publisher muss nicht wissen, welche Filterrichtlinien die einzelnen Subscriber verwenden. Er ergänzt die Nachricht lediglich um Attribute, die das Ereignis beschreiben. SNS übernimmt das Routing automatisch. Dadurch bleiben Publisher vollständig von subscriber-spezifischer Logik entkoppelt.

Eine ausgefeilte Fan-out-Topologie kann vorsehen, dass SNS Nachrichten auf mehreren Spezifikationsstufen an SQS-Warteschlangen weiterleitet: Eine Warteschlange empfängt alle Bestellungen (ohne Filter) zur Protokollierung, eine weitere nur Bestellungen mit hohem Wert (HIGH_VALUE, Betrag >= 1000) zur Betrugsprüfung und eine dritte nur Bestellungen der Kategorie ELECTRONICS für das Elektroniklager. Jede SQS-Warteschlange verfügt über einen eigenen Lambda-Consumer. Dieses Muster ermöglicht die unabhängige Skalierung jeder Verarbeitungsebene und das Hinzufügen neuer Consumer, ohne bestehende Consumer oder den Publisher zu ändern.

SNS kann Nachrichten an SQS-Warteschlangen in einem anderen AWS-Konto zustellen. Die ressourcenbasierte Policy der SQS-Warteschlange muss dem SNS-Service-Prinzipal erlauben, sqs:SendMessage aus dem ARN des SNS-Topics im veröffentlichenden Konto aufzurufen. Dadurch wird eine zentrale Veröffentlichung von Ereignissen ermöglicht (ein Konto veröffentlicht, mehrere Kontoteams abonnieren), ohne Anmeldedaten gemeinsam zu verwenden. Accountübergreifender Fan-out ist ein häufig verwendetes Muster in AWS-Organizations-Umgebungen mit mehreren Konten.

Wenn das Ereignisvolumen stark ansteigt, skalieren direkte SNS-to-Lambda-Aufrufe Lambda sofort und können dadurch nachgelagerte Datenbanken oder APIs überlasten. Wird zwischen SNS und Lambda SQS eingefügt, entsteht ein Puffer: SNS stellt Nachrichten an SQS zu, und Lambda fragt SQS mit einer kontrollierten Batch-Größe ab. So kann Lambda mit einer nachhaltigen Rate verarbeiten, während SQS Verkehrsspitzen auffängt. Die Tiefe der Warteschlange dient als Backpressure-Mechanismus. Sie können sie überwachen und alarmiert werden, wenn sie über einen Schwellenwert hinaus anwächst, der auf einen Verarbeitungsrückstand hindeutet.

SNS → Lambda (direkt): geringste Latenz, keine Pufferung, Lambda skaliert sofort. Am besten für Echtzeitwarnungen oder dringende Benachrichtigungen, bei denen eine Latenz von unter einer Sekunde wichtig ist. SNS → SQS → Lambda: bietet zusätzlich DLQ-Unterstützung, kontrollierten Durchsatz, Wiederholungen mit Visibility Timeout und die Überwachung der Warteschlangentiefe. Am besten für Transaktionsverarbeitung, Bestandsaktualisierungen und alle Szenarien, in denen nachgelagerte Limits eingehalten werden müssen. Wählen Sie in Prüfungsfragen immer die SQS-Pufferung, sobald Haltbarkeit und Ratensteuerung erwähnt werden.

Verwenden Sie den Editor für Filterrichtlinien der SNS-Konsole, um vor der Bereitstellung zu testen, ob eine Beispielnachricht Ihrer Filterrichtlinie entsprechen würde. Sie können auch die SNS Sandbox verwenden, um die Nachrichtenübermittlung zu simulieren und das Routing zu überprüfen. Validieren Sie Filterrichtlinien im Code, indem Sie Testnachrichten mit bekannten Attributen veröffentlichen und die CloudWatch-Metriken für jedes Abonnement prüfen: Die Metrik NumberOfMessagesFiltered zeigt, wie viele Nachrichten durch den Filter blockiert wurden. So können Sie Richtlinien optimieren, ohne auf Ereignisse in der Produktionsumgebung warten zu müssen.

Eine vollständige SNS- und SQS-Integration sieht folgendermaßen aus: (1) Die Anwendung veröffentlicht ein Ereignis mit Nachrichtenattributen in einem SNS Standard topic; (2) SNS wertet die Filterrichtlinie jedes Abonnements aus und übermittelt nur passende Nachrichten an die jeweilige SQS-Warteschlange; (3) Lambda ruft Nachrichten mit einer konfigurierten Batchgröße aus jeder SQS-Warteschlange ab und verarbeitet sie; (4) Fehlgeschlagene Nachrichten erreichen nach maxReceiveCount die DLQ; (5) Ein CloudWatch-Alarm zur Tiefe der DLQ benachrichtigt das Team. Dieses vollständig entkoppelte und ausfallsichere Muster ist eine beispielhafte SAA-C03-Architektur.

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

In dieser Lektion haben Sie gelernt: SNS-Filterrichtlinien leiten Nachrichten auf SNS-Ebene anhand von Nachrichtenattributen oder dem Nachrichteninhalt weiter und vermeiden dadurch unnötige Verarbeitung durch nachgelagerte Consumer; das Muster SNS→SQS→Lambda ergänzt die Broadcast-Verteilung um eine dauerhafte Pufferung und Ratensteuerung vor der Verarbeitung; und die SQS-Übermittlung kontoübergreifend ermöglicht zentralisiertes Pub/Sub in Umgebungen mit mehreren Konten mithilfe von Ressourcenrichtlinien für Warteschlangen. Als Nächstes sehen wir uns die REST-, HTTP- und WebSocket-APIs von Amazon API Gateway an.