Amazon SOA-C02: Serverless und Anwendungsintegration — Lernleitfaden

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Teil des AWS SysOps Administrator Associate SOA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Serverless und Anwendungsintegration umfassen das Ausführen ereignisgesteuerter Anwendungen ohne Serververwaltung und die zuverlässige Verbindung von Diensten. Aus betrieblicher Sicht ist es entscheidend, Skalierung, Latenz, Fehlermodi und den Zugriff nach dem Least-Privilege-Prinzip zu verwalten und dabei die Kosten vorhersehbar zu halten. Dieser Bereich konzentriert sich auf das Verhalten von Lambda (Kaltstarts, Concurrency), die zuverlässige Zustellung von Ereignissen (EventBridge, SNS, SQS), Sicherheitskontrollen (Ausführungsrollen und Berechtigungen) und die Beobachtbarkeit (Observability) für asynchrone Abläufe.

Betriebliche Aspekte und Concurrency von AWS Lambda

Die Leistung und Verfügbarkeit von Lambda hängen von Kaltstarts, Concurrency-Limits und Throttling-Kontrollen ab. Kaltstarts treten auf, wenn Lambda eine neue Ausführungsumgebung initialisieren muss; reduzieren Sie die Auswirkungen durch den Einsatz von Provisioned Concurrency (

undefined

) für latenzkritische Pfade und bevorzugen Sie schlankere Runtimes oder geringeren Initialisierungsaufwand. Reservieren und begrenzen Sie die Concurrency mit Reserved Concurrency (

undefined

), um nachgelagerte Dienste zu schützen und funktionsspezifische Quotas durchzusetzen; überwachen Sie die CloudWatch-Metriken ConcurrentExecutions und Throttles.

Wiederholungs- und Aufrufmodelle unterscheiden sich je nach Modus: synchrone Aufrufe (API Gateway, direkter Invoke) geben Fehler sofort zurück; asynchrone Aufrufe (EventBridge, SNS, asynchrone S3-Benachrichtigungen) nutzen die asynchrone Wiederholungsrichtlinie von Lambda (zwei Wiederholungen mit Backoff) und können DLQs oder Destinations verwenden. Bei Event Source Mappings (SQS, Kinesis, DynamoDB Streams) versucht der Poller von Lambda den Aufruf so lange zu wiederholen, bis die Nachricht abläuft oder die Redrive Policy der Ereignisquelle eine Dead-Letter-Zustellung auslöst. Konfigurieren Sie Timeout und Speicher konservativ (

undefined

) und setzen Sie das SQS Visibility Timeout > Funktions-Timeout (empfohlen: Visibility >= Funktions-Timeout * 2), um doppelte Verarbeitungen zu reduzieren.

Ereignisgesteuerte Architekturen mit EventBridge

EventBridge bietet einen verwalteten Event Bus mit flexiblem Routing, einer Schema Registry, kontoübergreifender Zustellung und Einstellungen für Wiederholungen/DLQs. Verwenden Sie benutzerdefinierte Event Buses zur Domänentrennung und Partner Event Buses für SaaS-Integrationen; erstellen Sie Regeln mit Patterns (

undefined

) und fügen Sie Ziele (Targets) mit Dead-Letter- und Wiederholungskonfiguration hinzu (das Targets-JSON unterstützt DeadLetterConfig und RetryPolicy). Nutzen Sie die Schema Registry, um Ereignisformate zu erkennen und durchzusetzen; registrieren Sie Schemas, wenn die Producer klar definiert sind, und verwenden Sie Code Bindings, um bei Bedarf typisierte Modelle zu generieren.

Wählen Sie EventBridge, wenn Sie Folgendes benötigen:

• Komplexes Routing und Filtern mit umfangreichen Event Patterns oder konto-/Event-Bus-übergreifender Isolierung
• Native Unterstützung für mehrere Ziele (Lambda, Step Functions, Kinesis, SQS, SNS)
• Schema-Erkennung und Governance über Teams hinweg

Wählen Sie direktes SNS/SQS, wenn Sie einfacheres Fan-Out oder garantierte Queue-Semantik benötigen:

• SNS für Fan-Out an viele Abonnenten und Push-Semantik
• SQS für langlebige, Pull-basierte Verarbeitung mit Visibility Timeout und Redrive Policies

Messaging mit SNS und SQS (DLQs, Visibility Timeout)

SNS ist ein Pub/Sub-Push-Dienst; SQS ist eine langlebige Warteschlange (Queue) mit Pull-Semantik. Für hochzuverlässige Verarbeitung bevorzugen Sie SNS -> SQS -> Lambda-Muster, um die Aufnahme (Ingestion) von der Verarbeitung zu entkoppeln und Kontrolle über Wiederholungen und Sichtbarkeit zu erlangen. Konfigurieren Sie die SQS Redrive Policy (

undefined

), um Nachrichten nach Erreichen von maxReceiveCount in eine DLQ zu verschieben, und stellen Sie sicher, dass das Visibility Timeout lang genug ist, um eine vorzeitige erneute Zustellung zu vermeiden (empfohlen: Visibility >= Funktions-Timeout * 2). Für FIFO-Anforderungen verwenden Sie SQS FIFO oder SNS FIFO mit Message Group IDs, um die Reihenfolge beizubehalten, und Deduplication IDs, um Duplikate zu vermeiden.

Optionen für das Dead-Letter-Handling und ihre Anwendungsbereiche:

• Asynchrone Lambda-Aufrufe: Konfigurieren Sie DeadLetterConfig oder Destinations (AsyncEventInvokeConfig), um Fehler an SQS/SNS zu senden oder eine andere Lambda-Funktion aufzurufen.
• SQS: Konfigurieren Sie die Redrive Policy zu einer SQS-DLQ für „Poison Messages“ und setzen Sie einen angemessenen maxReceiveCount.
• EventBridge: Setzen Sie DeadLetterConfig und RetryPolicy für die Ziele (Targets) einer Regel, um unzustellbare Ereignisse zu erfassen.

Idempotenz ist unerlässlich: Implementieren Sie idempotente Handler mithilfe von bedingten Schreibvorgängen in DynamoDB (PutItem mit ConditionExpression attribute_not_exists(pk)), Idempotenz-Tokens, die mit einer TTL gespeichert werden, oder der SQS-FIFO-Deduplizierung für Exactly-Once-Semantik.

Funktionsberechtigungen, Rollen und Least Privilege

Wenden Sie das Prinzip der geringsten Rechte (Least Privilege) auf Lambda Execution Roles und die Ressourcenrichtlinien von Funktionen an. Beginnen Sie mit der AWSLambdaBasicExecutionRole für CloudWatch Logs und gewähren Sie dann explizite Ressourcen-ARNs für Dienste (z. B. dynamodb:PutItem auf arn:aws:dynamodb:region:acct:table/MyTable). Vermeiden Sie Wildcards wie Resource: “*”, wenn spezifische ARNs möglich sind. Verwenden Sie verwaltete oder benutzerdefinierte Richtlinien, die auf Aktionen und Ressourcen beschränkt sind, und fügen Sie Bedingungen (aws:SourceAccount, aws:SourceArn) hinzu, wenn Sie Aufrufberechtigungen für Dienste erteilen:

• Aufrufberechtigung für EventBridge hinzufügen:

undefined

• Für SNS: Verwenden Sie die source-arn-Bedingung, um einzuschränken, welches Topic die Funktion aufrufen kann

Entscheidungskriterien:

• Verwenden Sie ressourcenbasierte Richtlinien der Funktion, um Dienstaufrufe zu erlauben (EventBridge, SNS, CloudWatch Events)
• Verwenden Sie die IAM Execution Role für Laufzeitberechtigungen (DynamoDB, S3, Secrets Manager)
• Bevorzugen Sie Berechtigungen auf Ressourcenebene und bedingte Einschränkungen, um den „Blast Radius“ (Schadensradius) zu reduzieren

Observability und Fehlerbehebung für Serverless

Observability muss Metriken, Logs, Traces und den asynchronen Zustellstatus umfassen. Wichtige CloudWatch-Metriken: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (für Stream- und SQS-Trigger). Für die Sichtbarkeit asynchroner Fehler überwachen Sie die „AsyncEventInvoke“-Metriken und richten Sie CloudWatch Alarms für DeadLetterErrors und Throttles ein. Aktivieren Sie X-Ray Tracing (

undefined

), um End-to-End-Traces über Dienste hinweg zu erhalten und Kaltstarts, nachgelagerte Latenzen und Ausnahmen zu visualisieren.

Verwenden Sie strukturierte JSON-Logs und CloudWatch Logs Insights-Abfragen, um Fehlermuster schnell zu finden; instrumentieren Sie Idempotenzprüfungen und zeichnen Sie Korrelations-IDs in den Logs auf. Für verteiltes Tracing propagieren Sie Trace-IDs explizit in den Event-Payloads für EventBridge/SNS-Flows, wenn der automatische Kontext verloren geht. Bei SQS Event-Source-Mappings überwachen Sie ApproximateAgeOfOldestMessage und richten Sie Alarme ein, wenn dieser Wert ansteigt, was auf Gegendruck (Backpressure) oder Drosselung (Throttling) hindeutet. Erfassen Sie die Lambda-Metrik Throttles und lösen Sie Alarme dafür aus. Verfolgen Sie außerdem die Nutzung von Provisioned Concurrency im Verhältnis zu den Kosten.

Häufige Fallstricke und Entscheidungskriterien

• Keine Konfiguration von DLQs oder alleiniges Verlassen auf Standard-Wiederholungsversuche: Konfigurieren Sie DLQs oder Destinations für asynchrone Lambdas und SQS-Redrive für Queues, um „Poison Messages“ zur manuellen Untersuchung zu erfassen.
• Falsches Visibility Timeout bei SQS, das zu doppelter Verarbeitung führt: Setzen Sie das Visibility Timeout auf >= Funktions-Timeout * 2 und berücksichtigen Sie Wiederholungsversuche sowie nachgelagerte Aufrufe, um Duplikate zu vermeiden.
• Zu freizügige Lambda Execution Roles: Vermeiden Sie Resource: “*” und fügen Sie Service-/Quellbedingungen (aws:SourceArn, aws:SourceAccount) zu Aufruf- und Ressourcenrichtlinien hinzu.
• Ignorieren von Gleichzeitigkeitslimits, was zu Drosselung führt: Verwenden Sie Reserved Concurrency, um Funktionen zu deckeln, Provisioned Concurrency für latenzempfindliche Funktionen und überwachen Sie ConcurrentExecutions/Throttles.
• Fehlendes Tracing über asynchrone Grenzen hinweg: Fügen Sie Korrelations-IDs zu Events hinzu und aktivieren Sie X-Ray oder propagieren Sie Trace-Header, um Abläufe zu rekonstruieren.
• Missbrauch von direkten SNS-zu-Lambda-Aufrufen für Anforderungen an die Dauerhaftigkeit: Bevorzugen Sie SNS->SQS->Lambda, wenn Sie eine dauerhafte Pufferung, Kontrolle über die Sichtbarkeit und eine einfachere Handhabung von DLQs benötigen.

Praktisches Problem: Anwendungsfallszenario

AcmePayments empfängt ein hohes Volumen an Zahlungs-Events über EventBridge und erfährt während Spitzenlasten zeitweise Lambda-Drosselung und doppelte Verarbeitung. Sie benötigen eine zuverlässige Verarbeitung, keinen Datenverlust und eine begrenzte Last auf der nachgelagerten DynamoDB.

1. Erstellen Sie einen benutzerdefinierten EventBridge-Bus und eine Regel, die auf Zahlungs-Events passt; fügen Sie eine SQS-FIFO-Queue als dauerhaftes Ziel (Target) mit DeadLetterConfig und RetryPolicy in der Zielkonfiguration hinzu.
2. Konfigurieren Sie Lambda so, dass es die SQS-Queue abfragt (Event-Source-Mapping), wobei die Batch-Größe auf die Kapazität der nachgelagerten Systeme abgestimmt ist und das Visibility Timeout auf >= Funktions-Timeout * 2 gesetzt wird.
3. Reservieren Sie Concurrency für die Lambda-Funktion (

undefined

), um Schreibspitzen auf DynamoDB zu begrenzen; implementieren Sie Provisioned Concurrency für einen kleinen Pool, falls eine niedrige Latenz erforderlich ist. 4. Implementieren Sie Idempotenz mithilfe von bedingten Schreibvorgängen (Conditional Writes) in DynamoDB, die auf der Payment-ID basieren, und speichern Sie Idempotenz-Datensätze mit einer TTL zur Bereinigung. 5. Aktivieren Sie X-Ray Tracing und strukturierte Logs mit einer Korrelations-ID im Event, um die Verarbeitung nachzuverfolgen; richten Sie CloudWatch Alarms für die Metriken ApproximateAgeOfOldestMessage, Throttles und DLQ ein.

Begründung: Die Entkopplung von EventBridge zu SQS bietet eine dauerhafte Pufferung und Wiederholungssemantik; Reserved Concurrency schützt die nachgelagerte DynamoDB vor Lastspitzen, Idempotenz verhindert Duplikate und Tracing/Alarme sorgen für operative Transparenz bei Fehlerszenarien.

← Datenbanken und Caching · Alle Domänen · Kostenmanagement und Ressourcen-Tagging →

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

Amazon durchsuchen →