SQS, SNS, EventBridge

“Wir machen Event-Driven Architecture.” Guter Plan. Welchen Service nimmst du? SQS? SNS? EventBridge? Alle drei machen “Events.” Alle drei stehen in jedem AWS-Architekturdiagramm. Und es gibt Teams die alle drei gleichzeitig nutzen, für denselben Use Case, weil niemand den Unterschied kennt.

Das AWS-Whitepaper “Implementing Microservices on AWS” schlägt Event-Driven als Pattern vor. Was es nicht macht: klar sagen wann welcher Service der richtige ist. Also mach ich das.

Drei Services, drei Paradigmen

SQS ist eine Queue. Point-to-Point: ein Producer schickt eine Nachricht, ein Consumer holt sie ab. Genau einer. Wenn du 10 Consumer hast, teilen sie sich die Nachrichten, jede geht an genau einen. Das ist der entscheidende Unterschied.

SNS ist Pub/Sub. Ein Producer published auf ein Topic, alle Subscriber bekommen die Nachricht. Jeder. Gleichzeitig. Fan-Out. Wenn du ein Event an 5 verschiedene Services schicken willst, ist das dein Service.

EventBridge ist ein Event Bus. Wie SNS, aber mit Content-Based Routing: du definierst Rules die auf Event-Attribute matchen, und nur die passenden Targets bekommen das Event. Plus Schema Registry, Event Replay, Cross-Account Routing.

Schau dir die Feature-Matrix an und sende testweise Messages:

Wann welcher Service

SQS: Work Queues

SQS wenn du eine Aufgabe verteilen willst. Ein Job, ein Worker. Klassische Beispiele:

• Image Processing: User lädt Bild hoch, SQS Message, Lambda scaled Worker ab
• Email Queue: 10.000 Emails versenden, 50 Worker holen sich je eine Nachricht
• Order Processing: jede Bestellung wird von genau einem Processor bearbeitet

import {
  SQSClient,
  ReceiveMessageCommand,
  DeleteMessageCommand,
} from "@aws-sdk/client-sqs";

const sqs = new SQSClient({});

async function processMessages() {
  const { Messages } = await sqs.send(
    new ReceiveMessageCommand({
      QueueUrl: process.env.QUEUE_URL,
      MaxNumberOfMessages: 10,
      WaitTimeSeconds: 20, // Long Polling  immer nutzen
    }),
  );

  for (const msg of Messages ?? []) {
    await processOrder(JSON.parse(msg.Body!));
    await sqs.send(
      new DeleteMessageCommand({
        QueueUrl: process.env.QUEUE_URL,
        ReceiptHandle: msg.ReceiptHandle!,
      }),
    );
  }
}

SQS FIFO wenn Reihenfolge wichtig ist. 300 Messages/s Limit (3.000 mit Batching). Für die meisten Use Cases reicht Standard SQS; Ordering ist meistens nice-to-have, nicht must-have.

SNS: Fan-Out

SNS wenn ein Event mehrere Subscriber triggern soll. Klassisches Pattern: SNS Topic + SQS Queues.

• OrderCreated → SNS → Inventory Queue + Payment Queue + Email Queue
• UserSignedUp → SNS → Welcome Email + Analytics + CRM Update

import { SNSClient, PublishCommand } from "@aws-sdk/client-sns";

const sns = new SNSClient({});

await sns.send(
  new PublishCommand({
    TopicArn: process.env.ORDER_TOPIC_ARN,
    Message: JSON.stringify({
      orderId: "12345",
      userId: "user-99",
      total: 49.99,
    }),
    MessageAttributes: {
      eventType: { DataType: "String", StringValue: "OrderCreated" },
    },
  }),
);

EventBridge: Routing

EventBridge wenn du komplexes Routing brauchst: Events filtern, transformieren, an verschiedene Targets routen, basierend auf dem Inhalt.

• order.placed mit total > 1000 → Fraud Detection Lambda
• order.placed mit total <= 1000 → Standard Processing
• Events von einem SaaS-Partner (Stripe, Shopify) → eigene Verarbeitung
• Cross-Account: Team A published Events, Team B consumed ohne dass beide denselben Account teilen

// CDK
new Rule(this, "HighValueOrders", {
  eventBus: bus,
  eventPattern: {
    source: ["orders"],
    detailType: ["OrderPlaced"],
    detail: {
      total: [{ numeric: [">", 1000] }],
    },
  },
  targets: [new LambdaFunction(fraudDetectionFn)],
});

Die Killer-Features von EventBridge: Event Replay (du kannst alte Events erneut senden gut für Debugging), Schema Discovery (EventBridge lernt deine Event-Struktur automatisch), Scheduling (cron-artige Rules ohne CloudWatch Events).

Die Rechnung und die Latenz

Kosten. EventBridge kostet 2.5x so viel wie SQS pro Message. Bei 100 Millionen Events/Monat: $100 für EventBridge vs $40 für SQS. Klingt nicht viel, bis du 10 Event Buses hast.

Latency. EventBridge hat ~50ms Latency. SQS hat 1-10ms. Für die meisten Async-Workflows irrelevant, für Echtzeit-Verarbeitung nicht.

Lock-In. EventBridge-Rules, Schema Registry und die Event-Format-Konventionen sind AWS-spezifisch. SQS ist eine Queue, die kannst du überall nachbauen. EventBridge-Logik ist schwerer zu portieren.

Kurzfassung

Ein Producer, ein Consumer, Arbeit verteilen? SQS. Ein Event, mehrere Consumer, alle bekommen alles? SNS + SQS. Events filtern, routen, transformieren, Cross-Account? EventBridge. Unsicher? SQS. Simpler, billiger, und du kannst jederzeit SNS oder EventBridge davorschalten.

Die meisten Event-Driven Architectures brauchen keine EventBridge-Rules am ersten Tag. Eine SQS Queue tut’s. Wenn du Fan-Out brauchst, schiebst du ein SNS Topic davor. Fertig.