SNS vs. SQS vs. Kinesis: Aufhören zu raten, anfangen zu entscheiden

SNS vs. SQS vs. Kinesis: Aufhören zu raten, anfangen zu entscheiden

Ehrlich gesagt: Beim ersten Mal, als ich mich zwischen SNS und SQS entscheiden musste, habe ich 40 Minuten auf die AWS-Konsole gestarrt, sieben Tabs aufgemacht – und war am Ende immer noch unsicher. Das ist Jahre her, und heute bietet AWS gleich sechs – ja, sechs – verschiedene Services für Event Delivery an. Selbst für erfahrene Architekten ist das überwältigend.

Dabei ist das gar kein so hartes Problem, wenn man aufhört, die Services zu vergleichen, und anfängt, über die *Form* der Daten nachzudenken. Brauchst du Push oder Pull? Replay? Fan-out? Content-based Routing? Das sind die eigentlichen Entscheidungsfragen.

Lass mich das mit dem Framework aufschlüsseln, das ich mir damals gewünscht hätte.

Die Kandidaten (Kurzer, Meinungstarker Überblick)

SNS — Der Lautsprecher
SNS (Simple Notification Service, https://aws.amazon.com/sns/) ist ein Pub/Sub-Push-Service. Du publishst eine Nachricht, und SNS schiebt sie sofort an alle Subscriber – Lambda-Funktionen, SQS-Queues, HTTP-Endpoints, E-Mail, sogar Mobile Push. Fire-and-Forget pur: SNS behält Nachrichten nicht, retryed kaum. Wenn niemand zuhört, ist die Nachricht weg.

**Nimm es, wenn:** Ein Event mehrere Aktionen gleichzeitig auslösen soll.

SQS — Die Zuverlässige Warteschlange
SQS (https://aws.amazon.com/sqs/) ist eine Pull-basierte Queue. Producer werfen Messages rein, Consumer polen und verarbeiten in ihrem eigenen Tempo. Kein Pub/Sub – Punkt-zu-Punkt. Messages leben bis zu 14 Tage, FIFO-Queues geben dir strikte Ordering und Exactly-Once-Processing.

**Nimm es, wenn:** Du einen Producer von einem Consumer entkoppeln willst und Zuverlässigkeit brauchst, ohne komplexes Routing.

Kinesis — Das Zeitmaschinen-Band
Kinesis (https://aws.amazon.com/kinesis/) ist eine Streaming-Datenplattform. Anders als bei SQS, wo eine Message konsumiert und gelöscht wird, lässt Kinesis mehrere Consumer unabhängig vom selben Stream lesen – und Daten für bis zu 365 Tage wiederholen. Du bekommst rock-solid Ordering pro Shard und massiven Durchsatz.

**Nimm es, wenn:** Du hochvolumige Streaming-Daten hast und Replayability brauchst.

MSK — Kafka ohne Kopfschmerzen (Naja, Weniger Davon)
MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) ist verwaltetes Kafka. Du bekommst das volle Kafka-Ökosystem – Topics, Partitionen, Consumer Groups, Kafka Connect, ksqlDB – ohne den Cluster selbst bauen zu müssen. Aber: Du bist weiterhin für Broker-Sizing, Tuning und OS-Patching verantwortlich.

**Nimm es, wenn:** Du schon Kafka-Know-how hast, Kafka Connect brauchst, oder eine bestehende Kafka-Deployment migrierst.

EventBridge — Der Clevere Router
EventBridge (https://aws.amazon.com/eventbridge/) ist der Newcomer, der schnell erwachsen wurde. Ein Event Bus mit mächtigem Content-based Filtering und Routing. Du publishst nicht einfach und hoffst das Beste – du kannst filtern, transformieren und Events basierend auf ihrem Inhalt an verschiedene Targets routen. Dazu kommen Scheduled Events (eingebauter Cron) und native Integration mit 140+ AWS-Services.

**Nimm es, wenn:** Routing-Logik vom Event-Inhalt abhängt, oder du eine ernsthafte Event-Driven Architecture baust.

RabbitMQ — Der Erprobte Veteran
RabbitMQ (https://www.rabbitmq.com/) ist der jahrzehntealte Open-Source-Broker. Er unterstützt mehrere Protokolle (AMQP, MQTT, STOMP), bietet flexibles Routing mit Exchanges und Bindings, und läuft überall. Auf AWS würdest du ihn typischerweise auf EC2 (https://aws.amazon.com/ec2/) betreiben oder einen verwalteten Third-Party-Service nutzen.

**Nimm es, wenn:** Du komplexe Routing-Patterns brauchst – Topic Exchanges mit Wildcards – oder Multi-Protokoll-Support.

Die Entscheidungsmatrix (Dein Spickzettel)

Hör auf, Feature-Tabellen zu vergleichen. Stell stattdessen diese sechs Fragen:

| Frage | Beste Wahl |
|---|---|
| Eins-zu-eins Entkopplung? | SQS |
| Eins-zu-viele Fan-out? | SNS oder EventBridge |
| Mehrere unabhängige Consumer? | Kinesis |
| Schon Kafka-fit oder Kafka-Ökosystem nötig? | MSK |
| Routing basiert auf Message-Content? | EventBridge |
| Komplexes/bestehendes Routing + viele Protokolle? | RabbitMQ |

Meine Philosophie: **Standardmäßig AWS-native Services nehmen, außer du hast einen Grund, es nicht zu tun.** Einen eigenen Broker zu betreiben, ist operationaler Aufwand, den du 2026 nicht mehr brauchst.

Real-World Szenarien

Szenario 1: E-Commerce Order Pipeline

Du betreibst einen Online-Shop. Wenn eine Bestellung reinkommt, musst du Bestätigungsmail schicken, Inventar updaten, Versand triggern, und Betrugserkennung benachrichtigen.

Klassisches Fan-out. Meine Wahl: **SNS oder EventBridge**. Ein "order.placed"-Event veröffentlichen, und SNS pusht es an eine E-Mail-Lambda, eine Inventar-SQS-Queue und den Versand-Service gleichzeitig. Aber wenn du Filterung willst (z. B. *nur* Betrugserkennung bei Bestellungen über 100 $ benachrichtigen), gewinnen EventBridges Content-based Rules. Die Consumer werden simpler – sie kriegen nur das, was sie sollen.

Szenario 2: Clickstream Analytics

Deine Plattform bekommt Millionen Klicks pro Stunde, und drei Teams – Analytics, ML, Security – müssen die Daten unabhängig konsumieren. Jedes Team will Replay für mindestens eine Woche.

Das ist **Kinesis**-Territorium. Bei SQS ist eine Message, die ein Consumer liest, für alle anderen weg. Kinesis Data Streams lässt drei unabhängige Consumer denselben Stream gleichzeitig lesen, jeder in eigenem Tempo. Wenn dein Analytics-Team schon Kafka spricht, ist MSK eine faire Alternative – aber Kinesis braucht weniger Operational Care.

Szenario 3: Legacy-System mit Komplexem Routing

Du modernisierst ein altes POS-System, das RabbitMQ mit Topic Exchanges nutzt – `order.created.retail`, `warehouse.stock.low`. Hunderte Routing Keys sind in Backend-Services verdrahtet.

Die Logik zu SNS zu porten wäre brutal – SNS unterstützt nur basisches Subscription-Filtering, keine komplexen Patterns. **RabbitMQ** oder **EventBridge** funktionieren beide. EventBridge gibt dir native AWS-Integration und Schema Registry, aber das Umverdrahten aller Routing-Regeln dauert. RabbitMQ zu behalten heißt weniger Migrationsaufwand, aber du managst EC2-Instances auf absehbare Zeit. Ich würd EventBridge nur nehmen, wenn das Team die Bandbreite hat; sonst RabbitMQ laufen lassen und dich auf wichtigere Dinge fokussieren.

Praxistipps Aus Der Trichter

1. **Fang mit SQS + Lambda an.** Das ist das einfachste asynchrone Pattern in AWS. Deckt 90 % der Backend-Entkopplungs-Bedürfnisse ab. SNS dazu, wenn du Fan-out brauchst. EventBridge, wenn du Routing-Intelligenz brauchst.

2. **Denk an Replay von Tag eins an.** Die harte Frage ist nicht "Kann mein Service eine fehlgeschlagene Message handlen?" Sondern: "Kann mein Service *dasselbe Message zweimal lesen*?" Kinesis und MSK machen Replays natürlich. SQS FIFO gibt dir Exactly-Once-Semantik, aber limitiert Durchsatz.

3. **Respektier Retention-Limits.** SNS behält gar nichts. SQS deckelt bei 14 Tagen. Kinesis schafft 365 Tage mit Extended Retention. MSK defaultet auf 7 Tage (konfigurierbar höher). Wenn du Audit-Trails oder Reprocessing brauchst, wähl entsprechend.

4. **Nutz Long Polling bei SQS.** Es sammelt 20 Sekunden Messages statt ständig leere Queues zu polen. Diese eine Änderung kann deine SQS-Rechnung um 90 % senken.

5. **Vermeide die Eierlegende Wollmilchsau.** Ich hab schon gesehen: Lambda triggert SNS Topic, das published zu SQS Queue, die pusht zu另一Lambda, die dumpt zu Kinesis – für einen simplen File-Upload. Jeder Hop fügt Latenz und einen neuen Failure Mode hinzu. Nur weil du *alles* verketten *kannst*, heißt nicht, dass du *solltest*.

FAQ

Können SNS und SQS zusammen genutzt werden?
Absolut – und es ist eines der mächtigsten Patterns in AWS. SNS fanned-out an mehrere SQS Queues, und jede Queue wird unabhängig von verschiedenen Services verarbeitet. Kombiniert SNS's Fan-out-Power mit SQS's Zuverlässigkeit, Retention und Retries. Das ist das Pattern hinter den meisten ernsthaften AWS Event-Driven Architectures.

Ersetzt EventBridge SNS?
Nicht ganz, aber es nähert sich an. EventBridge macht alles, was SNS macht – Pub/Sub, Fan-out – plus Content-based Filtering, Schema Discovery und tiefe AWS-Integration. Für neue Projekte default ich auf EventBridge. Aber für einfache Push-to-Lambda Use Cases ist SNS immer noch simpler zu verstehen und zu betreiben.

Wann sollte ich MSK statt Kinesis wählen?
MSK wählen, wenn dein Team schon Kafka kennt, wenn du Kafka Connect oder ksqlDB brauchst, oder wenn du bestehende Kafka-Infrastruktur migrierst. Kinesis gewinnt, wenn du frisch startest, weniger Operational Overhead willst, und Kafka's Ökosystem nicht brauchst.

Ist RabbitMQ in der AWS-Welt tot?
Nein, aber Nische. Es glänzt bei komplexer Routing-Logik und Multi-Protokoll-Support. Viele Enterprises laufen RabbitMQ immer noch in Production. Aber wenn du Greenfield auf AWS baust, würd ich stark EventBridge oder Kinesis bevorzugen. Einmal migrieren, und dich später dafür danken.

Schlussgedanken

Der "beste" Messaging-Service ist nicht der mit den meisten Features. Es ist der, der zur Form deines Problems passt: SQS für simple Entkopplung. SNS für Fan-out. Kinesis für Streaming mit Replay. MSK für Kafka at Scale. EventBridge für smartes Routing. RabbitMQ für Old-School-Komplexität.

Du hast jetzt eine mentale Entscheidungsmatrix, die mir an jenem ersten Tag 40 Minuten und sieben Tabs gespart hätte. Go build something.