Amazon SAA-C03: Serverless & Ereignisgesteuerte Architekturen / API-Integration — 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.

AWS Lambda: Ausführungsmodell, Laufzeit-Lebenszyklus und Kaltstarts

Lambda führt Code in isolierten Firecracker Micro-VMs aus, die einem zweiphasigen Lebenszyklus folgen. Die INIT-Phase stellt den Container bereit, bootet die Laufzeitumgebung, lädt und entpackt das Deployment-Paket und führt jegliche Initialisierung auf Modulebene aus – Erstellung von SDK-Clients, Laden von mit KMS entschlüsselten Secrets, Aufbau von Datenbank-Verbindungspools, Laden von JVM-Klassen und JIT-Warm-up. Die INVOKE-Phase führt den Handler aus. Ein Kaltstart verursacht die vollen Kosten der INIT-Phase; ein warmer Aufruf verwendet die Umgebung wieder, sodass alles, was außerhalb des Handlers zwischengespeichert wird (HTTP-Keep-Alive-Pools, entschlüsselte Secrets, DB-Clients), über Aufrufe hinweg in diesem Container bestehen bleibt. Deshalb ist das kanonische Muster, teure Objekte im Geltungsbereich des Moduls zu erstellen und sie wiederzuverwenden:

import boto3, os
ddb = boto3.client('dynamodb')          # reused across warm invokes
_secret = None
def _load_secret():
    global _secret
    if _secret is None:
        _secret = kms.decrypt(...)      # KMS call once per container, not per invoke
    return _secret

def handler(event, ctx):
    ...

Die Dauer eines Kaltstarts variiert je nach Laufzeitumgebung. Bei Node.js und Python liegt sie im Bereich von zehn bis einigen hundert Millisekunden; bei JVM und .NET kann sie eine Sekunde überschreiten. Bei Funktionen, die an eine VPC angebunden sind, haben Hyperplane ENIs den historischen Nachteil beim Anhängen von ENIs weitgehend amortisiert, aber die Paketgröße und aufwendiger INIT-Code sind weiterhin die dominierenden Faktoren.

Drei Werkzeuge gehen Kaltstarts auf unterschiedliche Weise an:

SnapStart ist die kostengünstigste Lösung für Java-Workloads ohne harte Latenzanforderungen – Kaltstarts reduzieren sich um etwa eine Größenordnung ohne Aufpreis pro Aufruf. Provisioned Concurrency ist die richtige Antwort, wenn eine synchrone API bei Lastspitzen eine p99-Latenz von unter, sagen wir, 100 ms einhalten muss; eine Dimensionierung auf den p95-Burst schließt die Tail-Latency-Lücke. Eine zu geringe Dimensionierung ist ein klassischer Fehler: On-Demand startet neue Container erst dann, wenn eine Anfrage eintrifft, sodass eine Lastspitze zu mehrsekündigen Wartezeiten für echte Benutzer führt.

# SAM: SnapStart on a Java 17 function
MyJavaFn:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: java17
    SnapStart: { ApplyOn: PublishedVersions }
    AutoPublishAlias: live

Provisioned Concurrency selbst kann über Application Auto Scaling skaliert werden – eine geplante Aktion, die die Kapazität um 07:45 Uhr von 10 auf 200 hochfährt und um 10:00 Uhr wieder reduziert, vermeidet Kosten für warme Kapazität über Nacht und eliminiert gleichzeitig Kaltstarts während der morgendlichen Lastspitze.

Die Speichergröße ist gleichzeitig ein CPU-Regler: die vCPU-Leistung skaliert linear mit dem Speicher bis zu ca. 1.769 MB pro vCPU. Eine Funktion, die auf 128 MB festgelegt ist, kann insgesamt mehr kosten als eine mit 1.024 MB, da die verdoppelte Laufzeit oft den verdoppelten Preis pro ms übersteigt. Raten Sie nicht – verwenden Sie AWS Lambda Power Tuning, um Konfigurationen mit repräsentativen Payloads zu testen.

Lambda Concurrency-Steuerung und Schutz nachgelagerter Systeme

Drei Regler für die Gleichzeitigkeit sind wichtig, und jeder erfüllt eine andere Aufgabe:

• Reserved Concurrency begrenzt und reserviert, wie viele gleichzeitige Ausführungen eine Funktion nutzen darf. Sie schneidet Kapazität aus dem Account-Pool heraus und schützt nachgelagerte Systeme (eine kleine RDS-Instanz, eine Partner-API mit Ratenbegrenzung) vor Überlastung.
• Provisioned Concurrency initialisiert Umgebungen vorab – der Hebel für die Latenz, nicht für die Skalierung.
• Unreserved Account Concurrency ist der gemeinsam genutzte Pool, standardmäßig 1.000 pro Region.

Die Annahme, dass Lambda „unendlich skaliert“, übersieht zwei Obergrenzen. Erstens ist das Limit für gleichzeitige Ausführungen auf Kontoebene real, und Burst-Limits (anfänglich 500–3.000 je nach Region, dann +500/min) steuern die Anstiegsrate. Wird dieses Limit überschritten, erhalten synchrone Aufrufer eine 429 TooManyRequestsException, die API Gateway als 5xx-Fehler weitergibt. Zweitens haben nachgelagerte Systeme ihre eigenen Limits: Eine db.t3.micro mit max_connections=85 kann nicht überleben, wenn tausend gleichzeitige Lambdas jeweils eine Verbindung öffnen. PostgreSQL startet für jede Verbindung einen eigenen Backend-Prozess, der ~10 MB RAM verbraucht; selbst bei freien CPU-Ressourcen kann allein der Auf- und Abbau der Verbindungen die Instanz an ihre Grenzen bringen.

Die beiden Gegenmaßnahmen sind (1) RDS Proxy, der viele clientseitige Verbindungen bündelt und auf einen kleinen Satz persistenter Backend-Verbindungen multiplext, und (2) das Einfügen einer Warteschlange, sodass die Verarbeitungsrate von der Ankunftsrate entkoppelt wird:

import psycopg2, os
conn = psycopg2.connect(
    host=os.environ['PROXY_ENDPOINT'],   # RDS Proxy, not the DB directly
    dbname='orders', user='app', password=get_secret())

RDS Proxy ist eine Lösung mit minimalem Änderungsaufwand – der Treiber und der Connection-String ändern sich kaum – was ihn zur richtigen Antwort macht, wenn die Anforderung „geringstmögliche Änderung an der Anwendung“ plus Schutz vor Verbindungserschöpfung lautet. DynamoDB hat dieses Problem nicht: Seine zustandslose HTTPS-API ist der Grund, warum DynamoDB sich natürlich mit High-Fan-Out-Lambda-Workloads kombinieren lässt.

Lambda: IAM, Umgebungsvariablen und Networking

Jede Funktion übernimmt bei ihrem Aufruf eine Ausführungsrolle (Execution Role). Die Vertrauensrichtlinie der Rolle gewährt sts:AssumeRole für lambda.amazonaws.com; ihre Berechtigungsrichtlinie definiert, was die Funktion tun darf. Die Laufzeitumgebung injiziert automatisch kurzlebige STS-Anmeldeinformationen in AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN. Betten Sie niemals IAM-Benutzer-Zugriffsschlüssel in Umgebungsvariablen oder Code ein – sie sind statisch, in geleaktem Quellcode oder CloudTrail-Exporten auffindbar, müssen manuell rotiert werden und umgehen das gesamte Modell der temporären Anmeldeinformationen.

FnRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
      - Effect: Allow
        Principal: { Service: lambda.amazonaws.com }
        Action: sts:AssumeRole
    Policies:
      - PolicyName: ReadOrders
        PolicyDocument:
          Statement:
          - Effect: Allow
            Action: ["dynamodb:GetItem", "dynamodb:Query"]
            Resource: !GetAtt OrdersTable.Arn

Umgebungsvariablen, die sensible Konfigurationsdaten enthalten, sollten mit einem kundenseitig verwalteten KMS-Schlüssel verschlüsselt werden. Nutzen Sie dabei die „Hilfsfunktionen für die Verschlüsselung während der Übertragung“ (helpers for encryption in transit), damit die Konsole clientseitig verschlüsselt. Entschlüsseln Sie die Daten einmal in der INIT-Phase und cachen Sie den Klartext in einer Variable auf Modulebene – andernfalls verursacht jeder Aufruf einen kostenpflichtigen KMS-API-Aufruf.

Standardmäßig wird eine Funktion in einer von AWS verwalteten VPC mit uneingeschränktem ausgehendem Internetzugriff ausgeführt. Binden Sie sie nur dann an Ihre eigene VPC an, wenn sie auf Ressourcen innerhalb der VPC zugreifen muss (z. B. RDS in privaten Subnetzen, ElastiCache, On-Premises über Direct Connect). Lambda fügt dann Hyperplane ENIs in die von Ihnen angegebenen Subnetze ein und übernimmt deren Routing.

Die klassische Falle ist, eine Lambda-Funktion in einem privaten Subnetz zu platzieren, das keine Route für den Datenverkehr zu AWS-Services hat, außer über ein NAT-Gateway – oder schlimmer noch, eine selbstverwaltete NAT-Instanz. NAT-Instanzen sind durch eine einzelne NIC begrenzt, stellen einen SPOF (Single Point of Failure) dar und werden pro GB abgerechnet. Selbst NAT-Gateways werden pro GB abgerechnet und sind für den Datenverkehr zu AWS-Services unnötig. Das korrekte Muster ist:

• Gateway-VPC-Endpunkte für S3 und DynamoDB (kostenlos)
• Interface-Endpunkte (PrivateLink) für KMS, Secrets Manager, SQS, SNS, STS und ähnliche Dienste

Dies hält den Datenverkehr im AWS-Backbone, hebt die Durchsatzbeschränkungen von NATs auf und verhindert überraschende Kosten für ausgehenden Datenverkehr (Egress). Beachten Sie, dass Lambda-ENIs niemals eine öffentliche IP-Adresse erhalten; das Platzieren der Funktion in einem „öffentlichen“ Subnetz gibt ihr keinen Internetzugang – Sie benötigen weiterhin ein NAT-Gateway in einem separaten öffentlichen Subnetz mit einer entsprechenden Route.

Amazon API Gateway: Endpunkttypen, Autorisierung und Bereitstellung

API Gateway bietet drei Arten von APIs:

Wählen Sie REST, wenn Sie API-Schlüssel und Nutzungspläne, Anfragevalidierung mittels JSON Schema, VTL-Mapping-Vorlagen, Cognito-Authorizer mit Geltungsbereichen pro Methode oder WAF benötigen. Wählen Sie HTTP für leichtgewichtige, JWT-authentifizierte Proxy-Muster, bei denen Kosten und Latenz wichtiger sind.

Endpunkttypen steuern, wo die API bereitgestellt wird:

• Edge-optimiert: Über eine von API Gateway verwaltete CloudFront-Distribution bereitgestellt; TLS wird am nächstgelegenen POP (Point of Presence) terminiert. Optimal für global verteilte Clients.
• Regional: Wird aus einer einzelnen Region ohne CloudFront bereitgestellt. Optimal, wenn sich die Clients in derselben Region befinden, wenn Sie Ihre eigene CloudFront-Distribution vorschalten möchten oder wenn Sie latenzbasiertes Routing von Route 53 über mehrere Regionen hinweg verwenden.
• Privat: Nur über einen Interface-VPC-Endpunkt erreichbar. Optimal für interne Microservices, die nicht über das öffentliche Internet kommunizieren dürfen.

Die Wahl eines edge-optimierten Endpunkts für eine interne, auf eine Region beschränkte API fügt einen unnötigen CloudFront-Hop hinzu und verlangsamt die Verteilung von Deployments. Die Wahl eines regionalen Endpunkts für eine global genutzte öffentliche API zwingt jede Anfrage über das öffentliche Internet in eine einzige Region.

Benutzerdefinierte Domänen (Custom Domains) erfordern ACM-Zertifikate, deren Standort vom Endpunkttyp abhängt: us-east-1 für edge-optimierte Endpunkte (CloudFront ist global und terminiert TLS dort); die Region der API selbst für regionale Endpunkte. Dies zu verwechseln ist eine häufige Fehlkonfiguration. Basispfad-Zuweisungen (Base Path Mappings) ermöglichen es, mehrere APIs über eine einzige Domäne zu multiplexen (/orders → Orders-API, /users → Users-API).

Es gibt vier Autorisierungsmodelle, und an den integrierten Mechanismen vorbei zu arbeiten, ist ein klassisches Anti-Pattern:

Ein benutzerdefinierter Lambda-Authorizer fügt einen zusätzlichen Aufruf pro Anfrage (oder pro Cache-TTL) hinzu, eine weitere Funktion, die gewartet und überwacht werden muss, und einen Codepfad, in dem Fehler bei der Signaturvalidierung unbemerkt Zugriff gewähren können. Verwenden Sie ihn nur, wenn die integrierten Mechanismen die Anforderung wirklich nicht abbilden können.

Die Lambda-Proxy-Integration ist das Standardmuster – die gesamte Anfrage wird als Event übergeben, und die Funktion muss die Antwort in einer bestimmten Umschlagstruktur (Envelope) zurückgeben:

{
  "statusCode": 200,
  "headers": {"Content-Type": "application/json"},
  "body": "{\"orderId\":\"abc123\"}",
  "isBase64Encoded": false
}

Für eine Fire-and-Forget-Ingestion bei sehr hohem TPS (Transactions Per Second) nutzen Sie die direkte AWS-Service-Integration von API Gateway, um Daten direkt in SQS oder Kinesis zu schreiben und so den Lambda-Hop komplett zu überspringen. Dies eliminiert Kaltstarts auf dem Schreibpfad und entkoppelt die Ingestion-Rate von der Verarbeitungskapazität.

Für sichere Rollouts verwenden Sie Canary-Deployments auf einer Stage: Ein prozentualer Anteil des Traffics wird an das neue Deployment geleitet, während die Mehrheit auf der stabilen Version verbleibt. Canary-spezifische CloudWatch-Metriken bilden die Grundlage für die Entscheidung über eine Beförderung (Promotion) oder ein Rollback.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/canarySettings/percentTraffic,value=10 \
    op=replace,path=/canarySettings/deploymentId,value=xyz789

Für einen einfachen Webhook, bei dem der Aufwand für API Gateway übertrieben wäre (z. B. mandantenspezifischer Slack-Callback, GitHub-Push-Handler), bieten Lambda Function URLs einen dedizierten HTTPS-Endpunkt direkt für die Funktion. Sichern Sie diese mit AuthType: AWS_IAM, wenn die Aufrufer AWS-Principals sind; wenn NONE eingestellt ist, müssen Sie die Signatur der Anfrage in der Funktion validieren. Eine Function URL mit AuthType: NONE und ohne Validierung in der Funktion ist ein anonymer Compute-Endpunkt im öffentlichen Internet.

Aufruftypen, Wiederholungsversuche und Idempotenz

Ereignisquellen (Event Sources) lassen sich in zwei Kategorien mit sehr unterschiedlichem Verhalten einteilen. Push-basierte Quellen (API Gateway, ALB, S3, SNS, EventBridge, Cognito) rufen Lambda direkt auf und erfordern eine ressourcenbasierte Richtlinie (AWS::Lambda::Permission), die lambda:InvokeFunction mit dem korrekten Principal (z. B. events.amazonaws.com) und SourceArn gewährt. Ohne diese Richtlinie werden Ereignisse zwar von der Regel erfasst, aber jeder Aufruf wird stillschweigend abgelehnt – die Funktion wird nie ausgeführt und Fehler erscheinen nur in CloudTrail. Dies ist von der Ausführungsrolle (Execution Role) zu unterscheiden, die regelt, was die Funktion tun kann, nicht, wer sie aufrufen darf.

Poll-basierte Quellen (SQS, Kinesis, DynamoDB Streams, MSK) werden vom Lambda-Service über ein Event Source Mapping ausgelesen – es ist keine ressourcenbasierte Richtlinie erforderlich, aber die Ausführungsrolle muss Leseberechtigungen gewähren.

Aufruftypen bestimmen weiterhin das Verhalten bei Wiederholungsversuchen:

• Synchron (API Gateway, ALB, RequestResponse SDK): Fehler werden sofort zurückgegeben; der Aufrufer ist für Wiederholungsversuche verantwortlich.
• Asynchron (S3, SNS, EventBridge): Lambda puffert in einer internen Warteschlange und versucht es bei einem Fehler zweimal mit Verzögerungen erneut, bevor die Nachricht an eine DLQ oder ein On-Failure-Ziel gesendet wird.
• SQS Event Source Mapping: SQS stellt die Nachricht so lange erneut zu, bis maxReceiveCount erreicht ist und die Nachricht in die DLQ der Quell-Warteschlange verschoben wird.
• Kinesis / DynamoDB Streams: Wiederholt die Verarbeitung eines einzelnen Shard-Batches bis zum Erfolg oder bis zum Ablauf der Gültigkeit und blockiert dabei den Shard – ein feststeckender Batch hält die gesamte nachgelagerte Verarbeitung für diese Partition auf.

Da Wiederholungsversuche in jeder Schicht fest verankert sind, ist Idempotenz zwingend erforderlich und nicht optional. Ein SQS Visibility Timeout, das während eines langsamen Schreibvorgangs abläuft, oder ein asynchroner Wiederholungsversuch nach einem nachgelagerten 5xx-Fehler erzeugt Duplikate. Das kanonische Muster verwendet einen deterministischen Schlüssel und einen bedingten Schreibvorgang (Conditional Write) in DynamoDB:

def handler(event, context):
    msg_id = event['Records'][0]['messageId']
    try:
        ddb.put_item(
            TableName='processed',
            Item={'id': {'S': msg_id}, 'ttl': {'N': str(ttl)}},
            ConditionExpression='attribute_not_exists(id)')
    except ddb.exceptions.ConditionalCheckFailedException:
        return  # already processed
    process(event)

Der @idempotent-Decorator der AWS Lambda Powertools implementiert genau dieses Muster mit DynamoDB als Backend.

Entkopplung mit SQS und SNS

Die direkte Anbindung von Push-Quellen mit hohem Fan-Out an Lambda ist fragil. S3-Ereignisbenachrichtigungen sind beispielsweise pro Ereignis synchron und unterliegen der Concurrency-Obergrenze von Lambda. Wenn bei einem schubweisen Upload (z. B. eine Marketingkampagne, die Tausende von Dokumenten in Sekunden ablegt) die Aufrufe die verfügbare Concurrency überschreiten, ist das Wiederholungsfenster von S3 kurz, und Ereignisse können effektiv verloren gehen (dropped). Die Abhilfe ist ein Puffer:

SNS ist Pub/Sub: eine Veröffentlichung, viele Abonnenten (SQS, Lambda, HTTPS, E-Mail). Die Nachrichtenfilterung ist attributbasiert. SQS ist eine langlebige Punkt-zu-Punkt-Warteschlange, die Nachrichten bis zu 14 Tage aufbewahrt. Die bewährte Standardkombination ist der SNS → SQS Fan-Out, der jedem Konsumenten eine eigene gepufferte Warteschlange für unabhängige Skalierung und Wiederholung (Replay) gibt.

Für eine strikte Reihenfolge (z. B. Bestellungen pro Kunde, die sequenziell verarbeitet werden), verwenden Sie eine SQS FIFO-Warteschlange, bei der die MessageGroupId auf den Schlüssel für die Reihenfolge gesetzt wird. Nachrichten innerhalb einer Gruppe werden der Reihe nach zugestellt; verschiedene Gruppen werden parallel verarbeitet. Standard-SQS bietet nur eine Best-Effort-Reihenfolge.

Das kanonische entkoppelte Ingestion-Muster nutzt die direkte SQS-Integration von API Gateway, um Lastspitzen abzufangen, und einen ratenbegrenzten Prozessor:

Resources:
  OrdersQueue:
    Type: AWS::SQS::Queue
    Properties:
      FifoQueue: true
      ContentBasedDeduplication: true
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt OrdersDLQ.Arn
        maxReceiveCount: 5

  ProcessorFunction:
    Type: AWS::Lambda::Function
    Properties:
      ReservedConcurrentExecutions: 20   # cap the DB write rate

  Mapping:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt OrdersQueue.Arn
      FunctionName: !Ref ProcessorFunction
      BatchSize: 10

Die reservierte Concurrency ist beabsichtigt – sie begrenzt, wie schnell die Datenbank Schreibvorgänge erhält, sodass die Warteschlange (nicht RDS) die Lastspitze abfängt. Fehlgeschlagene Nachrichten werden nach Erreichen von maxReceiveCount zur Offline-Analyse an eine DLQ weitergeleitet.

EventBridge: Regeln, Input Transformation und API Destinations

EventBridge ist ein schema-sensitiver Event Bus mit umfangreichem JSON Pattern Matching, SaaS-Partnerquellen, einer Schema Registry sowie Archivierungs- und Replay-Funktionen. Regeln wenden Muster auf Ereignisse an und leiten sie per Fan-Out an über 30 Zieltypen (Lambda, Step Functions, SQS, Kinesis, ECS, Firehose) weiter, wobei eine inhaltsbasierte Filterung auf den Nachrichtentext (Message Body) angewendet wird – nicht nur auf Attribute wie bei SNS:

{
  "source": ["tenant.energy"],
  "detail-type": ["UsageReported"],
  "detail": { "kWh": [{ "numeric": [">", 100] }] }
}

Eine Regel kann bis zu fünf Ziele haben, von denen jedes entweder das rohe Ereignis oder eine transformierte Teilmenge davon erhält. Input Transformers erzwingen eine lose Kopplung: Eine InputPathsMap extrahiert JSON-Pfade aus dem Ereignis, und ein InputTemplate formt diese genau in das Format um, das das Ziel erwartet:

EventPattern:
  source: ["com.acme.orders"]
  detail-type: ["OrderPlaced"]
Targets:
  - Arn: !GetAtt PaymentValidator.Arn
    InputTransformer:
      InputPathsMap:
        orderId: "$.detail.orderId"
        amount: "$.detail.total"
        card: "$.detail.payment.cardToken"
      InputTemplate: |
        {"orderId": <orderId>, "amount": <amount>, "cardToken": <card>}

Jede Validierungs-Lambda erhält nur das, was sie benötigt; der Adress-Validator sieht niemals den Karten-Token. Dies ist einem monolithischen Lambda, das das gesamte Ereignis empfängt und intern verzweigt, entscheidend überlegen – ein Monolith konzentriert IAM-Berechtigungen (eine Rolle muss jede nachgelagerte Berechtigung halten), vergrößert den Explosionsradius (Blast Radius) eines Fehlers, koppelt die Deployment-Zyklen, verhindert eine aufgabenbezogene Speicher-/Timeout-Abstimmung und zwingt die gesamte Funktion, auf die Rate des aufrufstärksten Zweigs zu skalieren.

API Destinations kehren die Richtung um: EventBridge ruft einen externen HTTPS-Endpunkt auf. Gepaart mit einer Connection, die Basic-, API-Key- oder OAuth-Anmeldeinformationen im Secrets Manager speichert, ist dies der serverlose Weg, um einen Drittanbieter-SaaS zu benachrichtigen, wenn beispielsweise ein AWS Batch-Job erfolgreich ist – ganz ohne Lambda. EventBridge erfasst das Zustandsänderungsereignis, eine Regel passt auf JobSucceeded, und das API-Destination-Ziel sendet einen POST-Request an den Anbieter, wobei die Anmeldeinformationen aus der Connection eingefügt werden.

Zeitgesteuerte Regeln (Scheduled Rules) (Cron-/Rate-Ausdrücke) oder der neuere EventBridge Scheduler ersetzen Heartbeat-EC2-Instanzen für periodische Aufgaben – wie nächtliche Berichte oder stündliche Cache-Aktualisierungen.

Wählen Sie EventBridge anstelle von SNS, wenn die Filterung auf dem Inhalt des Nachrichtentextes (nicht nur auf Attributen) basieren soll, wenn neue Konsumenten später ohne Änderungen am Producer angebunden werden müssen oder wenn das Routing über Konten oder SaaS-Quellen hinweg erfolgt. Wählen Sie SNS, wenn der Fan-Out eine einfache, attributgefilterte Benachrichtigung an eine stabile Gruppe von Abonnenten ist.

Step Functions: Orchestrierung und Distributed Map

Wenn ein Workflow mehr als nur ein paar Schritte, Verzweigungen, Wiederholungsversuche, menschliche Genehmigungen oder lange Wartezeiten umfasst, wird die Einbettung dieser Logik in verkettete Lambdas nicht mehr wartbar. Step Functions externalisiert die Zustandsmaschine in der Amazon States Language.

• Standard-Workflows: bis zu einem Jahr, Exactly-Once-Semantik, vollständiger Ausführungsverlauf, .waitForTaskToken für menschliche/externe Freigaben. Bestellabwicklung, ETL, Genehmigungs-Workflows.
• Express-Workflows: bis zu fünf Minuten, At-Least-Once, hohes Volumen, günstig pro Ausführung. Kurze synchrone Orchestrierungen hinter API Gateway; IoT- und Streaming-Transformationen.

Jeder Task sollte explizit Retry und Catch deklarieren:

"ValidatePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "PaymentValidator", "Payload.$": "$"},
  "Retry": [{
    "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
    "IntervalSeconds": 2, "MaxAttempts": 4, "BackoffRate": 2.0
  }],
  "Catch": [{"ErrorEquals": ["PaymentDeclined"], "Next": "RefundStep"}],
  "Next": "ShipOrder"
}

Parallel- und Map-Zustände führen Zweige parallel aus und fassen die Ergebnisse zusammen – eine saubere Lösung für Bestellsysteme mit unabhängigen Validatoren (Adresse, Inventar, Zahlung). Der Zustand zwischen den Schritten fließt durch das JSON-Dokument der Ausführung, wodurch eine gemeinsam genutzte Datenbank, die ausschließlich zur Workflow-Koordination dient, überflüssig wird.

Das .waitForTaskToken-Muster pausiert die Ausführung, bis ein externer Akteur SendTaskSuccess mit dem Token aufruft – die Standardlösung, wenn sich ein Workflow über Lambdas, EC2, Container, On-Premise-Systeme erstreckt und eine manuelle Genehmigung mit minimalem Betriebsaufwand erfordert:

"ManagerApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:us-east-1:111:approvals",
    "Message": { "TaskToken.$": "$$.Task.Token", "OrderId.$": "$.orderId" }
  },
  "Next": "Fulfill"
}

Distributed Map erweitert den Standard-Map-Zustand, um bis zu 10.000 parallele untergeordnete Ausführungen zu verarbeiten, und kann direkt über Objekte in einem S3-Bucket oder Zeilen in einer CSV/JSONL-Datei iterieren, mit automatischem Batching, Checkpointing und Fehlertoleranz. Für Tausende von semistrukturierten S3-Objekten ist dies die operativ effizienteste Option – man richtet sie auf ein Präfix aus, definiert die Aufgabe pro Element, und Step Functions kümmert sich um Fan-Out, MaxConcurrency, Wiederholungsversuche und die Zusammenfassung der Ergebnisse:

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:listObjectsV2",
    "Parameters": { "Bucket": "raw-events", "Prefix": "2024/" }
  },
  "MaxConcurrency": 1000,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" },
    "StartAt": "ProcessObject",
    "States": { "ProcessObject": { "Type": "Task", "Resource": "arn:aws:lambda:...:function:ProcessOne", "End": true } }
  }
}

Ein Nachbau derselben Logik auf SQS oder EventBridge erfordert eine benutzerdefinierte Nachverfolgung für den Abschluss, Wiederholungsversuche und die Zusammenstellung der Ergebnisse.

Step Functions vs. EventBridge: Step Functions ist die richtige Wahl, wenn Sie die Abfolge und das Ergebnis kontrollieren – Zustand, Verzweigungen, Wiederholungsversuche, Genehmigungen. EventBridge ist die richtige Wahl, wenn Produzenten nicht wissen oder sich nicht darum kümmern, wer die Konsumenten sind, und die Konsumenten sich unabhängig anbinden.

S3 Event Notifications

Für die Verarbeitung von Uploads nahezu in Echtzeit konfigurieren Sie S3-Event-Benachrichtigungen für s3:ObjectCreated:* (oder eine spezifische Variante wie Put, Post, CompleteMultipartUpload) mit einem Lambda-Ziel – unter Berücksichtigung der oben genannten Vorbehalte bei Lastspitzen (Bursts). Schutzmaßnahmen:

• Legen Sie reservierte Nebenläufigkeit fest, um eine nachgelagerte Datenbank zu schützen.
• Aktivieren Sie eine DLQ oder ein On-Failure-Ziel für fehlerhafte Nachrichten (Poison Messages).
• Leiten Sie S3-Events über EventBridge, wenn mehrere Konsumenten dieselben Events benötigen. Direkte S3-Benachrichtigungskonfigurationen sind in ihrer Anzahl und Ausdruckskraft begrenzt; ein Fan-Out über EventBridge mit zielspezifischen Input-Transformern skaliert weitaus besser.

Streaming: Kinesis Data Streams vs. Firehose

Kinesis Data Streams (KDS) ist ein geshardetes, geordnetes, wiederabspielbares Protokoll (Log) mit einer Aufbewahrungsfrist von 24 Stunden bis zu 365 Tagen. Die Reihenfolge wird pro Shard beibehalten, basierend auf dem Partition Key – entscheidend für die geräte- oder mandantenbasierte Aggregation. Mehrere Konsumenten lesen unabhängig voneinander (Enhanced Fan-Out für isolierten Durchsatz pro Konsument). Wählen Sie KDS, wenn Sie eine geordnete Wiedergabe, mehrere unabhängige Konsumenten oder einen hohen Durchsatz pro Shard benötigen.

Kinesis Data Firehose ist ein vollständig verwalteter Lieferstream zu S3, Redshift, OpenSearch oder Splunk mit integrierter Pufferung (60 s oder 1–128 MB), optionaler Lambda-Transformation, Komprimierung (GZIP, Snappy) und Parquet/ORC-Konvertierung. Keine Shards zu verwalten. Firehose ist die Wahl mit geringem Betriebsaufwand, wenn keine benutzerdefinierten Konsumenten und keine Wiederholungen benötigt werden – sondern es nur darum geht, Daten nahezu in Echtzeit abzulegen.

Die kanonische Analyse-Pipeline für Nahezu-Echtzeit ist: Produzenten → KDS → Firehose → S3 (Parquet) → Athena/QuickSight, mit optionaler Anreicherung durch Lambda in Firehose.

AWS Transfer Family für Managed SFTP

Wenn Partner SFTP, FTPS oder FTP für den Datentransfer zu oder von S3 oder EFS benötigen, bietet AWS Transfer Family einen verwalteten, Multi-AZ-Endpunkt, der die Protokolle spricht, die die Clients bereits verwenden. Die Authentifizierung unterstützt vom Service verwaltete Benutzer, SSH-Schlüssel oder benutzerdefinierte IdPs über API Gateway/Lambda. Dateien landen direkt in S3, wobei SSE und Lifecycle-Richtlinien angewendet werden; IAM Scope-Down-Richtlinien beschränken jeden Benutzer auf ein bestimmtes Präfix.

Dies selbst auf EC2 zu erstellen, erfordert die Härtung von OpenSSH, Patching, Hochverfügbarkeit über AZs hinweg, Schlüsselrotation und Log-Versand – all das übernimmt Transfer Family. Wählen Sie diesen Service immer dann, wenn die Anforderung lautet „Partner senden uns Dateien über SFTP“ und Sie die Dateien mit minimalem Betriebsaufwand in S3 haben möchten.

Zusammensetzen eines kanonischen Serverless-Musters

Ein Ingestion-Design mit geringem Overhead für mandantenbasierte stündliche Metriken: Sensoren senden per POST an API Gateway (HTTP API, regional) → Lambda validiert und veröffentlicht an EventBridge → Regeln leiten die Daten an eine DynamoDB-Writer-Lambda weiter (Mandanten-ID als Partition Key, Stunden-Bucket als Sort Key) und parallel dazu an Firehose → S3 (Parquet) für Analysen. Neue Konsumenten werden als zusätzliche EventBridge-Regeln angebunden, ohne die Produzenten zu verändern – eine Anforderung an die Erweiterbarkeit, die SNS allein nicht so sauber erfüllen würde. Wo nachhaltiger Durchsatz und Reihenfolge wichtig sind (Abrechnungsabstimmung, Finanz-Event-Streams), ersetzen Sie EventBridge durch Kinesis Data Streams und verwenden Sie Enhanced Fan-Out für unabhängige Konsumenten.

Fallenkatalog: Warum die häufigsten Fehlmuster scheitern

NAT-Instanz/-Gateway für den Datenverkehr von Lambdas in privaten Subnetzen zu AWS-Services. NAT-Instanzen binden den Durchsatz an eine einzige EC2-NIC und sind ein SPOF; NAT-Gateways werden pro GB abgerechnet. Beides ist für AWS-Service-Ziele unnötig. Verwenden Sie Gateway-Endpunkte für S3/DynamoDB und Interface-Endpunkte für alles andere.

Ignorieren von Kaltstarts bei latenzkritischen APIs. On-Demand stellt Container nur dann bereit, wenn eine Anfrage eingeht, sodass Lastspitzen (Bursts) SLAs verletzen. Dimensionieren Sie die Provisioned Concurrency auf den p95-Burst; verwenden Sie SnapStart für Java-Workloads ohne harte SLAs.

Monolithische Lambda, die ein vollständiges Event empfängt und intern verzweigt. Verletzt das Prinzip der geringsten Rechte (Least Privilege) (eine Rolle besitzt alle Berechtigungen für nachgelagerte Dienste), koppelt die Deployment-Kadenz, verhindert eine zuständigkeitsbezogene Feinabstimmung und skaliert die gesamte Funktion auf die Rate des am stärksten ausgelasteten Zweigs. Trennen Sie nach Zuständigkeit; verknüpfen Sie die Teile mit EventBridge oder Step Functions.

Direkte Datenbankverbindungen von vielen Lambdas. Die Gesamtzahl der Verbindungen entspricht den gleichzeitigen Aufrufen, da Container keine Pools gemeinsam nutzen. Lösung mit RDS Proxy (Pooling), Reserved Concurrency (Ratenbegrenzung) oder SQS (Pufferung).

Synchrone Lambda für die Aufnahme von Lastspitzen (bursty ingestion). Das Überschreiten der Concurrency gibt einen 429-Fehler an API Gateway und 5xx-Fehler an Clients zurück; direkte S3-Benachrichtigungen während Lastspitzen verwerfen Events stillschweigend. Schalten Sie SQS dazwischen oder verwenden Sie die direkte Integration von Gateway → SQS.

Öffentliche Lambda Function URLs mit AuthType: NONE und ohne Signaturvalidierung in der Funktion. Anonyme Rechenleistung im öffentlichen Internet. Verwenden Sie AWS_IAM für AWS-Aufrufer oder validieren Sie Signaturen für Webhooks von Drittanbietern.

Benutzerdefinierter Lambda Authorizer, wo ein integrierter ausreichen würde. Fügt Latenz hinzu, eine weitere zu patchende Funktion und einen Codepfad, in dem Fehler bei der Signaturprüfung stillschweigend den Zugriff erlauben. Bevorzugen Sie die IAM-Autorisierung für AWS-Principals; den Cognito Authorizer für User Pools.

Falsche Region für das ACM-Zertifikat bei Custom Domains. Edge-optimierte Endpunkte erfordern das Zertifikat in us-east-1; regionale Endpunkte in der eigenen Region der API.

Fehlende AWS::Lambda::Permission für Push-Quellen (EventBridge, S3, SNS). Events entsprechen den Regeln, aber Aufrufe werden stillschweigend verweigert. Dies ist von der Ausführungsrolle (Execution Role) zu unterscheiden – es regelt, wer die Funktion aufrufen darf, nicht, was die Funktion tun darf.

Fehlende Idempotenz. Jede Schicht führt Wiederholungsversuche durch – asynchrone Aufrufe, erneute Zustellung bei SQS nach Ablauf des Visibility Timeouts, Wiederholungsversuche bei Kinesis-Batches. Ohne einen deterministischen Deduplizierungsschlüssel und bedingtes Schreiben sind Duplikate unvermeidlich.

← Container · Alle Domänen · Speicherung →

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

Amazon durchsuchen →