0Pricing
AWS Solutions Architect · Lektion

Lambda@Edge und ereignisgesteuerte Patterns

Führen Sie Funktionen an CloudFront-Edge-Locations aus und verbinden Sie Lambda für ereignisgesteuerte Architekturen mit SQS, SNS, DynamoDB Streams und Kinesis.

Lambda@Edge und ereignisgesteuerte Patterns ist eine kostenlose AWS Solutions Architect-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AWS Solutions Architect-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AWS Solutions Architect-Kurs umfasst insgesamt 4 Lektionen.

Was ist Lambda@Edge

Lambda@Edge ermöglicht es Ihnen, Lambda-Funktionen an CloudFront-Edge-Standorten auf der ganzen Welt auszuführen – näher an den Endbenutzern – statt in einer zentralen Region. Dadurch können Sie HTTP-Anfragen und -Antworten mit einer zusätzlichen Latenz von unter einer Millisekunde auf der CDN-Ebene anpassen. Lambda@Edge-Funktionen werden global bereitgestellt und bei jedem CloudFront-Ereignis eines Cache-Treffers oder Cache-Fehlers aufgerufen. Damit eignen sie sich ideal für leichte Aufgaben zur Anfragenmanipulation.

Die vier CloudFront-Triggerpunkte

Lambda@Edge kann Datenverkehr an vier Punkten im CloudFront-Anfragelebenszyklus abfangen:

  • Viewer Request: wird ausgelöst, wenn CloudFront eine Anfrage vom Viewer (Benutzer) empfängt, bevor der Cache geprüft wird
  • Origin Request: wird ausgelöst, wenn CloudFront einen Cache-Fehler an den Origin weiterleitet
  • Origin Response: wird ausgelöst, wenn der Origin eine Antwort zurückgibt, bevor sie gecacht wird
  • Viewer Response: wird ausgelöst, bevor CloudFront die Antwort an den Viewer zurückgibt

Einschränkungen von Lambda@Edge im Vergleich zu regulärem Lambda

Lambda@Edge hat strengere Einschränkungen als reguläres Lambda: maximal 128 MB Arbeitsspeicher (Viewer-Ereignisse), 1 GB (Origin-Ereignisse), maximales Timeout von 5 Sekunden (Viewer) beziehungsweise 30 Sekunden (Origin). Funktionen müssen in us-east-1 erstellt und über CloudFront an die Edge-Standorte bereitgestellt werden. VPCs, Umgebungsvariablen und Lambda-Layer werden nicht unterstützt. Aufgrund dieser Einschränkungen ist Lambda@Edge für leichte Transformationen und nicht für aufwendige Verarbeitung ausgelegt.

Häufige Anwendungsfälle für Lambda@Edge

Lambda@Edge eignet sich besonders für: A/B-Tests (Umschreiben von URLs in verschiedene Origin-Pfade basierend auf Cookies), Authentifizierung (Validieren von JWTs am Edge, bevor die Anfrage an den Origin weitergeleitet wird), Manipulation von HTTP-Headern (Hinzufügen von Sicherheits-Headern wie HSTS, CSP und X-Frame-Options), URL-Normalisierung (Weiterleiten von www auf non-www oder Erzwingen von abschließenden Schrägstrichen) und Personalisierung (Ausliefern unterschiedlicher Inhalte basierend auf dem Land des Viewers aus dem Header CloudFront-Viewer-Country).

// Viewer Request: Add security headers
exports.handler = async (event) => {
    const response = event.Records[0].cf.response;
    response.headers['strict-transport-security'] = [{
        key: 'Strict-Transport-Security',
        value: 'max-age=63072000; includeSubdomains; preload'
    }];
    response.headers['x-frame-options'] = [{
        key: 'X-Frame-Options',
        value: 'DENY'
    }];
    return response;
};

CloudFront Functions im Vergleich zu Lambda@Edge

CloudFront Functions sind extrem leichtgewichtige JavaScript-Funktionen, die nur in den Phasen Viewer Request und Viewer Response ausgeführt werden. Sie haben ein Ausführungslimit von 2 ms und sind deutlich kostengünstiger. Für einfache Anwendungsfälle (URL-Umschreibungen, Header-Manipulation, Normalisierung des Cache-Schlüssels) werden CloudFront Functions gegenüber Lambda@Edge bevorzugt, da sie schneller und günstiger sind. Verwenden Sie Lambda@Edge, wenn Sie Netzwerkaufrufe oder größere Payloads benötigen oder die Triggerpunkte Origin Request und Origin Response verwenden möchten.

Ereignisgesteuerte Architektur mit Lambda

Eine ereignisgesteuerte Architektur verbindet Services über Ereignisse – Nachrichten, die etwas Geschehenes darstellen. In AWS ist Lambda der primäre Ereigniskonsument: Es empfängt Ereignisse aus SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge und weiteren Quellen. Jedes Ereignis löst eine Lambda-Ausführung aus, sodass Systeme asynchron und unabhängig reagieren können, ohne eng gekoppelt zu sein. Dieses Muster ermöglicht lose Kopplung, unabhängige Skalierung und Fehlerisolierung.

Lambda als SQS-Konsument

Lambda kann als Event-Source-Mapping für SQS konfiguriert werden. Lambda fragt die Warteschlange ab, ruft bis zu einer Batchgröße von Nachrichten ab (bis zu 10.000 bei Standard-Warteschlangen, 10 bei FIFO) und ruft die Funktion einmal pro Batch auf. Wenn die Funktion fehlschlägt, wird der gesamte Batch an die Warteschlange zurückgegeben. Konfigurieren Sie ein Batch-Fenster, um vor dem Aufruf auf weitere Nachrichten zu warten und dadurch den Durchsatz zu verbessern. Verwenden Sie eine DLQ in der Quell-SQS-Warteschlange für Nachrichten, deren Verarbeitung wiederholt fehlschlägt.

aws lambda create-event-source-mapping \
  --function-name 'OrderProcessor' \
  --event-source-arn 'arn:aws:sqs:us-east-1:123456789012:OrderQueue' \
  --batch-size 10 \
  --maximum-batching-window-in-seconds 5

Lambda mit DynamoDB Streams

DynamoDB Streams erfassen jede Änderung auf Elementebene (INSERT, MODIFY, REMOVE) als geordnete Folge von Ereignissen. Lambda liest den Stream mithilfe eines Event-Source-Mappings mit TRIM_HORIZON (Start beim ältesten Eintrag) oder LATEST (Start beim neuesten Eintrag). Lambda verarbeitet Datensätze innerhalb einer Partition in der richtigen Reihenfolge. Fehlgeschlagene Batches blockieren die weitere Verarbeitung derselben Partition, bis das Problem behoben ist – verwenden Sie bisect on error, um fehlschlagende Batches zu teilen und problematische Datensätze zu isolieren.

aws lambda create-event-source-mapping \
  --function-name 'StreamProcessor' \
  --event-source-arn 'arn:aws:dynamodb:us-east-1:123456789012:table/Orders/stream/...' \
  --starting-position TRIM_HORIZON \
  --batch-size 100 \
  --bisect-batch-on-function-error

Lambda mit Kinesis Data Streams

Lambda verarbeitet Kinesis-Datensätze ähnlich wie DynamoDB Streams – eine gleichzeitige Ausführung pro Shard. Zu den wichtigsten Konfigurationsoptionen gehören der Parallelisierungsfaktor (bis zu 10 gleichzeitige Lambda-Aufrufe pro Shard, bei paralleler Verarbeitung von Teil-Batches) und Enhanced Fan-Out (dedizierter Durchsatz von 2 MB/s pro Shard für den Lambda-Konsumenten). Diese Optionen erhöhen den Durchsatz bei Streams mit hohem Volumen erheblich, ohne die Anzahl der Shards zu vergrößern.

EventBridge als Ereignis-Router

Amazon EventBridge ist der empfohlene Event-Bus für die Verbindung von AWS-Services und benutzerdefinierten Anwendungen. Ereignisse fließen in einen Bus, und Regeln filtern Ereignisse anhand eines Musters und leiten sie an Ziele wie Lambda, SQS, Step Functions und weitere weiter. EventBridge entkoppelt Ereigniserzeuger und -konsumenten vollständig – keiner kennt den anderen. Der Standard-Event-Bus empfängt Ereignisse von AWS-Services; erstellen Sie für die Ereignisse Ihrer Anwendung einen benutzerdefinierten Event-Bus.

aws events put-rule \
  --name 'OrderPlacedRule' \
  --event-pattern '{"source": ["com.myapp.orders"], "detail-type": ["OrderPlaced"]}' \
  --state ENABLED

aws events put-targets \
  --rule 'OrderPlacedRule' \
  --targets 'Id=LambdaTarget,Arn=arn:aws:lambda:us-east-1:123456789012:function:InventoryUpdater'

Fan-Out-Muster: SNS an mehrere Lambdas

Ein häufiges ereignisgesteuertes Muster ist Fan-Out: Ein Ereignis löst mehrere parallel arbeitende Verarbeitungspipelines aus. Veröffentlichen Sie eine Nachricht in einem SNS-Thema, reagieren mehrere abonnierte Lambda-Funktionen jeweils unabhängig. Beispielsweise kann ein Ereignis zur Aufgabe einer Bestellung an folgende Funktionen verteilt werden: eine Lambda-Funktion sendet eine Bestätigungs-E-Mail, eine aktualisiert den Bestand und eine benachrichtigt das Lager. Jeder Konsument ist unabhängig und wird separat skaliert – kein einzelner Konsument kann die anderen blockieren.

Schnelltest

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

Zusammenfassung der Lektion

In dieser Lektion haben Sie gelernt: Lambda@Edge führt Funktionen an CloudFront-Edge-Standorten mit vier Triggerpunkten (Viewer Request/Response, Origin Request/Response) für Aufgaben wie Authentifizierung, URL-Umschreibung und Header-Manipulation aus; CloudFront Functions sind die kostengünstigere Alternative mit geringerer Latenz für einfache Transformationen auf der Viewer-Ebene; und ereignisgesteuerte Muster mit SQS, DynamoDB Streams, Kinesis, EventBridge und SNS-Fan-Out ermöglichen lose gekoppelte Architekturen, in denen Lambda auf Ereignisse in Echtzeit reagiert. Als Nächstes sehen wir uns SQS-Standard- und FIFO-Warteschlangen an.

Häufig gestellte Fragen

Ist die Lektion „Lambda@Edge und ereignisgesteuerte Patterns“ kostenlos?

Ja — der vollständige Text von „Lambda@Edge und ereignisgesteuerte Patterns“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AWS Solutions Architect-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AWS Solutions Architect-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Lambda@Edge und ereignisgesteuerte Patterns“?

Führen Sie Funktionen an CloudFront-Edge-Locations aus und verbinden Sie Lambda für ereignisgesteuerte Architekturen mit SQS, SNS, DynamoDB Streams und Kinesis. Du übst AWS Solutions Architect mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AWS Solutions Architect zu starten?

Keine Vorkenntnisse erforderlich. AWS Solutions Architect auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Lambda@Edge und ereignisgesteuerte Patterns“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AWS Solutions Architect-Lektion Code schreiben und ausführen?

Ja. Jede AWS Solutions Architect-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Lambda-Funktionen: Runtimes, Trigger und Handler
  2. Nebenläufigkeit, Drosselung und reservierte Nebenläufigkeit
  3. Lambda Layers und Deployment-Pakete
  4. Lambda@Edge und ereignisgesteuerte Patterns
← Zurück zu AWS Solutions Architect