Amazon SAA-C03: Anwendungsintegration, Messaging & Streaming — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Amazon SQS: Entkopplung, Reihenfolge und Zustellungssemantik

Amazon SQS ist eine vollständig verwaltete, Pull-basierte Nachrichtenwarteschlange, deren primäre architektonische Rolle darin besteht, Produzenten von Konsumenten zu entkoppeln. Eine synchrone Aufrufkette bindet die Latenz und Verfügbarkeit des Produzenten an jede nachgelagerte Abhängigkeit; das Einfügen einer SQS-Warteschlange wandelt dies in eine asynchrone Übergabe um. Produzenten stellen Nachrichten mit der Rate ein, mit der der Traffic ankommt, und Konsumenten entnehmen Nachrichten mit der Rate, die sie sicher verarbeiten können. Dies ist die kanonische Lösung für Schreibspitzen, die andernfalls eine RDS-Instanz überlasten würden – die Warteschlange absorbiert die Lastspitze, und eine begrenzte Flotte von Konsumenten arbeitet sie mit kontrollierter Parallelität ab, wodurch die Anzahl der Datenbankverbindungen unter Kontrolle gehalten wird.

Es gibt zwei Arten von Warteschlangen, und die Wahl bestimmt sowohl den Durchsatz als auch die Zustellungsgarantien.

Standard-Warteschlangen liefern Nachrichten mindestens einmal (at-least-once) mit nur Best-Effort-Reihenfolge. Duplikate können auftreten, wenn ein Konsument eine Nachricht nicht löscht, bevor das Sichtbarkeitszeitlimit (Visibility Timeout) abläuft, oder wenn das verteilte Backend eine Nachricht über Shards hinweg erneut abspielt. Selbst wenn Sie beim Testen nie ein Duplikat sehen, ist es dem Dienst architektonisch erlaubt, Nachrichten erneut zuzustellen, insbesondere bei einem Broker-Failover. Anzunehmen, dass Standard-Warteschlangen „normalerweise“ nur einmal zustellen, ist ein Designfehler, kein Betriebsrisiko – bei entsprechender Skalierung werden Duplikate garantiert irgendwann auftreten. Die Logik des Konsumenten muss daher idempotent sein: eine MessageId oder einen Geschäftsschlüssel in DynamoDB mit einem bedingten Schreibvorgang verfolgen, einen Idempotenzschlüssel bei nachgelagerten API-Aufrufen verwenden oder sich auf Upsert-Semantiken verlassen.

FIFO-Warteschlangen bieten eine strikte Reihenfolge innerhalb einer MessageGroupId und eine genau einmalige Verarbeitung (exactly-once) über eine MessageDeduplicationId (entweder explizit oder ein SHA-256 des Body), die Duplikate für ein 5-Minuten-Fenster unterdrückt. Die MessageGroupId ist das zentrale Konzept: alle Nachrichten mit derselben Gruppen-ID werden streng der Reihe nach an einen einzigen Konsumenten gleichzeitig zugestellt, während verschiedene Gruppen-IDs parallel verarbeitet werden können. Für ein Bestellverarbeitungssystem, bei dem die Ereignisse jedes Kunden sequenziell sein müssen, verschiedene Kunden aber unabhängig voneinander sind, verwenden Sie MessageGroupId = customerId. Die Verwendung einer einzigen Gruppen-ID für alles serialisiert die gesamte Arbeitslast und zerstört den Durchsatz. Deduplizierungs-IDs sind das richtige Primitiv, um die Erstellung doppelter Bestellungen zu verhindern, wenn ein Benutzer einen hängengebliebenen Checkout erneut abschickt: der Client generiert ein deterministisches Idempotenz-Token (eine UUID, die an die Checkout-Sitzung gebunden ist) und SQS verwirft alle doppelten Übermittlungen, die innerhalb des Fensters eintreffen.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Die Wahl von Standard-Warteschlangen, wenn die Anforderung „Reihenfolge“ oder „keine Duplikate“ lautet, ist der klassische Fehler. Keine noch so ausgefeilte Anwendungslogik kann eine Reihenfolge wiederherstellen, die die Warteschlange nie beibehalten hat, da Nachrichten von verschiedenen Backend-Hosts verschachtelt ankommen. Wählen Sie FIFO immer dann, wenn die Arbeitslast eine Reihenfolge (Transaktionsbücher, Zustandsautomaten-Übergänge) oder Exactly-Once-Semantik (Zahlungseinzug, Bestandsreduzierung) erfordert.

Sichtbarkeitszeitlimit, Poison-Nachrichten und Payload-Grenzen

Wenn ein Konsument eine Nachricht empfängt, macht SQS sie für andere Konsumenten für die Dauer des Sichtbarkeitszeitlimits (Visibility Timeout) unsichtbar (Standard 30 Sekunden, max. 12 Stunden). Wenn der Konsument die Nachricht vor Ablauf des Zeitlimits löscht, ist sie entfernt; andernfalls – weil der Konsument abgestürzt ist oder die Verarbeitung einfach zu lange gedauert hat – erscheint die Nachricht wieder und wird erneut zugestellt. Das Festlegen eines Sichtbarkeitszeitlimits, das kürzer ist als die tatsächliche Verarbeitungszeit, ist eine Hauptursache für doppelte Verarbeitung: eine Lambda-Funktion, die 45 Sekunden benötigt, wird bei einer Warteschlange mit dem standardmäßigen 30-Sekunden-Timeout jede Nachricht mindestens zweimal erneut verarbeiten. Setzen Sie das Zeitlimit auf mindestens die p99-Verarbeitungszeit (die AWS-Empfehlung für Lambda-gesteuerte Warteschlangen ist mindestens das 6-fache des Funktions-Timeouts) und verlängern Sie das Zeitlimit für Jobs unvorhersehbarer Länge dynamisch:

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Dead-Letter-Queues (DLQs) fangen „Poison-Pill“-Nachrichten ab. Eine RedrivePolicy auf der Quell-Warteschlange gibt eine maxReceiveCount an (typischerweise 3–5); sobald diese überschritten ist, verschiebt SQS die Nachricht zur Offline-Analyse in die DLQ. Die DLQ muss dem Typ der Quell-Warteschlange entsprechen (FIFO ↔ FIFO). Ohne eine DLQ zirkulieren fehlerhafte Nachrichten unendlich, was bei FIFO besonders schädlich ist – die Reihenfolgenerhaltung verhindert, dass nachfolgende Nachrichten in derselben Gruppe zugestellt werden, bis der Verursacher behandelt wurde. Eine einzige fehlerhafte Nachricht hält also eine ganze Gruppe auf.

SQS-Nachrichten sind auf 256 KB begrenzt. Für größere Payloads – zum Beispiel ein Job, der ein gerendertes Dokument enthält – verwenden Sie die SQS Extended Client Library, die den Payload nach S3 schreibt und nur eine Referenz auf Bucket/Schlüssel in die Warteschlange einreiht. Die Konsumenten-Bibliothek ruft den Inhalt beim Empfang transparent ab. Teilen Sie Payloads nicht auf mehrere Nachrichten auf (Sie verlieren Atomarität und Reihenfolge) und kodieren Sie kein 2-MB-Blob mit Base64 in der Hoffnung, dass es passt.

Warteschlangen-gesteuerte Autoskalierung

Für eine Konsumenten-Flotte auf EC2 oder ECS hinter einer SQS-Warteschlange ist das richtige Skalierungssignal nicht die CPU-Auslastung, sondern der Rückstau (Backlog) in der Warteschlange. Die CPU-Auslastung hinkt der Ankunftsrate hinterher und interpretiert einen ausgelasteten Konsumenten fälschlicherweise als „beschäftigt, aber kommt zurecht“. Die kanonische Skalierungsmetrik ist ApproximateNumberOfMessagesVisible, aber eine Skalierung direkt auf Basis der reinen Warteschlangentiefe ist zu grob. Der empfohlene Ansatz ist die benutzerdefinierte Metrik Backlog-pro-Instanz:

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Veröffentlichen Sie diese in CloudWatch und steuern Sie damit eine Zielverfolgungsrichtlinie (Target-Tracking-Policy) für eine Auto Scaling Group oder einen ECS-Service, sodass jeder Worker einen begrenzten Backlog beibehält (zum Beispiel 10 Nachrichten). Dies führt zu einer reibungslosen Skalierung nach außen (Scale-Out) bei Lastspitzen und verhindert Oszillationen, wenn die Warteschlangentiefe gering ist, die Konsumenten aber bereits ausgelastet sind. Für die Skalierung nach innen (Scale-In) kombinieren Sie dies mit ApproximateAgeOfOldestMessage, um zu vermeiden, dass Kapazität beendet wird, während noch alte Nachrichten in der Warteschlange verbleiben.

Amazon SNS: Fan-Out, Filterung und kontoübergreifende Zustellung

SNS ist ein Push-basierter Publish/Subscribe-Dienst. Publisher schreiben in ein Topic; SNS pusht an jedes Abonnement: SQS-Warteschlangen, Lambda-Funktionen, HTTP(S)-Endpunkte, E-Mail, SMS, Kinesis Data Firehose oder mobile Push-Benachrichtigungen. Das dominante Muster für Langlebigkeit (Durability) ist der SNS → SQS Fan-Out: ein Topic, das von mehreren SQS-Warteschlangen abonniert wird. So hat jeder nachgelagerte Dienst seinen eigenen langlebigen Puffer, seine eigene Wiederholungsrichtlinie und DLQ, während der Publisher nur das Topic kennt. Fällt ein Konsumentendienst für Stunden aus, sammelt seine Warteschlange Nachrichten an und verarbeitet sie nach der Wiederherstellung – SNS allein fehlt diese Pufferung und würde seine Wiederholungsrichtlinie ausschöpfen.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

Die Nachrichtenfilterung ermöglicht es jedem Abonnement, eine JSON-Filterrichtlinie zu deklarieren, sodass SNS nur passende Nachrichten zustellt. Dies vermeidet das Anti-Pattern, bei dem jeder Konsument jede Nachricht empfängt und clientseitig filtert:

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

Zwei Verhaltenseigenschaften sind wichtig. Erstens garantieren Standard-SNS-Topics keine Reihenfolge über Nachrichten hinweg – abonnentenspezifische Wiederholungs-Timer und unabhängige Netzwerkpfade machen eine Neuordnung zur Routine. Wenn die Reihenfolge wichtig ist, verwenden Sie ein SNS-FIFO-Topic, das SQS-FIFO-Warteschlangen abonniert; die Message Group ID wird durchgängig weitergegeben. Andernfalls müssen Abonnenten idempotent und tolerant gegenüber Neuordnungen sein. Zweitens versuchen HTTP(S)-Abonnements die Zustellung gemäß einer Zustellungsrichtlinie erneut (Standard: drei sofortige Wiederholungen, dann exponentieller Backoff bis zu einer Stunde, dann Verwerfen). Abonnenten müssen innerhalb von 15 Sekunden mit einem 2xx-Statuscode antworten, die x-amz-sns-message-type-Signatur validieren und – bei unzuverlässigen Endpunkten – immer eine SNS-DLQ (die an SQS weitergeleitet wird) haben, damit nicht zugestellte Nachrichten erfasst und nicht stillschweigend verworfen werden.

Kontoübergreifender Aufruf ist eine häufige Fehlerquelle. Wenn Konto A in ein Topic publiziert, das per Fan-Out an eine Lambda-Funktion in Konto B verteilt, sind zwei Richtlinien erforderlich: Die SNS-Topic-Richtlinie (oder die Richtung des Abonnements) muss das Abonnement erlauben, und die ressourcenbasierte Richtlinie der Lambda-Funktion muss lambda:InvokeFunction von sns.amazonaws.com mit einer SourceArn-Bedingung, die auf das Topic verweist, gestatten. Das Fehlen der Lambda-Ressourcenrichtlinie ist die häufigste Fehlerursache – das Abonnement scheint fehlerfrei zu sein, aber Aufrufe werden mit einem 403-Fehler abgelehnt. Wenn das Topic mit einem kundenseitig verwalteten KMS-Schlüssel verschlüsselt ist, muss die Schlüsselrichtlinie auch dem veröffentlichenden Principal und sns.amazonaws.com die Berechtigungen kms:Decrypt und kms:GenerateDataKey gewähren.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge: Geroutete Event-Busse

EventBridge (ehemals CloudWatch Events) erweitert Pub/Sub um inhaltsbasiertes Routing, Schema-Erkennung, SaaS-Partner-Event-Quellen und Archivierung/Wiedergabe. Events fließen durch Event-Busse (Standard, benutzerdefiniert oder Partner) und werden mit Regeln abgeglichen, deren Event-Pattern nach der JSON-Struktur filtern. Regeln können Payloads über Eingabepfade und Eingabevorlagen transformieren, Dead-Letter-Ziele anhängen und an mehr als 20 native Ziele zustellen, darunter Lambda, Step Functions, ECS-Tasks, SQS, SNS, Kinesis und API-Destinations.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

Der Unterschied zu SNS ist architektonischer Natur. SNS ist für den Broadcast mit hohem Durchsatz an homogene Abonnenten mit einfacher Attributfilterung und geringerer Latenz optimiert. EventBridge ist für heterogene ereignisgesteuerte Architekturen optimiert: Viele Produzenten geben unterschiedliche Event-Schemata aus, und Konsumenten abonnieren nach einem Muster statt nach einem Topic. Für einen Monolithen, der in Microservices zerlegt wird – insbesondere wenn zu den Produzenten SaaS-Partner oder AWS-Dienste (Config, GuardDuty, CodePipeline, CloudTrail) gehören, die nativ Events ausgeben – ist EventBridge typischerweise die passende Wahl. Für Fan-Out mit extrem hohem Volumen und niedriger Latenz an identische Abonnenten ist SNS immer noch überlegen, da EventBridge eine etwas höhere Latenz pro Ereignis und eine niedrigere standardmäßige Durchsatzobergrenze hat.

Amazon MQ: Brokered Messaging für bestehende Protokolle

Amazon MQ ist ein verwalteter Broker, der ActiveMQ oder RabbitMQ ausführt. Er dient dazu, On-Premises-Workloads zu migrieren, die von AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire oder JMS abhängen, ohne die Anwendung neu zu schreiben. Wenn ein Zahlungssystem einen JMS-Broker eines Drittanbieters mit transaktionaler Exactly-Once-Semantik verwendet, bewahrt ein Lift-and-Shift zu Amazon MQ das Übertragungsprotokoll und die Zustellgarantien, während die Verwaltung der Infrastruktur entfällt. Wählen Sie SQS/SNS/EventBridge für Greenfield-Designs, die nativ auf AWS aufbauen; wählen Sie Amazon MQ nur dann, wenn Protokollkompatibilität die Einschränkung ist.

Kinesis Data Streams

Kinesis Data Streams (KDS) ist ein langlebiges, geordnetes, partitioniertes Protokoll für die Aufnahme von Streaming-Daten mit hohem Durchsatz – Clickstreams, IoT-Telemetrie, Log-Aggregation. Datensätze werden anhand des PartitionKey in Shards platziert; die Reihenfolge wird innerhalb eines Shards garantiert, nicht über den gesamten Stream hinweg. Jeder Shard unterstützt 1 MB/s oder 1.000 Datensätze/s Schreibdurchsatz und 2 MB/s Lesedurchsatz (oder mehr mit Enhanced Fan-Out). Datensätze werden standardmäßig 24 Stunden aufbewahrt, erweiterbar auf 365 Tage, sodass mehrere unabhängige Konsumenten dieselbe Historie wiederholt abspielen können – etwas, das SQS nicht kann, da SQS nach der Bestätigung (Ack) löscht.

Der On-Demand-Modus macht die Berechnung von Shards überflüssig, indem er automatisch auf bis zu 200 MiB/s Schreibdurchsatz pro Stream skaliert, was ideal für unvorhersehbaren Datenverkehr ist. Der Provisioned-Modus ist bei konstantem Datenverkehr, bei dem die Kapazität bekannt ist, kostengünstiger.

Wählen Sie KDS anstelle von SQS FIFO, wenn der Workload eine geordnete, wiederholbare Aufnahme bei Durchsätzen erfordert, die FIFO nicht bewältigen kann (FIFO erreicht seine Obergrenze weit unter den Millionen von Datensätzen pro Sekunde, die KDS verarbeiten kann), wenn mehrere unabhängige Konsumenten denselben Stream lesen müssen oder wenn die Formulierung „ursprüngliche Reihenfolge während der gesamten Verarbeitung beibehalten“ mit hohem Volumen kombiniert wird.

Kinesis Data Firehose

Kinesis Data Firehose ist ein vollständig verwalteter Bereitstellungs-Dienst. Er liest aus einem Kinesis-Stream oder per direktem PUT, puffert nach Größe (1–128 MB) oder Zeit (60–900 Sekunden, je nachdem, was zuerst erreicht wird), ruft optional eine Lambda-Funktion für die Transformation einzelner Datensätze auf (PII-Bereinigung, Formatnormalisierung), kann JSON on-the-fly mit einem Glue-Schema in Parquet oder ORC konvertieren, verschlüsselt mit KMS und liefert an S3, Redshift, OpenSearch oder Splunk. Er hat keine Shards, keine auszuführenden Consumer und ein Pay-per-GB-Preismodell.

Das kanonische Muster für die skalierbare Aufnahme in einen Data Lake kombiniert Data Streams (On-Demand) als dauerhaften Puffer mit Firehose für die Bereitstellung in S3:

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Für die Aufnahme von Millionen von mobilen Ereignissen, deren Verschlüsselung und deren Ablage in S3 als Parquet ist die richtige Antwort Firehose mit Parquet-Konvertierung und einem KMS-Schlüssel – nicht KDS plus ein benutzerdefinierter Consumer plus ein selbst geschriebener Parquet-Writer, was dramatisch mehr Code und Infrastruktur bedeutet. Firehose arbeitet nahezu in Echtzeit und unterstützt keine consumerseitige Wiederholung (Replay); wenn Replay erforderlich ist, behalten Sie KDS im Pfad bei.

Kinesis Data Analytics (jetzt Managed Service for Apache Flink) führt SQL- oder Flink-Jobs für Fensteraggregationen auf einem Stream aus.

Lambda-Integration und Wiederholungssemantik

Lambda integriert sich mit diesen Diensten mit wesentlich unterschiedlichem Wiederholungsverhalten:

Für SQS: Lambda-Funktions-Timeout ≤ Sichtbarkeits-Timeout der Queue beibehalten und das Sichtbarkeits-Timeout auf mindestens das 6-fache des Funktions-Timeouts einstellen. Für Kinesis: BisectBatchOnFunctionError aktivieren und ein OnFailure-Ziel (SQS oder SNS) konfigurieren, damit ein einzelner fehlerhafter Datensatz (Poison Record) nicht den gesamten Shard auf unbestimmte Zeit blockiert.

Entscheidungstabelle zur Auswahl

← Analytik · Alle Domänen · Sicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →