Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Anpassen am Edge mit Lambda@Edge
<a name="lambda-at-the-edge"></a>

Lambda @Edge ist eine Erweiterung von. AWS Lambda Lambda @Edge ist ein Rechenservice, mit dem Sie Funktionen ausführen können, mit denen Sie die von Amazon bereitgestellten Inhalte anpassen können CloudFront . Sie können Node.js- oder Python-Funktionen in der Lambda-Konsole in einer AWS-Region, USA Ost (Nord-Virginia), erstellen.

Nachdem Sie die Funktion erstellt haben, können Sie mithilfe der Lambda-Konsole oder der CloudFront Lambda-Konsole Trigger hinzufügen, sodass die Funktionen AWS an Orten ausgeführt werden, die sich näher am Betrachter befinden, ohne Server bereitzustellen oder zu verwalten. Optional können Sie Lambda- und CloudFront API-Operationen verwenden, um Ihre Funktionen und Trigger programmgesteuert einzurichten.

Lambda@Edge skaliert automatisch zwischen einigen wenigen Anforderungen pro Tag und ein paar Tausend Anforderungen pro Sekunde. Die Verarbeitung von Anfragen an AWS Orten, die sich näher am Betrachter befinden, anstatt auf Originalservern, reduziert die Latenz erheblich und verbessert die Benutzererfahrung.

**Anmerkung**  
Lambda@Edge wird für gRPC-Anforderungen nicht unterstützt. Weitere Informationen finden Sie unter [gRPC mit CloudFront Distributionen verwenden](distribution-using-grpc.md).

**Topics**
+ [

# So arbeitet Lambda@Edge mit Anforderungen und Antworten
](lambda-edge-event-request-response.md)
+ [

# Anwendungsmöglichkeiten von Lambda@Edge
](lambda-edge-ways-to-use.md)
+ [

# Erste Schritte mit Lambda@Edge-Funktionen (Konsole)
](lambda-edge-how-it-works.md)
+ [

# Einrichten von IAM-Berechtigungen und -Rollen für Lambda@Edge
](lambda-edge-permissions.md)
+ [

# Schreiben und Erstellen einer Lambda@Edge-Funktion
](lambda-edge-create-function.md)
+ [

# Hinzufügen von Auslösern für eine Lambda@Edge-Funktion
](lambda-edge-add-triggers.md)
+ [

# Testen und Debuggen von Lambda@Edge-Funktionen
](lambda-edge-testing-debugging.md)
+ [

# Löschen von Lambda@Edge-Funktionen und Replikaten
](lambda-edge-delete-replicas.md)
+ [

# Lambda@Edge-Ereignisstruktur
](lambda-event-structure.md)
+ [

# Arbeiten mit Anforderungen und Antworten
](lambda-generating-http-responses.md)
+ [

# Beispielfunktionen für Lambda@Edge
](lambda-examples.md)

# So arbeitet Lambda@Edge mit Anforderungen und Antworten
<a name="lambda-edge-event-request-response"></a>

Wenn Sie eine CloudFront Verteilung mit einer Lambda @Edge -Funktion verknüpfen, CloudFront fängt sie Anfragen und Antworten an CloudFront Edge-Standorten ab. Sie können Lambda-Funktionen ausführen, wenn die folgenden CloudFront Ereignisse eintreten:
+ Wann CloudFront erhält er eine Anfrage von einem Zuschauer (Viewer-Anfrage)
+ Bevor CloudFront eine Anfrage an den Ursprung weitergeleitet wird (ursprüngliche Anfrage)
+ Wann CloudFront erhält er eine Antwort vom Ursprung (ursprüngliche Antwort)
+ Before CloudFront gibt die Antwort an den Zuschauer zurück (Antwort des Betrachters)

Wenn Sie verwenden AWS WAF, wird die Lambda @Edge Viewer-Anfrage ausgeführt, nachdem alle AWS WAF Regeln angewendet wurden.

Weitere Informationen erhalten Sie unter [Arbeiten mit Anforderungen und Antworten](lambda-generating-http-responses.md) und [Lambda@Edge-Ereignisstruktur](lambda-event-structure.md).

# Anwendungsmöglichkeiten von Lambda@Edge
<a name="lambda-edge-ways-to-use"></a>

Es gibt viele Verwendungsmöglichkeiten für die Lambda @Edge -Verarbeitung mit Ihrer CloudFront Amazon-Distribution, wie z. B. die folgenden Beispiele:
+ Eine Lambda-Funktion kann Cookies untersuchen und neu schreiben, URLs sodass Benutzern verschiedene Versionen einer Website zum A/B Testen angezeigt werden.
+ CloudFront kann den Zuschauern je nach verwendetem Gerät unterschiedliche Objekte zurückgeben, indem sie den `User-Agent` Header überprüft, der Informationen zu den Geräten enthält. CloudFront Kann beispielsweise je nach Bildschirmgröße des Geräts unterschiedliche Bilder zurückgeben. In ähnlicher Weise könnte die Funktion den Wert des `Referer` Headers berücksichtigen und veranlassen CloudFront , dass die Bilder an Bots mit der niedrigsten verfügbaren Auflösung zurückgegeben werden. 
+ Sie können Cookies auch auf andere Kriterien überprüfen. Wenn Sie beispielsweise auf einer Einzelhandels-Website, die Kleidung verkauft, Cookies verwenden, um anzugeben, welche Farbe ein Benutzer für eine Jacke ausgewählt hat, kann eine Lambda-Funktion die Anfrage so ändern, dass das Bild einer Jacke in der ausgewählten Farbe CloudFront zurückgegeben wird.
+ Eine Lambda-Funktion kann HTTP-Antworten generieren, wenn CloudFront Viewer-Anfragen oder Origin-Request-Ereignisse auftreten.
+ Eine Funktion kann Header oder Autorisierungstoken überprüfen und einen Header einfügen, um den Zugriff auf Ihre Inhalte zu kontrollieren, bevor die Anfrage an Ihren Ursprung CloudFront weitergeleitet wird.
+ Eine Lambda-Funktion kann auch Netzwerkaufrufe an externe Ressourcen durchführen, um die Anmeldeinformationen von Benutzern zu bestätigen oder weitere Inhalte zum Anpassen einer Antwort abzurufen.

Weitere Informationen hierzu einschließlich Beispielcode finden Sie unter [Beispielfunktionen für Lambda@Edge](lambda-examples.md).

Weitere Informationen zum Einrichten von Lambda@Edge in der Konsole finden Sie unter [Tutorial: Erstellen einer grundlegenden Lambda@Edge-Funktion (Konsole)](lambda-edge-how-it-works-tutorial.md).

# Erste Schritte mit Lambda@Edge-Funktionen (Konsole)
<a name="lambda-edge-how-it-works"></a>

Mit Lambda @Edge können Sie CloudFront Trigger verwenden, um eine Lambda-Funktion aufzurufen. Wenn Sie eine CloudFront Verteilung mit einer Lambda-Funktion verknüpfen, CloudFront [fängt sie Anfragen und Antworten an CloudFront Edge-Standorten ab und](https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html) führt die Funktion aus. Lambda-Funktionen können die Sicherheit erhöhen oder Informationen besser an Ihre Viewer anpassen, um die Leistung zu verbessern.

Die folgende Liste bietet einen grundlegenden Überblick darüber, wie Lambda-Funktionen mit CloudFront erstellt und verwendet werden.

**Überblick: Lambda-Funktionen erstellen und verwenden mit CloudFront**

1. Erstellen Sie eine Lambda-Funktion in der Region USA Ost (Nord-Virginia).

1. Speichern und veröffentlichen Sie eine nummerierte Version der Funktion.

   Wenn Sie die Funktion ändern möchten, müssen Sie die \$1LATEST-Version der Funktion in der Region USA Ost (Nord-Virginia) bearbeiten. Bevor Sie es für die Verwendung einrichten CloudFront, veröffentlichen Sie dann eine neue nummerierte Version.

1. Ordnen Sie der Funktion ein CloudFront Verteilungs- und Cache-Verhalten zu. Geben Sie dann ein oder mehrere CloudFront Ereignisse (*Trigger*) an, die die Ausführung der Funktion veranlassen. Sie können beispielsweise einen Trigger erstellen, damit die Funktion ausgeführt wird, wenn sie eine Anfrage von einem Viewer CloudFront erhält.

1. Wenn Sie einen Auslöser erstellen, erstellt Lambda Replikate der Funktion an AWS -Standorten weltweit.

**Tipp**  
Weitere Informationen finden Sie unter [Funktionen erstellen und aktualisieren](lambda-edge-create-function.md), [Ereignisstruktur](lambda-event-structure.md) und [Hinzufügen von CloudFront Triggern](lambda-edge-add-triggers.md). Weitere Ideen und Codebeispiele finden Sie auch in [Beispielfunktionen für Lambda@Edge](lambda-examples.md).

Ein step-by-step Tutorial finden Sie unter dem folgenden Thema:

**Topics**
+ [

# Tutorial: Erstellen einer grundlegenden Lambda@Edge-Funktion (Konsole)
](lambda-edge-how-it-works-tutorial.md)

# Tutorial: Erstellen einer grundlegenden Lambda@Edge-Funktion (Konsole)
<a name="lambda-edge-how-it-works-tutorial"></a>

Dieses Tutorial zeigt Ihnen, wie Sie mit Lambda @Edge beginnen können, indem Sie eine Beispielfunktion für Node.js erstellen und konfigurieren, die in CloudFront ausgeführt wird. In diesem Beispiel werden einer Antwort beim CloudFront Abrufen einer Datei HTTP-Sicherheitsheader hinzugefügt. (Dies kann die Sicherheit und den Datenschutz einer Website verbessern.)

Sie benötigen keine eigene Website für dieses Tutorial. Wenn Sie jedoch Ihre eigene Lambda@Edge-Lösung erstellen möchten, führen Sie ähnliche Schritte aus und wählen aus denselben Optionen aus.

**Topics**
+ [

## Schritt 1: Registrieren für AWS-Konto
](#lambda-edge-how-it-works-tutorial-AWS)
+ [

## Schritt 2: Erstellen einer CloudFront -Verteilung
](#lambda-edge-how-it-works-tutorial-cloudfront)
+ [

## Schritt 3: Erstellen Ihrer Funktion
](#lambda-edge-how-it-works-tutorial-create-function)
+ [

## Schritt 4: Fügen Sie einen CloudFront Trigger hinzu, um die Funktion auszuführen
](#lambda-edge-how-it-works-tutorial-add-trigger)
+ [

## Schritt 5: Überprüfen, ob die Funktion funktioniert
](#lambda-edge-how-it-works-tutorial-verify)
+ [

## Schritt 6: Beheben von Problemen
](#lambda-edge-how-it-works-tutorial-troubleshoot)
+ [

## Schritt 7: Bereinigen der Ressourcen für Ihr Beispiel
](#lambda-edge-how-it-works-tutorial-cleanup-resources)
+ [

## Ähnliche Informationen
](#lambda-edge-how-it-works-tutorial-resources)

## Schritt 1: Registrieren für AWS-Konto
<a name="lambda-edge-how-it-works-tutorial-AWS"></a>

Registrieren Sie sich für ein AWS-Konto, falls Sie das noch nicht getan haben. Weitere Informationen finden Sie unter [Melden Sie sich für eine an AWS-Konto](setting-up-cloudfront.md#sign-up-for-aws).

## Schritt 2: Erstellen einer CloudFront -Verteilung
<a name="lambda-edge-how-it-works-tutorial-cloudfront"></a>

Bevor Sie die Lambda @Edge -Beispielfunktion erstellen, müssen Sie über eine CloudFront Umgebung verfügen, mit der Sie arbeiten können und die einen Ursprung für die Bereitstellung von Inhalten enthält.

In diesem Beispiel erstellen Sie eine CloudFront Distribution, die einen Amazon S3 S3-Bucket als Ursprung für die Verteilung verwendet. Wenn Sie bereits über eine Umgebung verfügen, die Sie benutzen können, können Sie diesen Schritt überspringen.<a name="lambda-edge-how-it-works-tutorial-cf-proc"></a>

**Um eine CloudFront Distribution mit einem Amazon S3 S3-Ursprung zu erstellen**

1. Erstellen Sie einen Amazon S3-Bucket mit einer oder zwei Dateien, z. B. Image-Dateien, als Beispielinhalt. Für Hilfe folgen Sie den Schritten unter [Hochladen Ihrer Inhalte zu Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html#GettingStartedUploadContent). Stellen Sie sicher, dass Sie Berechtigungen erteilen, um öffentliche Lesezugriff auf die Objekte in Ihrem Bucket zu gewähren.

1. Erstellen Sie eine CloudFront Distribution und fügen Sie Ihren S3-Bucket als Ursprung hinzu, indem Sie die Schritte [ CloudFront unter Web-Distribution erstellen befolgen](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html#GettingStartedCreateDistribution). Wenn Sie bereits eine Verteilung haben, können Sie stattdessen den Bucket als Ursprung für diese Verteilung hinzufügen.
**Tipp**  
Notieren Sie sich die ID Ihrer Verteilung. Wenn Sie später in diesem Tutorial einen CloudFront Trigger für Ihre Funktion hinzufügen, müssen Sie die ID für Ihre Distribution in einer Dropdownliste auswählen — zum Beispiel. `E653W22221KDDL`

## Schritt 3: Erstellen Ihrer Funktion
<a name="lambda-edge-how-it-works-tutorial-create-function"></a>

In diesem Schritt erstellen Sie eine Lambda-Funktion anhand einer Vorlage in der Lambda-Konsole. Die Funktion fügt Code hinzu, um Sicherheitsheader in Ihrer CloudFront-Verteilung zu aktualisieren. <a name="lambda-edge-how-it-works-tutorial-create-function-blueprint-proc"></a>

**So erstellen Sie eine Lambda-Funktion**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Lambda Konsole unter. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)
**Wichtig**  
Vergewissern Sie sich, dass Sie sich in der Region **US-East-1 (Nord-Virginia) AWS-Region (**US-East-1**)** befinden. Sie müssen sich in dieser Region befinden, um Lambda@Edge-Funktionen erstellen zu können.

1. Wählen Sie **Funktion erstellen**.

1. Wählen Sie auf der Seite **Funktion erstellen** die Option **Blueprint verwenden aus, und filtern Sie dann nach den CloudFront Blueprints**, indem Sie sie in das Suchfeld eingeben. **cloudfront**
**Anmerkung**  
CloudFront **Blueprints sind nur in der Region **US-East-1 (Nord-Virginia) (us-east-1)** verfügbar.**

1. Wählen Sie die Vorlage **HTTP-Antwortheader ändern** als Vorlage für Ihre Funktion.

1. Geben Sie folgende Informationen zu Ihrer Funktion ein:
   + **Funktionsname** – Geben Sie einen Namen für Ihre Funktion ein.
   + **Ausführungsrolle** – Wählen Sie, wie Sie die Berechtigungen für Ihre Funktion festlegen. Um die empfohlene Standardvorlage für Lambda @Edge -Berechtigungsrichtlinien zu verwenden, wählen Sie **Neue Rolle aus AWS Richtlinienvorlagen erstellen**.
   + **Rollenname** – Geben Sie einen Namen für die Rolle ein, die von der Richtlinienvorlage erstellt wird.
   + **Richtlinienvorlagen** — Lambda fügt automatisch die Richtlinienvorlage **Basic Lambda @Edge -Berechtigungen** hinzu, da Sie einen CloudFront Blueprint als Grundlage für Ihre Funktion ausgewählt haben. Diese Richtlinienvorlage fügt Ausführungsrollenberechtigungen hinzu, mit denen CloudFront Sie Ihre Lambda-Funktion CloudFront an Standorten auf der ganzen Welt für Sie ausführen können. Weitere Informationen finden Sie unter [Einrichten von IAM-Berechtigungen und -Rollen für Lambda@Edge](lambda-edge-permissions.md).

1. Wählen Sie unten auf der Seite **Funktion erstellen** aus.

1. Wählen Sie im daraufhin angezeigten Bereich **In Lambda@Edge bereitstellen** die Option **Abbrechen** aus. (Für dieses Tutorial müssen Sie den Funktionscode ändern, bevor Sie die Funktion in Lambda@Edge bereitstellen.)

1. Scrollen Sie nach unten bis zum Abschnitt **Code-Quelle**.

1. Ersetzen Sie den Vorlagencode durch eine Funktion, die die Sicherheits-Header ändert, die Ihren Ursprung zurückgibt. Beispielsweise könnten Sie Code wie den folgenden verwenden:

   ```
   'use strict';
   export const handler = (event, context, callback) => {
   
       //Get contents of response
       const response = event.Records[0].cf.response;
       const headers = response.headers;
   
       //Set new headers
       headers['strict-transport-security'] = [{key: 'Strict-Transport-Security', value: 'max-age= 63072000; includeSubdomains; preload'}];
       headers['content-security-policy'] = [{key: 'Content-Security-Policy', value: "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"}];
       headers['x-content-type-options'] = [{key: 'X-Content-Type-Options', value: 'nosniff'}];
       headers['x-frame-options'] = [{key: 'X-Frame-Options', value: 'DENY'}];
       headers['x-xss-protection'] = [{key: 'X-XSS-Protection', value: '1; mode=block'}];
       headers['referrer-policy'] = [{key: 'Referrer-Policy', value: 'same-origin'}];
   
       //Return modified response
       callback(null, response);
   };
   ```

1. Wählen Sie **Datei** und dann **Speichern** aus, um den aktualisierten Code zu speichern.

1. Wählen Sie **Bereitstellen**.

Fahren Sie mit dem nächsten Abschnitt fort, um einen CloudFront Trigger zum Ausführen der Funktion hinzuzufügen.

## Schritt 4: Fügen Sie einen CloudFront Trigger hinzu, um die Funktion auszuführen
<a name="lambda-edge-how-it-works-tutorial-add-trigger"></a>

Da Sie nun über eine Lambda-Funktion zum Aktualisieren von Sicherheitsheadern verfügen, konfigurieren Sie den CloudFront Trigger so, dass Ihre Funktion so ausgeführt wird, dass die Header zu jeder Antwort hinzugefügt werden, die vom Ursprung Ihrer Distribution CloudFront empfangen wird.<a name="lambda-edge-how-it-works-tutorial-add-trigger-proc"></a>

**Um den CloudFront Trigger für Ihre Funktion zu konfigurieren**

1. Wählen Sie in der Lambda-Konsole auf der Seite **Funktionsübersicht** Ihrer Funktion die Option **Auslöser hinzufügen** aus.

1. Wählen Sie für die **Trigger-Konfiguration **CloudFront****.

1. Wählen Sie **In Lambda@Edge bereitstellen** aus.

1. Geben **Sie im Bereich Deploy to Lambda @Edge** unter **Configure CloudFront trigger** die folgenden Informationen ein:
   + **Distribution** — Die CloudFront Distribution-ID, die Ihrer Funktion zugeordnet werden soll. Wählen Sie in der Dropdown-Liste die Distributions-ID aus.
   + **Cacheverhalten** – Das Cacheverhalten, das für den Auslöser verwendet werden soll. Behalten Sie in diesem Beispiel den Wert **\$1** bei, der das Standard-Cache-Verhalten Ihrer Verteilung bezeichnet. Weitere Informationen finden Sie unter [Einstellungen für das Cache-Verhalten](DownloadDistValuesCacheBehavior.md) im Thema [Referenz für alle Distributionseinstellungen](distribution-web-values-specify.md).
   + **CloudFront event** — Der Trigger, der angibt, wann Ihre Funktion ausgeführt wird. Wir möchten, dass die Security-Header-Funktion immer dann ausgeführt wird, wenn eine Antwort vom Ursprung CloudFront zurückgegeben wird. Wählen Sie in der Dropdown-Liste **Ursprungsantwort** aus. Weitere Informationen finden Sie unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md).

1. Aktivieren Sie das Kontrollkästchen **Bereitstellung in Lambda@Edge bestätigen**.

1. Wählen Sie **Deploy**, um den Trigger hinzuzufügen und die Funktion AWS an Standorten weltweit zu replizieren.

1. Warten Sie, bis die Funktion repliziert wurde. Dies dauert in der Regel mehrere Minuten.

    Sie können überprüfen, ob die Replikation abgeschlossen ist, indem Sie [die CloudFront-Konsole öffnen](https://console.aws.amazon.com/cloudfront/v4/home) und sich Ihre Verteilung ansehen. Warten Sie darauf, dass sich der Status der Distribution von **Wird bereitgestellt** in ein Datum und eine Uhrzeit ändert, was bedeutet, dass Ihre Funktion repliziert wurde. Zur Überprüfung der Funktionstätigkeit befolgen Sie die Schritte im nächsten Abschnitt.

## Schritt 5: Überprüfen, ob die Funktion funktioniert
<a name="lambda-edge-how-it-works-tutorial-verify"></a>

Nachdem Sie Ihre Lambda-Funktion erstellt und einen Trigger konfiguriert haben, um sie für eine CloudFront Distribution auszuführen, überprüfen Sie, ob die Funktion das leistet, was Sie von ihr erwarten. In diesem Beispiel überprüfen wir die von CloudFront zurückgegebenen HTTP-Header, um sicherzustellen, dass die Sicherheits-Header hinzugefügt werden.<a name="lambda-edge-how-it-works-tutorial-verify-proc"></a>

**Überprüfen, ob Ihre Lambda@Edge-Funktion Sicherheitsheader hinzufügt**

1. Geben Sie in einem Browser die URL für eine Datei in Ihrem S3-Bucket ein. Sie können beispielsweise eine URL wie die folgende Verwenden: `https://d111111abcdef8.cloudfront.net/image.jpg`.

   Weitere Informationen zum CloudFront Domainnamen, der in der Datei-URL verwendet werden soll, finden Sie unter. [Anpassen des URL-Formats für Dateien in CloudFront](LinkFormat.md)

1. Öffnen Sie die Web-Developer-Symbolleiste Ihres Browsers. Öffnen Sie beispielsweise in Ihrem Browserfenster in Chrome das Kontextmenü (Rechtsklick) und wählen Sie **Inspect (Untersuchen)** aus.

1. Wählen Sie die Registerkarte **Network (Netzwerk)** aus.

1. Laden Sie die Seite, um Ihr Image anzuzeigen, und wählen Sie dann auf der linken Seite eine HTTP-Anforderung. Sie sehen die HTTP-Header in einem separaten Fenster.

1. Sehen Sie sich die Liste der HTTP-Header an, um zu überprüfen, ob die erwarteten Sicherheitsheader in der Liste enthalten sind. Beispielsweise könnten Sie Header wie im folgenden Screenshot gezeigt sehen.  
![\[HTTP-Header-Liste, in der die erwarteten Sicherheitsheader gekennzeichnet sind.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/lambda-at-edge-security-headers-list.png)

Wenn die Sicherheitsheader in Ihrem Header-Liste enthalten sind, dann ist das hervorragend\$1 Sie haben erfolgreich Ihre erste Lambda@Edge-Funktion erstellt. Wenn CloudFront Rückgabefehler auftreten oder andere Probleme auftreten, fahren Sie mit dem nächsten Schritt fort, um die Probleme zu beheben.

## Schritt 6: Beheben von Problemen
<a name="lambda-edge-how-it-works-tutorial-troubleshoot"></a>

Wenn Fehler CloudFront zurückgegeben werden oder die Sicherheitsheader nicht wie erwartet hinzugefügt werden, können Sie die Ausführung Ihrer Funktion anhand von CloudWatch Protokollen untersuchen. Achten Sie darauf, die Protokolle zu verwenden, die an dem AWS Ort gespeichert sind, der dem Ort, an dem die Funktion ausgeführt wird, am nächsten liegt.

Wenn Sie sich die Datei beispielsweise von London aus ansehen, versuchen Sie, die Region in der CloudWatch Konsole auf Europa (London) zu ändern.<a name="lambda-edge-how-it-works-tutorial-cloudwatch-proc"></a>

**Überprüfen von CloudWatch -Protokollen für Ihre Lambda@Edge-Funktion**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Ändern Sie **Region** auf den Speicherort, der angezeigt wird, wenn Sie die Datei in Ihrem Browser anzeigen. Hier wird die Funktion ausgeführt.

1. Klicken Sie im linken Bereich auf **Logs (Protokolle)**, um die Protokolle für Ihre Verteilung anzuzeigen. 

Weitere Informationen finden Sie unter [Überwachen von CloudFront-Metriken mit Amazon CloudWatch](monitoring-using-cloudwatch.md).

## Schritt 7: Bereinigen der Ressourcen für Ihr Beispiel
<a name="lambda-edge-how-it-works-tutorial-cleanup-resources"></a>

Wenn Sie einen Amazon S3 S3-Bucket und eine CloudFront Distribution nur für dieses Tutorial erstellt haben, löschen Sie die AWS Ressourcen, die Sie zugewiesen haben, sodass keine Gebühren mehr anfallen. Nachdem Sie Ihre AWS Ressourcen gelöscht haben, sind alle Inhalte, die Sie hinzugefügt haben, nicht mehr verfügbar.

**Aufgaben**
+ [Löschen des S3-Buckets](#lambda-edge-how-it-works-tutorial-delete-bucket) 
+ [Löschen Sie die Lambda-Funktion](#lambda-edge-how-it-works-tutorial-delete-function)
+ [Löschen Sie die CloudFront Distribution](#lambda-edge-how-it-works-tutorial-delete-distribution)

### Löschen des S3-Buckets
<a name="lambda-edge-how-it-works-tutorial-delete-bucket"></a>

Bevor Sie Ihren Amazon S3-Bucket löschen, stellen Sie sicher, dass die Protokollierung für den Bucket deaktiviert ist. Andernfalls werden AWS weiterhin Logs in Ihren Bucket geschrieben, während Sie ihn löschen.<a name="lambda-edge-how-it-works-tutorial-delete-bucket-proc"></a>

**Deaktivieren Sie die Protokollierung für einen Bucket wie folgt:**

1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Wählen Sie den Bucket aus, und wählen Sie dann **Properties (Eigenschaften)**.

1. Wählen Sie unter **Properties (Eigenschaften)** **Logging (Protokollierung)** aus.

1. Deaktivieren Sie das Kontrollkästchen **Enabled (Aktiviert)**.

1. Wählen Sie **Save (Speichern)** aus.

Jetzt können Sie Ihren Bucket löschen. Weitere Informationen erhalten Sie unter [Löschen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) im *Amazon Simple Storage Service-Konsolenbenutzerhandbuch*.

### Löschen Sie die Lambda-Funktion
<a name="lambda-edge-how-it-works-tutorial-delete-function"></a>

Anleitungen zum Löschen der Zuweisung der Lambda-Funktion und optional der Funktion selbst finden Sie unter [Löschen von Lambda@Edge-Funktionen und Replikaten](lambda-edge-delete-replicas.md).

### Löschen Sie die CloudFront Distribution
<a name="lambda-edge-how-it-works-tutorial-delete-distribution"></a>

Bevor Sie eine CloudFront Distribution löschen, müssen Sie sie deaktivieren. Eine deaktivierte Verteilung funktioniert nicht mehr und es fallen keine weiteren Kosten für sie an. Sie können eine deaktivierte Verteilung jederzeit wieder aktivieren. Nachdem Sie eine deaktivierte Verteilung gelöscht haben, ist sie nicht länger verfügbar.<a name="lambda-edge-how-it-works-tutorial-delete-distribution-proc"></a>

**Um eine CloudFront Distribution zu deaktivieren und zu löschen**

1. Öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Klicken Sie mit der rechten Maustaste auf die Verteilung, die Sie deaktivieren möchten, und anschließend auf **Disable (Deaktivieren)**.

1. Wenn Sie zur Bestätigung aufgefordert werden, wählen Sie **Yes, Disable (Ja, deaktivieren)**.

1. Wählen Sie die deaktivierte Verteilung aus, und klicken Sie dann auf **Delete (Löschen)**.

1. Wenn Sie zur Bestätigung aufgefordert werden, wählen Sie **Yes, Delete**.

## Ähnliche Informationen
<a name="lambda-edge-how-it-works-tutorial-resources"></a>

Nun, da Sie eine grundlegende Vorstellung davon haben, wie Lambda@Edge-Funktionen funktionieren, können Sie hier weitere Informationen erhalten:
+ [Beispielfunktionen für Lambda@Edge](lambda-examples.md)
+ [Bewährte Methoden für das Lambda @Edge -Design](https://aws.amazon.com/blogs/networking-and-content-delivery/lambdaedge-design-best-practices/)
+ [Reduzierung der Latenz und Verlagerung von Rechenleistung an den Edge mit Lambda @Edge](https://aws.amazon.com/blogs/networking-and-content-delivery/reducing-latency-and-shifting-compute-to-the-edge-with-lambdaedge/)

# Einrichten von IAM-Berechtigungen und -Rollen für Lambda@Edge
<a name="lambda-edge-permissions"></a>

Um Lambda@Edge zu konfigurieren, benötigen Sie die folgenden IAM-Berechtigungen und -Rollen für AWS Lambda: 
+ [IAM-Berechtigungen](#lambda-edge-permissions-required) — Mit diesen Berechtigungen können Sie Ihre Lambda-Funktion erstellen und sie Ihrer CloudFront Distribution zuordnen.
+ [Eine Ausführungsrolle für die Lambda-Funktion](#lambda-edge-permissions-function-execution) (IAM-Rolle) – Die Lambda-Service-Prinzipale übernehmen diese Rolle, um die Funktion auszuführen.
+ [Dienstgebundene Rollen für Lambda @Edge](#using-service-linked-roles-lambda-edge) — Die dienstverknüpften Rollen ermöglichen es bestimmten, Lambda-Funktionen in Protokolldateien AWS-Services zu replizieren AWS-Regionen und deren Verwendung zu ermöglichen CloudWatch. CloudFront 

## IAM-Berechtigungen sind erforderlich, um Lambda @Edge -Funktionen mit Distributionen zu verknüpfen CloudFront
<a name="lambda-edge-permissions-required"></a>

Zusätzlich zu den IAM-Berechtigungen, die Sie für Lambda benötigen, benötigen Sie die folgenden Berechtigungen, um Lambda-Funktionen Distributionen zuzuordnen: CloudFront 
+ `lambda:GetFunction` – Gewährt die Berechtigung, Konfigurationsinformationen für die Lambda-Funktion und eine vorsignierte URL zum Herunterladen einer `.zip`-Datei abzurufen, die die Funktion enthält.
+ `lambda:EnableReplication*` – Gewährt die Berechtigung für die Ressourcenrichtlinie, sodass der Lambda-Replikationsservice den Code und die Konfiguration der Funktion abrufen kann.
+ `lambda:DisableReplication*` – Gewährt die Berechtigung für die Ressourcenrichtlinie, sodass der Lambda-Replikationsservice die Funktion löschen kann.
**Wichtig**  
Sie müssen das Sternchen (`*`) am Ende der Aktionen `lambda:EnableReplication*` und `lambda:DisableReplication*` hinzufügen.
+ Geben Sie für die Ressource den ARN der Funktionsversion an, die Sie ausführen möchten, wenn ein CloudFront Ereignis eintritt, wie im folgenden Beispiel:

  `arn:aws:lambda:us-east-1:123456789012:function:TestFunction:2`
+ `iam:CreateServiceLinkedRole`— Erteilt die Erlaubnis, eine serviceverknüpfte Rolle zu erstellen, in der Lambda @Edge Lambda-Funktionen repliziert. CloudFront Nachdem Sie Lambda@Edge zum ersten Mal konfiguriert haben, wird die serviceverknüpfte Rolle automatisch für Sie erstellt. Sie müssen diese Berechtigung nicht zu anderen Distributionen hinzufügen, die Lambda@Edge verwenden.

  
+ `cloudfront:UpdateDistribution` oder `cloudfront:CreateDistribution` – Gewährt die Berechtigung, eine Distribution zu aktualisieren oder zu erstellen.

Weitere Informationen finden Sie unter den folgenden Themen:
+ [Identity and Access Management für Amazon CloudFront](security-iam.md)
+ [Zugriffsberechtigungen für Lambda-Ressourcen](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) im *Entwicklerhandbuch für AWS Lambda *

## Funktionsausführungsrolle für Service-Prinzipale
<a name="lambda-edge-permissions-function-execution"></a>

Sie müssen eine IAM-Rolle erstellen, die die Service-Prinzipale `lambda.amazonaws.com` und `edgelambda.amazonaws.com` übernehmen können, wenn sie Ihre Funktion ausführen. 

**Tipp**  
Wenn Sie Ihre Funktion in der Lambda-Konsole erstellen, können Sie wählen, ob Sie mithilfe einer AWS Richtlinienvorlage eine neue Ausführungsrolle erstellen möchten. Dieser Schritt fügt *automatisch* die erforderlichen Lambda@Edge-Berechtigungen hinzu, um Ihre Funktion auszuführen. Siehe [Schritt 5 im Tutorial: Erstellen einer einfachen Lambda@Edge-Funktion](lambda-edge-how-it-works-tutorial.md#lambda-edge-how-it-works-tutorial-create-function).

Weitere Informationen zum manuellen Erstellen einer IAM-Rolle finden Sie unter [Erstellen von Rollen und Anfügen von Richtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) im *IAM-Benutzerhandbuch*.

**Example Beispiel: Rollenvertrauensrichtlinie**  
Diese Rolle können Sie unter der Registerkarte **Vertrauensstellung** in der IAM-Konsole hinzufügen. Fügen Sie diese Richtlinie nicht unter der Registerkarte **Berechtigungen** hinzu.    
****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement": [
      {
         "Effect": "Allow",
         "Principal": {
            "Service": [
               "lambda.amazonaws.com",
               "edgelambda.amazonaws.com"
            ]
         },
         "Action": "sts:AssumeRole"
      }
   ]
}
```

Weitere Informationen zu den Berechtigungen, die Sie der Ausführungsrolle erteilen müssen, finden Sie unter [Zugriffsberechtigungen für Lambda-Ressourcen](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) im *Entwicklerhandbuch für AWS Lambda *.

**Hinweise**  
Standardmäßig werden Daten in CloudWatch Logs geschrieben, wenn ein CloudFront Ereignis eine Lambda-Funktion auslöst. Wenn Sie diese Protokolle verwenden möchten, benötigt die Ausführungsrolle die Berechtigung, Daten in CloudWatch Logs zu schreiben. Sie können die vordefinierte AWSLambdaBasicExecutionRole verwenden, um der Ausführungsrolle die Berechtigung zu erteilen.  
Weitere Hinweise zu CloudWatch Protokollen finden Sie unter[Protokolle für Edge-Funktionen](edge-functions-logs.md).
Wenn Ihr Lambda-Funktionscode auf andere AWS Ressourcen zugreift, z. B. auf das Lesen eines Objekts aus einem S3-Bucket, benötigt die Ausführungsrolle die Erlaubnis, diese Aktion auszuführen. 

## Serviceverknüpfte Rollen für Lambda@Edge
<a name="using-service-linked-roles-lambda-edge"></a>

Lambda@Edge verwendet [serviceverknüpfte IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). Eine serviceverknüpfte Rolle ist ein spezieller Typ von IAM-Rolle, der direkt mit einem Service verknüpft ist. Serviceverknüpfte Rollen werden vom Service vorab definiert und beinhalten alle Berechtigungen, die dieser zum Aufrufen anderer AWS -Services in Ihrem Namen benötigt.

Lambda@Edge verwendet die folgenden serviceverknüpften IAM-Rollen:
+ **AWSServiceRoleForLambdaReplicator** – Lambda@Edge verwendet diese Rolle, um es Lambda@Edge zu ermöglichen, Funktionen in AWS-Regionen zu replizieren.

  Wenn Sie zum ersten Mal einen Lambda @Edge -Trigger hinzufügen CloudFront, AWSServiceRoleForLambdaReplicator wird automatisch eine Rolle mit dem Namen erstellt, damit Lambda @Edge Funktionen replizieren kann. AWS-Regionen Diese Rolle ist für die Verwendung von Lambda@Edge-Funktionen erforderlich. Die ARN für die Rolle AWSServiceRoleForLambdaReplicator sieht wie im folgenden Beispiel aus:

  `arn:aws:iam::123456789012:role/aws-service-role/replicator.lambda.amazonaws.com/AWSServiceRoleForLambdaReplicator`
+ **AWSServiceRoleForCloudFrontLogger**— CloudFront verwendet diese Rolle, um Protokolldateien in die Datei zu übertragen. CloudWatch Sie können Protokolldateien verwenden, um Lambda@Edge-Validierungsfehler zu beheben.

  Die AWSServiceRoleForCloudFrontLogger Rolle wird automatisch erstellt, wenn Sie eine Lambda @Edge -Funktionsassoziation hinzufügen, an die Lambda @Edge -Fehlerprotokolldateien übertragen werden können CloudFront . CloudWatch Der ARN für die AWSServiceRoleForCloudFrontLogger-Rolle sieht so aus:

  `arn:aws:iam::account_number:role/aws-service-role/logger.cloudfront.amazonaws.com/AWSServiceRoleForCloudFrontLogger`

Eine serviceverknüpfte Rolle vereinfacht das Einrichten und Verwenden von Lambda@Edge, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Lambda@Edge definiert die Berechtigungen seiner servicegebundenen Rollen. Nur Lambda@Edge kann die Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Sie können die Berechtigungsrichtlinie keiner anderen IAM-Entität zuordnen.

Sie müssen alle zugehörigen Ressourcen CloudFront oder Lambda @Edge -Ressourcen entfernen, bevor Sie eine serviceverknüpfte Rolle löschen können. Dies trägt zum Schutz Ihrer Lambda@Edge-Ressourcen bei, sodass Sie keine serviceverknüpfte Rolle entfernen, die noch für den Zugriff auf aktive Ressourcen erforderlich ist.

Weitere Informationen zu serviceverknüpften Rollen finden Sie unter [Dienstbezogene Rollen für CloudFront](security_iam_service-with-iam.md#security_iam_service-with-iam-roles-service-linked). 

### Serviceverknüpfte Rollenberechtigungen für Lambda@Edge
<a name="slr-permissions-lambda-edge"></a>

Lambda@Edge verwendet zwei servicegebundene Rollen. Diese heißen **AWSServiceRoleForLambdaReplicator** und **AWSServiceRoleForCloudFrontLogger**. In den folgenden Abschnitten werden die Berechtigungen für jede dieser Rollen beschrieben.

**Contents**
+ [

#### Serviceverknüpfte Rollenberechtigungen für Lambda Replicator
](#slr-permissions-lambda-replicator)
+ [

#### Berechtigungen für dienstverknüpfte Rollen für den Logger CloudFront
](#slr-permissions-cloudfront-logger)

#### Serviceverknüpfte Rollenberechtigungen für Lambda Replicator
<a name="slr-permissions-lambda-replicator"></a>

Diese serviceverknüpfte Rolle ermöglicht Lambda das Replizieren von Lambda@Edge-Funktionen zu AWS-Regionen.

Die serviceverknüpfte Rolle AWSServiceRoleForLambdaReplicator vertraut dem Service `replicator.lambda.amazonaws.com`, sodass dieser die Rolle annehmen kann.

Die Rollenberechtigungsrichtlinie erlaubt Lambda@Edge die Durchführung der folgenden Aktionen für die angegebenen Ressourcen:
+ `lambda:CreateFunction` auf `arn:aws:lambda:*:*:function:*`
+ `lambda:DeleteFunction` auf `arn:aws:lambda:*:*:function:*`
+ `lambda:DisableReplication` auf `arn:aws:lambda:*:*:function:*`
+ `iam:PassRole` auf `all AWS resources`
+  `cloudfront:ListDistributionsByLambdaFunction` auf `all AWS resources`

#### Berechtigungen für dienstverknüpfte Rollen für den Logger CloudFront
<a name="slr-permissions-cloudfront-logger"></a>

Diese dienstbezogene Rolle ermöglicht das CloudFront Pushen von Protokolldateien, CloudWatch sodass Sie Lambda @Edge -Validierungsfehler debuggen können.

Die serviceverknüpfte Rolle AWSServiceRoleForCloudFrontLogger vertraut dem Service `logger.cloudfront.amazonaws.com`, sodass dieser die Rolle annehmen kann.

Die Rollenberechtigungsrichtlinie erlaubt Lambda@Edge die Durchführung der folgenden Aktionen für die angegebene `arn:aws:logs:*:*:log-group:/aws/cloudfront/*`-Ressource:
+ `logs:CreateLogGroup` ``
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`

Sie müssen Berechtigungen konfigurieren, damit eine IAM-Entität (z. B. ein Benutzer, eine Gruppe oder eine Rolle) die mit dem Lambda@Edge-Service verknüpften Rollen löschen kann. Weitere Informationen finden Sie unter [serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.

### Serviceverknüpfte Rollen für Lambda@Edge erstellen
<a name="create-slr-lambda-edge"></a>

Servicegebundene Rollen für Lambda@Edge werden in der Regel nicht manuell erstellt. In den folgenden Szenarien legt der Service die Rollen für Sie automatisch an:
+ Wenn Sie zum ersten Mal einen Auslöser erstellen, erstellt der Service die Rolle AWSServiceRoleForLambdaReplicator (sofern sie nicht bereits vorhanden ist). Diese Rolle ermöglicht Lambda das Replizieren von Lambda@Edge-Funktionen in AWS-Regionen.

  Wenn Sie die serviceverknüpfte Rolle löschen, wird die Rolle erneut erstellt, wenn Sie einen neuen Auslöser für Lambda@Edge in einer Verteilung hinzufügen.
+ Wenn Sie eine CloudFront Distribution aktualisieren oder erstellen, die über eine Lambda @Edge -Zuordnung verfügt, erstellt der Dienst die AWSServiceRoleForCloudFrontLogger Rolle (sofern die Rolle noch nicht vorhanden ist). Diese Rolle ermöglicht es CloudFront , Ihre Protokolldateien per Push zu CloudWatch übertragen.

  Wenn Sie die dienstverknüpfte Rolle löschen, wird die Rolle erneut erstellt, wenn Sie eine CloudFront Distribution aktualisieren oder erstellen, die über eine Lambda @Edge -Zuordnung verfügt.

Um diese dienstbezogenen Rollen manuell zu erstellen, können Sie die folgenden Befehle AWS Command Line Interface ()AWS CLI ausführen:

**So erstellen Sie die AWSServiceRoleForLambdaReplicator-Rolle**
+ Führen Sie den folgenden Befehl aus.

  ```
  aws iam create-service-linked-role --aws-service-name replicator.lambda.amazonaws.com
  ```

**So erstellen Sie die AWSServiceRoleForCloudFrontLogger-Rolle**
+ Führen Sie den folgenden Befehl aus.

  ```
  aws iam create-service-linked-role --aws-service-name logger.cloudfront.amazonaws.com
  ```

### Bearbeiten von serviceverknüpften Lambda@Edge-Rollen
<a name="edit-slr-lambda-edge"></a>

Lambda@Edge verhindert die Bearbeitung der serviceverknüpften Rollen AWSServiceRoleForLambdaReplicator und AWSServiceRoleForCloudFrontLogger. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach der Erstellung einer serviceverknüpften Rolle durch den Service nicht bearbeitet werden. Sie können mithilfe von IAM jedoch die Beschreibung der Rolle bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.

### Unterstützt AWS-Regionen für dienstverknüpfte Lambda @Edge -Rollen
<a name="slr-regions-lambda-edge"></a>

CloudFront unterstützt die Verwendung von dienstverknüpften Rollen für Lambda @Edge im Folgenden: AWS-Regionen
+ USA Ost (Nord-Virginia) – `us-east-1`
+ USA Ost (Ohio) – `us-east-2`
+ USA West (Nordkalifornien) – `us-west-1`
+ USA West (Oregon) – `us-west-2`
+ Asia Pacific (Mumbai) – `ap-south-1`
+ Asien-Pazifik (Seoul) – `ap-northeast-2`
+ Asia Pacific (Singapore) – `ap-southeast-1`
+ Asien-Pazifik (Sydney) – `ap-southeast-2`
+ Asien-Pazifik (Tokio) – `ap-northeast-1`
+ Europa (Frankfurt) – `eu-central-1`
+ Europa (Ireland) – `eu-west-1`
+ Europa (London) – `eu-west-2`
+ South America (São Paulo) – `sa-east-1`

# Schreiben und Erstellen einer Lambda@Edge-Funktion
<a name="lambda-edge-create-function"></a>

Um Lambda@Edge zu verwenden, *schreiben* Sie den Code für Ihre AWS Lambda -Funktion. Weitere Informationen zum Schreiben von Lambda@Edge-Funktionen finden Sie in den folgenden Ressourcen:
+  [Lambda@Edge-Ereignisstruktur](lambda-event-structure.md) – Informationen zur Ereignisstruktur, die Sie für Lambda@Edge verwenden
+ [Beispielfunktionen für Lambda@Edge](lambda-examples.md)— Beispielfunktionen wie A/B Testen und Generieren einer HTTP-Umleitung.

Das Programmiermodell für die Verwendung von Node.js mit Lambda@Edge entspricht der Verwendung von Lambda in einer AWS-Region. Weitere Informationen finden Sie unter [Erstellen von Lambda-Funktionen mit Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) oder [Erstellen von Lambda-Funktionen mit Python](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) im *Entwicklerhandbuch für AWS Lambda *.

Nehmen Sie in Ihre Lambda@Edge-Funktion den `callback`-Parameter auf und geben Sie das entsprechende Objekt für Anforderung- oder Antwortereignisse zurück:
+ **Request events (Anfrageereignisse)** – Schließen Sie das `cf.request`-Objekt in die Antwort ein.

  Wenn Sie eine Antwort generieren, schließen Sie das Objekt `cf.response` in die Antwort ein. Weitere Informationen finden Sie unter [Generieren von HTTP-Antworten in Anforderungsauslösern](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests). 
+ **Response events (Antwortereignisse)**: Schließen Sie das `cf.response`-Objekt in die Antwort ein.

Nachdem Sie Ihren eigenen Code geschrieben oder eines der Beispiele verwendet haben, erstellen Sie die Funktion in Lambda. Informationen zum Erstellen oder Bearbeiten einer vorhandenen Funktion finden Sie in den folgenden Themen:

**Topics**
+ [

# Erstellen einer Lambda@Edge-Funktion
](lambda-edge-create-in-lambda-console.md)
+ [

# Bearbeiten einer Lambda-Funktion
](lambda-edge-edit-function.md)

 *Nachdem Sie die Funktion in Lambda erstellt haben, richten Sie Lambda so ein, dass die Funktion auf der Grundlage bestimmter CloudFront Ereignisse ausgeführt wird, die als Trigger bezeichnet werden.* Weitere Informationen finden Sie unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md).

# Erstellen einer Lambda@Edge-Funktion
<a name="lambda-edge-create-in-lambda-console"></a>

Gehen Sie wie folgt vor AWS Lambda , um die Ausführung von Lambda-Funktionen einzurichten, die auf CloudFront Ereignissen basieren.<a name="lambda-edge-create-function-procedure"></a>

**So erstellen Sie eine Lambda@Edge-Funktion**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Lambda Konsole unter [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Wenn Sie bereits über eine oder mehrere Lambda-Funktionen verfügen, wählen Sie **Create function**.

   Wenn Sie nicht über Funktionen verfügen, wählen Sie **Get Started Now**.

1. Wählen Sie oben auf der Seite in der Liste „Region“ die Option **US Ost (Nord-Virginia)** aus.

1. Erstellen Sie eine Funktion mit Ihrem eigenen Code oder erstellen Sie eine Funktion, die mit einer CloudFront -Vorlage beginnt.
   + Um eine Funktion mit Ihrem eigenen Code zu erstellen, wählen Sie **Author from scratch**. 
   + **Um eine Liste mit Blueprints für anzuzeigen CloudFront, geben Sie **Cloudfront** in das Filterfeld ein und wählen Sie dann Enter.**

     Wenn Sie eine dieser Vorlagen verwenden möchten, wählen Sie den Namen der entsprechenden Vorlage.

1. Geben Sie im Abschnitt **Basic information** folgende Werte ein:

   1. **Name** – Geben Sie einen Namen für die Funktion ein.

   1. **Rolle** – Um schnell loszulegen, wählen Sie **Neue Rolle aus Vorlage(n) erstellen**. Sie können auch **Vorhandene Rolle auswählen** oder **Benutzerdefinierte Rolle erstellen** auswählen und dann den Prompts folgen, um die Informationen für diesen Abschnitt zu vervollständigen.

   1. **Rollenname** – Geben Sie einen Namen für die Rolle ein.

   1. **Richtlinienvorlagen** – Wählen Sie **Grundlegende Edge-Lambda-Berechtigungen** aus.

1. Wenn Sie in Schritt 4 **Author from scratch** gewählt haben, fahren Sie mit Schritt 7 fort.

   Wenn Sie in Schritt 4 einen Blueprint ausgewählt haben, können Sie im Abschnitt **Cloudfront** einen Trigger erstellen, der diese Funktion einem Cache in einer CloudFront Verteilung und einem Ereignis zuordnet. CloudFront Wir empfehlen, an dieser Stelle **Remove** zu wählen, damit es bei der Erstellung der Funktionen keinen Auslöser gibt. Sie können Auslöser zu einem späteren Zeitpunkt hinzufügen. 
**Tipp**  
Wir empfehlen Ihnen, die Funktion zu testen und zu debuggen, bevor Sie Auslöser hinzufügen. Wenn Sie jetzt einen Trigger hinzufügen, wird die Funktion ausgeführt, sobald Sie die Funktion erstellt haben. Die Replikation an AWS Standorte auf der ganzen Welt ist abgeschlossen und die entsprechende Distribution wird bereitgestellt.

1. Wählen Sie **Funktion erstellen**.

   Lambda erstellt zwei Versionen Ihrer Funktion: \$1LATEST und Version 1. Sie können nur die Version \$1LATEST bearbeiten, die Konsole zeit jedoch zunächst Version 1 an.

1. Um die Funktion zu bearbeiten, wählen Sie **Version 1** oben auf der Seite, unter dem ARN für die Funktion. Wählen Sie anschließend auf der Registerkarte **Versions** die Option **\$1LATEST**. (Wenn Sie die Funktion verlassen haben und anschließend zurückgekehrt sind, lautet die Bezeichnung der Schaltfläche **Qualifiers**.)

1. Wählen Sie auf der Registerkarte **Configuration** den geeigneten Wert für **Code entry type**. Folgen Sie dann den Eingabeaufforderungen, um Ihren Code zu bearbeiten oder hochzuladen.

1. Wählen Sie den Wert für **Runtime (Laufzeit)** basierend auf dem Code der Funktion.

1. Fügen Sie im Bereich **Tags** geeignete Tags hinzu.

1. Wählen Sie **Actions** und dann **Publish new version**.

1. Geben Sie eine Beschreibung für die neue Version der Funktion ein.

1. Wählen Sie **Publish**.

1. Testen und debuggen Sie die Funktion. Weitere Informationen zu den Tests in der Lambda-Konsole finden Sie unter [Aufrufen einer Lambda-Funktion mit der Konsole](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) im *Entwicklerhandbuch für AWS Lambda *.

1. Wenn Sie bereit sind, die Funktion für CloudFront Ereignisse auszuführen, veröffentlichen Sie eine weitere Version und bearbeiten Sie die Funktion, um Trigger hinzuzufügen. Weitere Informationen finden Sie unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md).

# Bearbeiten einer Lambda-Funktion
<a name="lambda-edge-edit-function"></a>

Nachdem Sie eine Lambda@Edge-Funktion erstellt haben, können Sie sie anhand der Lambda-Konsole bearbeiten.

**Hinweise**  
Die Originalversion ist mit \$1LATEST gekennzeichnet.
Sie können nur die \$1LATEST-Version bearbeiten.
Jedes Mal, wenn Sie die \$1LATEST-Version bearbeiten, müssen Sie eine neue nummerierte Version veröffentlichen.
Sie können keine Auslöser für \$1LATEST erstellen.
Wenn Sie eine neue Version einer Funktion veröffentlichen, kopiert Lambda nicht automatisch Auslöser von der vorherigen Version zur neuen Version. Sie müssen die Auslöser für die neue Version reproduzieren. 
Wenn Sie einer Funktion einen Trigger für ein CloudFront Ereignis hinzufügen und es bereits einen Trigger für dieselbe Verteilung, dasselbe Cache-Verhalten und dasselbe Ereignis für eine frühere Version derselben Funktion gibt, löscht Lambda den Trigger aus der früheren Version.
Nachdem Sie Aktualisierungen an einer CloudFront Verteilung vorgenommen haben, z. B. Trigger hinzugefügt haben, müssen Sie warten, bis die Änderungen an den Edge-Standorten wirksam werden, bevor die Funktionen, die Sie in den Triggern angegeben haben, funktionieren.<a name="lambda-edge-edit-function-procedure"></a>

**So bearbeiten Sie eine Lambda-Funktion**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Lambda Konsole unter [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Wählen Sie oben auf der Seite in der Liste „Region“ die Option **US Ost (Nord-Virginia)** aus.

1. Wählen Sie in der Liste der Funktionen den Namen der Funktion aus.

   Die Konsole zeigt standardmäßig die \$1LATEST-Version an. Sie können frühere Versionen anzeigen (wählen Sie **Qualifiers**), aber Sie können nur \$1LATEST bearbeiten.

1. Wählen Sie auf der Registerkarte **Code** für **Code entry type (Code-Eingabetyp)** die Bearbeitung des Codes im Browser, laden Sie eine .zip-Datei hoch oder laden Sie eine Datei aus Amazon S3 hoch.

1. Wählen Sie entweder **Save** oder **Save and test**.

1. Wählen Sie **Actions** und **Publish new version**. 

1. Geben Sie im Dialogfeld **Publish new version from \$1LATEST** eine Beschreibung der neuen Version ein. Diese Beschreibung wird in der Liste der Versionen zusammen mit einer automatisch generierten Versionsnummer angezeigt. 

1. Wählen Sie **Publish**.

   Die neue Version wird automatisch die aktuelle Version. Die Versionsnummer wird unter **Version** oben links auf der Seite angezeigt.
**Anmerkung**  
Wenn Sie noch keine Auslöser für die Funktion hinzugefügt haben, finden Sie Informationen hierzu unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md). 

1. Wählen Sie die Registerkarte **Triggers**.

1. Wählen Sie **Add trigger**.

1. Wählen Sie im Dialogfeld **Add trigger** das Feld mit Punkten und dann **CloudFront**.
**Anmerkung**  
Wenn Sie bereits einen oder mehrere Auslöser für eine Funktion erstellt haben, CloudFront ist dies der Standarddienst.

1. Geben Sie die folgenden Werte an, um anzugeben, wann die Lambda-Funktion ausgeführt werden soll.

   1. **Distributions-ID** – Wählen Sie die ID der Distribution, der Sie den Auslöser hinzufügen möchten.

   1. **Cacheverhalten** – Wählen Sie das Cacheverhalten, das die Objekte angibt, für die Sie die Funktion ausführen möchten.

   1. **CloudFront Ereignis** — Wählen Sie das CloudFront Ereignis aus, das die Ausführung der Funktion veranlasst.

   1. **Auslöser aktivieren und replizieren** – Markieren Sie dieses Kontrollkästchen, sodass Lambda die Funktionen in AWS-Regionen weltweit repliziert.

1. Wählen Sie **Absenden** aus.

1. Um weitere Auslöser für diese Funktion hinzuzufügen, wiederholen Sie die Schritte 10 bis 13.

Weitere Informationen zum Testen und Debuggen der Funktion in der Lambda-Konsole finden Sie unter [Aufrufen einer Lambda-Funktion mit der Konsole](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) im *Entwicklerhandbuch für AWS Lambda *.

Wenn Sie bereit sind, die Funktion bei CloudFront Ereignissen ausführen zu lassen, veröffentlichen Sie eine weitere Version und bearbeiten Sie die Funktion, um Auslöser hinzuzufügen. Weitere Informationen finden Sie unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md).

# Hinzufügen von Auslösern für eine Lambda@Edge-Funktion
<a name="lambda-edge-add-triggers"></a>

Ein Lambda @Edge -Trigger ist eine Kombination aus einer CloudFront Verteilung, einem Cache-Verhalten und einem Ereignis, das die Ausführung einer Funktion bewirkt. Sie können beispielsweise einen Trigger erstellen, der bewirkt, dass die Funktion ausgeführt wird, wenn von einem Viewer eine Anfrage für ein bestimmtes Cache-Verhalten CloudFront empfangen wird, das Sie für Ihre Distribution eingerichtet haben. Sie können einen oder mehrere CloudFront Trigger angeben. 

**Tipp**  
Wenn Sie eine CloudFront Verteilung erstellen, geben Sie Einstellungen an, die festlegen, CloudFront wie auf unterschiedliche Anfragen reagiert werden soll. Die Standardeinstellungen werden als *Standard-Cacheverhalten* für die Distribution bezeichnet. Sie können zusätzliche Cache-Verhaltensweisen einrichten, die definieren, wie unter bestimmten Umständen CloudFront reagiert wird, z. B. wenn eine Anfrage für einen bestimmten Dateityp empfangen wird. Weitere Informationen finden Sie unter [Einstellungen für das Cache-Verhalten](DownloadDistValuesCacheBehavior.md).

Wenn Sie eine Lambda-Funktion neu erstellen, können Sie nur *einen* Auslöser angeben. Sie können derselben Funktion später weitere Trigger hinzufügen, indem Sie die Lambda-Konsole verwenden oder die Verteilung in der CloudFront Konsole bearbeiten.
+ Die Lambda-Konsole funktioniert gut, wenn Sie einer Funktion für dieselbe CloudFront Distribution weitere Trigger hinzufügen möchten.
+ Die CloudFront Konsole kann besser sein, wenn Sie Trigger für mehrere Distributionen hinzufügen möchten, da es einfacher ist, die Distribution zu finden, die Sie aktualisieren möchten. Sie können auch andere CloudFront Einstellungen gleichzeitig aktualisieren.

**Topics**
+ [

# CloudFront Ereignisse, die eine Lambda @Edge -Funktion auslösen können
](lambda-cloudfront-trigger-events.md)
+ [

# Auswählen des Ereignisses zur Auslösung der Funktion
](lambda-how-to-choose-event.md)
+ [

# Hinzufügen von Auslösern zu einer Lambda@Edge-Funktion
](lambda-edge-add-triggers-console.md)

# CloudFront Ereignisse, die eine Lambda @Edge -Funktion auslösen können
<a name="lambda-cloudfront-trigger-events"></a>

Für jedes Cache-Verhalten in einer CloudFront Amazon-Distribution können Sie bis zu vier Trigger (Assoziationen) hinzufügen, die bewirken, dass eine Lambda-Funktion ausgeführt wird, wenn bestimmte CloudFront Ereignisse eintreten. CloudFront Trigger können auf einem von vier CloudFront Ereignissen basieren, wie in der folgenden Abbildung dargestellt.

![\[Konzeptgrafik, die zeigt, wie CloudFront Triggerereignisse für Lambda-Funktionen in integriert CloudFront werden.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png)


Die folgenden CloudFront Ereignisse können verwendet werden, um Lambda @Edge -Funktionen auszulösen:

**Viewer-Anforderung**  
Die Funktion wird ausgeführt, wenn sie eine Anfrage von einem Viewer CloudFront erhält, bevor sie überprüft, ob sich das angeforderte Objekt im CloudFront Cache befindet.  
Die Funktion wird in den folgenden Fällen nicht ausgeführt:  
+ beim Abrufen einer benutzerdefinierten Fehlerseite
+ Wenn eine HTTP-Anfrage CloudFront automatisch an HTTPS umgeleitet wird (wenn der Wert von **Redirect HTTP to HTTPS [Viewer-Protokollrichtlinien](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)** lautet).

**Ursprungsanfrage**  
Die Funktion wird *nur* ausgeführt, wenn eine Anfrage an Ihren Ursprung CloudFront weitergeleitet wird. Wenn sich das angeforderte Objekt im CloudFront Cache befindet, wird die Funktion nicht ausgeführt.

**Ursprungsantwort**  
Die Funktion wird ausgeführt, nachdem CloudFront sie eine Antwort vom Ursprung erhalten hat und bevor das Objekt in der Antwort zwischengespeichert wird. Beachten Sie, dass die Funktion auch dann ausgeführt wird, wenn ein Fehler vom Ursprung zurückgegeben wird.  
Die Funktion wird in den folgenden Fällen nicht ausgeführt:  
+ Wenn sich die angeforderte Datei im CloudFront Cache befindet und nicht abgelaufen ist.
+ Wenn die Antwort von einer Funktion generiert wird, die von einem Ursprungs-Anforderungsereignis ausgelöst wurde.

**Viewer-Antwort**  
Diese Funktion wird ausgeführt, bevor die angeforderte Datei an den Viewer zurückgegeben wird. Beachten Sie, dass die Funktion unabhängig davon ausgeführt wird, ob sich die Datei bereits im CloudFront Cache befindet.  
Die Funktion wird in den folgenden Fällen nicht ausgeführt:  
+ Wenn der Ursprung den HTTP-Statuscode „400“ oder höher zurückgibt.
+ Wenn eine benutzerdefinierte Fehlerseite zurückgesendet wird.
+ Wenn die Antwort von einer Funktion generiert wird, die von einem Viewer-Anforderungsereignis ausgelöst wurde.
+ Wenn eine HTTP-Anfrage CloudFront automatisch an HTTPS umgeleitet wird (wenn der Wert von „**HTTP zu HTTPS umleiten**“ [Viewer-Protokollrichtlinien](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) lautet).

Wenn Sie einem Cache-Verhalten mehrere Auslöser hinzufügen, können diese jeweils dieselbe oder verschiedene Funktionen für jeden Auslöser ausführen. Sie können Funktionen auch in mehreren Verteilungen zuweisen.

**Anmerkung**  
Wenn ein CloudFront Ereignis die Ausführung einer Lambda-Funktion auslöst, muss die Funktion beendet werden, *bevor sie* fortgesetzt CloudFront werden kann.   
Wenn beispielsweise eine Lambda-Funktion durch ein CloudFront Viewer-Anforderungsereignis ausgelöst CloudFront wird, gibt sie keine Antwort an den Betrachter zurück und leitet die Anfrage nicht an den Ursprung weiter, bis die Lambda-Funktion vollständig ausgeführt wurde.   
Dies bedeutet, dass jede Anforderung, die eine Lambda-Funktion auslöst, die Latenz für die Anforderung erhöht. Daher sollte die Funktion so schnell wie möglich arbeiten.

# Auswählen des Ereignisses zur Auslösung der Funktion
<a name="lambda-how-to-choose-event"></a>

Wenn Sie entscheiden, welches CloudFront Ereignis Sie verwenden möchten, um eine Lambda-Funktion auszulösen, sollten Sie Folgendes berücksichtigen:

**Ich CloudFront möchte Objekte zwischenspeichern, die durch eine Lambda-Funktion geändert wurden**  
Um ein Objekt zwischenzuspeichern, das durch eine Lambda-Funktion geändert wurde, CloudFront sodass es bei der nächsten Anforderung vom Edge-Standort aus bedient werden kann, verwenden Sie die *Origin-Anfrage oder das *Origin-Response-Ereignis**.   
Dadurch verringert sich die Verarbeitungslast für den Ursprung, die Latenz für nachfolgende Anforderungen wird verringert und die Kosten für den Aufruf von Lambda@Edge für nachfolgende Anforderungen reduziert.  
Wenn Sie beispielsweise Header für Objekte hinzufügen, entfernen oder ändern möchten, die vom Ursprung zurückgegeben werden, und Sie das Ergebnis zwischenspeichern CloudFront möchten, verwenden Sie das Origin-Response-Ereignis.

**Die Funktion soll für jede Anforderung ausgeführt werden**  
Um die Funktion für jede Anforderung auszuführen, die für die Verteilung CloudFront eingeht, verwenden Sie die *Viewer-Anforderung oder die *Viewer-Antwortereignisse**.   
Origin-Request- und Origin-Response-Ereignisse treten nur auf, wenn ein angefordertes Objekt nicht an einem Edge-Standort zwischengespeichert ist und eine Anfrage an den Ursprung CloudFront weiterleitet.

**Die Funktion soll den Cache-Schlüssel ändern**  
Um einen Wert zu ändern, den Sie als Grundlage für das Zwischenspeichern verwenden, wählen Sie das Ereignis *Viewer-Anforderung*.   
Wenn beispielsweise eine Funktion eine URL so ändert, dass Abkürzungen für die Sprachversionen in den Pfad eingebunden werden (zum Beispiel, weil der Benutzer seine Sprache aus einer Dropdown-Liste ausgewählt hat), verwenden Sie das Viewer-Anfrageereignis:  
+ **URL in der Viewer-Anfrage** — index.html https://example.com/en/
+ **URL, wenn die Anfrage von einer IP-Adresse in Deutschland kommt** — https://example.com/de/ index.html
Sie können Viewer-Anfrageereignisse auch verwenden, wenn die Zwischenspeicherung auf der Basis von Cookies oder Anfrageereignissen erfolgt.  
Wenn die Funktion Cookies oder Header ändert, konfigurieren Sie CloudFront sie so, dass der entsprechende Teil der Anfrage an den Ursprung weitergeleitet wird. Weitere Informationen finden Sie unter den folgenden Themen:  
+ [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md)
+ [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md)

**Die Funktion wirkt sich auf die Antwort vom Ursprung aus**  
Um die Anforderung so zu verändern, dass sich die Antwort vom Ursprung ändert, verwenden Sie das Ereignis *Ursprungsanforderung*.   
In der Regel werden die meisten Ereignisse mit Zuschaueranfragen nicht an den Absender weitergeleitet. CloudFront reagiert auf eine Anfrage mit einem Objekt, das sich bereits im Edge-Cache befindet. Wenn die Funktion die Anfrage auf der Grundlage eines ursprünglichen Anforderungsereignisses ändert, CloudFront speichert sie die Antwort auf die geänderte ursprüngliche Anfrage im Cache.

# Hinzufügen von Auslösern zu einer Lambda@Edge-Funktion
<a name="lambda-edge-add-triggers-console"></a>

Sie können die AWS Lambda Konsole oder die CloudFront Amazon-Konsole verwenden, um Ihrer Lambda @Edge -Funktion einen Trigger hinzuzufügen.

**Wichtig**  
Sie können Auslöser nur für nummerierte Versionen Ihrer Funktion erstellen (nicht für **\$1LATEST**).

------
#### [ Lambda console ]<a name="lambda-edge-add-triggers-procedure"></a>

**Um Trigger für CloudFront Ereignisse zu einer Lambda @Edge -Funktion hinzuzufügen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Lambda Konsole unter [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Wählen Sie oben auf der Seite in der Liste „Region“ die Option **US Ost (Nord-Virginia)** aus.

1. Wählen Sie auf der Seite **Functions** den Namen der Funktion, für die Sie Auslöser hinzufügen möchten.

1. Wählen Sie auf der Seite **Funktionsübersicht** die Registerkarte **Versionen** aus.

1. Wählen Sie die Version, der Sie Auslöser hinzufügen möchten.

   Nach der Wahl einer Version ändert sich der Name der Schaltfläche in **Version: \$1LATEST** oder **Version:** *Versionsnummer*.

1. Wählen Sie die Registerkarte **Triggers**.

1. Wählen Sie **Add trigger**.

1. Wählen Sie für die **Trigger-Konfiguration** die Option **Quelle auswählen****cloudfront**, geben Sie die Eingabetaste ein und wählen Sie dann **CloudFront**.
**Anmerkung**  
Wenn Sie bereits einen oder mehrere Auslöser erstellt haben, CloudFront ist dies der Standarddienst.

1. Geben Sie die folgenden Werte an, um anzugeben, wann die Lambda-Funktion ausgeführt werden soll.

   1. **Distribution** – Wählen Sie die Distribution aus, der Sie den Auslöser hinzufügen möchten.

   1. **Cacheverhalten** – Wählen Sie das Cacheverhalten, das die Objekte angibt, für die Sie die Funktion ausführen möchten.
**Anmerkung**  
Wenn Sie `*` für das Zwischenspeicher-Verhalten angeben, stellt die Lambda-Funktion das Standard-Zwischenspeicher-Verhalten bereit.

   1. **CloudFront Ereignis** — Wählen Sie das CloudFront Ereignis aus, das die Ausführung der Funktion veranlasst.

   1. **Text einschließen** – Aktivieren Sie dieses Kontrollkästchen, wenn Sie auf den Anforderungstext in Ihrer Funktion zugreifen möchten. 

   1. **Bereitstellung in Lambda@Edge bestätigen** – Aktivieren Sie dieses Kontrollkästchen, sodass AWS Lambda die Funktion in AWS-Regionen weltweit repliziert.

1. Wählen Sie **Hinzufügen** aus.

   Die Funktion beginnt mit der Verarbeitung von Anfragen für die angegebenen CloudFront Ereignisse, wenn die aktualisierte CloudFront Distribution bereitgestellt wird. Um zu ermitteln, ob eine Verteilung bereitgestellt ist, wählen Sie im Navigationsbereich die Option **Distributions**. Wenn eine Distribution bereitgestellt ist, ändert sich der Wert in der Spalte **Status** für die Distribution von **Wird bereitgestellt** in das Datum und die Uhrzeit der Bereitstellung.

------
#### [ CloudFront console ]<a name="lambda-create-functions-add-triggers-cloudfront-console-procedure"></a>

**Um Trigger für CloudFront Ereignisse zu einer Lambda @Edge -Funktion hinzuzufügen**

1. Rufen Sie den ARN der Lambda-Funktion ab, der Sie Auslöser hinzufügen möchten:

   1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Lambda Konsole unter [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

   1. Wählen Sie in der Liste der Regionen oben auf der Seite die Option **USA Ost (Nord-Virginia)**.

   1. Wählen Sie in der Liste der Funktionen den Namen der Funktion, der Sie Auslöser hinzufügen möchten.

   1. Wählen Sie auf der Seite **Funktionsübersicht** die Registerkarte **Versionen** und dann die nummerierte Version aus, der Sie Auslöser hinzufügen möchten.

   1. Wählen Sie die Schaltfläche **ARN kopieren**, um den ARN in Ihre Zwischenablage zu kopieren. Der ARN für die Lambda-Funktion sieht wie folgt aus:

      `arn:aws:lambda:us-east-1:123456789012:function:TestFunction:2`

      Die Nummer am Ende (**2** in diesem Beispiel) ist die Versionsnummer der Funktion.

1. Öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Wählen Sie in der Liste der Verteilungen die ID der Verteilung aus, der Sie Auslöser hinzufügen möchten.

1. Wählen Sie die Registerkarte **Behaviors** aus.

1. Wählen Sie das Cacheverhalten, dem Sie Auslöser hinzufügen möchten, und dann **Bearbeiten** aus.

1. Wählen Sie unter **Funktionszuordnungen** in der Liste **Funktionstyp** die Option **Lambda@Edge** aus, wenn die Funktion bei Viewer-Anforderungen, Viewer-Antworten, Ursprungsanforderungen oder Ursprungsantworten ausgeführt werden soll. 

   Weitere Informationen finden Sie unter [Auswählen des Ereignisses zur Auslösung der Funktion](lambda-how-to-choose-event.md).

1. Fügen Sie in das Textfeld **Funktions-ARN/Name** den ARN der Lambda-Funktion ein, die ausgeführt werden soll, wenn das ausgewählte Ereignis eintritt. Dies ist der Wert, den Sie aus der Lambda-Konsole kopiert haben.

1. Wählen Sie **Text einschließen** aus, wenn Sie auf den Anforderungstext in Ihrer Funktion zugreifen möchten.

   Wenn Sie nur den Anforderungstext ersetzen möchten, müssen Sie diese Option nicht auswählen.

1. Wenn dieselbe Funktion für mehrere Ereignistypen ausgeführt werden soll, wiederholen Sie die Schritte 6 und 7.

1. Wählen Sie **Änderungen speichern ** aus.

1. Um Trigger zu weiteren Cache-Verhaltensweisen für diese Verteilung hinzuzufügen, wiederholen Sie die Schritte 5 bis 10.

   Die Funktion beginnt mit der Verarbeitung von Anfragen für die angegebenen CloudFront Ereignisse, wenn die aktualisierte CloudFront Distribution bereitgestellt wird. Um zu ermitteln, ob eine Verteilung bereitgestellt ist, wählen Sie im Navigationsbereich die Option **Distributions**. Wenn eine Distribution bereitgestellt ist, ändert sich der Wert in der Spalte **Status** für die Distribution von **Wird bereitgestellt** in das Datum und die Uhrzeit der Bereitstellung.

------

# Testen und Debuggen von Lambda@Edge-Funktionen
<a name="lambda-edge-testing-debugging"></a>

Es ist wichtig, dass Sie Ihren Lambda @Edge -Funktionscode eigenständig testen, um sicherzustellen, dass er die beabsichtigte Aufgabe erfüllt, und Integrationstests durchzuführen, um sicherzustellen, dass die Funktion korrekt funktioniert. CloudFront 

Während des Integrationstests oder nach der Bereitstellung Ihrer Funktion müssen Sie möglicherweise Fehler wie HTTP CloudFront 5xx-Fehler debuggen. Fehler können eine ungültige Antwort der Lambda-Funktion, Ausführungsfehler beim Auslösen der Funktion oder Fehler aufgrund einer Ablehnung der Ausführung durch den Lambda-Service sein. Die Abschnitte in diesem Thema enthalten Strategien, um festzustellen, welche Art von Fehler das Problem verursacht. Dazu finden Sie Schritte, die Sie unternehmen können, um das Problem zu beheben.

**Anmerkung**  
Achten Sie bei der Überprüfung von CloudWatch Protokolldateien oder Metriken bei der Behebung von Fehlern darauf, dass diese an dem Ort angezeigt oder gespeichert werden, der dem Ort, an dem die Funktion ausgeführt wurde, AWS-Region am nächsten ist. Wenn Sie also eine Website oder Webanwendung mit Benutzern im Vereinigtes Königreich haben und Ihrer Distribution beispielsweise eine Lambda-Funktion zugeordnet ist, müssen Sie die Region ändern, um die CloudWatch Metriken oder Protokolldateien für London AWS-Region anzuzeigen. Weitere Informationen finden Sie unter [Bestimmen der Lambda@Edge-Region](#lambda-edge-testing-debugging-determine-region).

**Topics**
+ [

## Testen der Lambda@Edge-Funktionen
](#lambda-edge-testing-debugging-test-function)
+ [

## Identifizieren Sie Lambda @Edge -Funktionsfehler in CloudFront
](#lambda-edge-identifying-function-errors)
+ [

## Fehlerbehebung bei ungültigen Lambda@Edge-Funktionsantworten (Validierungsfehler)
](#lambda-edge-testing-debugging-troubleshooting-invalid-responses)
+ [

## Fehlerbehebung bei Lambda@Edge-Funktionsausführungsfehlern
](#lambda-edge-testing-debugging-execution-errors)
+ [

## Bestimmen der Lambda@Edge-Region
](#lambda-edge-testing-debugging-determine-region)
+ [

## Ermitteln Sie, ob Ihr Konto Logs an weiterleitet CloudWatch
](#lambda-edge-testing-debugging-cloudwatch-logs-enabled)

## Testen der Lambda@Edge-Funktionen
<a name="lambda-edge-testing-debugging-test-function"></a>

Der Test Ihrer Lambda-Funktion besteht aus zwei Schritten: eigenständiger Test und Integrationstest.

**Eigenständiger Test der Funktionalität**  
Bevor Sie Ihre Lambda-Funktion hinzufügen CloudFront, stellen Sie sicher, dass Sie die Funktionalität zuerst testen, indem Sie die Testfunktionen in der Lambda-Konsole oder andere Methoden verwenden. Weitere Informationen zu den Tests in der Lambda-Konsole finden Sie unter [Aufrufen einer Lambda-Funktion mit der Konsole](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) im *Entwicklerhandbuch für AWS Lambda *.

**Testen Sie den Betrieb Ihrer Funktion in CloudFront**  
Es ist wichtig, Integrationstests abzuschließen, bei denen Ihre Funktion einer Distribution zugeordnet ist und auf der Grundlage eines CloudFront Ereignisses ausgeführt wird. Stellen Sie sicher, dass die Funktion für das richtige Ereignis ausgelöst wird und eine für CloudFront gültige und korrekte Antwort zurückgibt. Achten Sie beispielsweise darauf, dass die Ereignisstruktur korrekt ist, dass nur gültige Header enthalten sind usw.  
Wenn Sie die Integrationstests mit Ihrer Funktion in der Lambda-Konsole wiederholen, folgen Sie den Schritten im Lambda @Edge -Tutorial, wenn Sie Ihren Code oder den CloudFront Trigger ändern, der Ihre Funktion aufruft. Stellen Sie beispielsweise sicher, dass Sie mit einer nummerierten Version Ihrer Funktion arbeiten, wie in diesem Schritt des Tutorials beschrieben: [Schritt 4: Fügen Sie einen CloudFront Trigger hinzu, um die Funktion auszuführen](lambda-edge-how-it-works-tutorial.md#lambda-edge-how-it-works-tutorial-add-trigger).   
Beachten Sie beim Vornehmen von Änderungen und deren Bereitstellung, dass es mehrere Minuten dauern kann, bis Ihre aktualisierte Funktion und CloudFront Trigger in allen Regionen repliziert sind. Dies dauert in der Regel wenige Minuten, kann jedoch auch bis zu 15 Minuten dauern.  
Sie können überprüfen, ob die Replikation abgeschlossen ist, indem Sie zur CloudFront Konsole gehen und sich Ihre Distribution ansehen.  

**So überprüfen Sie, ob die Bereitstellung Ihrer Replikation abgeschlossen ist**

1. Öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Wählen Sie den Distributionsnamen aus.

1. Überprüfen Sie, ob sich der Status der Verteilung von **InProgress (Läuft)** zurück auf **Deployed (Bereitgestellt)** geändert hat, d.h. Ihre Funktion wurde repliziert. Anschließend befolgen Sie die Schritte im nächsten Abschnitt, um zu überprüfen, ob die Funktion funktioniert.
Beachten Sie, dass das Testen in der Konsole nur die Logik Ihrer Funktion validiert und keine Servicekontingente (früher als Limits bezeichnet) anwendet, die spezifisch für Lambda@Edge sind.

## Identifizieren Sie Lambda @Edge -Funktionsfehler in CloudFront
<a name="lambda-edge-identifying-function-errors"></a>

Nachdem Sie überprüft haben, ob Ihre Funktionslogik korrekt funktioniert, werden möglicherweise immer noch HTTP 5xx-Fehler angezeigt, wenn Ihre Funktion ausgeführt wird. CloudFront HTTP 5xx-Fehler können aus einer Vielzahl von Gründen zurückgegeben werden, darunter Lambda-Funktionsfehler oder andere Probleme in. CloudFront
+ Wenn Sie Lambda @Edge -Funktionen verwenden, können Sie Diagramme in der CloudFront Konsole verwenden, um herauszufinden, was den Fehler verursacht, und dann daran arbeiten, ihn zu beheben. Sie können beispielsweise sehen, ob HTTP 5xx-Fehler durch CloudFront oder durch Lambda-Funktionen verursacht werden, und dann können Sie für bestimmte Funktionen zugehörige Protokolldateien einsehen, um das Problem zu untersuchen.
+ Informationen zur allgemeinen Behebung von HTTP-Fehlern finden Sie in CloudFront den Schritten zur Fehlerbehebung im folgenden Thema:. [Behebung von Statuscodes für die Fehlerantwort in CloudFront](troubleshooting-response-errors.md)

### Was verursacht Lambda @Edge -Funktionsfehler in CloudFront
<a name="lambda-edge-testing-debugging-function-errors"></a>

Es gibt mehrere Gründe, aus denen eine Lambda-Funktion einen HTTP 5xx-Fehler verursachen kann. Die Schritte zur Fehlerbehebung hängen von der Art des Fehlers ab. Fehler können wie folgt kategorisiert werden:

**Ein Lambda-Funktionsausführungsfehler.**  
Ein Ausführungsfehler tritt auf, wenn Sie CloudFront keine Antwort von Lambda erhalten, weil die Funktion unbehandelte Ausnahmen enthält oder ein Fehler im Code vorliegt. Zum Beispiel, wenn der Code "callback(Error)" beinhaltet.

**Eine ungültige Lambda-Funktionsantwort wird zurückgegeben an CloudFront**  
 CloudFront Erhält nach der Ausführung der Funktion eine Antwort von Lambda. Ein Fehler wird zurückgegeben, wenn die Objektstruktur der Antwort nicht der [Lambda@Edge-Ereignisstruktur](lambda-event-structure.md) entspricht oder die Antwort ungültige Header oder andere ungültige Felder enthält.

**Die Ausführung in CloudFront wird aufgrund von Lambda-Servicequotas (früher als Limits bezeichnet) gedrosselt**  
Der Lambda-Service drosselt die Ausführung in jeder Region und gibt einen Fehler zurück, wenn Sie das Kontingent überschreiten. Weitere Informationen finden Sie unter [Kontingente für Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).

### So bestimmten Sie den Typ des Fehlers
<a name="lambda-edge-testing-debugging-failure-type"></a>

Um Ihnen bei der Entscheidung zu helfen, worauf Sie sich beim Debuggen und bei der Behebung von Fehlern konzentrieren sollten, ist es hilfreich CloudFront, herauszufinden, warum CloudFront ein HTTP-Fehler zurückgegeben wird. Zu Beginn können Sie die Grafiken verwenden, die im Abschnitt **Überwachung** der CloudFront Konsole auf dem AWS-Managementkonsole bereitgestellt werden. Weitere Informationen zum Anzeigen von Diagrammen im Bereich **Überwachung** der CloudFront Konsole finden Sie unter[Überwachen von CloudFront-Metriken mit Amazon CloudWatch](monitoring-using-cloudwatch.md).

Die folgenden Diagramme sind besonders hilfreich, wenn Sie nachverfolgen möchten, ob Fehler von Ursprungs-Servern oder einer Lambda-Funktion zurückgegeben werden, und wenn Sie die Art des Problems eingrenzen möchten, wenn der Fehler aus einer Lambda-Funktion resultiert.

**Fehlerratendiagramm**  
Eines der Diagramme, das Sie auf der Registerkarte **Overview (Überblick)** für Ihre Verteilungen anzeigen können, ist das Diagramm **Error rates (Fehlerraten)**. Dieses Diagramm zeigt die Rate der Fehler als Prozentsatz aller Anforderungen an, die bei Ihren Verteilungen eingehen. Das Diagramm zeigt die Gesamtfehlerrate, die gesamten 4xx-Fehler, die gesamten 5xx-Fehler und die gesamten 5xx-Fehler an, die aus Lambda-Funktionen resultieren. Basierend auf Fehlertyp und Anzahl können Sie Schritte unternehmen, um diese Probleme zu untersuchen und zu beheben.  

![\[Diagramm der Fehlerraten für eine CloudFront Verteilung\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/Distribution-error-rate-pct-full.png)

+ Wenn Lambda-Fehler auftreten, können Sie eine genauere Untersuchung durchführen, indem Sie sich die spezifischen Arten von Fehlern ansehen, die von der Funktion zurückgegeben werden. Die Registerkarte **Lambda@Edge errors (Lambda@Edge-Fehler)** enthält Diagramme, die Funktionsfehler nach Typ kategorisieren, damit Sie das Problem für eine bestimmte Funktion herausfinden können.
+ Wenn Sie CloudFront Fehler sehen, können Sie Fehler beheben und daran arbeiten, die ursprünglichen Fehler zu beheben oder Ihre CloudFront Konfiguration zu ändern. Weitere Informationen finden Sie unter [Behebung von Statuscodes für die Fehlerantwort in CloudFront](troubleshooting-response-errors.md).

**Diagramme für Ausführungsfehler und ungültige Funktionsanworten**  
Die Registerkarte **Lambda@Edge errors (Lambda@Edge-Fehler)** enthält Diagramme, die Lambda@Edge-Fehler für eine bestimmte Verteilung nach Typ kategorisieren. So zeigt beispielsweise ein Diagramm alle Ausführungsfehler unterteilt nach AWS-Region an.  
Damit Fehler einfacher erkannt und behoben werden können, können Sie nach bestimmten Problemen suchen, indem Sie die Protokolldateien für spezifische Funktionen regionsweise öffnen und prüfen.   

**So zeigen Sie Protokolldateien für eine bestimmte Funktion nach Region an**

1. Wählen Sie auf der Registerkarte **Lambda@Edge-Fehler** unter **Zugeordnete Lambda@Edge-Funktionen** den Funktionsnamen und dann **Metriken anzeigen** aus. 

1. Klicken Sie anschließend auf der Seite mit dem Namen der Funktion rechts oben auf **Funktionsprotokolle anzeigen** und wählen Sie dann eine Region aus. 

   Wenn Sie beispielsweise Probleme im Diagramm **Fehler** für die Region USA West (Oregon) sehen, wählen Sie diese Region aus der Dropdown-Liste aus. Dadurch wird die CloudWatch Amazon-Konsole geöffnet.

1. Wählen Sie in der CloudWatch Konsole für diese Region unter **Protokollstreams** einen Protokollstream aus, um die Ereignisse für die Funktion anzuzeigen.
Lesen Sie darüber hinaus die folgenden Abschnitte in diesem Kapitel, um weitere Empfehlungen für die Behebung von Fehlern zu erhalten.

**Drosselungsdiagramm**  
Die Registerkarte **Lambda@Edge errors (Lambda@Edge-Fehler)** enthält auch ein Diagramm zu **Drosselungen**. In einigen Situationen drosselt der Lambda-Service Ihre Funktionsaufrufe auf Regionsbasis, wenn Sie sich dem regionalen Kontingent (früher als Limit bezeichnet) für die Gleichzeitigkeit nähern. Wenn Sie einen limit exceeded (Grenzwert überschritten)-Fehler sehen, hat Ihre Funktion ein Kontingent erreicht, das der Lambda-Service für Ausführungen in einer Region nutzt. Weitere Informationen, u. a. auch zur Erhöhung des Kontingents, finden Sie unter [Kontingente für Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).  

![\[Drosselungsdiagramm für die Lambda@Edge-Funktionsausführung\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/Lambda-throttles-page.png)


Ein Beispiel zur Verwendung dieser Informationen beim Beheben von HTTP-Fehlern finden Sie unter [Vier Schritte zum Debuggen der Bereitstelllung von Inhalten in AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/four-steps-for-debugging-your-content-delivery-on-aws/).

## Fehlerbehebung bei ungültigen Lambda@Edge-Funktionsantworten (Validierungsfehler)
<a name="lambda-edge-testing-debugging-troubleshooting-invalid-responses"></a>

Wenn Sie feststellen, dass es sich bei Ihrem Problem um einen Lambda-Validierungsfehler handelt, bedeutet dies, dass Ihre Lambda-Funktion eine ungültige Antwort auf zurückgibt. CloudFront Folgen Sie den Anweisungen in diesem Abschnitt, um Maßnahmen zur Überprüfung Ihrer Funktion zu ergreifen und sicherzustellen, dass Ihre Antwort den Anforderungen entspricht. CloudFront 

CloudFront validiert die Antwort einer Lambda-Funktion auf zwei Arten:
+ **Die Lambda-Antwort muss der gewünschten Objektstruktur entsprechen.** Beispiele für eine fehlerhafte Objektstruktur sind: nicht interpretierbarer JSON-Code, fehlende Pflichtfelder und ein ungültiges Objekt in der Antwort. Weitere Informationen hierzu finden Sie unter [Lambda@Edge-Ereignisstruktur](lambda-event-structure.md).
+ **Die Antwort darf nur gültige Objektwerte beinhalten.** Ein Fehler tritt auf, wenn die Antwort ein gültiges Objekt aber nicht unterstützte Werte enthält. Beispiele sind das Hinzufügen oder Aktualisieren von ungültigen Headern oder schreibgeschützten Headern (siehe [Einschränkungen für Edge-Funktionen](edge-functions-restrictions.md)), das Überschreiten der maximalen Body-Größe (siehe *Beschränkungen für die Größe der generierten Antwort* im Thema Lambda@Edge [Fehler](lambda-generating-http-responses.md#lambda-generating-http-responses-errors)) und ungültige Zeichen oder Werte (siehe [Lambda@Edge-Ereignisstruktur](lambda-event-structure.md)).

Wenn Lambda eine ungültige Antwort auf zurückgibt CloudFront, werden Fehlermeldungen in Protokolldateien geschrieben, die in die Region CloudFront übertragen werden, CloudWatch in der die Lambda-Funktion ausgeführt wurde. Dies ist das Standardverhalten, an das die Protokolldateien gesendet werden, CloudWatch wenn eine ungültige Antwort eingeht. Wenn Sie jedoch eine Lambda-Funktion mit verknüpft haben, CloudFront bevor die Funktionalität veröffentlicht wurde, ist sie möglicherweise nicht für Ihre Funktion aktiviert. Weitere Informationen finden Sie unter *Feststellen, ob Ihr Konto Protokolle an CloudWatch überträgt* weiter unten im Thema.

CloudFront überträgt Protokolldateien in die Region, die der Region entspricht, in der Ihre Funktion ausgeführt wurde, in der Protokollgruppe, die Ihrer Distribution zugeordnet ist. Protokollgruppen haben das folgende Format:`/aws/cloudfront/LambdaEdge/DistributionId`, wo *DistributionId* ist die ID Ihrer Distribution. Informationen zur Bestimmung der Region, in der Sie die CloudWatch Protokolldateien finden, finden Sie unter *Bestimmung der Lambda @Edge -Region weiter* unten in diesem Thema.

Wenn der Fehler reproduzierbar ist, können Sie eine neue Anfrage erstellen, die zu dem Fehler führt, und dann die Anforderungs-ID in einer fehlgeschlagenen CloudFront Antwort (`X-Amz-Cf-Id`Header) suchen, um einen einzelnen Fehler in den Protokolldateien zu lokalisieren. Der Eintrag in der Protokolldatei enthält Informationen, die Ihnen bei der Identifizierung Ursache für den Fehler helfen können. Er zeigt außerdem die entsprechende Lambda-Anforderungs-ID an, mit der Sie die Ursache im Kontext einer einzelnen Anforderung analysieren können.

Wenn ein Fehler nur sporadisch auftritt, können Sie mithilfe von CloudFront Zugriffsprotokollen die Anforderungs-ID für eine fehlgeschlagene Anfrage ermitteln und anschließend die CloudWatch Protokolle nach den entsprechenden Fehlermeldungen durchsuchen. Weitere Informationen finden Sie im vorherigen Abschnitt *Bestimmung der Fehlerart*.

## Fehlerbehebung bei Lambda@Edge-Funktionsausführungsfehlern
<a name="lambda-edge-testing-debugging-execution-errors"></a>

Wenn es sich bei dem Problem um einen Lambda-Ausführungsfehler handelt, kann es hilfreich sein, Protokollierungsanweisungen für Lambda-Funktionen zu erstellen, Meldungen in CloudWatch Protokolldateien zu schreiben, die die Ausführung Ihrer Funktion überwachen CloudFront und feststellen, ob sie wie erwartet funktioniert. Anschließend können Sie in den CloudWatch Protokolldateien nach diesen Anweisungen suchen, um zu überprüfen, ob Ihre Funktion funktioniert.

**Anmerkung**  
Auch wenn Sie Ihre Lambda@Edge-Funktion nicht geändert haben, kann diese durch Aktualisierungen der Lambda-Funktionsausführungsumgebung beeinträchtigt werden und einen Ausführungsfehler ausgeben. Informationen zum Testen und Migrieren auf eine neuere Version finden Sie unter [Kommende Updates für die AWS Lambda- und AWS Lambda @Edge](https://aws.amazon.com/blogs/compute/upcoming-updates-to-the-aws-lambda-execution-environment/) -Ausführungsumgebung.

## Bestimmen der Lambda@Edge-Region
<a name="lambda-edge-testing-debugging-determine-region"></a>

Um die Regionen zu sehen, in denen Ihre Lambda @Edge -Funktion Traffic empfängt, sehen Sie sich die Metriken für die Funktion auf der CloudFront Konsole auf der AWS-Managementkonsole an. Metriken werden für jede AWS Region angezeigt. Auf derselben Seite können Sie eine Region auswählen und Protokolldateien für diese anzeigen, um Probleme näher zu untersuchen. Sie müssen die CloudWatch Protokolldateien in der richtigen AWS Region überprüfen, um die Protokolldateien zu sehen, die bei der CloudFront Ausführung Ihrer Lambda-Funktion erstellt wurden.

Weitere Informationen zum Anzeigen von Diagrammen im Bereich **Überwachung** der CloudFront Konsole finden Sie unter[Überwachen von CloudFront-Metriken mit Amazon CloudWatch](monitoring-using-cloudwatch.md).

## Ermitteln Sie, ob Ihr Konto Logs an weiterleitet CloudWatch
<a name="lambda-edge-testing-debugging-cloudwatch-logs-enabled"></a>

 CloudFront Aktiviert standardmäßig die Protokollierung ungültiger Lambda-Funktionsantworten und überträgt die Protokolldateien CloudWatch mithilfe einer der [Serviceverknüpfte Rollen für Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge) Wenn Sie Lambda @Edge -Funktionen haben, die Sie hinzugefügt haben, CloudFront bevor die Funktion für das Protokoll der ungültigen Lambda-Funktionsantwort veröffentlicht wurde, wird die Protokollierung aktiviert, wenn Sie Ihre Lambda @Edge -Konfiguration das nächste Mal aktualisieren, z. B. indem Sie einen Trigger hinzufügen. CloudFront 

Gehen Sie wie folgt vor, um zu überprüfen, ob die Übertragung der Protokolldateien an für Ihr Konto aktiviert CloudWatch ist:
+ **Prüfen Sie, ob die Protokolle in erscheinen CloudWatch** — Achten Sie darauf, dass Sie in der Region suchen, in der die Lambda @Edge -Funktion ausgeführt wurde. Weitere Informationen finden Sie unter [Bestimmen der Lambda@Edge-Region](#lambda-edge-testing-debugging-determine-region).
+ **Stellen Sie fest, ob die zugehörige serviceverknüpfte Rolle in Ihrem Konto in IAM vorhanden ist.** Die IAM-Rolle `AWSServiceRoleForCloudFrontLogger` muss in Ihrem Konto vorhanden sein. Weitere Informationen über diese Rolle finden Sie unter [Serviceverknüpfte Rollen für Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge).

# Löschen von Lambda@Edge-Funktionen und Replikaten
<a name="lambda-edge-delete-replicas"></a>

Sie können eine Lambda@Edge-Funktion nur löschen, wenn die Replikate der Funktion von CloudFront gelöscht wurden. Replikate einer Lambda-Funktion werden in den folgenden Situationen automatisch gelöscht:
+ Nachdem Sie die letzte Zuordnung für die Funktion aus allen Ihren CloudFront-Verteilungen entfernt haben. Wenn mehrere Verteilungen eine Funktion verwenden, werden die Replikate erst gelöscht, nachdem Sie die Funktionszuordnung aus der letzten Verteilung entfernt haben.
+ Nachdem Sie die letzte Verteilung, der eine Funktion zugeordnet war, gelöscht haben.

Replicas werden in der Regel innerhalb von wenigen Stunden gelöscht. Lambda@Edge-Funktionsreplikate können nicht manuell gelöscht werden. Dadurch wird verhindert, dass ein Replikat gelöscht wird, das noch verwendet wird, was zu einem Fehler führen würde.

**Warnung**  
Erstellen Sie keine Anwendungen, die Lambda @Edge -Funktionsreplikate außerhalb von verwenden. CloudFront Diese Replikate werden gelöscht, wenn ihre Zuordnungen zu Verteilungen entfernt werden oder wenn die Verteilungen selbst gelöscht werden. Das Replikat, von dem eine externe Anwendung abhängt, könnte ohne Warnung entfernt werden, was zu einem Fehler führen würde.

**Um eine Lambda @Edge -Funktionsassoziation aus einer CloudFront Distribution zu löschen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Wählen Sie die ID der Distribution mit der Lambda@Edge-Funktionszuordnung aus, die Sie löschen möchten.

1. Wählen Sie die Registerkarte **Behaviors** aus.

1. Wählen Sie das Cacheverhalten mit der Lambda@Edge-Funktionszuordnung, die Sie löschen möchten, und dann **Bearbeiten** aus.

1. Wählen Sie unter **Funktionszuordnungen**, **Funktionstyp** die Option **Keine Zuordnung** aus, um die Lambda@Edge-Funktionszuordnung zu löschen.

1. Wählen Sie **Änderungen speichern ** aus.

Nachdem Sie eine Lambda @Edge -Funktionszuordnung aus einer CloudFront Distribution gelöscht haben, können Sie optional die Lambda-Funktion oder Funktionsversion aus löschen. AWS Lambda Warten Sie nach dem Löschen der Funktionszuordnung einige Stunden, damit die Lambda@Edge-Funktionsreplikate bereinigt werden können. Danach können Sie die Funktion mithilfe der Lambda-Konsole AWS CLI, der Lambda-API oder eines AWS SDK löschen.

Sie können auch eine bestimmte *Version* einer Lambda-Funktion löschen, wenn der Version keine CloudFront Distributionen zugeordnet sind. Warten Sie einige Stunden, nachdem Sie alle Zuordnungen für eine Lambda-Funktionsversion entfernt haben. Dann können Sie die Funktionsversion löschen.

# Lambda@Edge-Ereignisstruktur
<a name="lambda-event-structure"></a>

In den folgenden Themen werden die Anforderungs- und Antwortereignisobjekte beschrieben, die CloudFront an eine Lambda @Edge -Funktion übergeben werden, wenn sie ausgelöst wird.

**Topics**
+ [

## Dynamische Ursprungsauswahl
](#lambda-event-content-based-routing)
+ [

## Anforderungsereignisse
](#lambda-event-structure-request)
+ [

## Antwortereignisse
](#lambda-event-structure-response)

## Dynamische Ursprungsauswahl
<a name="lambda-event-content-based-routing"></a>

Sie können [das Pfadmuster in einem Cache-Verhalten](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern) verwenden, um Anforderungen an einen Ursprung zu leiten, basierend auf dem Pfad und Namen des angeforderten Objekts, z. B. `images/*.jpg`. Mit Lambda@Edge können Sie Anforderungen auch auf der Grundlage anderer Merkmale, wie z. B. der Werte in Anforderungs-Headern, an einen Ursprung weiterleiten. 

Es gibt eine Reihe von Möglichkeiten, wie diese dynamische Ursprungsauswahl genutzt werden kann. So können Sie z. B. Anforderungen über Ursprünge in verschiedenen geografischen Gebieten verteilen, um den globalen Lastausgleich zu unterstützen. Oder Sie können Anforderungen selektiv an verschiedene Ursprünge weiterleiten, die jeweils eine bestimmte Funktion erfüllen: Bot-Handling, SEO-Optimierung, Authentifizierung und so weiter. Code-Beispiele, die die Verwendung dieses Features demonstrieren, finden Sie unter [Inhaltsbasierte dynamische Ursprungsauswahl –Beispiele](lambda-examples.md#lambda-examples-content-based-routing-examples).

Im ursprünglichen CloudFront Anforderungsereignis enthält das `origin` Objekt in der Ereignisstruktur Informationen über den Ursprung, an den die Anforderung weitergeleitet werden würde, basierend auf dem Pfadmuster. Sie können die Werte im `origin`-Objekt aktualisieren, um eine Anforderung an eine andere Herkunft weiterzuleiten. Wenn Sie das `origin`-Objekt aktualisieren, müssen Sie den Ursprung in der Verteilung nicht definieren. Sie können ein Amazon S3-Ursprungsobjekt auch durch ein benutzerdefiniertes Ursprungsobjekt ersetzen und umgekehrt. Sie können jedoch nur einen einzigen Ursprung pro Anforderung angeben; entweder einen benutzerdefinierten Ursprung oder einen Amazon S3-Ursprung, aber nicht beide.

## Anforderungsereignisse
<a name="lambda-event-structure-request"></a>

Die folgenden Themen zeigen die Struktur des Objekts, das für [Viewer- und CloudFront Origin-Request-Ereignisse](lambda-cloudfront-trigger-events.md) an eine Lambda-Funktion übergeben wird. Diese Beispiele zeigen eine `GET`-Anfrage ohne Körper. Im Anschluss an die Beispiele finden Sie eine Liste aller möglichen Felder in Viewer- und Ursprungsanforderungsereignissen.

**Topics**
+ [

### Beispiel für Viewer-Anforderung
](#example-viewer-request)
+ [

### Beispiel für Ursprungsanforderung
](#example-origin-request)
+ [

### Anforderungsereignisfelder
](#request-event-fields)

### Beispiel für Viewer-Anforderung
<a name="example-viewer-request"></a>

Das folgende Beispiel zeigt ein Viewer-Anfrageereignisobjekt.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "viewer-request",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "host": [
              {
                "key": "Host",
                "value": "d111111abcdef8.cloudfront.net"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "curl/7.66.0"
              }
            ],
            "accept": [
              {
                "key": "accept",
                "value": "*/*"
              }
            ]
          },
          "method": "GET",
          "querystring": "",
          "uri": "/"
        }
      }
    }
  ]
}
```

### Beispiel für Ursprungsanforderung
<a name="example-origin-request"></a>

Das folgende Beispiel zeigt ein Ursprungsanforderungsereignisobjekt.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "origin-request",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "x-forwarded-for": [
              {
                "key": "X-Forwarded-For",
                "value": "203.0.113.178"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "Amazon CloudFront"
              }
            ],
            "via": [
              {
                "key": "Via",
                "value": "2.0 2afae0d44e2540f472c0635ab62c232b.cloudfront.net (CloudFront)"
              }
            ],
            "host": [
              {
                "key": "Host",
                "value": "example.org"
              }
            ],
            "cache-control": [
              {
                "key": "Cache-Control",
                "value": "no-cache"
              }
            ]
          },
          "method": "GET",
          "origin": {
            "custom": {
              "customHeaders": {},
              "domainName": "example.org",
              "keepaliveTimeout": 5,
              "path": "",
              "port": 443,
              "protocol": "https",
              "readTimeout": 30,
              "responseCompletionTimeout": 30,
              "sslProtocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
              ]
            }
          },
          "querystring": "",
          "uri": "/"
        }
      }
    }
  ]
}
```

### Anforderungsereignisfelder
<a name="request-event-fields"></a>

Anforderungsereignisobjektdaten sind in zwei Unterobjekten enthalten: `config` (`Records.cf.config`) und `request` (`Records.cf.request`). In den folgenden Listen werden die Felder jedes Unterobjekts beschrieben.

#### Felder im Config-Objekt
<a name="request-event-fields-config"></a>

Die folgende Liste beschreibt die Felder im `config`-Objekt (`Records.cf.config`).

**`distributionDomainName` (Schreibgeschützt)**  
Der Domänenname der Verteilung, die der Anforderung zugeordnet ist.

**`distributionID` (Schreibgeschützt)**  
Die ID der Verteilung, die der Anforderung zugeordnet ist.

**`eventType` (Schreibgeschützt)**  
Der Typ des Auslösers, der der Anforderung zugeordnet ist: `viewer-request` oder `origin-request`.

**`requestId` (Schreibgeschützt)**  
Eine verschlüsselte Zeichenfolge, die eine viewer-to-CloudFront Anfrage eindeutig identifiziert. Der `requestId`-Wert erscheint auch als CloudFront in `x-edge-request-id`-Zugriffsprotokollen. Weitere Informationen erhalten Sie unter [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md) und [Felder der Protokolldatei](standard-logs-reference.md#BasicDistributionFileFormat).

#### Felder im Anforderungsobjekt
<a name="request-event-fields-request"></a>

Die folgende Liste beschreibt die Felder im `request`-Objekt (`Records.cf.request`).

**`clientIp` (Schreibgeschützt)**  
Die IP-Adresse des Viewers, der die Anforderung gestellt hat. Wenn der Viewer einen HTTP-Proxy oder einen Load Balancer verwendet hat, um die Anfrage zu senden, entspricht der Wert der IP-Adresse des Proxys bzw. des Load Balancers.

**Header (lesen/schreiben)**  
Die Header der Anforderung. Beachten Sie Folgendes:  
+ Die Schlüssel im `headers`-Objekt sind kleingeschriebene Versionen von Standard-HTTP-Header-Namen. Über diese Kleinbuchstaben-Schlüssel haben Sie Zugriff auf die Headerwerte (ohne Berücksichtigung von Groß-/Kleinschreibung).
+ Jedes Header-Objekt (z. B. `headers["accept"]` oder `headers["host"]`) ist ein Array mit Schlüssel-Wert-Paaren. Für einen bestimmten Header enthält das Array ein Schlüssel-Wert-Paar für jeden Wert in der Anforderung.
+ `key` enthält den Namen des Headers unter Beachtung der Groß-/Kleinschreibung, wie er in der HTTP-Anforderung angezeigt wurde, z. B. `Host`, `User-Agent`, `X-Forwarded-For`, `Cookie`, usw.
+ `value` enthält den Header-Wert, wie er in der HTTP-Anforderung angezeigt wird.
+ Wenn Ihre Lambda-Funktion Anfrage-Header hinzufügt oder ändert und Sie das `key`-Header-Feld nicht einschließen, fügt Lambda@Edge automatisch den Header `key` mit dem von Ihnen angegebenen Header-Namen ein. Unabhängig davon, wie Sie den Header-Namen formatiert haben, wird der automatisch eingefügte Header-Schlüssel mit einem großen Anfangsbuchstaben für jeden Teil formatiert, wobei die einzelnen Teile durch Bindestriche (-) getrennt werden.

  Beispielsweise können Sie einen Header wie den folgenden ohne Header hinzufügen: `key`

  ```
  "user-agent": [
    {
      "value": "ExampleCustomUserAgent/1.X.0"
    }
  ]
  ```

  In diesem Beispiel fügt Lambda@Edge automatisch `"key": "User-Agent"` ein.
Weitere Informationen zu Einschränkungen zur Verwendung von Headern finden Sie unter [Einschränkungen für Edge-Funktionen](edge-functions-restrictions.md).

**`method` (Schreibgeschützt)**  
Die HTTP-Methode der Anforderung.

**`querystring` (Lesen/Schreiben)**  
Die Abfragezeichenfolge, falls vorhanden, in der Anforderung. Wenn die Anfrage keine Abfragezeichenfolge enthält, umfasst das Ereignisobjekt dennoch `querystring` mit einem leeren Wert. Weitere Informationen zu Abfragezeichenfolgen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern](QueryStringParameters.md).

**`uri` (Lesen/Schreiben)**  
Der relative Pfad des angeforderten Objekts. Wenn Ihre Lambda-Funktion den `uri`-Wert ändert, beachten Sie Folgendes:  
+ Der neue `uri`-Wert muss mit einem Schrägstrich (/) beginnen.
+ Wenn eine Funktion den `uri`-Wert ändert, ändert sich auch das Objekt, das die Betrachter anfordert.
+ Wenn eine Funktion den `uri`-Wert ändert, ändert sich *weder* das Cache-Verhalten für die Anforderung noch der Ursprung, an den die Anforderung weitergeleitet wird.

**`body` (Lesen/Schreiben)**  
Der Hauptteil der HTTP-Anforderung. Die `body`-Struktur kann folgende Felder enthalten:    
**`inputTruncated` (Schreibgeschützt)**  
Ein boolesches Flag, das angibt, ob der Textkörper von Lambda@Edge abgeschnitten wurde. Weitere Informationen finden Sie unter [Einschränkungen für Anforderungstext mit der Option „Text einschließen“](lambda-at-edge-function-restrictions.md#lambda-at-edge-restrictions-request-body).  
**`action` (Lesen/Schreiben)**  
Die Aktion, die Sie für den Body durchführen möchten. Für `action` gibt es die folgenden Optionen:  
+ `read-only:` Dies ist die Standardeinstellung. Lambda@Edge ignoriert bei der Rückgaben der Antwort von der Lambda-Funktion alle Änderungen an `encoding` oder `data`. wenn `action` schreibgeschützt ist.
+ `replace:` Geben Sie diese Option an, wenn Sie den an den Ursprung gesendeten Textkörper ersetzen möchten.  
**`encoding` (Lesen/Schreiben)**  
Die Kodierung für den Body. Wenn Lambda@Edge den Textkörper der Lambda-Funktion bereitstellt, konvertiert es den Textkörper zuerst zu base64-encoding. Wenn Sie `replace` für die `action` auswählen, um den Textkörper zu ersetzen, können Sie die Kodierung `base64` (Standard) oder `text` verwenden. Wenn Sie `encoding` als `base64` festlegen, der Body jedoch kein gültiges base64 ist, gibt CloudFront einen Fehler zurück.  
**`data` (Lesen/Schreiben)**  
Der Inhalt des Anforderungs-Bodys. 

**`origin` (lesen/schreiben) (nur Ursprungsereignisse)**  
Der Ursprung, an den die Anfrage gesendet werden soll. Die `origin`-Struktur muss *genau einen Ursprung* enthalten, der ein benutzerdefinierter Ursprung oder ein Amazon S3-Ursprung sein kann.  
Je nachdem, welchen Ursprungstyp Sie angeben (benutzerdefiniert oder Amazon-S3-Ursprünge), müssen Sie in Ihrer Anforderung die folgenden Felder angeben:    
**`customHeaders` (Lesen/Schreiben) (benutzerdefinierte und Amazon S3-Ursprünge)**  
(Optional) Sie können benutzerdefinierte Header in die Anforderung aufnehmen, indem Sie für jeden benutzerdefinierten Header einen Header-Namens- und Wertpaar angeben. Sie können keine Header hinzufügen, die nicht erlaubt sind, und ein Header mit dem gleichen Namen kann in `Records.cf.request.headers` nicht vorhanden sein. Die [Hinweise zu Anforderungs-Headern](#request-event-fields-request-headers) gelten auch für benutzerdefinierte Header. Weitere Informationen erhalten Sie unter [Benutzerdefinierte Header, die CloudFront nicht zu Ursprungsanforderungen hinzufügen kann](add-origin-custom-headers.md#add-origin-custom-headers-denylist) und [Einschränkungen für Edge-Funktionen](edge-functions-restrictions.md).  
**`domainName` (Lesen/Schreiben) (benutzerdefinierte und Amazon S3-Ursprünge)**  
Der Domänenname des Ursprungs. Der Domänenname darf nicht leer sein.  
+ **Für benutzerdefinierte Ursprünge** – Geben Sie einen DNS-Domänennamen an, z. B. `www.example.com` Der Domänenname darf keinen Doppelpunkt (:) enthalten und keine IP-Adresse sein. Der Domänenname kann bis zu 253 Zeichen lang sein.
+ **Für Amazon S3-Ursprünge** – Geben Sie den DNS-Domänennamen des Amazon S3-Buckets an, z. B. `amzn-s3-demo-bucket.s3.eu-west-1.amazonaws.com`. Der Name kann bis zu 128 Zeichen lang sein und muss in Kleinbuchstaben geschrieben werden.  
**`path` (Lesen/Schreiben) (benutzerdefinierte und Amazon S3-Ursprünge)**  
Der Verzeichnispfad auf dem Ursprung, aus dem die Anforderung den Inhalt abrufen soll. Der Pfad sollte mit einem Schrägstrich (/) beginnen, aber nicht damit enden (z. B. nicht mit `example-path/`). Nur für benutzerdefinierte Ursprünge sollte der Pfad URL-codiert sein und eine Maximallänge von 255 Zeichen haben.  
**`keepaliveTimeout` (lesen/schreiben) (nur benutzerdefinierte Ursprünge)**  
Wie lange (in Sekunden) CloudFront soll versucht werden, die Verbindung zum Ursprung aufrechtzuerhalten, nachdem das letzte Paket der Antwort empfangen wurde. Der Wert muss eine Zahl zwischen 1—120 (einschließlich) sein.  
**`port` (lesen/schreiben) (nur benutzerdefinierte Ursprünge)**  
Der Port, zu dem eine Verbindung zu Ihrem benutzerdefinierten Ursprung hergestellt werden CloudFront soll. Der Port muss 80, 443 oder 1024 bis einschließlich 65535 sein.  
**`protocol` (lesen/schreiben) (nur benutzerdefinierte Ursprünge)**  
Das Verbindungsprotokoll, das verwendet CloudFront werden soll, wenn Sie eine Verbindung zu Ihrem Origin herstellen. Dabei kann es sich um den Wert `http` oder `https` handeln.  
**`readTimeout` (Lesen/Schreiben) (benutzerdefinierte und Amazon S3-Ursprünge)**  
Wie lange (in Sekunden) CloudFront sollten Sie auf eine Antwort warten, nachdem Sie eine Anfrage an Ihren Absender gesendet haben. Dies gibt auch an, wie lange CloudFront warten soll, nachdem das Paket einer Antwort empfangen wurde, bevor das nächste Paket empfangen wird. Der Wert muss eine Zahl zwischen 1—120 (einschließlich) sein.  
Wenn Sie ein höheres Kontingent benötigen, finden Sie weitere Informationen unter [Antwort-Timeout pro Ursprung](cloudfront-limits.md#limits-web-distributions).  
**`responseCompletionTimeout` (Lesen/Schreiben) (benutzerdefinierte und Amazon S3-Ursprünge)**  
Die Zeit (in Sekunden), während der eine Anfrage vom CloudFront Ursprung aus geöffnet bleiben und auf eine Antwort warten kann. Wenn bis zu diesem Zeitpunkt noch keine vollständige Antwort vom Ursprung eingegangen ist, wird die Verbindung CloudFront beendet.  
Der Wert für `responseCompletionTimeout` muss größer oder gleich dem für `readTimeout` angegebenen Wert sein. Wenn Sie diesen Wert auf 0 setzen, werden alle zuvor von Ihnen festgelegten Werte entfernt und der Standardwert wird wiederhergestellt. Sie können dies auch erreichen, indem Sie das Feld `responseCompletionTimeout` aus der Ereignisanforderung löschen.   
**`sslProtocols` (lesen/schreiben) (nur benutzerdefinierte Ursprünge)**  
Das SSL/TLS Mindestprotokoll, das CloudFront Sie beim Aufbau einer HTTPS-Verbindung mit Ihrem Ursprung verwenden können. Werte können einer der folgenden sein: `TLSv1.2`, `TLSv1.1`, `TLSv1` oder `SSLv3`.  
**`authMethod` ( Lesen/Schreiben) (nur Amazon S3-Ursprünge)**  
Wenn Sie eine [Ursprungszugriffsidentität (OAI)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai) verwenden, setzen Sie dieses Feld auf `origin-access-identity`. Wenn Sie keine OAI verwenden, setzen Sie es auf `none`. Wenn Sie `authMethod` auf „`origin-access-identity`“ festlegen, gibt es mehrere Anforderungen:   
+ Sie müssen die `region` angeben (siehe das folgende Feld).
+ Sie müssen dieselbe OAI verwenden, wenn Sie die Anforderung von einem Amazon S3-Ursprung zu einem anderen ändern.
+ Sie können keine OAI verwenden, wenn Sie die Anforderung von einem benutzerdefinierten Ursprung zu einem Amazon-S3-Ursprung ändern.
Dieses Feld unterstützt keine [Ursprungszugriffssteuerung (OAC)](private-content-restricting-access-to-s3.md).  
**`region` ( Lesen/Schreiben) (nur Amazon S3-Ursprünge)**  
Die AWS Region Ihres Amazon S3 S3-Buckets. Dies ist nur erforderlich, wenn Sie `authMethod` auf „`origin-access-identity`“ festlegen.

## Antwortereignisse
<a name="lambda-event-structure-response"></a>

Die folgenden Themen zeigen die Struktur des Objekts, das für [Viewer- und Origin-Response-Ereignisse](lambda-cloudfront-trigger-events.md) an eine Lambda-Funktion CloudFront übergeben wird. Im Anschluss an die Beispiele finden Sie eine Liste aller möglichen Felder in Viewer- und Ursprungantwortereignissen.

**Topics**
+ [

### Beispiel für Ursprungsantwort
](#lambda-event-structure-response-origin)
+ [

### Beispiel für Viewer-Antwort
](#lambda-event-structure-response-viewer)
+ [

### Antwortereignisfelder
](#response-event-fields)

### Beispiel für Ursprungsantwort
<a name="lambda-event-structure-response-origin"></a>

Das folgende Beispiel zeigt ein Ursprungsantwortereignisobjekt.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "origin-response",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "x-forwarded-for": [
              {
                "key": "X-Forwarded-For",
                "value": "203.0.113.178"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "Amazon CloudFront"
              }
            ],
            "via": [
              {
                "key": "Via",
                "value": "2.0 8f22423015641505b8c857a37450d6c0.cloudfront.net (CloudFront)"
              }
            ],
            "host": [
              {
                "key": "Host",
                "value": "example.org"
              }
            ],
            "cache-control": [
              {
                "key": "Cache-Control",
                "value": "no-cache"
              }
            ]
          },
          "method": "GET",
          "origin": {
            "custom": {
              "customHeaders": {},
              "domainName": "example.org",
              "keepaliveTimeout": 5,
              "path": "",
              "port": 443,
              "protocol": "https",
              "readTimeout": 30,
              "responseCompletionTimeout": 30,
              "sslProtocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
              ]
            }
          },
          "querystring": "",
          "uri": "/"
        },
        "response": {
          "headers": {
            "access-control-allow-credentials": [
              {
                "key": "Access-Control-Allow-Credentials",
                "value": "true"
              }
            ],
            "access-control-allow-origin": [
              {
                "key": "Access-Control-Allow-Origin",
                "value": "*"
              }
            ],
            "date": [
              {
                "key": "Date",
                "value": "Mon, 13 Jan 2020 20:12:38 GMT"
              }
            ],
            "referrer-policy": [
              {
                "key": "Referrer-Policy",
                "value": "no-referrer-when-downgrade"
              }
            ],
            "server": [
              {
                "key": "Server",
                "value": "ExampleCustomOriginServer"
              }
            ],
            "x-content-type-options": [
              {
                "key": "X-Content-Type-Options",
                "value": "nosniff"
              }
            ],
            "x-frame-options": [
              {
                "key": "X-Frame-Options",
                "value": "DENY"
              }
            ],
            "x-xss-protection": [
              {
                "key": "X-XSS-Protection",
                "value": "1; mode=block"
              }
            ],
            "content-type": [
              {
                "key": "Content-Type",
                "value": "text/html; charset=utf-8"
              }
            ],
            "content-length": [
              {
                "key": "Content-Length",
                "value": "9593"
              }
            ]
          },
          "status": "200",
          "statusDescription": "OK"
        }
      }
    }
  ]
}
```

### Beispiel für Viewer-Antwort
<a name="lambda-event-structure-response-viewer"></a>

Das folgende Beispiel zeigt ein Viewer-Antwortereignisobjekt.

```
{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "viewer-response",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "host": [
              {
                "key": "Host",
                "value": "d111111abcdef8.cloudfront.net"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "curl/7.66.0"
              }
            ],
            "accept": [
              {
                "key": "accept",
                "value": "*/*"
              }
            ]
          },
          "method": "GET",
          "querystring": "",
          "uri": "/"
        },
        "response": {
          "headers": {
            "access-control-allow-credentials": [
              {
                "key": "Access-Control-Allow-Credentials",
                "value": "true"
              }
            ],
            "access-control-allow-origin": [
              {
                "key": "Access-Control-Allow-Origin",
                "value": "*"
              }
            ],
            "date": [
              {
                "key": "Date",
                "value": "Mon, 13 Jan 2020 20:14:56 GMT"
              }
            ],
            "referrer-policy": [
              {
                "key": "Referrer-Policy",
                "value": "no-referrer-when-downgrade"
              }
            ],
            "server": [
              {
                "key": "Server",
                "value": "ExampleCustomOriginServer"
              }
            ],
            "x-content-type-options": [
              {
                "key": "X-Content-Type-Options",
                "value": "nosniff"
              }
            ],
            "x-frame-options": [
              {
                "key": "X-Frame-Options",
                "value": "DENY"
              }
            ],
            "x-xss-protection": [
              {
                "key": "X-XSS-Protection",
                "value": "1; mode=block"
              }
            ],
            "age": [
              {
                "key": "Age",
                "value": "2402"
              }
            ],
            "content-type": [
              {
                "key": "Content-Type",
                "value": "text/html; charset=utf-8"
              }
            ],
            "content-length": [
              {
                "key": "Content-Length",
                "value": "9593"
              }
            ]
          },
          "status": "200",
          "statusDescription": "OK"
        }
      }
    }
  ]
}
```

### Antwortereignisfelder
<a name="response-event-fields"></a>

Die Daten des Antwortereignisobjekts sind in drei Unterobjekten enthalten: `config` (`Records.cf.config`), `request` (`Records.cf.request`) und `response` (`Records.cf.response`). Weitere Hinweise zu den Feldern im Anforderungsobjekt finden Sie unter [Felder im Anforderungsobjekt](#request-event-fields-request). In den folgenden Listen werden die Felder in den Unterobjekten `config` und `response` beschrieben.

#### Felder im Config-Objekt
<a name="response-event-fields-config"></a>

Die folgende Liste beschreibt die Felder im `config`-Objekt (`Records.cf.config`).

**`distributionDomainName` (Schreibgeschützt)**  
Der Domänenname der Verteilung, die der Antwort zugeordnet ist.

**`distributionID` (Schreibgeschützt)**  
Die ID der Verteilung, die der Antwort zugeordnet ist.

**`eventType` (Schreibgeschützt)**  
Der Typ des Auslösers, der der Antwort zugeordnet ist: `origin-response` oder `viewer-response`.

**`requestId` (Schreibgeschützt)**  
Eine verschlüsselte Zeichenfolge, die die viewer-to-CloudFront Anfrage, der diese Antwort zugeordnet ist, eindeutig identifiziert. Der `requestId` Wert erscheint auch in den CloudFront Zugriffsprotokollen als`x-edge-request-id`. Weitere Informationen erhalten Sie unter [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md) und [Felder der Protokolldatei](standard-logs-reference.md#BasicDistributionFileFormat).

#### Felder im Antwortobjekt
<a name="response-event-fields-response"></a>

Die folgende Liste beschreibt die Felder im `response`-Objekt (`Records.cf.response`). Hinweise zum Generieren einer HTTP-Antwort mithilfe einer Lambda@Edge-Funktion finden Sie unter [Generieren von HTTP-Antworten in Anforderungsauslösern](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).

**`headers` (Lesen/Schreiben)**  
Die Header der Antwort. Beachten Sie Folgendes:  
+ Die Schlüssel im `headers`-Objekt sind kleingeschriebene Versionen von Standard-HTTP-Header-Namen. Über diese Kleinbuchstaben-Schlüssel haben Sie Zugriff auf die Headerwerte (ohne Berücksichtigung von Groß-/Kleinschreibung).
+ Jedes Header-Objekt (z. B. `headers["content-type"]` oder `headers["content-length"]`) ist ein Array mit Schlüssel-Wert-Paaren. Für einen bestimmten Header enthält das Array ein Schlüssel-Wert-Paar für jeden Wert in der generierten Antwort.
+ `key` enthält den Namen des Headers unter Beachtung der Groß-/Kleinschreibung, wie er in der HTTP-Antwort angezeigt wird, z. B. `Content-Type`, `Content-Length`, `Cookie` usw.
+ `value` enthält den Header-Wert, wie er in der HTTP-Antwort angezeigt wird.
+ Wenn Ihre Lambda-Funktion Antwort-Header hinzufügt oder ändert und Sie das `key`-Header-Feld nicht einschließen, fügt Lambda@Edge automatisch den Header `key` mit dem von Ihnen angegebenen Header-Namen ein. Unabhängig davon, wie Sie den Header-Namen formatiert haben, wird der automatisch eingefügte Header-Schlüssel mit einem großen Anfangsbuchstaben für jeden Teil formatiert, wobei die einzelnen Teile durch Bindestriche (-) getrennt werden.

  Beispielsweise können Sie einen Header wie den folgenden ohne Header hinzufügen: `key`

  ```
  "content-type": [
    {
      "value": "text/html;charset=UTF-8"
    }
  ]
  ```

  In diesem Beispiel fügt Lambda@Edge automatisch `"key": "Content-Type"` ein.
Weitere Informationen zu Einschränkungen zur Verwendung von Headern finden Sie unter [Einschränkungen für Edge-Funktionen](edge-functions-restrictions.md).

**`status`**  
Den HTTP-Statuscode der Antwort.

**`statusDescription`**  
Die HTTP-Statusbeschreibung der Antwort.

# Arbeiten mit Anforderungen und Antworten
<a name="lambda-generating-http-responses"></a>

Informationen zur Verwendung von Lambda@Edge-Anforderungen und -Antworten finden Sie in den folgenden Themen:

**Topics**
+ [

## Verwenden von Lambda@Edge-Funktionen mit Origin Failover
](#lambda-and-origin-failover)
+ [

## Generieren von HTTP-Antworten in Anforderungsauslösern
](#lambda-generating-http-responses-in-requests)
+ [

## Aktualisieren von HTTP-Antworten in Ursprungsantwortauslösern
](#lambda-updating-http-responses)
+ [

## Zugriff auf den Anforderungstext über die Option „Text einschließen“
](#lambda-include-body-access)

## Verwenden von Lambda@Edge-Funktionen mit Origin Failover
<a name="lambda-and-origin-failover"></a>

Sie können Lambda @Edge -Funktionen mit CloudFront Verteilungen verwenden, die Sie mit Ursprungsgruppen eingerichtet haben, z. B. für Origin-Failover, das Sie konfigurieren, um eine hohe Verfügbarkeit sicherzustellen. Um eine Lambda-Funktion mit einer Ursprungsgruppe zu verwenden, geben Sie die Funktion in einem Ursprungsanfragen- oder Ursprungsantwort-Auslöser für eine Ursprungsgruppe an, wenn Sie das Zwischenspeicher-Verhalten erstellen.

Weitere Informationen finden Sie hier:
+ **Erstellen von Ursprungsgruppen:** [Erstellen einer Ursprungsgruppe](high_availability_origin_failover.md#concept_origin_groups.creating)
+ **Funktionsweise von Origin Failover mit Lambda@Edge:** [Verwenden von Origin Failover mit Lambda@Edge-Funktionen](high_availability_origin_failover.md#concept_origin_groups.lambda)

## Generieren von HTTP-Antworten in Anforderungsauslösern
<a name="lambda-generating-http-responses-in-requests"></a>

Wenn Sie CloudFront eine Anfrage erhalten, können Sie eine Lambda-Funktion verwenden, um eine HTTP-Antwort zu generieren, die direkt an den Betrachter CloudFront zurückkehrt, ohne die Antwort an den Ursprung weiterzuleiten. Die Generierung von HTTP-Antworten reduziert die Auslastung des Ursprungs und reduziert in der Regel auch die Latenzzeit für den Viewer.

Einige häufige Szenarien für die Generierung von HTTP-Antworten sind die folgenden:
+ Rückgabe einer kleinen Website an den Viewer.
+ Rückgabe eines HTTP 301- oder 302-Statuscodes, um den Benutzer auf eine andere Webseite umzuleiten.
+ Rückgabe eines HTTP 401-Statuscodes an den Viewer, wenn sich der Benutzer nicht authentifiziert hat.

Eine Lambda@Edge-Funktion kann eine HTTP-Antwort generieren, wenn die folgenden CloudFront-Ereignisse auftreten:

**Viewer-Anforderungsereignisse**  
Wenn eine Funktion durch ein Viewer-Anforderungsereignis ausgelöst wird, CloudFront gibt sie die Antwort an den Betrachter zurück und speichert sie nicht im Cache.

**Ursprungsanforderungsereignisse**  
Wenn eine Funktion durch ein Origin-Anforderungsereignis ausgelöst wird, CloudFront wird im Edge-Cache nach einer Antwort gesucht, die zuvor von der Funktion generiert wurde.   
+ Wenn sich die Antwort im Cache befindet, wird die Funktion nicht ausgeführt und CloudFront gibt die zwischengespeicherte Antwort an den Viewer zurück.
+ Wenn sich die Antwort nicht im Cache befindet, wird die Funktion ausgeführt, CloudFront gibt die Antwort an den Betrachter zurück und speichert sie ebenfalls im Cache.

Beispiel-Code zum Generieren von HTTP-Antworten finden Sie unter [Beispielfunktionen für Lambda@Edge](lambda-examples.md). Sie können auch die HTTP-Antworten in Antwortauslösern ersetzen. Weitere Informationen finden Sie unter [Aktualisieren von HTTP-Antworten in Ursprungsantwortauslösern](#lambda-updating-http-responses).

### Programmiermodell
<a name="lambda-generating-http-responses-programming-model"></a>

Dieser Abschnitt enthält Informationen über das Programmiermodell für die Nutzung von Lambda@Edge zum Generieren von HTTP-Antworten.

**Topics**
+ [

#### Antwortobjekt
](#lambda-generating-http-responses-object)
+ [

#### Fehler
](#lambda-generating-http-responses-errors)
+ [

#### Pflichtfelder
](#lambda-generating-http-responses-required-fields)

#### Antwortobjekt
<a name="lambda-generating-http-responses-object"></a>

Die Antwort, die Sie als `result`-Parameter der `callback`-Methode zurückgeben, sollte folgenden Aufbau haben (beachten Sie, dass nur das `status`-Feld erforderlich ist).

```
const response = {
    body: 'content',
    bodyEncoding: 'text' | 'base64',
    headers: {
        'header name in lowercase': [{
            key: 'header name in standard case',
            value: 'header value'
         }],
         ...
    },
    status: 'HTTP status code (string)',
    statusDescription: 'status description'
};
```

Das Antwortobjekt kann die folgenden Werte enthalten:

**`body`**  
Der Text, falls vorhanden, den Sie in der generierten Antwort zurückgeben CloudFront möchten.

**`bodyEncoding`**  
Die Kodierung für den Wert, den Sie in `body` festgelegt haben. Die einzigen gültigen Codierungen sind `text` und `base64`. Wenn Sie `body` in das `response` Objekt aufnehmen, aber weglassen`bodyEncoding`, wird der CloudFront Hauptteil als Text behandelt.  
Wenn Sie `bodyEncoding` als `base64` festlegen, der Body jedoch kein gültiges base64 ist, gibt CloudFront einen Fehler zurück.

**`headers`**  
Header, die Sie in der generierten Antwort zurückgeben möchten CloudFront . Beachten Sie Folgendes:  
+ Die Schlüssel im `headers`-Objekt sind kleingeschriebene Versionen von Standard-HTTP-Header-Namen. Über diese Kleinbuchstaben-Schlüssel haben Sie Zugriff auf die Headerwerte (ohne Berücksichtigung von Groß-/Kleinschreibung).
+ Jeder Header (z. B. `headers["accept"]` oder `headers["host"]`) ist ein Array mit Schlüssel-Wert-Paaren. Für einen bestimmten Header enthält das Array ein Schlüssel-Wert-Paar für jeden Wert in der generierten Antwort.
+ `key` (optional) ist der von Groß- und Kleinschreibung unabhängige Name des Headers, wie er in einer HTTP-Anforderung erscheint (z. B. `accept` oder `host`).
+ Geben Sie `value` als Header-Wert an.
+ Wenn Sie den Header-Schlüsselteil des Schlüssel-Wert-Paares nicht aufnehmen, fügt Lambda@Edge automatisch einen Header-Schlüssel mit dem von Ihnen angegebenen Header-Namen ein. Unabhängig davon, wie Sie den Header-Namen formatiert haben, wird der automatisch eingefügte Header-Schlüssel mit einem großen Anfangsbuchstaben für jeden Teil formatiert, wobei die einzelnen Teile durch Bindestriche (-) getrennt werden.

  Beispielsweise können Sie einen Header wie den folgenden ohne Header-Schlüssel hinzufügen: `'content-type': [{ value: 'text/html;charset=UTF-8' }]`

  In diesem Beispiel erstellt Lambda@Edge den folgenden Header-Schlüssel: `Content-Type`.
Weitere Informationen zu Einschränkungen zur Verwendung von Headern finden Sie unter [Einschränkungen für Edge-Funktionen](edge-functions-restrictions.md).

**`status`**  
Den HTTP-Statuscode . Geben Sie den Statuscode als Zeichenfolge an. CloudFront verwendet den bereitgestellten Statuscode für Folgendes:  
+ Rückgabe in der Antwort
+ Cache im CloudFront Edge-Cache, wenn die Antwort durch eine Funktion generiert wurde, die durch ein Origin-Request-Ereignis ausgelöst wurde
+ Loggen Sie sich ein CloudFront [Zugriffsprotokolle (Standardprotokolle)](AccessLogs.md)
Wenn der `status`-Wert nicht zwischen 200 und 599 liegt, gibt CloudFront einen Fehler an den Betrachter zurück.

**`statusDescription`**  
Die Beschreibung, die CloudFront Sie zusammen mit dem HTTP-Statuscode in der Antwort zurückgeben möchten. Sie müssen keine Standardbeschreibungen verwenden (z. B. `OK` für einen HTTP-Statuscode 200).

#### Fehler
<a name="lambda-generating-http-responses-errors"></a>

Es folgen mögliche Fehler für generierte HTTP-Antworten.

**Antwort enthält einen Body und legt 204 (No Content) als Status fest**  
Wenn eine Funktion durch eine Viewer-Anfrage ausgelöst wird, CloudFront gibt sie dem Viewer einen HTTP 502-Statuscode (Bad Gateway) zurück, wenn beide der folgenden Bedingungen zutreffen:  
+ Der Wert von `status` ist 204 (No Content)
+ Die Antwort enthält einen Wert für `body`
Der Grund hierfür ist, dass Lambda@Edge eine optionale Einschränkung aus RFC 2616 umsetzt, die besagt, dass eine `HTTP 204`-Antwort keinen Nachrichtentext zu enthalten braucht.

**Beschränkungen für die Größe der generierten Antwort**  
Die maximale Größe einer durch eine Lambda-Funktion generierten Antwort hängt von dem Ereignis ab, das die Funktion ausgelöst hat:  
+ **Viewer-Anfrage-Ereignisse** – 40 KB
+ **Ursprungsanfrageereignisse** – 1 MB
Wenn die Antwort größer als die zulässige Größe ist, wird ein HTTP 502-Statuscode (Bad Gateway) an den Betrachter CloudFront zurückgegeben.

#### Pflichtfelder
<a name="lambda-generating-http-responses-required-fields"></a>

Das Feld `status` ist ein Pflichtfeld. 

Alle anderen Felder sind optional.

## Aktualisieren von HTTP-Antworten in Ursprungsantwortauslösern
<a name="lambda-updating-http-responses"></a>

Wenn eine HTTP-Antwort vom Ursprungsserver CloudFront empfangen wird und ein Origin-Response-Trigger mit dem Cache-Verhalten verknüpft ist, können Sie die HTTP-Antwort so ändern, dass sie überschreibt, was vom Ursprung zurückgegeben wurde.

Einige häufige Szenarien für die Aktualisierung von HTTP-Antworten sind die folgenden:
+ Ändern des Status, um einen HTTP 200-Statuscode festzulegen, und Erstellen statischer Body-Inhalte für die Rückgabe an den Viewer, wenn ein Ursprung einen Fehlerstatuscode (4xx oder 5xx) zurückgibt. Einen Beispiel-Code finden Sie unter [Beispiel: Mithilfe eines Ursprungsantwortauslösers den Fehlerstatuscode auf 200 aktualisieren](lambda-examples.md#lambda-examples-custom-error-static-body).
+ Ändern des Status, um einen HTTP 301- oder HTTP 302-Statuscode festzulegen, um den Benutzer auf eine andere Website umzuleiten, wenn ein Ursprung einen Fehlerstatuscode zurückgibt (4xx oder 5xx). Einen Beispiel-Code finden Sie unter [Beispiel: Mithilfe eines Ursprungsantwortauslösers den Fehlerstatuscode auf 302 aktualisieren](lambda-examples.md#lambda-examples-custom-error-new-site).

**Anmerkung**  
Die Funktion muss einen Statuswert zwischen `200` und `599` (einschließlich) zurückgeben, andernfalls CloudFront gibt sie einen Fehler an den Viewer zurück.

Sie können auch die HTTP-Antworten in Viewer- und Ursprungsanfrageereignissen ersetzen. Weitere Informationen finden Sie unter [Generieren von HTTP-Antworten in Anforderungsauslösern](#lambda-generating-http-responses-in-requests).

Wenn Sie mit der HTTP-Antwort arbeiten, stellt Lambda@Edge den Textkörper, der vom Ursprungsserver zurückgegeben wird, nicht für den Ursprungsantwortauslöser bereit. Sie können einen statischen Inhaltstext erzeugen, indem Sie ihn auf den gewünschten Wert setzen, oder den Text innerhalb der Funktion entfernen, indem Sie den Wert auf leer setzen. Wenn Sie das Textkörperfeld in Ihrer Funktion nicht aktualisieren, wird der ursprüngliche Textkörper, der vom Ursprungsserver zurückgegeben wird, an den Viewer zurückgegeben.

## Zugriff auf den Anforderungstext über die Option „Text einschließen“
<a name="lambda-include-body-access"></a>

Sie können jetzt auswählen, ob Lambda@Edge den Textkörper in einer Anforderung für eine nicht schreibgeschützte HTTP-Methode (POST, PUT, DELETE etc.) weitergeben soll, sodass Sie in Ihrer Lambda-Funktion darauf zugreifen können. Sie können den Lesezugriff wählen oder angeben, dass Sie den Textkörper ersetzen möchten.

Um diese Option zu aktivieren, wählen Sie **Include Body (Body einbeziehen)** aus, wenn Sie einen CloudFront -Auslöser für Ihre für ein Betrachteranforderungs- oder Ursprungsanforderungsereignis vorgesehene Funktion erstellen. Weitere Informationen finden Sie unter [Hinzufügen von Auslösern für eine Lambda@Edge-Funktion](lambda-edge-add-triggers.md). Mehr zur Nutzung von **Include Body (Textkörper einbeziehen)** mit Ihrer Funktion finden Sie unter [Lambda@Edge-Ereignisstruktur](lambda-event-structure.md).

Sie können dieses Feature in den folgenden Szenarien nutzen:
+ Verarbeitung von Webformularen (z. B. "Kontakt"-Formulare) ohne Rückgabe von Kundeneingabedaten an den Ursprungs-Server
+ Erfassen von Web-Beacon-Daten, die von Viewer-Browsern gesendet werden, und Verarbeiten am Edge

Einen Beispiel-Code finden Sie unter [Beispielfunktionen für Lambda@Edge](lambda-examples.md).

**Anmerkung**  
Wenn der Anforderungs-Body groß ist, wird er von Lambda@Edge abgeschnitten. Ausführliche Informationen zur maximalen Größe und Kürzung finden Sie unter [Einschränkungen für Anforderungstext mit der Option „Text einschließen“](lambda-at-edge-function-restrictions.md#lambda-at-edge-restrictions-request-body).

# Beispielfunktionen für Lambda@Edge
<a name="lambda-examples"></a>

Sehen Sie sich die folgenden Beispiele für die Verwendung von Lambda-Funktionen mit Amazon CloudFront an.

**Anmerkung**  
Wenn Sie die Laufzeitumgebung Node.js 18 oder höher für Ihre Lambda@Edge-Funktion auswählen, wird automatisch eine `index.mjs`-Datei für Sie erstellt. Um die folgenden Codebeispiele zu verwenden, benennen Sie die `index.mjs`-Datei in `index.js` um.

**Topics**
+ [

## Allgemeine Beispiele
](#lambda-examples-general-examples)
+ [

## Generieren von Antworten – Beispiele
](#lambda-examples-generated-response-examples)
+ [

## Abfragezeichenfolgen – Beispiele
](#lambda-examples-query-string-examples)
+ [

## Personalisieren von Inhalten nach Land oder Gerätetyp-Header – Beispiele
](#lambda-examples-redirecting-examples)
+ [

## Inhaltsbasierte dynamische Ursprungsauswahl –Beispiele
](#lambda-examples-content-based-routing-examples)
+ [

## Aktualisieren von Fehlerstatusangaben – Beispiele
](#lambda-examples-update-error-status-examples)
+ [

## Zugriff auf den Anforderungstext – Beispiele
](#lambda-examples-access-request-body-examples)

## Allgemeine Beispiele
<a name="lambda-examples-general-examples"></a>

Die folgenden Beispiele zeigen gängige Verwendungsmöglichkeiten von Lambda @Edge in CloudFront.

**Topics**
+ [

### Beispiel: Testen A/B
](#lambda-examples-a-b-testing)
+ [

### Beispiel: Überschreiben eines Antwortheaders
](#lambda-examples-overriding-response-header)

### Beispiel: Testen A/B
<a name="lambda-examples-a-b-testing"></a>

Sie können das folgende Beispiel verwenden, um zwei verschiedene Versionen eines Images zu testen, ohne Weiterleitungen zu erstellen oder die URL zu ändern. In diesem Beispiel werden die Cookies in der Viewer-Anfrage gelesen und die Anforderungs-URL wird entsprechend geändert. Wenn der Betrachter kein Cookie mit einem der erwarteten Werte sendet, weist das Beispiel den Betrachter nach dem Zufallsprinzip einem der URLs folgenden zu.

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    if (request.uri !== '/experiment-pixel.jpg') {
        // do not process if this is not an A-B test request
        callback(null, request);
        return;
    }

    const cookieExperimentA = 'X-Experiment-Name=A';
    const cookieExperimentB = 'X-Experiment-Name=B';
    const pathExperimentA = '/experiment-group/control-pixel.jpg';
    const pathExperimentB = '/experiment-group/treatment-pixel.jpg';

    /*
     * Lambda at the Edge headers are array objects.
     *
     * Client may send multiple Cookie headers, i.e.:
     * > GET /viewerRes/test HTTP/1.1
     * > User-Agent: curl/7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.1 OpenSSL/1.0.1u zlib/1.2.3
     * > Cookie: First=1; Second=2
     * > Cookie: ClientCode=abc
     * > Host: example.com
     *
     * You can access the first Cookie header at headers["cookie"][0].value
     * and the second at headers["cookie"][1].value.
     *
     * Header values are not parsed. In the example above,
     * headers["cookie"][0].value is equal to "First=1; Second=2"
     */
    let experimentUri;
    if (headers.cookie) {
        for (let i = 0; i < headers.cookie.length; i++) {
            if (headers.cookie[i].value.indexOf(cookieExperimentA) >= 0) {
                console.log('Experiment A cookie found');
                experimentUri = pathExperimentA;
                break;
            } else if (headers.cookie[i].value.indexOf(cookieExperimentB) >= 0) {
                console.log('Experiment B cookie found');
                experimentUri = pathExperimentB;
                break;
            }
        }
    }

    if (!experimentUri) {
        console.log('Experiment cookie has not been found. Throwing dice...');
        if (Math.random() < 0.75) {
            experimentUri = pathExperimentA;
        } else {
            experimentUri = pathExperimentB;
        }
    }

    request.uri = experimentUri;
    console.log(`Request uri set to "${request.uri}"`);
    callback(null, request);
};
```

------
#### [ Python ]

```
import json
import random

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    if request['uri'] != '/experiment-pixel.jpg':
        # Not an A/B Test
        return request

    cookieExperimentA, cookieExperimentB = 'X-Experiment-Name=A', 'X-Experiment-Name=B'
    pathExperimentA, pathExperimentB = '/experiment-group/control-pixel.jpg', '/experiment-group/treatment-pixel.jpg'

    '''
    Lambda at the Edge headers are array objects.

    Client may send multiple cookie headers. For example:
    > GET /viewerRes/test HTTP/1.1
    > User-Agent: curl/7.18.1 (x86_64-unknown-linux-gnu) libcurl/7.18.1 OpenSSL/1.0.1u zlib/1.2.3
    > Cookie: First=1; Second=2
    > Cookie: ClientCode=abc
    > Host: example.com

    You can access the first Cookie header at headers["cookie"][0].value
    and the second at headers["cookie"][1].value.

    Header values are not parsed. In the example above,
    headers["cookie"][0].value is equal to "First=1; Second=2"
    '''

    experimentUri = ""

    for cookie in headers.get('cookie', []):
        if cookieExperimentA in cookie['value']:
            print("Experiment A cookie found")
            experimentUri = pathExperimentA
            break
        elif cookieExperimentB in cookie['value']:
            print("Experiment B cookie found")
            experimentUri = pathExperimentB
            break

    if not experimentUri:
        print("Experiment cookie has not been found. Throwing dice...")
        if random.random() < 0.75:
            experimentUri = pathExperimentA
        else:
            experimentUri = pathExperimentB

    request['uri'] = experimentUri
    print(f"Request uri set to {experimentUri}")
    return request
```

------

### Beispiel: Überschreiben eines Antwortheaders
<a name="lambda-examples-overriding-response-header"></a>

Das folgende Beispiel zeigt, wie Sie den Wert eines Antwortheaders basierend auf dem Wert eines anderen Headers modifizieren:

------
#### [ Node.js ]

```
export const handler = async (event) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;

    const headerNameSrc = 'X-Amz-Meta-Last-Modified';
    const headerNameDst = 'Last-Modified';

    if (headers[headerNameSrc.toLowerCase()]) {
        headers[headerNameDst.toLowerCase()] = [{
            key: headerNameDst,
            value: headers[headerNameSrc.toLowerCase()][0].value,
        }];
        console.log(`Response header "${headerNameDst}" was set to ` +
                    `"${headers[headerNameDst.toLowerCase()][0].value}"`);
    }

    return response;
};
```

------
#### [ Python ]

```
import json 

def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']
    headers = response['headers']
    
    header_name_src = 'X-Amz-Meta-Last-Modified'
    header_name_dst = 'Last-Modified'
    
    if headers.get(header_name_src.lower()):
        headers[header_name_dst.lower()] = [{
            'key': header_name_dst,
            'value': headers[header_name_src.lower()][0]['value']
        }]
        print(f'Response header "{header_name_dst}" was set to '
              f'"{headers[header_name_dst.lower()][0]["value"]}"')
    
    return response
```

------

## Generieren von Antworten – Beispiele
<a name="lambda-examples-generated-response-examples"></a>

Die folgenden Beispiele zeigen, wie Sie Lambda@Edge zum Generieren von Antworten verwenden können.

**Topics**
+ [

### Beispiel: Bereitstellen von statischen Inhalten (generierte Antwort)
](#lambda-examples-static-web-server)
+ [

### Beispiel: Generieren einer HTTP-Umleitung (generierte Antwort)
](#lambda-examples-http-redirect)

### Beispiel: Bereitstellen von statischen Inhalten (generierte Antwort)
<a name="lambda-examples-static-web-server"></a>

Das folgende Beispiel zeigt, wie Sie mit einer Lambda-Funktion Inhalte von statischen Websites bereitstellen können, wodurch sich die Verarbeitungslast auf dem Ursprungs-Server und die Latenz insgesamt verringert. 

**Anmerkung**  
Sie können HTTP-Antworten für Viewer-Anfrage- und Ursprungsanfrageereignisse generieren. Weitere Informationen finden Sie unter [Generieren von HTTP-Antworten in Anforderungsauslösern](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).  
Sie können auch den Text der HTTP-Antwort in Ursprungsantwortereignissen ersetzen oder entfernen. Weitere Informationen finden Sie unter [Aktualisieren von HTTP-Antworten in Ursprungsantwortauslösern](lambda-generating-http-responses.md#lambda-updating-http-responses).

------
#### [ Node.js ]

```
'use strict';

const content = `
<\!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Simple Lambda@Edge Static Content Response</title>
  </head>
  <body>
    <p>Hello from Lambda@Edge!</p>
  </body>
</html>
`;

exports.handler = (event, context, callback) => {
    /*
     * Generate HTTP OK response using 200 status code with HTML body.
     */
    const response = {
        status: '200',
        statusDescription: 'OK',
        headers: {
            'cache-control': [{
                key: 'Cache-Control',
                value: 'max-age=100'
            }],
            'content-type': [{
                key: 'Content-Type',
                value: 'text/html'
            }]
        },
        body: content,
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
import json

CONTENT = """
<\!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Simple Lambda@Edge Static Content Response</title>
</head>
<body>
    <p>Hello from Lambda@Edge!</p>
</body>
</html>
"""

def lambda_handler(event, context):
    # Generate HTTP OK response using 200 status code with HTML body.
    response = {
        'status': '200',
        'statusDescription': 'OK',
        'headers': {
            'cache-control': [
                {
                    'key': 'Cache-Control',
                    'value': 'max-age=100'
                }
            ],
            "content-type": [
                {
                    'key': 'Content-Type',
                    'value': 'text/html'
                }
            ]
        },
        'body': CONTENT
    }
    return response
```

------

### Beispiel: Generieren einer HTTP-Umleitung (generierte Antwort)
<a name="lambda-examples-http-redirect"></a>

Das folgende Beispiel zeigt, wie Sie eine HTTP-Umleitung generieren.

**Anmerkung**  
Sie können HTTP-Antworten für Viewer-Anfrage- und Ursprungsanfrageereignisse generieren. Weitere Informationen finden Sie unter [Generieren von HTTP-Antworten in Anforderungsauslösern](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    /*
     * Generate HTTP redirect response with 302 status code and Location header.
     */
    const response = {
        status: '302',
        statusDescription: 'Found',
        headers: {
            location: [{
                key: 'Location',
                value: 'https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html',
            }],
        },
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):

    # Generate HTTP redirect response with 302 status code and Location header.

    response = {
        'status': '302',
        'statusDescription': 'Found',
        'headers': {
            'location': [{
                'key': 'Location',
                'value': 'https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html'
            }]
        }
    }

    return response
```

------

## Abfragezeichenfolgen – Beispiele
<a name="lambda-examples-query-string-examples"></a>

Die folgenden Beispiele zeigen Möglichkeiten zur Verwendung von Lambda@Edge mit Abfragezeichenfolgen.

**Topics**
+ [

### Beispiel: Hinzufügen eines Headers auf Grundlage eines Abfragezeichenfolgeparameters
](#lambda-examples-header-based-on-query-string)
+ [

### Beispiel: Normalisieren von Abfragezeichenfolgeparametern zum Verbessern der Cache-Trefferrate
](#lambda-examples-normalize-query-string-parameters)
+ [

### Beispiel: Umleiten von nicht authentifizierten Benutzern auf eine Anmeldeseite
](#lambda-examples-redirect-to-signin-page)

### Beispiel: Hinzufügen eines Headers auf Grundlage eines Abfragezeichenfolgeparameters
<a name="lambda-examples-header-based-on-query-string"></a>

Im folgenden Beispiel wird gezeigt, wie Sie das Schlüssel-Wert-Paar eines Abfragezeichenfolgeparameter abrufen und auf Grundlage dieser Werte einen Header hinzufügen können.

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    
    /* When a request contains a query string key-value pair but the origin server
     * expects the value in a header, you can use this Lambda function to
     * convert the key-value pair to a header. Here's what the function does:
     * 1. Parses the query string and gets the key-value pair.
     * 2. Adds a header to the request using the key-value pair that the function got in step 1.
     */

    /* Parse request querystring to get javascript object */
    const params = querystring.parse(request.querystring);

    /* Move auth param from querystring to headers */
    const headerName = 'Auth-Header';
    request.headers[headerName.toLowerCase()] = [{ key: headerName, value: params.auth }];
    delete params.auth;

    /* Update request querystring */
    request.querystring = querystring.stringify(params);

    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs, urlencode

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    '''
    When a request contains a query string key-value pair but the origin server
    expects the value in a header, you can use this Lambda function to
    convert the key-value pair to a header. Here's what the function does:
        1. Parses the query string and gets the key-value pair.
        2. Adds a header to the request using the key-value pair that the function got in step 1.
    '''

    # Parse request querystring to get dictionary/json
    params = {k : v[0] for k, v in parse_qs(request['querystring']).items()}

    # Move auth param from querystring to headers
    headerName = 'Auth-Header'
    request['headers'][headerName.lower()] = [{'key': headerName, 'value': params['auth']}]
    del params['auth']

    # Update request querystring
    request['querystring'] = urlencode(params)

    return request
```

------

### Beispiel: Normalisieren von Abfragezeichenfolgeparametern zum Verbessern der Cache-Trefferrate
<a name="lambda-examples-normalize-query-string-parameters"></a>

Das folgende Beispiel zeigt, wie Sie Ihre Cache-Trefferquote verbessern können, indem Sie die folgenden Änderungen an Abfragezeichenfolgen vornehmen, bevor CloudFront Anfragen an Ihren Ursprung weitergeleitet werden:
+ Alphabetisches Anordnen von Schlüssel-Wert-Paaren nach dem Parametername.
+ Ändern der Schreibung von Schlüssel-Wert-Paaren in Kleinschreibung.

Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern](QueryStringParameters.md).

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    /* When you configure a distribution to forward query strings to the origin and
     * to cache based on an allowlist of query string parameters, we recommend
     * the following to improve the cache-hit ratio:
     * - Always list parameters in the same order.
     * - Use the same case for parameter names and values.
     *
     * This function normalizes query strings so that parameter names and values
     * are lowercase and parameter names are in alphabetical order.
     *
     * For more information, see:
     * https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html
     */

    console.log('Query String: ', request.querystring);

    /* Parse request query string to get javascript object */
    const params = querystring.parse(request.querystring.toLowerCase());
    const sortedParams = {};

    /* Sort param keys */
    Object.keys(params).sort().forEach(key => {
        sortedParams[key] = params[key];
    });

    /* Update request querystring with normalized  */
    request.querystring = querystring.stringify(sortedParams);

    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs, urlencode

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    '''
    When you configure a distribution to forward query strings to the origin and
    to cache based on an allowlist of query string parameters, we recommend
    the following to improve the cache-hit ratio:
    Always list parameters in the same order.
    - Use the same case for parameter names and values.

    This function normalizes query strings so that parameter names and values
    are lowercase and parameter names are in alphabetical order.

    For more information, see:
    https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html
    '''
    print("Query string: ", request["querystring"])

    # Parse request query string to get js object
    params = {k : v[0] for k, v in parse_qs(request['querystring'].lower()).items()}

    # Sort param keys
    sortedParams = sorted(params.items(), key=lambda x: x[0])

    # Update request querystring with normalized
    request['querystring'] = urlencode(sortedParams)
    
    return request
```

------

### Beispiel: Umleiten von nicht authentifizierten Benutzern auf eine Anmeldeseite
<a name="lambda-examples-redirect-to-signin-page"></a>

Im folgenden Beispiel wird gezeigt, wie Benutzer zu einer Anmeldeseite umgeleitet werden, wenn sie ihre Anmeldeinformationen nicht eingegeben haben.

------
#### [ Node.js ]

```
'use strict';

function parseCookies(headers) {
    const parsedCookie = {};
    if (headers.cookie) {
        headers.cookie[0].value.split(';').forEach((cookie) => {
            if (cookie) {
                const parts = cookie.split('=');
                parsedCookie[parts[0].trim()] = parts[1].trim();
            }
        });
    }
    return parsedCookie;
}

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    /* Check for session-id in request cookie in viewer-request event,
     * if session-id is absent, redirect the user to sign in page with original
     * request sent as redirect_url in query params.
     */

    /* Check for session-id in cookie, if present then proceed with request */
    const parsedCookies = parseCookies(headers);
    if (parsedCookies && parsedCookies['session-id']) {
        callback(null, request);
        return;
    }

    /* URI encode the original request to be sent as redirect_url in query params */
    const encodedRedirectUrl = encodeURIComponent(`https://${headers.host[0].value}${request.uri}?${request.querystring}`);
    const response = {
        status: '302',
        statusDescription: 'Found',
        headers: {
            location: [{
                key: 'Location',
                value: `https://www.example.com/signin?redirect_url=${encodedRedirectUrl}`,
            }],
        },
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
import urllib

def parseCookies(headers):
    parsedCookie = {}
    if headers.get('cookie'):
        for cookie in headers['cookie'][0]['value'].split(';'):
            if cookie:
                parts = cookie.split('=')
                parsedCookie[parts[0].strip()] = parts[1].strip()
    return parsedCookie

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    '''
    Check for session-id in request cookie in viewer-request event,
    if session-id is absent, redirect the user to sign in page with original
    request sent as redirect_url in query params.
    '''

    # Check for session-id in cookie, if present, then proceed with request
    parsedCookies = parseCookies(headers)

    if parsedCookies and parsedCookies['session-id']:
        return request

    # URI encode the original request to be sent as redirect_url in query params
    redirectUrl = "https://%s%s?%s" % (headers['host'][0]['value'], request['uri'], request['querystring'])
    encodedRedirectUrl = urllib.parse.quote_plus(redirectUrl.encode('utf-8'))

    response = {
        'status': '302',
        'statusDescription': 'Found',
        'headers': {
            'location': [{
                'key': 'Location',
                'value': 'https://www.example.com/signin?redirect_url=%s' % encodedRedirectUrl
            }]
        }
    }
    return response
```

------

## Personalisieren von Inhalten nach Land oder Gerätetyp-Header – Beispiele
<a name="lambda-examples-redirecting-examples"></a>

Die folgenden Beispiele zeigen, wie Sie mit Lambda@Edge das Verhalten basierend auf dem Standort oder dem Typ des Geräts anpassen können, das vom jeweiligen Viewer verwendet wird.

**Topics**
+ [

### Beispiel: Umleiten von Viewer-Anforderungen an eine länderspezifische URL
](#lambda-examples-redirect-based-on-country)
+ [

### Beispiel: Bereitstellen verschiedener Versionen eines Objekts auf Grundlage des Geräts
](#lambda-examples-vary-on-device-type)

### Beispiel: Umleiten von Viewer-Anforderungen an eine länderspezifische URL
<a name="lambda-examples-redirect-based-on-country"></a>

Im folgenden Beispiel wird gezeigt, wie eine HTTP-Umleitungsantwort mit einer länderspezifischen URL erzeugt und die Antwort an den Viewer zurückgegeben wird. Dies ist nützlich, wenn Sie länderspezifische Antworten bereitstellen möchten. Beispiel:
+ Wenn Sie über länderspezifischen Subdomänen verfügen, z. B. us.example.com und tw.example.com, können Sie eine Umleitungsantwort erzeugen, wenn ein Viewer example.com anfordert.
+ Wenn Sie Videos streamen, aber keine Rechte für das Streamen von Inhalten in einem bestimmten Land besitzen, können Sie Benutzer in diesem Land auf eine Seite umleiten, auf der erklärt wird, warum sie das Video nicht ansehen können. 

Beachten Sie Folgendes:
+ Sie müssen Ihre Verteilung so konfigurieren, dass die Zwischenspeicherung auf Grundlage des `CloudFront-Viewer-Country`-Headers erfolgt. Weitere Informationen finden Sie unter [Basierend auf den ausgewählten Anforderungsheadern](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).
+ CloudFront fügt den `CloudFront-Viewer-Country` Header nach dem Viewer-Anforderungsereignis hinzu. Wenn Sie dieses Beispiel verwenden möchten, müssen Sie einen Auslöser für das ursprüngliche Anfrageereignis erstellen.

------
#### [ Node.js ]

```
'use strict';

/* This is an origin request function */
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    /*
     * Based on the value of the CloudFront-Viewer-Country header, generate an
     * HTTP status code 302 (Redirect) response, and return a country-specific
     * URL in the Location header.
     * NOTE: 1. You must configure your distribution to cache based on the
     *          CloudFront-Viewer-Country header. For more information, see
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
     *       2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
     *          request event. To use this example, you must create a trigger for the
     *          origin request event.
     */

    let url = 'https://example.com/';
    if (headers['cloudfront-viewer-country']) {
        const countryCode = headers['cloudfront-viewer-country'][0].value;
        if (countryCode === 'TW') {
            url = 'https://tw.example.com/';
        } else if (countryCode === 'US') {
            url = 'https://us.example.com/';
        }
    }

    const response = {
        status: '302',
        statusDescription: 'Found',
        headers: {
            location: [{
                key: 'Location',
                value: url,
            }],
        },
    };
    callback(null, response);
};
```

------
#### [ Python ]

```
# This is an origin request function

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    '''
    Based on the value of the CloudFront-Viewer-Country header, generate an
    HTTP status code 302 (Redirect) response, and return a country-specific
    URL in the Location header.
    NOTE: 1. You must configure your distribution to cache based on the
            CloudFront-Viewer-Country header. For more information, see
            https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
          2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
            request event. To use this example, you must create a trigger for the
            origin request event.
    '''

    url = 'https://example.com/'
    viewerCountry = headers.get('cloudfront-viewer-country')
    if viewerCountry:
        countryCode = viewerCountry[0]['value']
        if countryCode == 'TW':
            url = 'https://tw.example.com/'
        elif countryCode == 'US':
            url = 'https://us.example.com/'

    response = {
        'status': '302',
        'statusDescription': 'Found',
        'headers': {
            'location': [{
                'key': 'Location',
                'value': url
            }]
        }
    }

    return response
```

------

### Beispiel: Bereitstellen verschiedener Versionen eines Objekts auf Grundlage des Geräts
<a name="lambda-examples-vary-on-device-type"></a>

Das folgende Beispiel zeigt, wie Sie für verschiedene Versionen eines Objekts auf Grundlage des Gerätetyps, den der Benutzer verwendet (z. B. ein mobiles Gerät oder ein Tablet), bereitstellen. Beachten Sie Folgendes:
+ Sie müssen Ihre Verteilung so konfigurieren, dass die Zwischenspeicherung auf Grundlage der `CloudFront-Is-*-Viewer`-Header erfolgt. Weitere Informationen finden Sie unter [Basierend auf den ausgewählten Anforderungsheadern](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).
+ CloudFront fügt die `CloudFront-Is-*-Viewer` Header nach dem Viewer-Anforderungsereignis hinzu. Wenn Sie dieses Beispiel verwenden möchten, müssen Sie einen Auslöser für das ursprüngliche Anfrageereignis erstellen.

------
#### [ Node.js ]

```
'use strict';

/* This is an origin request function */
exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    /*
     * Serve different versions of an object based on the device type.
     * NOTE: 1. You must configure your distribution to cache based on the
     *          CloudFront-Is-*-Viewer headers. For more information, see
     *          the following documentation:
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-device-type
     *       2. CloudFront adds the CloudFront-Is-*-Viewer headers after the viewer
     *          request event. To use this example, you must create a trigger for the
     *          origin request event.
     */

    const desktopPath = '/desktop';
    const mobilePath = '/mobile';
    const tabletPath = '/tablet';
    const smarttvPath = '/smarttv';

    if (headers['cloudfront-is-desktop-viewer']
        && headers['cloudfront-is-desktop-viewer'][0].value === 'true') {
        request.uri = desktopPath + request.uri;
    } else if (headers['cloudfront-is-mobile-viewer']
               && headers['cloudfront-is-mobile-viewer'][0].value === 'true') {
        request.uri = mobilePath + request.uri;
    } else if (headers['cloudfront-is-tablet-viewer']
               && headers['cloudfront-is-tablet-viewer'][0].value === 'true') {
        request.uri = tabletPath + request.uri;
    } else if (headers['cloudfront-is-smarttv-viewer']
               && headers['cloudfront-is-smarttv-viewer'][0].value === 'true') {
        request.uri = smarttvPath + request.uri;
    }
    console.log(`Request uri set to "${request.uri}"`);

    callback(null, request);
};
```

------
#### [ Python ]

```
# This is an origin request function
def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']

    '''
    Serve different versions of an object based on the device type.
    NOTE: 1. You must configure your distribution to cache based on the
            CloudFront-Is-*-Viewer headers. For more information, see
            the following documentation:
            https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
            https://docs.aws.amazon.com/console/cloudfront/cache-on-device-type
          2. CloudFront adds the CloudFront-Is-*-Viewer headers after the viewer
            request event. To use this example, you must create a trigger for the
            origin request event.
    '''

    desktopPath = '/desktop';
    mobilePath = '/mobile';
    tabletPath = '/tablet';
    smarttvPath = '/smarttv';

    if 'cloudfront-is-desktop-viewer' in headers and headers['cloudfront-is-desktop-viewer'][0]['value'] == 'true':
        request['uri'] = desktopPath + request['uri']
    elif 'cloudfront-is-mobile-viewer' in headers and headers['cloudfront-is-mobile-viewer'][0]['value'] == 'true':
        request['uri'] = mobilePath + request['uri']
    elif 'cloudfront-is-tablet-viewer' in headers and headers['cloudfront-is-tablet-viewer'][0]['value'] == 'true':
        request['uri'] = tabletPath + request['uri']
    elif 'cloudfront-is-smarttv-viewer' in headers and headers['cloudfront-is-smarttv-viewer'][0]['value'] == 'true':
        request['uri'] = smarttvPath + request['uri']

    print("Request uri set to %s" % request['uri'])

    return request
```

------

## Inhaltsbasierte dynamische Ursprungsauswahl –Beispiele
<a name="lambda-examples-content-based-routing-examples"></a>

Die folgenden Beispiele zeigen, wie Sie Lambda@Edge zur Weiterleitung an verschiedene Ursprünge basierend auf Informationen in der Anforderung verwenden können.

**Topics**
+ [

### Beispiel: Mithilfe eines Ursprungsanforderungsauslösers von einem benutzerdefinierten Ursprung zu einem Amazon-S3-Ursprung wechseln
](#lambda-examples-content-based-S3-origin-based-on-query)
+ [

### Beispiel: Ändern der Amazon-S3-Ursprungsregion mithilfe eines Ursprungsanforderungsauslösers
](#lambda-examples-content-based-S3-origin-request-trigger)
+ [

### Beispiel: Mithilfe eines Ursprungsanforderungsauslösers von einem Amazon-S3-Ursprung zu einem benutzerdefinierten Ursprung wechseln
](#lambda-examples-content-based-custom-origin-request-trigger)
+ [

### Beispiel: Verwenden eines Ursprungsanforderungsauslösers zur schrittweisen Übertragung von Netzwerkverkehr von einem Amazon-S3-Bucket zu einem anderen
](#lambda-examples-content-based-gradual-traffic-transfer)
+ [

### Beispiel: Verwenden eines Ursprungsanforderungsauslösers zum Ändern des Ursprungsdomainnamens anhand des Landes-Headers
](#lambda-examples-content-based-geo-header)

### Beispiel: Mithilfe eines Ursprungsanforderungsauslösers von einem benutzerdefinierten Ursprung zu einem Amazon-S3-Ursprung wechseln
<a name="lambda-examples-content-based-S3-origin-based-on-query"></a>

Diese Funktion demonstriert, wie mit Hilfe eines Ursprungsanforderungsauslösers von einem benutzerdefinierten Ursprung zu einem Amazon S3-Ursprung gewechselt werden kann, von dem der Inhalt auf Basis der Anforderungseigenschaften abgerufen wird.

------
#### [ Node.js ]

```
'use strict';

 const querystring = require('querystring');
 
 exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
 
     /**
      * Reads query string to check if S3 origin should be used, and
      * if true, sets S3 origin properties.
      */
 
     const params = querystring.parse(request.querystring);
 
     if (params['useS3Origin']) {
         if (params['useS3Origin'] === 'true') {
             const s3DomainName = 'amzn-s3-demo-bucket.s3.amazonaws.com';
 
             /* Set S3 origin fields */
             request.origin = {
                 s3: {
                     domainName: s3DomainName,
                     region: '',
                     authMethod: 'origin-access-identity',
                     path: '',
                     customHeaders: {}
                 }
             };
             request.headers['host'] = [{ key: 'host', value: s3DomainName}];
         }
     }
     
    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    '''
    Reads query string to check if S3 origin should be used, and
    if true, sets S3 origin properties
    '''
    params = {k: v[0] for k, v in parse_qs(request['querystring']).items()}
    if params.get('useS3Origin') == 'true':
        s3DomainName = 'amzn-s3-demo-bucket.s3.amazonaws.com'

        # Set S3 origin fields
        request['origin'] = {
            's3': {
                'domainName': s3DomainName,
                'region': '',
                'authMethod': 'origin-access-identity',
                'path': '',
                'customHeaders': {}
            }
        }
        request['headers']['host'] = [{'key': 'host', 'value': s3DomainName}]
    return request
```

------

### Beispiel: Ändern der Amazon-S3-Ursprungsregion mithilfe eines Ursprungsanforderungsauslösers
<a name="lambda-examples-content-based-S3-origin-request-trigger"></a>

Diese Funktion demonstriert, wie mit Hilfe eines Ursprungsanforderungsauslösers von einem Amazon S3-Ursprung gewechselt werden kann, von dem der Inhalt auf Basis der Anforderungseigenschaften abgerufen wird.

In diesem Beispiel verwenden wir den Wert des `CloudFront-Viewer-Country`-Headers zum Aktualisieren des S3-Bucket-Domänennamens auf einen Bucket in einer Region, die sich näher am Viewer befindet. Dies kann auf verschiedene Weise nützlich sein:
+ Es werden Latenzen reduziert, wenn die angegebene Region näher am Land des Viewers liegt.
+ Es sorgt für Datenhoheit, indem es sicherstellt, dass die Daten aus einem Ursprung stammen, der in dem Land liegt, aus dem die Anfrage stammt.

In diesem Beispiel gehen Sie wie folgt vor:
+ Konfigurieren Sie Ihre Verteilung so, dass die Zwischenspeicherung auf Grundlage des `CloudFront-Viewer-Country`-Headers erfolgt. Weitere Informationen finden Sie unter [Basierend auf den ausgewählten Anforderungsheadern](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders). 
+ Erstellen Sie einen Trigger für diese Funktion im ursprünglichen Anforderungsereignis. CloudFrontfügt den `CloudFront-Viewer-Country` Header nach dem Viewer-Anforderungsereignis hinzu. Um dieses Beispiel zu verwenden, müssen Sie also sicherstellen, dass die Funktion für eine ursprüngliche Anfrage ausgeführt wird.

**Anmerkung**  
Der folgende Beispielcode verwendet dieselbe Ursprungszugriffsidentität (OAI) für alle S3-Buckets, die Sie für Ihren Ursprung verwenden. Weitere Informationen finden Sie unter [Ursprungszugriffsidentitäten](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    /**
     * This blueprint demonstrates how an origin-request trigger can be used to
     * change the origin from which the content is fetched, based on request properties.
     * In this example, we use the value of the CloudFront-Viewer-Country header
     * to update the S3 bucket domain name to a bucket in a Region that is closer to
     * the viewer.
     * 
     * This can be useful in several ways:
     *      1) Reduces latencies when the Region specified is nearer to the viewer's
     *         country.
     *      2) Provides data sovereignty by making sure that data is served from an
     *         origin that's in the same country that the request came from.
     * 
     * NOTE: 1. You must configure your distribution to cache based on the
     *          CloudFront-Viewer-Country header. For more information, see
     *          https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
     *       2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
     *          request event. To use this example, you must create a trigger for the
     *          origin request event.
     */

    const countryToRegion = {
        'DE': 'eu-central-1',
        'IE': 'eu-west-1',
        'GB': 'eu-west-2',
        'FR': 'eu-west-3',
        'JP': 'ap-northeast-1',
        'IN': 'ap-south-1'
    };

    if (request.headers['cloudfront-viewer-country']) {
        const countryCode = request.headers['cloudfront-viewer-country'][0].value;
        const region = countryToRegion[countryCode];
        
        /**
         * If the viewer's country is not in the list you specify, the request
         * goes to the default S3 bucket you've configured.
         */  
        if (region) {
            /**
             * If you've set up OAI, the bucket policy in the destination bucket
             * should allow the OAI GetObject operation, as configured by default
             * for an S3 origin with OAI. Another requirement with OAI is to provide
             * the Region so it can be used for the SIGV4 signature. Otherwise, the
             * Region is not required.
             */
            request.origin.s3.region = region;
            const domainName = `amzn-s3-demo-bucket-in-${region}.s3.${region}.amazonaws.com`;
            request.origin.s3.domainName = domainName;
            request.headers['host'] = [{ key: 'host', value: domainName }];
        }
    }

    callback(null, request);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    '''
    This blueprint demonstrates how an origin-request trigger can be used to
    change the origin from which the content is fetched, based on request properties.
    In this example, we use the value of the CloudFront-Viewer-Country header
    to update the S3 bucket domain name to a bucket in a Region that is closer to
    the viewer.
    
    This can be useful in several ways:
        1) Reduces latencies when the Region specified is nearer to the viewer's
            country.
        2) Provides data sovereignty by making sure that data is served from an
            origin that's in the same country that the request came from.
    
    NOTE: 1. You must configure your distribution to cache based on the
            CloudFront-Viewer-Country header. For more information, see
            https://docs.aws.amazon.com/console/cloudfront/cache-on-selected-headers
          2. CloudFront adds the CloudFront-Viewer-Country header after the viewer
            request event. To use this example, you must create a trigger for the
            origin request event.
    '''

    countryToRegion = {
        'DE': 'eu-central-1',
        'IE': 'eu-west-1',
        'GB': 'eu-west-2',
        'FR': 'eu-west-3',
        'JP': 'ap-northeast-1',
        'IN': 'ap-south-1'
    }

    viewerCountry = request['headers'].get('cloudfront-viewer-country')
    if viewerCountry:
        countryCode = viewerCountry[0]['value']
        region = countryToRegion.get(countryCode)

        # If the viewer's country in not in the list you specify, the request
        # goes to the default S3 bucket you've configured
        if region:
            '''
            If you've set up OAI, the bucket policy in the destination bucket
            should allow the OAI GetObject operation, as configured by default
            for an S3 origin with OAI. Another requirement with OAI is to provide
            the Region so it can be used for the SIGV4 signature. Otherwise, the
            Region is not required.
            '''
            request['origin']['s3']['region'] = region
            domainName = 'amzn-s3-demo-bucket-in-{0}.s3.{0}.amazonaws.com'.format(region)
            request['origin']['s3']['domainName'] = domainName
            request['headers']['host'] = [{'key': 'host', 'value': domainName}]

    return request
```

------

### Beispiel: Mithilfe eines Ursprungsanforderungsauslösers von einem Amazon-S3-Ursprung zu einem benutzerdefinierten Ursprung wechseln
<a name="lambda-examples-content-based-custom-origin-request-trigger"></a>

Diese Funktion demonstriert, wie mit Hilfe eines Ursprungsanforderungsauslösers von einem benutzerdefinierten Ursprung gewechselt werden kann, von dem der Inhalt auf Basis der Anforderungseigenschaften abgerufen wird.

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');
 
 exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
 
     /**
      * Reads query string to check if custom origin should be used, and
      * if true, sets custom origin properties.
      */
 
     const params = querystring.parse(request.querystring);
 
     if (params['useCustomOrigin']) {
         if (params['useCustomOrigin'] === 'true') {
 
             /* Set custom origin fields*/
             request.origin = {
                 custom: {
                     domainName: 'www.example.com',
                     port: 443,
                     protocol: 'https',
                     path: '',
                     sslProtocols: ['TLSv1', 'TLSv1.1'],
                     readTimeout: 5,
                     keepaliveTimeout: 5,
                     customHeaders: {}
                 }
             };
             request.headers['host'] = [{ key: 'host', value: 'www.example.com'}];
         }
     }
    callback(null, request);
};
```

------
#### [ Python ]

```
from urllib.parse import parse_qs

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    # Reads query string to check if custom origin should be used, and
    # if true, sets custom origin properties

    params = {k: v[0] for k, v in parse_qs(request['querystring']).items()}

    if params.get('useCustomOrigin') == 'true':
            # Set custom origin fields
            request['origin'] = {
                'custom': {
                    'domainName': 'www.example.com',
                    'port': 443,
                    'protocol': 'https',
                    'path': '',
                    'sslProtocols': ['TLSv1', 'TLSv1.1'],
                    'readTimeout': 5,
                    'keepaliveTimeout': 5,
                    'customHeaders': {}
                }
            }
            request['headers']['host'] = [{'key': 'host', 'value': 'www.example.com'}]

    return request
```

------

### Beispiel: Verwenden eines Ursprungsanforderungsauslösers zur schrittweisen Übertragung von Netzwerkverkehr von einem Amazon-S3-Bucket zu einem anderen
<a name="lambda-examples-content-based-gradual-traffic-transfer"></a>

Diese Funktion demonstriert, wie Sie schrittweise und kontrolliert den Datenverkehr von einem Amazon-S3-Bucket zu einem anderen übertragen können.

------
#### [ Node.js ]

```
'use strict';

    function getRandomInt(min, max) {
        /* Random number is inclusive of min and max*/
        return Math.floor(Math.random() * (max - min + 1)) + min;
 }

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const BLUE_TRAFFIC_PERCENTAGE = 80;

    /**
      * This Lambda function demonstrates how to gradually transfer traffic from
      * one S3 bucket to another in a controlled way.
      * We define a variable BLUE_TRAFFIC_PERCENTAGE which can take values from
      * 1 to 100. If the generated randomNumber less than or equal to BLUE_TRAFFIC_PERCENTAGE, traffic
      * is re-directed to blue-bucket. If not, the default bucket that we've configured
      * is used.
      */

    const randomNumber = getRandomInt(1, 100);

if (randomNumber <= BLUE_TRAFFIC_PERCENTAGE) {
         const domainName = 'blue-bucket.s3.amazonaws.com';
         request.origin.s3.domainName = domainName;
         request.headers['host'] = [{ key: 'host', value: domainName}];
     }
    callback(null, request);
};
```

------
#### [ Python ]

```
import math
import random

def getRandomInt(min, max):
    # Random number is inclusive of min and max
    return math.floor(random.random() * (max - min + 1)) + min

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    BLUE_TRAFFIC_PERCENTAGE = 80

    '''
    This Lambda function demonstrates how to gradually transfer traffic from
    one S3 bucket to another in a controlled way.
    We define a variable BLUE_TRAFFIC_PERCENTAGE which can take values from
    1 to 100. If the generated randomNumber less than or equal to BLUE_TRAFFIC_PERCENTAGE, traffic
    is re-directed to blue-bucket. If not, the default bucket that we've configured
    is used.
    '''

    randomNumber = getRandomInt(1, 100)

    if randomNumber <= BLUE_TRAFFIC_PERCENTAGE:
        domainName = 'blue-bucket.s3.amazonaws.com'
        request['origin']['s3']['domainName'] = domainName
        request['headers']['host'] = [{'key': 'host', 'value': domainName}]

    return request
```

------

### Beispiel: Verwenden eines Ursprungsanforderungsauslösers zum Ändern des Ursprungsdomainnamens anhand des Landes-Headers
<a name="lambda-examples-content-based-geo-header"></a>

Diese Funktion demonstriert, wie Sie den Ursprungsdomänennamen, basierend auf dem `CloudFront-Viewer-Country`-Header, ändern können, sodass der Inhalt von einem Ursprungsland aus bereitgestellt wird, das näher am Land des Viewers liegt.

Die Implementierung dieser Funktionalität für Ihre Verteilung bietet u. a. ggf. folgende Vorteile:
+ Es werden Latenzen reduziert, wenn die angegebene Region näher am Land des Viewers liegt.
+ Es wird für Datenhoheit gesorgt, indem sichergestellt wird, dass die Daten aus einem Ursprung stammen, der in dem Land liegt, aus dem die Anfrage stammt

Beachten Sie, dass Sie Ihre Verteilung für die Zwischenspeicherung auf Basis des `CloudFront-Viewer-Country`-Headers konfigurieren müssen, um diese Funktionalität zu aktivieren. Weitere Informationen finden Sie unter [Basierend auf den ausgewählten Anforderungsheadern](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
     const request = event.Records[0].cf.request;
     
  if (request.headers['cloudfront-viewer-country']) {
         const countryCode = request.headers['cloudfront-viewer-country'][0].value;
         if (countryCode === 'GB' || countryCode === 'DE' || countryCode === 'IE' ) {
             const domainName = 'eu.example.com';
             request.origin.custom.domainName = domainName;
             request.headers['host'] = [{key: 'host', value: domainName}];
         } 
     }
     
    callback(null, request);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    viewerCountry = request['headers'].get('cloudfront-viewer-country')
    if viewerCountry:
        countryCode = viewerCountry[0]['value']
        if countryCode == 'GB' or countryCode == 'DE' or countryCode == 'IE':
            domainName = 'eu.example.com'
            request['origin']['custom']['domainName'] = domainName
            request['headers']['host'] = [{'key': 'host', 'value': domainName}]
    return request
```

------

## Aktualisieren von Fehlerstatusangaben – Beispiele
<a name="lambda-examples-update-error-status-examples"></a>

Die folgenden Beispiele leiten Sie bei der Verwendung von Lambda@Edge zum Ändern des an Benutzer zurückgegebenen Fehlerstatus an.

**Topics**
+ [

### Beispiel: Mithilfe eines Ursprungsantwortauslösers den Fehlerstatuscode auf 200 aktualisieren
](#lambda-examples-custom-error-static-body)
+ [

### Beispiel: Mithilfe eines Ursprungsantwortauslösers den Fehlerstatuscode auf 302 aktualisieren
](#lambda-examples-custom-error-new-site)

### Beispiel: Mithilfe eines Ursprungsantwortauslösers den Fehlerstatuscode auf 200 aktualisieren
<a name="lambda-examples-custom-error-static-body"></a>

Diese Funktion demonstriert, wie Sie den Antwortstatus auf 200 aktualisieren und statischen Body-Content für die Rückgabe an den Viewer generieren können:
+ Die Funktion wird in einer Ursprungsantwort ausgelöst.
+ Der Antwortstatus vom Ursprungs-Server ist ein Fehlerstatuscode (4xx oder 5xx).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    /**
     * This function updates the response status to 200 and generates static
     * body content to return to the viewer in the following scenario:
     * 1. The function is triggered in an origin response
     * 2. The response status from the origin server is an error status code (4xx or 5xx)
     */

    if (response.status >= 400 && response.status <= 599) {
        response.status = 200;
        response.statusDescription = 'OK';
        response.body = 'Body generation example';
    }

    callback(null, response);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']

    '''
    This function updates the response status to 200 and generates static
    body content to return to the viewer in the following scenario:
    1. The function is triggered in an origin response
    2. The response status from the origin server is an error status code (4xx or 5xx)
    '''

    if int(response['status']) >= 400 and int(response['status']) <= 599:
        response['status'] = 200
        response['statusDescription'] = 'OK'
        response['body'] = 'Body generation example'
    return response
```

------

### Beispiel: Mithilfe eines Ursprungsantwortauslösers den Fehlerstatuscode auf 302 aktualisieren
<a name="lambda-examples-custom-error-new-site"></a>

Diese Funktion demonstriert, wie Sie den HTTP-Statuscode auf 302 aktualisieren können, um ihn auf einen anderen Pfad (Cache-Verhalten) umzuleiten, der einen anderen Ursprung hat. Beachten Sie Folgendes:
+ Die Funktion wird in einer Ursprungsantwort ausgelöst.
+ Der Antwortstatus vom Ursprungs-Server ist ein Fehlerstatuscode (4xx oder 5xx).

------
#### [ Node.js ]

```
'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const request = event.Records[0].cf.request;

    /**
     * This function updates the HTTP status code in the response to 302, to redirect to another
     * path (cache behavior) that has a different origin configured. Note the following:
     * 1. The function is triggered in an origin response
     * 2. The response status from the origin server is an error status code (4xx or 5xx)
     */

    if (response.status >= 400 && response.status <= 599) {
        const redirect_path = `/plan-b/path?${request.querystring}`;

        response.status = 302;
        response.statusDescription = 'Found';

        /* Drop the body, as it is not required for redirects */
        response.body = '';
        response.headers['location'] = [{ key: 'Location', value: redirect_path }];
    }

    callback(null, response);
};
```

------
#### [ Python ]

```
def lambda_handler(event, context):
    response = event['Records'][0]['cf']['response']
    request = event['Records'][0]['cf']['request']

    '''
    This function updates the HTTP status code in the response to 302, to redirect to another
    path (cache behavior) that has a different origin configured. Note the following:
    1. The function is triggered in an origin response
    2. The response status from the origin server is an error status code (4xx or 5xx)
    '''

    if int(response['status']) >= 400 and int(response['status']) <= 599:
        redirect_path = '/plan-b/path?%s' % request['querystring']

        response['status'] = 302
        response['statusDescription'] = 'Found'

        # Drop the body as it is not required for redirects
        response['body'] = ''
        response['headers']['location'] = [{'key': 'Location', 'value': redirect_path}]

    return response
```

------

## Zugriff auf den Anforderungstext – Beispiele
<a name="lambda-examples-access-request-body-examples"></a>

Die folgenden Beispiele veranschaulichen, wie Sie Lambda@Edge für die Arbeit mit POST-Anforderungen verwenden können.

**Anmerkung**  
Um diese Beispiele zu verwenden, müssen Sie die Option *Textkörper einschließen* in der Lambda-Funktionszuordnung der Verteilung aktivieren. Sie ist standardmäßig nicht aktiviert.  
Um diese Einstellung in der CloudFront Konsole zu aktivieren, aktivieren Sie das Kontrollkästchen **Body in the **Lambda Function Association** einbeziehen**.
Um diese Einstellung in der CloudFront API oder mit zu aktivieren CloudFormation, setzen Sie das `IncludeBody` Feld auf `true` in`LambdaFunctionAssociation`.

**Topics**
+ [

### Beispiel: Verwenden eines Anforderungsauslösers zum Lesen eines HTML-Formulars
](#lambda-examples-access-request-body-examples-read)
+ [

### Beispiel: Verwenden eines Anforderungsauslösers zum Bearbeiten eines HTML-Formulars
](#lambda-examples-access-request-body-examples-replace)

### Beispiel: Verwenden eines Anforderungsauslösers zum Lesen eines HTML-Formulars
<a name="lambda-examples-access-request-body-examples-read"></a>

Diese Funktion zeigt, wie Sie den Body einer POST-Anforderung verarbeiten können, die durch ein HTML-Formular (Webformular) erzeugt wird (z. B. ein "Kontaktformular"). Beispielsweise könnten Sie ein HTML-Formular wie das Folgende nutzen:

```
<html>
  <form action="https://example.com" method="post">
    Param 1: <input type="text" name="name1"><br>
    Param 2: <input type="text" name="name2"><br>
    input type="submit" value="Submit">
  </form>
</html>
```

Für die folgende Beispielfunktion muss die Funktion in einer CloudFront -Betrachteranforderung oder -Ursprungsanforderung ausgelöst werden.

------
#### [ Node.js ]

```
'use strict';

const querystring = require('querystring');

/**
 * This function demonstrates how you can read the body of a POST request 
 * generated by an HTML form (web form). The function is triggered in a
 * CloudFront viewer request or origin request event type.
 */

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    if (request.method === 'POST') {
        /* HTTP body is always passed as base64-encoded string. Decode it. */
        const body = Buffer.from(request.body.data, 'base64').toString();
 
        /* HTML forms send the data in query string format. Parse it. */
        const params = querystring.parse(body);
 
        /* For demonstration purposes, we only log the form fields here.
         * You can put your custom logic here. For example, you can store the 
         * fields in a database, such as Amazon DynamoDB, and generate a response
         * right from your Lambda@Edge function.
         */
        for (let param in params) {
            console.log(`For "${param}" user submitted "${params[param]}".\n`);
        }
    }
    return callback(null, request);
};
```

------
#### [ Python ]

```
import base64
from urllib.parse import parse_qs

'''
Say there is a POST request body generated by an HTML such as:

<html>
<form action="https://example.com" method="post">
    Param 1: <input type="text" name="name1"><br>
    Param 2: <input type="text" name="name2"><br>
    input type="submit" value="Submit">
</form>
</html>

'''

'''
This function demonstrates how you can read the body of a POST request 
generated by an HTML form (web form). The function is triggered in a
CloudFront viewer request or origin request event type.
'''

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']

    if request['method'] == 'POST':
        # HTTP body is always passed as base64-encoded string. Decode it
        body = base64.b64decode(request['body']['data'])

        # HTML forms send the data in query string format. Parse it
        params = {k: v[0] for k, v in parse_qs(body).items()}

        '''
        For demonstration purposes, we only log the form fields here.
        You can put your custom logic here. For example, you can store the
        fields in a database, such as Amazon DynamoDB, and generate a response
        right from your Lambda@Edge function.
        '''
        for key, value in params.items():
            print("For %s use submitted %s" % (key, value))
            
    return request
```

------

### Beispiel: Verwenden eines Anforderungsauslösers zum Bearbeiten eines HTML-Formulars
<a name="lambda-examples-access-request-body-examples-replace"></a>

Diese Funktion zeigt, wie Sie den Body einer POST-Anforderung bearbeiten können, die durch ein HTML-Formular (Webformular) erzeugt wird. Die Funktion wird in einer CloudFront Viewer-Anfrage oder einer Origin-Anfrage ausgelöst.

------
#### [ Node.js ]

```
'use strict';
				
const querystring = require('querystring');

exports.handler = (event, context, callback) => {
    var request = event.Records[0].cf.request;
    if (request.method === 'POST') {
        /* Request body is being replaced. To do this, update the following
        /* three fields:
         *    1) body.action to 'replace'
         *    2) body.encoding to the encoding of the new data.
         *
         *       Set to one of the following values:
         *
         *           text - denotes that the generated body is in text format.
         *               Lambda@Edge will propagate this as is.
         *           base64 - denotes that the generated body is base64 encoded.
         *               Lambda@Edge will base64 decode the data before sending
         *               it to the origin.
         *    3) body.data to the new body.
         */
        request.body.action = 'replace';
        request.body.encoding = 'text';
        request.body.data = getUpdatedBody(request);
    }
    callback(null, request);
};

function getUpdatedBody(request) {
    /* HTTP body is always passed as base64-encoded string. Decode it. */
    const body = Buffer.from(request.body.data, 'base64').toString();

    /* HTML forms send data in query string format. Parse it. */
    const params = querystring.parse(body);

    /* For demonstration purposes, we're adding one more param.
     *
     * You can put your custom logic here. For example, you can truncate long
     * bodies from malicious requests.
     */
    params['new-param-name'] = 'new-param-value';
    return querystring.stringify(params);
}
```

------
#### [ Python ]

```
import base64
from urllib.parse import parse_qs, urlencode

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    if request['method'] == 'POST':
        '''
        Request body is being replaced. To do this, update the following
        three fields:
            1) body.action to 'replace'
            2) body.encoding to the encoding of the new data.
        
            Set to one of the following values:
        
                text - denotes that the generated body is in text format.
                    Lambda@Edge will propagate this as is.
                base64 - denotes that the generated body is base64 encoded.
                    Lambda@Edge will base64 decode the data before sending
                    it to the origin.
            3) body.data to the new body.
        '''
        request['body']['action'] = 'replace'
        request['body']['encoding'] = 'text'
        request['body']['data'] = getUpdatedBody(request)
    return request

def getUpdatedBody(request):
    # HTTP body is always passed as base64-encoded string. Decode it
    body = base64.b64decode(request['body']['data'])

    # HTML forms send data in query string format. Parse it
    params = {k: v[0] for k, v in parse_qs(body).items()}

    # For demonstration purposes, we're adding one more param

    # You can put your custom logic here. For example, you can truncate long
    # bodies from malicious requests
    params['new-param-name'] = 'new-param-value'
    return urlencode(params)
```

------