Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Personnalisation en périphérie avec Lambda@Edge
<a name="lambda-at-the-edge"></a>

Lambda @Edge est une extension de. AWS Lambda Lambda @Edge est un service de calcul qui vous permet d'exécuter des fonctions qui personnalisent le contenu diffusé par Amazon CloudFront . Vous pouvez créer des fonctions Node.js ou Python dans la console Lambda dans l'une d'elles Région AWS, dans l'est des États-Unis (Virginie du Nord).

Après avoir créé la fonction, vous pouvez ajouter des déclencheurs à l'aide de la console Lambda ou CloudFront de la console Lambda afin que les fonctions s'exécutent dans AWS des emplacements plus proches du visualiseur, sans provisionner ni gérer de serveurs. Vous pouvez éventuellement utiliser les opérations Lambda et CloudFront API pour configurer vos fonctions et vos déclencheurs par programmation.

Lambda@Edge s'adapte automatiquement, de quelques requêtes par jour jusqu'à des milliers de requêtes par seconde. Le traitement des demandes à AWS des emplacements plus proches de l'utilisateur plutôt que sur les serveurs d'origine réduit considérablement le temps de latence et améliore l'expérience utilisateur.

**Note**  
Lambda@Edge n’est pas pris en charge avec les demandes gRPC. Pour plus d’informations, consultez [Utilisation de gRPC avec des distributions CloudFront](distribution-using-grpc.md).

**Topics**
+ [Fonctionnement de Lambda@Edge avec les demandes et les réponses](lambda-edge-event-request-response.md)
+ [Comment utiliser Lambda@Edge](lambda-edge-ways-to-use.md)
+ [Mise en route des fonctions Lambda@Edge (console)](lambda-edge-how-it-works.md)
+ [Définition des autorisations et rôles IAM pour Lambda@Edge](lambda-edge-permissions.md)
+ [Écriture et création d’une fonction Lambda@Edge](lambda-edge-create-function.md)
+ [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md)
+ [Test et débogage des fonctions Lambda@Edge](lambda-edge-testing-debugging.md)
+ [Suppression des fonctions et des réplicas Lambda@Edge](lambda-edge-delete-replicas.md)
+ [Structure d'événement Lambda@Edge](lambda-event-structure.md)
+ [Utilisation des demandes et des réponses](lambda-generating-http-responses.md)
+ [Exemples de fonctions Lambda@Edge](lambda-examples.md)

# Fonctionnement de Lambda@Edge avec les demandes et les réponses
<a name="lambda-edge-event-request-response"></a>

Lorsque vous associez une CloudFront distribution à une fonction Lambda @Edge, elle CloudFront intercepte les demandes et les réponses à CloudFront des emplacements périphériques. Vous pouvez exécuter des fonctions Lambda lorsque les CloudFront événements suivants se produisent :
+ Quand CloudFront reçoit une demande d'un téléspectateur (demande du téléspectateur)
+ Avant CloudFront de transmettre une demande à l'origine (demande d'origine)
+ Quand CloudFront reçoit une réponse de l'origine (réponse d'origine)
+ Before CloudFront renvoie la réponse au spectateur (réponse du spectateur)

Si vous l'utilisez AWS WAF, la demande du visualiseur Lambda @Edge est exécutée une fois les AWS WAF règles appliquées.

Pour plus d’informations, consultez [Utilisation des demandes et des réponses](lambda-generating-http-responses.md) et [Structure d'événement Lambda@Edge](lambda-event-structure.md).

# Comment utiliser Lambda@Edge
<a name="lambda-edge-ways-to-use"></a>

Le traitement Lambda @Edge peut être utilisé à de nombreuses fins dans votre CloudFront distribution Amazon, comme dans les exemples suivants :
+ Une fonction Lambda peut inspecter les cookies et les réécrire URLs afin que les utilisateurs puissent consulter les différentes versions d'un site à tester. A/B 
+ CloudFront peuvent renvoyer différents objets aux spectateurs en fonction de l'appareil qu'ils utilisent en vérifiant l'`User-Agent`en-tête, qui contient des informations sur les appareils. Par exemple, ils CloudFront peuvent renvoyer différentes images en fonction de la taille de l'écran de leur appareil. De même, la fonction peut prendre en compte la valeur de l'`Referer`en-tête et CloudFront renvoyer les images aux robots dont la résolution disponible est la plus faible. 
+ Ou, vous pouvez vérifier les cookies pour d'autres critères. Par exemple, sur un site Web de vente au détail qui vend des vêtements, si vous utilisez des cookies pour indiquer la couleur choisie par un utilisateur pour une veste, une fonction Lambda peut modifier la demande afin de CloudFront renvoyer l'image d'une veste dans la couleur sélectionnée.
+ Une fonction Lambda peut générer des réponses HTTP lorsque des événements de demande d' CloudFront utilisateur ou de demande d'origine se produisent.
+ Une fonction peut inspecter les en-têtes ou les jetons d'autorisation et insérer un en-tête pour contrôler l'accès à votre contenu avant de CloudFront transmettre la demande à votre origine.
+ Une fonction Lambda peut également effectuer des appels réseau à des ressources externes pour confirmer les informations d'identification utilisateur, ou récupérer du contenu supplémentaire pour personnaliser une réponse.

Pour plus d’informations, avec un exemple de code à l’appui, consultez [Exemples de fonctions Lambda@Edge](lambda-examples.md).

Pour plus d’informations sur la configuration de Lambda@Edge dans la console, consultez [Didacticiel : création d’une fonction Lambda@Edge basique (console)](lambda-edge-how-it-works-tutorial.md).

# Mise en route des fonctions Lambda@Edge (console)
<a name="lambda-edge-how-it-works"></a>

Avec Lambda @Edge, vous pouvez utiliser des CloudFront déclencheurs pour appeler une fonction Lambda. Lorsque vous associez une CloudFront distribution à une fonction Lambda, CloudFront [intercepte les demandes et les réponses à des](https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html) emplacements CloudFront périphériques et exécute la fonction. Les fonctions Lambda peuvent améliorer la sécurité ou personnaliser des informations à proximité de vos utilisateurs, afin d’améliorer les performances.

La liste suivante fournit un aperçu de base de la création et de l'utilisation de fonctions Lambda avec. CloudFront

**Présentation : Création et utilisation de fonctions Lambda avec CloudFront**

1. Créez une fonction Lambda dans la région USA Est (Virginie du Nord).

1. Enregistrez et publiez une version numérotée de la fonction.

   Si vous souhaitez modifier la fonction, vous devez modifier la version \$1LATEST de la fonction dans la région USA Est (Virginie du Nord). Ensuite, avant de le configurer pour qu'il fonctionne CloudFront, vous publiez une nouvelle version numérotée.

1. Associez la fonction à un comportement CloudFront de distribution et de cache. Spécifiez ensuite un ou plusieurs CloudFront événements (*déclencheurs*) à l'origine de l'exécution de la fonction. Par exemple, vous pouvez créer un déclencheur pour que la fonction s'exécute lorsqu'elle CloudFront reçoit une demande d'un utilisateur.

1. Lorsque vous créez un déclencheur, Lambda crée des réplicas de la fonction dans les emplacements AWS à travers le monde.

**Astuce**  
Pour plus d'informations, consultez les [sections Création et mise à jour de fonctions](lambda-edge-create-function.md)[, structure d'événement](lambda-event-structure.md) et [ajout de CloudFront déclencheurs](lambda-edge-add-triggers.md). Vous pouvez également trouver d'autres idées et obtenir des exemples de code dans [Exemples de fonctions Lambda@Edge](lambda-examples.md).

Pour un step-by-step didacticiel, consultez la rubrique suivante :

**Topics**
+ [Didacticiel : création d’une fonction Lambda@Edge basique (console)](lambda-edge-how-it-works-tutorial.md)

# Didacticiel : création d’une fonction Lambda@Edge basique (console)
<a name="lambda-edge-how-it-works-tutorial"></a>

Ce didacticiel explique comment démarrer avec Lambda @Edge en créant et en configurant un exemple de fonction Node.js qui s'exécute dans. CloudFront Cet exemple ajoute des en-têtes de sécurité HTTP à une réponse lors de la CloudFront récupération d'un fichier. (Cette opération peut améliorer la sécurité et la confidentialité d’un site web.)

Vous n’avez pas besoin d’avoir un site web pour suivre ce didacticiel. Cependant, lorsque vous choisissez de créer votre propre solution Lambda@Edge, vous suivez des étapes similaires et sélectionnez les mêmes options.

**Topics**
+ [Étape 1 : Inscrivez-vous à un Compte AWS](#lambda-edge-how-it-works-tutorial-AWS)
+ [Étape 2 : Création d'une CloudFront distribution](#lambda-edge-how-it-works-tutorial-cloudfront)
+ [Étape 3 : créer votre fonction](#lambda-edge-how-it-works-tutorial-create-function)
+ [Étape 4 : ajouter un CloudFront déclencheur pour exécuter la fonction](#lambda-edge-how-it-works-tutorial-add-trigger)
+ [Étape 5 : vérifier l’exécution de la fonction](#lambda-edge-how-it-works-tutorial-verify)
+ [Étape 6 : résoudre les problèmes](#lambda-edge-how-it-works-tutorial-troubleshoot)
+ [Étape 7 : nettoyer votre exemple de ressources](#lambda-edge-how-it-works-tutorial-cleanup-resources)
+ [Informations connexes](#lambda-edge-how-it-works-tutorial-resources)

## Étape 1 : Inscrivez-vous à un Compte AWS
<a name="lambda-edge-how-it-works-tutorial-AWS"></a>

Si vous ne l’avez pas encore fait, créez un Compte AWS. Pour de plus amples informations, veuillez consulter [Inscrivez-vous pour un Compte AWS](setting-up-cloudfront.md#sign-up-for-aws).

## Étape 2 : Création d'une CloudFront distribution
<a name="lambda-edge-how-it-works-tutorial-cloudfront"></a>

Avant de créer l'exemple de fonction Lambda @Edge, vous devez disposer d'un CloudFront environnement de travail incluant une origine à partir de laquelle diffuser le contenu.

Dans cet exemple, vous créez une CloudFront distribution qui utilise un compartiment Amazon S3 comme origine de la distribution. Si vous avez déjà un environnement à utiliser, vous pouvez ignorer cette étape.<a name="lambda-edge-how-it-works-tutorial-cf-proc"></a>

**Pour créer une CloudFront distribution avec une origine Amazon S3**

1. Créez un compartiment Amazon S3 avec un fichier ou deux, par exemple des fichiers image, comme exemples de contenu. Pour obtenir de l'aide, suivez les étapes dans [Chargement de votre contenu sur Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html#GettingStartedUploadContent). Assurez-vous de définir des autorisations pour accorder l'accès public en lecture sur les objets de votre compartiment.

1. Créez une CloudFront distribution et ajoutez votre compartiment S3 comme origine, en suivant les étapes décrites dans [Créer une distribution CloudFront Web](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html#GettingStartedCreateDistribution). Si vous avez déjà une distribution, vous pouvez, au lieu de cela, ajouter le compartiment en tant qu'origine pour cette distribution.
**Astuce**  
Notez votre ID de distribution. Plus loin dans ce didacticiel, lorsque vous ajoutez un CloudFront déclencheur pour votre fonction, vous devez choisir l'ID de votre distribution dans une liste déroulante, par exemple,. `E653W22221KDDL`

## Étape 3 : créer votre fonction
<a name="lambda-edge-how-it-works-tutorial-create-function"></a>

Au cours de cette étape, vous créez une fonction Lambda à partir d’un modèle de plan dans la console Lambda. La fonction ajoute du code pour mettre à jour les en-têtes de sécurité dans votre distribution CloudFront. <a name="lambda-edge-how-it-works-tutorial-create-function-blueprint-proc"></a>

**Pour créer une fonction Lambda**

1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
**Important**  
**Assurez-vous que vous êtes dans le **US-east-1 (Virginie du Nord) (** Région AWS us-east-1).** Vous devez être dans cette région pour créer des fonctions Lambda@Edge.

1. Choisissez **Créer une fonction**.

1. Sur la page **Créer une fonction**, choisissez **Utiliser un plan**, puis filtrez les CloudFront plans en les saisissant **cloudfront** dans le champ de recherche.
**Note**  
CloudFront **les plans ne sont disponibles que dans la **région US-east-1 (Virginie du Nord) (us-east-1**).**

1. Choisissez le plan **Modifier l’en-tête de réponse HTTP** comme modèle pour votre fonction.

1. Entrez les informations suivantes sur votre fonction :
   + **Nom de la fonction** : entrez un nom pour votre fonction.
   + **Rôle d’exécution** : choisissez la façon de définir les autorisations pour votre fonction. Pour utiliser le modèle de politique d'autorisation de base recommandé par Lambda @Edge, choisissez **Create a new role from AWS policy** templates.
   + **Nom du rôle** : entrez un nom pour le rôle créé par le modèle de stratégie.
   + **Modèles de politique** — Lambda ajoute automatiquement le modèle de stratégie Basic **Lambda @Edge permissions** parce que vous avez choisi un CloudFront plan comme base pour votre fonction. Ce modèle de politique ajoute des autorisations de rôle d'exécution qui CloudFront permettent d'exécuter votre fonction Lambda pour vous dans le CloudFront monde entier. Pour de plus amples informations, veuillez consulter [Définition des autorisations et rôles IAM pour Lambda@Edge](lambda-edge-permissions.md).

1. Dans le bas de la page, choisissez **Créer une fonction**.

1. Dans le volet **Déployer sur Lambda@Edge** qui apparaît, choisissez **Annuler**. (Pour ce didacticiel, vous devez modifier le code de la fonction avant de déployer la fonction sur Lambda@Edge.)

1. Faites défiler la page jusqu’à la section **Source du code**.

1. Remplacez le code de modèle par une fonction qui modifie les en-têtes de sécurité renvoyés par votre origine. Par exemple, vous pouvez utiliser du code tel que :

   ```
   '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. Choisissez **Fichier**, puis **Enregistrer** pour enregistrer votre code mis à jour.

1. Choisissez **Déployer**.

Passez à la section suivante pour ajouter un CloudFront déclencheur permettant d'exécuter la fonction.

## Étape 4 : ajouter un CloudFront déclencheur pour exécuter la fonction
<a name="lambda-edge-how-it-works-tutorial-add-trigger"></a>

Maintenant que vous disposez d'une fonction Lambda pour mettre à jour les en-têtes de sécurité, configurez le CloudFront déclencheur pour exécuter votre fonction afin d'ajouter les en-têtes dans toute réponse CloudFront reçue de l'origine de votre distribution.<a name="lambda-edge-how-it-works-tutorial-add-trigger-proc"></a>

**Pour configurer le CloudFront déclencheur de votre fonction**

1. Dans la console Lambda, sur la page **Présentation de la fonction**, choisissez **Ajouter un déclencheur**.

1. Pour la **configuration du déclencheur**, choisissez **CloudFront**.

1. Choisissez **Déployer sur Lambda@Edge**.

1. Dans le volet **Deploy to Lambda @Edge**, sous **Configurer le CloudFront déclencheur**, entrez les informations suivantes :
   + **Distribution** : ID de CloudFront distribution à associer à votre fonction. Dans la liste déroulante, choisissez l’ID de distribution.
   + **Comportement de cache** : le comportement de cache à utiliser avec le déclencheur. Pour cet exemple, laissez la valeur définie sur **\$1**, qui correspond au comportement de cache par défaut de votre distribution. Pour plus d’informations, consultez [Paramètres de comportement du cache](DownloadDistValuesCacheBehavior.md) dans la rubrique [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).
   + **CloudFront event** — Le déclencheur qui indique le moment où votre fonction s'exécute. Nous voulons que la fonction d'en-têtes de sécurité s'exécute chaque fois que CloudFront renvoie une réponse depuis l'origine. Dans la liste déroulante, choisissez **Réponse de l’origine**. Pour de plus amples informations, veuillez consulter [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md).

1. Cochez la case **Confirmer le déploiement sur Lambda@Edge**.

1. Choisissez **Déployer** pour ajouter le déclencheur et répliquer la fonction dans le monde AWS entier.

1. Attendez que la réplication de la fonction soit terminée. Cela prend généralement plusieurs minutes.

    Vous pouvez vérifier si la réplication est terminée en [accédant à la console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home) et en visualisant votre distribution. Attendez que l’état de la distribution passe de **Déploiement** à une date et une heure, ce qui indique que votre fonction a été répliquée. Pour vérifier que la fonction s'exécute correctement, suivez les étapes de la section suivante.

## Étape 5 : vérifier l’exécution de la fonction
<a name="lambda-edge-how-it-works-tutorial-verify"></a>

Maintenant que vous avez créé votre fonction Lambda et configuré un déclencheur pour l'exécuter pour une CloudFront distribution, assurez-vous que la fonction répond à vos attentes. Dans cet exemple, nous vérifions les en-têtes HTTP que CloudFront renvoie pour nous assurer que les en-têtes de sécurité sont ajoutés.<a name="lambda-edge-how-it-works-tutorial-verify-proc"></a>

**Pour vérifier que votre fonction Lambda@Edge ajoute des en-têtes de sécurité**

1. Dans un navigateur, entrez l'URL d'un fichier dans votre compartiment S3. Par exemple, vous pouvez utiliser une URL similaire à `https://d111111abcdef8.cloudfront.net/image.jpg`.

   Pour plus d'informations sur le nom de CloudFront domaine à utiliser dans l'URL du fichier, consultez[Personnalisez le format d'URL pour les fichiers dans CloudFront](LinkFormat.md).

1. Ouvrez la barre d'outils Web Developer de votre navigateur. Par exemple, dans votre fenêtre de navigateur Chrome, ouvrez le menu contextuel (clic droit), puis choisissez **Inspecter**.

1. Choisissez l'onglet **Network (Réseau)**.

1. Rechargez la page pour afficher votre image, puis choisissez une demande HTTP dans le volet de gauche. Vous voyez les en-têtes HTTP s'afficher dans un volet distinct.

1. Parcourez la liste des en-têtes HTTP pour vérifier que les en-têtes de sécurité attendus sont inclus dans la liste. Par exemple, vous pourrez peut-être voir des en-têtes similaires à ceux affichés dans la capture d'écran suivante.  
![\[Liste d'en-têtes HTTP avec les en-têtes de sécurité attendus mis en évidence.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/lambda-at-edge-security-headers-list.png)

Si les en-têtes de sécurité sont inclus dans votre liste d'en-têtes, cela signifie que vous avez créé avec succès votre première fonction Lambda@Edge. En cas d'erreur de CloudFront retour ou d'autres problèmes, passez à l'étape suivante pour résoudre les problèmes.

## Étape 6 : résoudre les problèmes
<a name="lambda-edge-how-it-works-tutorial-troubleshoot"></a>

Si elle CloudFront renvoie des erreurs ou n'ajoute pas les en-têtes de sécurité comme prévu, vous pouvez étudier l'exécution de votre fonction en consultant CloudWatch Logs. Veillez à utiliser les journaux stockés à l' AWS emplacement le plus proche de l'endroit où la fonction est exécutée.

Par exemple, si vous consultez le fichier depuis Londres, essayez de remplacer la région dans la CloudWatch console par Europe (Londres).<a name="lambda-edge-how-it-works-tutorial-cloudwatch-proc"></a>

**Pour examiner les CloudWatch journaux de votre fonction Lambda @Edge**

1. Connectez-vous à la CloudWatch console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Modifiez **Région** en spécifiant l'emplacement qui est montré lorsque vous affichez le fichier dans votre navigateur. C'est là que la fonction s'exécute.

1. Dans le volet de gauche, choisissez **Logs (Journaux)** pour afficher les journaux de votre distribution. 

Pour plus d’informations, consultez [Surveillez CloudFront les métriques avec Amazon CloudWatch](monitoring-using-cloudwatch.md).

## Étape 7 : nettoyer votre exemple de ressources
<a name="lambda-edge-how-it-works-tutorial-cleanup-resources"></a>

Si vous avez créé un compartiment et une CloudFront distribution Amazon S3 uniquement pour ce didacticiel, supprimez les AWS ressources que vous avez allouées afin de ne plus payer de frais. Une fois que vous avez supprimé vos AWS ressources, le contenu que vous avez ajouté n'est plus disponible.

**Tâches**
+ [Supprimer le compartiment S3](#lambda-edge-how-it-works-tutorial-delete-bucket) 
+ [Supprimer la fonction Lambda](#lambda-edge-how-it-works-tutorial-delete-function)
+ [Supprimer la CloudFront distribution](#lambda-edge-how-it-works-tutorial-delete-distribution)

### Supprimer le compartiment S3
<a name="lambda-edge-how-it-works-tutorial-delete-bucket"></a>

Avant de supprimer votre compartiment Amazon S3, assurez-vous que la journalisation est désactivée pour le compartiment. Sinon, AWS continue d'écrire des journaux dans votre compartiment lorsque vous le supprimez.<a name="lambda-edge-how-it-works-tutorial-delete-bucket-proc"></a>

**Pour désactiver la journalisation pour un compartiment**

1. Ouvrez la console Amazon S3 à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Sélectionnez le compartiment, puis choisissez **Properties (Propriétés)**.

1. Dans **Properties (Propriétés)**, choisissez **Logging (Journalisation)**.

1. Désactivez la case à cocher **Activé**.

1. Choisissez **Enregistrer**.

Vous pouvez maintenant supprimer votre compartiment. Pour plus d’informations, consultez [Suppression d’un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) dans le *Guide de l’utilisateur de la console Amazon Simple Storage Service*.

### Supprimer la fonction Lambda
<a name="lambda-edge-how-it-works-tutorial-delete-function"></a>

Pour obtenir les instructions permettant de supprimer l’association à la fonction Lambda et, éventuellement, la fonction elle-même, consultez [Suppression des fonctions et des réplicas Lambda@Edge](lambda-edge-delete-replicas.md).

### Supprimer la CloudFront distribution
<a name="lambda-edge-how-it-works-tutorial-delete-distribution"></a>

Avant de supprimer une CloudFront distribution, vous devez la désactiver. Une distribution désactivée n'est plus fonctionnelle et n'accumule pas de frais. Vous pouvez activer une distribution désactivée à tout moment. Une fois que vous avez supprimé une distribution désactivée, celle-ci n'est plus disponible.<a name="lambda-edge-how-it-works-tutorial-delete-distribution-proc"></a>

**Pour désactiver et supprimer une CloudFront distribution**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Sélectionnez la distribution que vous souhaitez désactiver, puis choisissez **Désactiver)**.

1. Lorsque vous serez invité à confirmer l'opération, choisissez **Oui, désactiver**.

1. Sélectionnez la distribution désactivée, puis choisissez **Supprimer**.

1. Lorsque vous êtes invité à confirmer l'opération, choisissez **Oui, supprimer**.

## Informations connexes
<a name="lambda-edge-how-it-works-tutorial-resources"></a>

Maintenant que vous avez une idée générale de la manière dont les fonctions Lambda@Edge s'exécutent, lisez les documents suivants pour en savoir plus :
+ [Exemples de fonctions Lambda@Edge](lambda-examples.md)
+ [Bonnes pratiques de conception Lambda @Edge](https://aws.amazon.com/blogs/networking-and-content-delivery/lambdaedge-design-best-practices/)
+ [Réduction de la latence et transfert du calcul vers la périphérie avec Lambda @Edge](https://aws.amazon.com/blogs/networking-and-content-delivery/reducing-latency-and-shifting-compute-to-the-edge-with-lambdaedge/)

# Définition des autorisations et rôles IAM pour Lambda@Edge
<a name="lambda-edge-permissions"></a>

Pour configurer Lambda@Edge, vous devez disposer des autorisations et des rôles IAM pour AWS Lambda : 
+ [Autorisations IAM](#lambda-edge-permissions-required) : ces autorisations vous permettent de créer votre fonction Lambda et de l'associer CloudFront à votre distribution.
+ [Un rôle d’exécution de fonction Lambda](#lambda-edge-permissions-function-execution) (rôle IAM) : les principaux de service Lambda assument ce rôle pour exécuter votre fonction.
+ [Rôles liés à un service pour Lambda @Edge — Les rôles](#using-service-linked-roles-lambda-edge) liés à un service permettent à des utilisateurs spécifiques de Services AWS répliquer des fonctions Lambda dans des fichiers journaux et de les utiliser. Régions AWS CloudWatch CloudFront 

## Autorisations IAM requises pour associer les fonctions Lambda @Edge aux distributions CloudFront
<a name="lambda-edge-permissions-required"></a>

Outre les autorisations IAM dont vous avez besoin pour Lambda, vous avez besoin des autorisations suivantes pour associer les fonctions Lambda aux distributions : CloudFront 
+ `lambda:GetFunction` : accorde l’autorisation d’obtenir les informations de configuration de votre fonction Lambda ainsi qu’une URL pré-signée pour télécharger un fichier `.zip` contenant la fonction.
+ `lambda:EnableReplication*` : accorde une autorisation à la politique de ressource afin que le service de réplication Lambda puisse récupérer le code et la configuration de la fonction.
+ `lambda:DisableReplication*` : accorde une autorisation à la politique de ressource afin que le service de réplication Lambda puisse supprimer la fonction.
**Important**  
Vous devez ajouter l’astérisque (`*`) à la fin des actions `lambda:EnableReplication*` et `lambda:DisableReplication*`.
+ Pour la ressource, spécifiez l'ARN de la version de fonction que vous souhaitez exécuter lorsqu'un CloudFront événement se produit, comme dans l'exemple suivant :

  `arn:aws:lambda:us-east-1:123456789012:function:TestFunction:2`
+ `iam:CreateServiceLinkedRole`— Accorde l'autorisation de créer un rôle lié à un service que Lambda @Edge utilise pour répliquer les fonctions Lambda. CloudFront Après avoir configuré Lambda@Edge pour la première fois, le rôle lié au service est créé automatiquement pour vous. Il n’est pas nécessaire d’ajouter cette autorisation aux autres distributions qui utilisent Lambda@Edge.

  
+ `cloudfront:UpdateDistribution` ou `cloudfront:CreateDistribution` : accorde l’autorisation de mettre à jour ou de créer une distribution.

Pour plus d’informations, consultez les rubriques suivantes :
+ [Identity and Access Management pour Amazon CloudFront](security-iam.md)
+ [Autorisations d’accès aux ressources Lambda](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) dans le *Guide du développeur AWS Lambda *

## Rôle d'exécution de fonction pour les principaux de service
<a name="lambda-edge-permissions-function-execution"></a>

Vous devez créer un rôle IAM que les principaux de service `lambda.amazonaws.com` et `edgelambda.amazonaws.com` peuvent assumer lorsqu’ils exécutent votre fonction. 

**Astuce**  
Lorsque vous créez votre fonction dans la console Lambda, vous pouvez choisir de créer un nouveau rôle d'exécution à l'aide d'un modèle de AWS politique. Cette étape ajoute *automatiquement* les autorisations Lambda@Edge requises pour exécuter votre fonction. Consultez [l’étape 5 du Didacticiel : création d’une fonction Lambda@Edge simple](lambda-edge-how-it-works-tutorial.md#lambda-edge-how-it-works-tutorial-create-function).

Pour plus d’informations sur la création manuelle d’un rôle IAM, consultez [Création des rôles et association des politiques (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) dans le *Guide de l’utilisateur IAM*.

**Example Exemple : stratégie d’approbation du rôle**  
Vous pouvez ajouter ce rôle sous l’onglet **Relations d’approbation** dans la console IAM. N’ajoutez pas cette politique sous l’onglet **Autorisations**.    
****  

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

Pour plus d’informations sur les autorisations que vous devez associer au rôle d’exécution, consultez [Autorisations d’accès aux ressources Lambda](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role) dans le *Guide du développeur AWS Lambda *.

**Remarques**  
Par défaut, chaque fois qu'un CloudFront événement déclenche une fonction Lambda, les données sont écrites dans Logs. CloudWatch Si vous souhaitez utiliser ces journaux, le rôle d'exécution doit être autorisé à écrire des données dans les CloudWatch journaux. Vous pouvez utiliser le AWSLambdaBasicExecutionRole prédéfini pour accorder l’autorisation nécessaire au rôle d’exécution.  
Pour plus d'informations sur CloudWatch les journaux, consultez[Journaux des fonctions de périphérie](edge-functions-logs.md).
Si votre code de fonction Lambda accède à d'autres AWS ressources, telles que la lecture d'un objet depuis un compartiment S3, le rôle d'exécution doit être autorisé pour effectuer cette action. 

## Rôles liés à un service pour Lambda@Edge
<a name="using-service-linked-roles-lambda-edge"></a>

Lambda@Edge utilise des [rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) IAM. Un rôle lié à un service est un type unique de rôle IAM lié directement à un service. Les rôles liés à un service sont prédéfinis par le service et comprennent toutes les autorisations nécessaires au service pour appeler d'autres services AWS en votre nom.

Lambda@Edge utilise les rôles liés à un service IAM suivants :
+ **AWSServiceRoleForLambdaReplicator** – Lambda@Edge utilise ce rôle pour autoriser Lambda@Edge à répliquer des fonctions vers Régions AWS.

  Lorsque vous ajoutez un déclencheur Lambda @Edge pour la première fois CloudFront, un rôle nommé AWSServiceRoleForLambdaReplicator est créé automatiquement pour permettre à Lambda @Edge de répliquer des fonctions sur. Régions AWS Ce rôle est obligatoire pour utiliser les fonctions Lambda@Edge. L’ARN du rôle AWSServiceRoleForLambdaReplicator ressemble à l’exemple suivant :

  `arn:aws:iam::123456789012:role/aws-service-role/replicator.lambda.amazonaws.com/AWSServiceRoleForLambdaReplicator`
+ **AWSServiceRoleForCloudFrontLogger**— CloudFront utilise ce rôle pour transférer les fichiers journaux dans CloudWatch. Vous pouvez utiliser des fichiers journaux pour corriger les erreurs de validation Lambda@Edge.

  Le AWSServiceRoleForCloudFrontLogger rôle est créé automatiquement lorsque vous ajoutez une association de fonctions Lambda @Edge pour permettre de transférer les fichiers CloudFront journaux d'erreurs Lambda @Edge vers. CloudWatch L’ARN pour le rôle AWSServiceRoleForCloudFrontLogger prend la forme suivante :

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

Un rôle lié à un service simplifie la configuration et l'utilisation de Lambda@Edge, car vous n'avez pas besoin d'ajouter manuellement les autorisations requises. Lambda@Edge définit les autorisations de ses rôles liés un service et seul Lambda@Edge peut endosser ces rôles. Les autorisations définies comprennent la politique d'approbation et la politique d'autorisations. Vous ne pouvez pas attacher la politique d'autorisations à une autre entité IAM.

Vous devez supprimer toutes les ressources associées CloudFront ou Lambda @Edge avant de pouvoir supprimer un rôle lié à un service. Cela vous aide à protéger vos ressources Lambda@Edge afin d’éviter la suppression d’un rôle lié à un service qui est encore nécessaire pour accéder à des ressources actives.

Pour plus d’informations sur les rôles liés à un service, consultez [Rôles liés à un service pour CloudFront](security_iam_service-with-iam.md#security_iam_service-with-iam-roles-service-linked). 

### Autorisations du rôle lié à un service pour Lambda@Edge
<a name="slr-permissions-lambda-edge"></a>

Lambda@Edge utilise deux rôles liés à un service nommé **AWSServiceRoleForLambdaReplicator** et **AWSServiceRoleForCloudFrontLogger**. Les sections suivantes décrivent comment gérer les autorisations pour chacun de ces rôles.

**Contents**
+ [Autorisations du rôle lié à un service pour Lambda Replicator](#slr-permissions-lambda-replicator)
+ [Autorisations de rôle liées au service pour l'enregistreur CloudFront](#slr-permissions-cloudfront-logger)

#### Autorisations du rôle lié à un service pour Lambda Replicator
<a name="slr-permissions-lambda-replicator"></a>

Ce rôle lié à un service permet à Lambda de répliquer les fonctions Lambda@Edge vers Régions AWS.

Le rôle lié à un service AWSServiceRoleForLambdaReplicator fait confiance au service `replicator.lambda.amazonaws.com` pour endosser le rôle.

La politique d'autorisations du rôle permet à Lambda@Edge de réaliser les actions suivantes sur les ressources spécifiées :
+ `lambda:CreateFunction` sur `arn:aws:lambda:*:*:function:*`
+ `lambda:DeleteFunction` sur `arn:aws:lambda:*:*:function:*`
+ `lambda:DisableReplication` sur `arn:aws:lambda:*:*:function:*`
+ `iam:PassRole` sur `all AWS resources`
+  `cloudfront:ListDistributionsByLambdaFunction` sur `all AWS resources`

#### Autorisations de rôle liées au service pour l'enregistreur CloudFront
<a name="slr-permissions-cloudfront-logger"></a>

Ce rôle lié à un service permet de CloudFront transférer des fichiers journaux CloudWatch afin que vous puissiez corriger les erreurs de validation Lambda @Edge.

Le rôle lié à un service AWSServiceRoleForCloudFrontLogger fait confiance au service `logger.cloudfront.amazonaws.com` pour endosser le rôle.

La politique d’autorisations du rôle permet à Lambda@Edge de réaliser les actions suivantes sur les ressources `arn:aws:logs:*:*:log-group:/aws/cloudfront/*` spécifiées :
+ `logs:CreateLogGroup` ``
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`

Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, groupe ou rôle) de supprimer les rôles liés à un service Lambda@Edge. Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.

### Création de rôles liés à un service pour Lambda@Edge
<a name="create-slr-lambda-edge"></a>

Vous n'avez généralement pas besoin de créer manuellement les rôles liés à un service pour Lambda@Edge. Le service crée les rôles automatiquement pour vous dans les scénarios suivants :
+ Lorsque vous créez un déclencheur pour la première fois, le service crée le rôle AWSServiceRoleForLambdaReplicator (s’il n’existe pas encore.). Ce rôle permet à Lambda de répliquer les fonctions Lambda@Edge vers Régions AWS.

  Si vous supprimez le rôle lié à un service, le rôle sera à nouveau créé lorsque vous ajouterez un nouveau déclencheur pour Lambda@Edge dans une distribution.
+ Lorsque vous mettez à jour ou créez une CloudFront distribution associée à Lambda @Edge, le service crée le AWSServiceRoleForCloudFrontLogger rôle (si le rôle n'existe pas déjà). Ce rôle permet CloudFront de transférer vos fichiers journaux vers CloudWatch.

  Si vous supprimez le rôle lié à un service, le rôle sera créé à nouveau lorsque vous mettrez à jour ou créerez une CloudFront distribution associée à Lambda @Edge.

Pour créer manuellement ces rôles liés à un service, vous pouvez exécuter les commandes suivantes AWS Command Line Interface (AWS CLI) :

**Pour créer le rôle AWSServiceRoleForLambdaReplicator**
+ Exécutez la commande suivante.

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

**Pour créer le rôle AWSServiceRoleForCloudFrontLogger**
+ Exécutez la commande suivante.

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

### Modification des rôles liés à un service Lambda@Edge.
<a name="edit-slr-lambda-edge"></a>

Lambda@Edge ne vous permet pas de modifier les rôles liés à un service AWSServiceRoleForLambdaReplicator ou AWSServiceRoleForCloudFrontLogger. Une fois que le service a créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent y faire référence. Néanmoins, vous pouvez utiliser IAM pour modifier la description du rôle. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.

### Pris en charge Régions AWS pour les rôles liés au service Lambda @Edge
<a name="slr-regions-lambda-edge"></a>

CloudFront prend en charge l'utilisation de rôles liés à un service pour Lambda @Edge dans les domaines suivants : Régions AWS
+ USA Est (Virginie du Nord) – `us-east-1`
+ USA Est (Ohio) – `us-east-2`
+ USA Ouest (Californie du Nord) – `us-west-1`
+ USA Ouest (Oregon) – `us-west-2`
+ Asie-Pacifique (Mumbai) – `ap-south-1`
+ Asie-Pacifique (Séoul) – `ap-northeast-2`
+ Asie-Pacifique (Singapour) – `ap-southeast-1`
+ Asie-Pacifique (Sydney) – `ap-southeast-2`
+ Asie-Pacifique (Tokyo) : `ap-northeast-1`
+ Europe (Francfort) – `eu-central-1`
+ Europe (Irlande) – `eu-west-1`
+ Europe (Londres) – `eu-west-2`
+ South America (São Paulo) – `sa-east-1`

# Écriture et création d’une fonction Lambda@Edge
<a name="lambda-edge-create-function"></a>

Pour utiliser Lambda@Edge, vous devez *écrire* le code de votre fonction AWS Lambda . Pour vous aider à écrire des fonctions Lambda@Edge, consultez les ressources suivantes :
+  [Structure d'événement Lambda@Edge](lambda-event-structure.md) : comprenez la structure d’événement à utiliser avec Lambda@Edge.
+ [Exemples de fonctions Lambda@Edge](lambda-examples.md)— Exemples de fonctions, telles que le A/B test et la génération d'une redirection HTTP.

Le modèle de programmation pour utiliser Node.js ou Python avec Lambda@Edge est le même que pour l’utilisation de Lambda dans une Région AWS. Pour plus d’informations, consultez [Création de fonctions Lambda avec Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) ou [Création de fonctions Lambda avec Python](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html) dans le *Guide du développeur AWS Lambda *.

Dans votre fonction Lambda@Edge, insérez le paramètre `callback` et renvoyez l’objet applicable pour les événements de demande ou de réponse :
+ **Événements de demande** – Incluez l'objet `cf.request` dans la réponse.

  Si vous générez une réponse, incluez l'objet `cf.response` dans la réponse. Pour plus d’informations, consultez [Génération de réponses HTTP dans les déclencheurs de demande](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests). 
+ **Événements de réponse** – Incluez l'objet `cf.response` dans la réponse.

Après avoir écrit votre propre code ou utilisé l’un des exemples, vous créez la fonction dans Lambda. Pour créer une fonction ou modifier une fonction existante, consultez les rubriques suivantes :

**Topics**
+ [Création d’une fonction Lambda@Edge](lambda-edge-create-in-lambda-console.md)
+ [Modification d’une fonction Lambda](lambda-edge-edit-function.md)

 *Après avoir créé la fonction dans Lambda, vous configurez Lambda pour qu'elle exécute la fonction en fonction d' CloudFront événements spécifiques, appelés déclencheurs.* Pour de plus amples informations, veuillez consulter [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md).

# Création d’une fonction Lambda@Edge
<a name="lambda-edge-create-in-lambda-console"></a>

 AWS Lambda Pour configurer l'exécution de fonctions Lambda basées sur des CloudFront événements, suivez cette procédure.<a name="lambda-edge-create-function-procedure"></a>

**Pour créer une fonction Lambda@Edge**

1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Si vous avez déjà une ou plusieurs fonctions Lambda, choisissez **Create function (Créer fonction)**.

   Si vous n'avez aucune fonction, choisissez **Mise en route**.

1. Dans la liste des régions située en haut de la page, choisissez **US East (N. Virginia) (USA Est (Virginie du Nord))**.

1. Créez une fonction à l'aide de votre propre code ou en partant d'un plan CloudFront .
   + Pour créer une fonction à l'aide de votre propre code, choisissez **Créer à partir de zéro**. 
   + **Pour afficher une liste de plans pour CloudFront, saisissez **cloudfront** dans le champ de filtre, puis choisissez Entrée.**

     Si vous trouvez un plan que vous souhaitez utiliser, choisissez le nom de ce plan.

1. Dans la section **Informations de base**, spécifiez les valeurs suivantes :

   1. **Nom** : saisissez le nom de votre fonction.

   1. **Rôle** : pour démarrer rapidement, choisissez **Créer un rôle à partir de modèles**. Vous pouvez également sélectionner **Choisir un rôle existant** ou **Créer un rôle personnalisé**, puis suivre les invites pour compléter les informations de cette section.

   1. **Nom du rôle** : entrez un nom pour le rôle.

   1. **Modèles de stratégies** : choisissez **Autorisations Lambda de périphérique standard**.

1. Si vous avez choisi **Créer à partir de zéro** à l'étape 4, passez directement à l'étape 7.

   Si vous avez choisi un plan à l'étape 4, la section **cloudfront** vous permet de créer un déclencheur, qui associe cette fonction à un cache dans une CloudFront distribution et à un événement. CloudFront Pour l'instant, nous vous recommandons de choisir **Supprimer**, afin qu'il n'y ait pas de déclencheur pour la fonction lorsqu'elle sera créée. Vous pourrez ajouter des déclencheurs par la suite. 
**Astuce**  
Nous vous recommandons de tester et déboguer la fonction avant d’ajouter des déclencheurs. Si vous ajoutez un déclencheur maintenant, la fonction s'exécutera dès que vous la créerez, qu'elle aura fini de se répliquer AWS dans le monde entier et que la distribution correspondante sera déployée.

1. Choisissez **Créer une fonction**.

   Lambda crée deux versions de votre fonction : \$1LATEST et Version 1. Vous pouvez modifier uniquement la version \$1LATEST, mais la console affiche initialement la version 1.

1. Pour modifier la fonction, choisissez **Version 1** en haut de la page, sous l'ARN de la fonction. Puis, dans l'onglet **Versions**, choisissez **\$1LATEST**. (Si vous avez quitté la fonction, puis êtes revenu à celle-ci, le bouton est appelé **Qualificateurs**.)

1. Dans l'onglet **Configuration**, choisissez le **Type d'entrée de code** applicable. Ensuite, suivez les instructions pour modifier ou charger votre code.

1. Pour **Exécution**, choisissez la valeur en fonction du code de votre fonction.

1. Dans la section **Balises**, ajoutez les éventuelles balises applicables.

1. Choisissez **Actions**, puis **Publier une nouvelle version**.

1. Saisissez la description de la nouvelle version de la fonction.

1. Choisissez **Publish**.

1. Testez et déboguez la fonction. Pour plus d’informations sur les tests de la console Lambda, consultez [Invoquer une fonction Lambda avec la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) dans le *Guide du développeur AWS Lambda *.

1. Lorsque vous êtes prêt à exécuter la fonction pour des CloudFront événements, publiez une autre version et modifiez la fonction pour ajouter des déclencheurs. Pour de plus amples informations, veuillez consulter [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md).

# Modification d’une fonction Lambda
<a name="lambda-edge-edit-function"></a>

Après avoir créé une fonction Lambda@Edge, vous pouvez utiliser la console Lambda pour la modifier.

**Remarques**  
La version d'origine est étiquetée \$1LATEST.
Vous ne pouvez modifier que la version \$1LATEST.
Chaque fois que vous modifiez la version \$1LATEST, vous devez publier une nouvelle version numérotée.
Vous ne pouvez pas créer de déclencheurs pour \$1LATEST.
Lorsque vous publiez une nouvelle version d'une fonction, Lambda ne copie pas automatiquement les déclencheurs à partir de la version précédente vers la nouvelle version. Vous devez reproduire les déclencheurs pour la nouvelle version. 
Lorsque vous ajoutez un déclencheur pour un CloudFront événement à une fonction, s'il existe déjà un déclencheur pour la même distribution, le même comportement de cache et le même événement pour une version antérieure de la même fonction, Lambda supprime le déclencheur de la version précédente.
Après avoir mis à jour une CloudFront distribution, par exemple en ajoutant des déclencheurs, vous devez attendre que les modifications se propagent aux emplacements périphériques pour que les fonctions que vous avez spécifiées dans les déclencheurs fonctionnent.<a name="lambda-edge-edit-function-procedure"></a>

**Pour modifier une fonction Lambda**

1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Dans la liste des régions située en haut de la page, choisissez **US East (N. Virginia) (USA Est (Virginie du Nord))**.

1. Dans la liste des fonctions, choisissez le nom de la fonction.

   Par défaut, la console affiche la version \$1LATEST. Vous pouvez consulter les versions précédentes (choisissez **Qualificateurs**), mais vous ne pouvez modifier que \$1 LATEST.

1. Dans l'onglet **Code**, pour **Code entry type (Type d'entrée de code)**, choisissez de modifier le code dans le navigateur, de charger un fichier .zip ou de charger un fichier depuis Amazon S3.

1. Choisissez **Enregistrer** ou **Enregistrer et tester**.

1. Choisissez **Actions**, puis **Publish new version (Publier nouvelle version)**. 

1. Dans la boîte de dialogue **Publier la nouvelle version à partir de \$1LATEST**, indiquez une description de la nouvelle version. Cette description s'affiche dans la liste des versions, accompagnée d'un numéro de version généré automatiquement. 

1. Choisissez **Publish**.

   La nouvelle version devient automatiquement la version la plus récente. Le numéro de version s’affiche dans la zone **Version** dans l’angle supérieur gauche de la page.
**Note**  
Si vous n’avez pas encore ajouté de déclencheurs pour votre fonction, consultez [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md). 

1. Choisissez l’onglet **Déclencheurs**.

1. Choisissez **Add trigger (Ajouter déclencheur)**.

1. Dans la boîte de dialogue **Add trigger (Ajouter déclencheur)**, choisissez la zone en pointillé, puis **CloudFront**.
**Note**  
Si vous avez déjà créé un ou plusieurs déclencheurs pour une fonction, CloudFront c'est le service par défaut.

1. Spécifiez les valeurs suivantes pour indiquer le moment où vous voulez que la fonction Lambda s’exécute.

   1. **ID de distribution** : choisissez l’ID de la distribution que vous souhaitez ajouter au déclencheur.

   1. **Comportement du cache** : choisissez le comportement de cache qui spécifie les objets sur lesquels vous souhaitez exécuter la fonction.

   1. **CloudFront event** — Choisissez l' CloudFront événement à l'origine de l'exécution de la fonction.

   1. **Activer le déclencheur et répliquer** : cochez cette case pour que Lambda effectue une réplication globale de la fonction vers les Régions AWS .

1. Sélectionnez **Soumettre**.

1. Pour ajouter d'autres déclencheurs pour cette fonction, répétez les étapes 10 à 13.

Pour plus d’informations sur les tests et le débogage de la console Lambda, consultez [Invoquer une fonction Lambda avec la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) dans le *Guide du développeur AWS Lambda *.

Lorsque vous êtes prêt à exécuter la fonction pour des CloudFront événements, publiez une autre version et modifiez la fonction pour ajouter des déclencheurs. Pour de plus amples informations, veuillez consulter [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md).

# Ajout de déclencheurs pour une fonction Lambda@Edge
<a name="lambda-edge-add-triggers"></a>

Un déclencheur Lambda @Edge est une combinaison d'une CloudFront distribution, d'un comportement de cache et d'un événement qui entraîne l'exécution d'une fonction. Par exemple, vous pouvez créer un déclencheur qui entraîne l'exécution de la fonction lorsqu'un utilisateur CloudFront reçoit une demande concernant un comportement de cache spécifique que vous avez configuré pour votre distribution. Vous pouvez spécifier un ou plusieurs CloudFront déclencheurs. 

**Astuce**  
Lorsque vous créez une CloudFront distribution, vous spécifiez des paramètres qui indiquent CloudFront comment répondre lorsqu'elle reçoit différentes demandes. Les paramètres par défaut correspondent au *comportement de cache par défaut* pour la distribution. Vous pouvez configurer des comportements de cache supplémentaires qui définissent la manière dont il CloudFront répond dans des circonstances spécifiques, par exemple lorsqu'il reçoit une demande pour un type de fichier spécifique. Pour de plus amples informations, veuillez consulter [Paramètres de comportement du cache](DownloadDistValuesCacheBehavior.md).

Lorsque vous créez pour la première fois une fonction Lambda, vous ne pouvez spécifier qu’*un* seul déclencheur. Vous pouvez ajouter d'autres déclencheurs à la même fonction ultérieurement en utilisant la console Lambda ou en modifiant la distribution dans la CloudFront console.
+ La console Lambda fonctionne bien si vous souhaitez ajouter d'autres déclencheurs à une fonction pour la même CloudFront distribution.
+ La CloudFront console peut être meilleure si vous souhaitez ajouter des déclencheurs pour plusieurs distributions, car il est plus facile de trouver la distribution que vous souhaitez mettre à jour. Vous pouvez également mettre à jour d'autres CloudFront paramètres en même temps.

**Topics**
+ [CloudFront événements pouvant déclencher une fonction Lambda @Edge](lambda-cloudfront-trigger-events.md)
+ [Choix de l’événement qui déclenche la fonction](lambda-how-to-choose-event.md)
+ [Ajout de déclencheurs à une fonction Lambda@Edge](lambda-edge-add-triggers-console.md)

# CloudFront événements pouvant déclencher une fonction Lambda @Edge
<a name="lambda-cloudfront-trigger-events"></a>

Pour chaque comportement de cache dans une CloudFront distribution Amazon, vous pouvez ajouter jusqu'à quatre déclencheurs (associations) qui déclenchent l'exécution d'une fonction Lambda lorsque des CloudFront événements spécifiques se produisent. CloudFront les déclencheurs peuvent être basés sur l'un des quatre CloudFront événements suivants, comme le montre le schéma suivant.

![\[Graphique conceptuel qui montre comment les événements CloudFront déclencheurs pour les fonctions Lambda s'intègrent à. CloudFront\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png)


Les CloudFront événements qui peuvent être utilisés pour déclencher les fonctions Lambda @Edge sont les suivants :

**Demande utilisateur**  
La fonction s'exécute lorsqu'elle CloudFront reçoit une demande d'un visualiseur, avant de vérifier si l'objet demandé se trouve dans le CloudFront cache.  
La fonction ne s’exécute pas dans les cas suivants :  
+ Lors de la récupération d’une page d’erreur personnalisée.
+ Lorsque redirige CloudFront automatiquement une requête HTTP vers HTTPS (lorsque la valeur de [Viewer Protocol Policy](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) est **Rediriger HTTP vers HTTPS**).

**demande à l’origine**  
La fonction s'exécute *uniquement* lorsque CloudFront vous transmettez une demande à votre origine. Lorsque l'objet demandé est dans le CloudFront cache, la fonction ne s'exécute pas.

**Réponse de l’origine**  
La fonction s'exécute après avoir CloudFront reçu une réponse de l'origine et avant de mettre en cache l'objet dans la réponse. Notez que la fonction s'exécute même si une erreur est renvoyée de l'origine.  
La fonction ne s’exécute pas dans les cas suivants :  
+ Lorsque le fichier demandé est dans le CloudFront cache et n'a pas expiré.
+ Lorsque la réponse est générée à partir d'une fonction qui a été déclenchée par un événement de demande à l'origine.

**Réponse utilisateur**  
La fonction s'exécute avant de renvoyer le fichier demandé à l'utilisateur. Notez que la fonction s'exécute indépendamment du fait que le fichier soit déjà dans le CloudFront cache ou non.  
La fonction ne s’exécute pas dans les cas suivants :  
+ Lorsque l'origine renvoie un code de statut HTTP égal ou supérieur à 400.
+ Lorsqu'une page d'erreur personnalisée est renvoyée.
+ Lorsque la réponse est générée à partir d'une fonction qui a été déclenchée par un événement de demande utilisateur.
+ Lorsque redirige CloudFront automatiquement une requête HTTP vers HTTPS (lorsque la valeur de [Viewer Protocol Policy](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy) est **Rediriger HTTP vers HTTPS**).

Lorsque vous ajoutez plusieurs déclencheurs au même comportement de cache, vous pouvez les utiliser pour exécuter la même fonction ou des fonctions différentes pour chaque déclencheur. Vous pouvez associer la même fonction à plusieurs distributions.

**Note**  
Lorsqu'un CloudFront événement déclenche l'exécution d'une fonction Lambda, celle-ci doit se terminer *avant* de CloudFront pouvoir continuer.   
Par exemple, si une fonction Lambda est déclenchée par un événement de demande d'affichage, elle CloudFront ne renverra pas de réponse au CloudFront visualiseur ni ne transmettra la demande à l'origine tant que la fonction Lambda n'aura pas fini de s'exécuter.   
Cela signifie que chaque demande qui déclenche une fonction Lambda augmente sa latence. Vous souhaitez ainsi que la fonction s’exécute le plus vite possible.

# Choix de l’événement qui déclenche la fonction
<a name="lambda-how-to-choose-event"></a>

Lorsque vous décidez quel CloudFront événement vous souhaitez utiliser pour déclencher une fonction Lambda, tenez compte des points suivants :

**Je souhaite CloudFront mettre en cache des objets modifiés par une fonction Lambda**  
Pour mettre en cache un objet qui a été modifié par une fonction Lambda afin de CloudFront pouvoir le servir depuis l'emplacement périphérique lors de sa prochaine demande, utilisez l'événement de *demande d'origine* ou de *réponse d'origine*.   
Cela réduit la charge sur l'origine, réduit la latence pour les demandes suivantes et réduit le coût de l'appel de Lambda@Edge sur les demandes suivantes.  
Par exemple, si vous souhaitez ajouter, supprimer ou modifier les en-têtes des objets renvoyés par l'origine et que vous souhaitez CloudFront mettre le résultat en cache, utilisez l'événement de réponse d'origine.

**Je souhaite que la fonction s’exécute pour chaque demande**  
Pour exécuter la fonction pour chaque demande CloudFront reçue pour la distribution, utilisez les événements de *demande du visualiseur* ou de *réponse du visualiseur*.   
Les événements de demande d'origine et de réponse d'origine se produisent uniquement lorsqu'un objet demandé n'est pas mis en cache dans un emplacement périphérique et CloudFront transmet une demande à l'origine.

**Je souhaite que la fonction modifie la clé de cache**  
Pour modifier une valeur que vous utilisez comme base pour la mise en cache, utilisez l’événement *demande utilisateur*.   
Par exemple, si une fonction modifie l'URL pour inclure une abréviation de langue dans le chemin d'accès (par exemple, parce que l'utilisateur a choisi sa langue dans une liste déroulante), utilisez l'événement de demande utilisateur :  
+ **URL dans la demande du visualiseur** — https://example.com/en/ index.html
+ **URL lorsque la demande provient d'une adresse IP en Allemagne** https://example.com/de/ — index.html
Vous utilisez également l'événement de demande utilisateur si vous mettez en cache en fonction des cookies ou des en-têtes de demande.  
Si la fonction modifie les cookies ou les en-têtes, configurez CloudFront pour transmettre la partie applicable de la demande à l'origine. Pour plus d’informations, consultez les rubriques suivantes :  
+ [Mise en cache de contenu basée sur des cookies](Cookies.md)
+ [Mise en cache de contenu basée sur des en-têtes de demandes](header-caching.md)

**La fonction affecte la réponse provenant de l’origine**  
Pour modifier la demande d’une manière qui affecte la réponse de l’origine, utilisez l’événement *demande à l’origine*.   
En général, la plupart des événements de demande du visiteur ne sont pas transmis à l'origine. CloudFront répond à une demande avec un objet qui se trouve déjà dans le cache périphérique. Si la fonction modifie la demande en fonction d'un événement de demande d'origine, met en CloudFront cache la réponse à la demande d'origine modifiée.

# Ajout de déclencheurs à une fonction Lambda@Edge
<a name="lambda-edge-add-triggers-console"></a>

Vous pouvez utiliser la AWS Lambda console ou la CloudFront console Amazon pour ajouter un déclencheur à votre fonction Lambda @Edge.

**Important**  
Vous ne pouvez créer des déclencheurs que pour les versions numérotées de votre fonction (et non pour le **\$1LATEST**).

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

**Pour ajouter des déclencheurs d' CloudFront événements à une fonction Lambda @Edge**

1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

1. Dans la liste des régions située en haut de la page, choisissez **US East (N. Virginia) (USA Est (Virginie du Nord))**.

1. Sur la page **Fonctions**, choisissez le nom de la fonction pour laquelle vous souhaitez ajouter des déclencheurs.

1. Sur la page **Présentation de la fonction**, choisissez l’onglet **Versions**.

1. Choisissez la version à laquelle vous souhaitez ajouter des déclencheurs.

   Une fois que vous avez choisi une version, le texte du bouton est remplacé par **Version: \$1LATEST** ou **Version:** *numéro de version*.

1. Choisissez l’onglet **Triggers (Déclencheurs)**.

1. Choisissez **Add trigger (Ajouter déclencheur)**.

1. Pour **la configuration du déclencheur**, choisissez **Sélectionner une source****cloudfront**, entrez, puis choisissez **CloudFront**.
**Note**  
Si vous avez déjà créé un ou plusieurs déclencheurs, CloudFront c'est le service par défaut.

1. Spécifiez les valeurs suivantes pour indiquer le moment où vous voulez que la fonction Lambda s’exécute.

   1. **Distribution** : choisissez la distribution que vous souhaitez ajouter au déclencheur.

   1. **Comportement du cache** : choisissez le comportement de cache qui spécifie les objets sur lesquels vous souhaitez exécuter la fonction.
**Note**  
Si vous spécifiez `*` pour le comportement de cache, la fonction Lambda se déploie sur le comportement de cache par défaut.

   1. **CloudFront event** — Choisissez l'CloudFront événement à l'origine de l'exécution de la fonction.

   1. **Inclure le corps** : cochez cette case si vous souhaitez accéder au corps de la demande dans votre fonction. 

   1. **Confirmer le déploiement sur Lambda@Edge** : cochez cette case pour qu’ AWS Lambda réplique la fonction dans les Régions AWS du monde entier.

1. Choisissez **Ajouter**.

   La fonction commence à traiter les demandes relatives aux CloudFront événements spécifiés lorsque la CloudFront distribution mise à jour est déployée. Pour déterminer si une distribution a été déployée, choisissez **Distributions** dans le panneau de navigation. Lorsqu’une distribution a été déployée, la valeur de la colonne **Statut** correspondant à la distribution passe de **Déploiement** à la date et l’heure du déploiement.

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

**Pour ajouter des déclencheurs d' CloudFront événements à une fonction Lambda @Edge**

1. Obtenez le nom ARN de la fonction Lambda pour laquelle vous voulez ajouter des déclencheurs :

   1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).

   1. Dans la liste des régions située en haut de la page, choisissez **US East (N. Virginia) (USA Est (Virginie du Nord))**.

   1. Dans la liste des fonctions, choisissez le nom de la fonction à laquelle vous voulez ajouter des déclencheurs.

   1. Sur la page **Présentation de la fonction**, choisissez l’onglet **Versions** et sélectionnez la version numérotée à laquelle vous voulez ajouter des déclencheurs.

   1. Choisissez le bouton **Copier l’ARN** pour copier l’ARN dans votre presse-papiers. L’ARN de la fonction Lambda ressemble à ceci :

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

      Le numéro à la fin (**2** dans cet exemple) est le numéro de version de la fonction.

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dans la liste des distributions, choisissez l'ID de la distribution à laquelle vous voulez ajouter des déclencheurs.

1. Choisissez l'onglet **Comportements**.

1. Sélectionnez le comportement de cache auquel vous souhaitez ajouter des déclencheurs, puis choisissez **Modifier**.

1. Dans **Associations de fonctions**, dans la liste **Type de fonction**, choisissez **Lambda@Edge** pour exécuter la fonction lors des demandes utilisateur, des réponses utilisateur, des demandes d’origine ou des réponses d’origine. 

   Pour de plus amples informations, veuillez consulter [Choix de l’événement qui déclenche la fonction](lambda-how-to-choose-event.md).

1. Dans la zone de texte **ARN/Nom de la fonction**, collez l’ARN de la fonction Lambda que vous souhaitez exécuter lorsque l’événement choisi se produit. Il s’agit de la valeur que vous avez copiée à partir de la console Lambda.

1. Cochez la case **Inclure corps** si vous souhaitez accéder au corps de la demande dans votre fonction.

   Si vous souhaitez simplement remplacer le corps de la demande, vous n'avez pas besoin de sélectionner cette option.

1. Pour exécuter la même fonction pour plusieurs types d’événements, répétez les étapes 6 et 7.

1. Sélectionnez **Enregistrer les modifications**.

1. Pour ajouter des déclencheurs à d'autres comportements de cache pour cette distribution, répétez les étapes 5 à 10.

   La fonction commence à traiter les demandes relatives aux CloudFront événements spécifiés lorsque la CloudFront distribution mise à jour est déployée. Pour déterminer si une distribution a été déployée, choisissez **Distributions** dans le panneau de navigation. Lorsqu’une distribution a été déployée, la valeur de la colonne **Statut** correspondant à la distribution passe de **Déploiement** à la date et l’heure du déploiement.

------

# Test et débogage des fonctions Lambda@Edge
<a name="lambda-edge-testing-debugging"></a>

Il est important de tester votre code de fonction Lambda @Edge de manière autonome, pour vous assurer qu'il exécute la tâche prévue, et de réaliser des tests d'intégration pour vous assurer que la fonction fonctionne correctement avec. CloudFront 

Au cours des tests d'intégration ou après le déploiement de votre fonction, il se peut que vous deviez CloudFront corriger des erreurs, telles que des erreurs HTTP 5xx. Les erreurs peuvent être de différents types : une réponse non valide renvoyée par la fonction Lambda, des erreurs d'exécution lorsque la fonction est déclenchée, ou encore des erreurs en raison de la limitation d'exécution par le service Lambda. Les sections de cette rubrique donnent des stratégies pour déterminer le type de défaillance qui est à l'origine du problème, puis les étapes à suivre afin de résoudre le problème.

**Note**  
Lorsque vous consultez des fichiers CloudWatch journaux ou des indicateurs pour résoudre des erreurs, sachez qu'ils sont affichés ou stockés à l'emplacement le Région AWS plus proche de l'endroit où la fonction s'est exécutée. Ainsi, si vous avez un site Web ou une application Web avec des utilisateurs au Royaume-Uni, et qu'une fonction Lambda est associée à votre distribution, par exemple, vous devez modifier la région pour afficher les métriques ou CloudWatch les fichiers journaux de Londres. Région AWS Pour de plus amples informations, veuillez consulter [Définition de la région Lambda@Edge](#lambda-edge-testing-debugging-determine-region).

**Topics**
+ [Test de vos fonctions Lambda@Edge](#lambda-edge-testing-debugging-test-function)
+ [Identifiez les erreurs de fonction Lambda @Edge dans CloudFront](#lambda-edge-identifying-function-errors)
+ [Dépannage en cas de réponses de fonction Lambda@Edge non valide (erreurs de validation)](#lambda-edge-testing-debugging-troubleshooting-invalid-responses)
+ [Dépannage des erreurs d’exécution de fonction Lambda@Edge](#lambda-edge-testing-debugging-execution-errors)
+ [Définition de la région Lambda@Edge](#lambda-edge-testing-debugging-determine-region)
+ [Déterminez si votre compte envoie les journaux vers CloudWatch](#lambda-edge-testing-debugging-cloudwatch-logs-enabled)

## Test de vos fonctions Lambda@Edge
<a name="lambda-edge-testing-debugging-test-function"></a>

Il existe deux étapes pour tester votre fonction Lambda : le test autonome et le test d'intégration.

**Test de la fonctionnalité autonome**  
Avant d'ajouter votre fonction Lambda à CloudFront, assurez-vous de la tester d'abord en utilisant les fonctionnalités de test de la console Lambda ou en utilisant d'autres méthodes. Pour plus d’informations sur les tests de la console Lambda, consultez [Invoquer une fonction Lambda avec la console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#get-started-invoke-manually) dans le *Guide du développeur AWS Lambda *.

**Testez le fonctionnement de votre fonction dans CloudFront**  
Il est important de réaliser des tests d'intégration, dans lesquels votre fonction est associée à une distribution et s'exécute en fonction d'un CloudFront événement. Assurez-vous que la fonction est déclenchée pour le bon événement, et qu'elle renvoie une réponse valide et correcte CloudFront. Par exemple, assurez-vous que la structure de l’événement est correcte, que seuls les en-têtes valides sont inclus, etc.  
Au fur et à mesure que vous testez l'intégration de votre fonction dans la console Lambda, reportez-vous aux étapes du didacticiel Lambda @Edge pour modifier votre code ou CloudFront le déclencheur qui appelle votre fonction. Par exemple, vérifiez que vous travaillez avec une version numérotée de votre fonction, comme le décrit cette étape du tutoriel : [Étape 4 : ajouter un CloudFront déclencheur pour exécuter la fonction](lambda-edge-how-it-works-tutorial.md#lambda-edge-how-it-works-tutorial-add-trigger).   
Lorsque vous apportez des modifications et que vous les déployez, sachez qu'il faudra plusieurs minutes pour que votre fonction et vos CloudFront déclencheurs mis à jour soient répliqués dans toutes les régions. Cela prend généralement quelques minutes, mais peut durer jusqu'à 15 minutes.  
Vous pouvez vérifier si la réplication est terminée en accédant à la CloudFront console et en consultant votre distribution.  

**Pour vérifier si le déploiement de votre réplication est terminé**

1. Ouvrez la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez le nom de la distribution.

1. Vérifiez que le statut de distribution passe de **En cours** à **Déployé**, ce qui signifie que votre fonction a été répliquée. Suivez les étapes de la section suivante afin de vérifier que la fonction s'exécute correctement.
Sachez que les tests effectués dans la console valident uniquement la logique de votre fonction et n'appliquent pas de quotas (auparavant appelés limites) de service spécifiques à Lambda@Edge.

## Identifiez les erreurs de fonction Lambda @Edge dans CloudFront
<a name="lambda-edge-identifying-function-errors"></a>

Une fois que vous avez vérifié que la logique de votre fonction fonctionne correctement, des erreurs HTTP 5xx peuvent encore s'afficher lors de l'exécution de votre fonction. CloudFront Les erreurs HTTP 5xx peuvent être renvoyées pour diverses raisons, notamment des erreurs liées à la fonction Lambda ou d'autres problèmes. CloudFront
+ Si vous utilisez les fonctions Lambda @Edge, vous pouvez utiliser les graphiques de la CloudFront console pour identifier la cause de l'erreur, puis essayer de la corriger. Par exemple, vous pouvez voir si les erreurs HTTP 5xx sont causées par CloudFront ou par des fonctions Lambda, puis, pour des fonctions spécifiques, vous pouvez consulter les fichiers journaux associés afin d'étudier le problème.
+ Pour résoudre les erreurs HTTP en général dans CloudFront, consultez les étapes de résolution des problèmes décrites dans la rubrique suivante :[Résolution des codes d'état des réponses aux erreurs dans CloudFront](troubleshooting-response-errors.md).

### Quelles sont les causes des erreurs de fonction Lambda @Edge dans CloudFront
<a name="lambda-edge-testing-debugging-function-errors"></a>

Il existe plusieurs raisons pour lesquelles une fonction Lambda peut entraîner une erreur HTTP 5xx. Les étapes de résolution à suivre dépendent du type d'erreur. Les erreurs peuvent être classées comme suit :

**Une erreur d'exécution de la fonction Lambda**  
Une erreur d'exécution se produit lorsque Lambda CloudFront ne reçoit pas de réponse en raison d'exceptions non gérées dans la fonction ou d'une erreur dans le code. Par exemple, si le code comprend le rappel (Error).

**Une réponse de fonction Lambda non valide est renvoyée à CloudFront**  
Une fois la fonction exécutée, CloudFront reçoit une réponse de Lambda. Une erreur est renvoyée si la structure d'objet de la réponse n'est pas conforme à [Structure d'événement Lambda@Edge](lambda-event-structure.md) ou si la réponse contient des en-têtes ou d'autres champs non valides.

**L'exécution dans CloudFront est limitée en raison des quotas de service Lambda (anciennement appelés limites)**  
Le service Lambda limite les exécutions dans chaque région, et renvoie une erreur si vous dépassez le quota. Pour de plus amples informations, veuillez consulter [Quotas sur Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).

### Comment déterminer le type d'échec
<a name="lambda-edge-testing-debugging-failure-type"></a>

Pour vous aider à décider sur quoi vous concentrer lorsque vous débugez et que vous vous efforcez de résoudre les erreurs renvoyées CloudFront, il est utile de déterminer pourquoi une erreur HTTP CloudFront est renvoyée. Pour commencer, vous pouvez utiliser les graphiques fournis dans la section **Surveillance** de la CloudFront console sur le AWS Management Console. Pour plus d'informations sur l'affichage des graphiques dans la section **Surveillance** de la CloudFront console, consultez[Surveillez CloudFront les métriques avec Amazon CloudWatch](monitoring-using-cloudwatch.md).

Les graphiques suivants peuvent être particulièrement utiles lorsque vous souhaitez retracer si des erreurs sont renvoyées par les origines ou par une fonction Lambda, et pour réduire le type de problème lorsqu'il s'agit d'une erreur provenant d'une fonction Lambda.

**Graphique des taux d'erreurs**  
L'un des graphiques que vous pouvez afficher dans l'onglet **Présentation** pour chacune de vos distributions est un graphique de **taux d'erreurs**. Ce graphique affiche le taux d'erreurs sous forme de pourcentage du nombre total de demandes adressées à votre distribution. Ce graphique montre le taux d'erreurs total, le total des erreurs 4xx, le total des erreurs 5xx et le total des erreurs 5xx provenant des fonctions Lambda. Selon le type d'erreur et le volume, vous pouvez prendre des mesures pour étudier et résoudre le problème initial.  

![\[Graphique des taux d'erreur pour une CloudFront distribution\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/Distribution-error-rate-pct-full.png)

+ Si vous voyez des erreurs Lambda, vous pouvez poursuivre vos investigations en examinant les types d'erreurs spécifiques que la fonction renvoie. L'onglet **Lambda@Edge errors (Erreurs Lambda@Edge)** inclut des graphiques qui classent les erreurs de fonction par type pour vous aider à identifier le problème pour une fonction spécifique.
+ Si vous CloudFront constatez des erreurs, vous pouvez les résoudre et vous efforcer de corriger les erreurs d'origine ou de modifier votre CloudFront configuration. Pour de plus amples informations, veuillez consulter [Résolution des codes d'état des réponses aux erreurs dans CloudFront](troubleshooting-response-errors.md).

**Graphiques des erreurs d'exécution et des réponses de fonction non valide**  
L'onglet **Lambda@Edge errors (Erreurs Lambda@Edge)** inclut des graphiques permettant de classer les erreurs Lambda@Edge pour une distribution spécifique, par type. Par exemple, un graphique montre toutes les erreurs d’exécution par Région AWS.  
Pour faciliter la résolution des problèmes, vous pouvez rechercher des problèmes spécifiques en ouvrant et en examinant les fichiers journaux des fonctions spécifiques par région.   

**Pour afficher les fichiers journaux d’une fonction spécifique par région**

1. Dans l’onglet **Erreurs Lambda@Edge**, sous **Fonctions Lambda@Edge associées**, choisissez le nom de la fonction, puis choisissez **Afficher les métriques**. 

1. Ensuite, sur la page affichant le nom de votre fonction, dans le coin supérieur droit, choisissez **Afficher les journaux de fonction**, puis sélectionnez une Région. 

   Par exemple, si vous constatez des problèmes dans le graphique **Erreurs** pour la Région USA Ouest (Oregon), choisissez cette Région dans la liste déroulante. Cela ouvre la CloudWatch console Amazon.

1. Dans la CloudWatch console de cette région, sous **Log streams**, choisissez un log stream pour afficher les événements liés à la fonction.
De plus, lisez les sections suivantes de ce chapitre pour plus de recommandations sur le dépannage et la correction des erreurs.

**Graphique des limitations**  
L'onglet **Lambda@Edge errors (Erreurs Lambda@Edge)** inclut également un graphique **Throttles (Limitations)**. Occasionnellement, le service Lambda limite vos appels de fonction par région si vous atteignez le quota (auparavant appelé limite) de simultanéité régionale. Si vous voyez une erreur de dépassement de limite, cela signifie que votre fonction a atteint un quota que le service Lambda impose sur les exécutions dans une région. Pour obtenir plus d’informations sur ces limites et découvrir comment demander une augmentation du quota, consultez [Quotas sur Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge).  

![\[Graphique des limitations pour l’exécution de la fonction Lambda@Edge.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/Lambda-throttles-page.png)


Pour obtenir un exemple sur la façon d'utiliser ces informations pour résoudre des erreurs HTTP, consultez le billet de blog [Four steps for debugging your content delivery on AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/four-steps-for-debugging-your-content-delivery-on-aws/).

## Dépannage en cas de réponses de fonction Lambda@Edge non valide (erreurs de validation)
<a name="lambda-edge-testing-debugging-troubleshooting-invalid-responses"></a>

Si vous identifiez que votre problème est dû à une erreur de validation Lambda, cela signifie que votre fonction Lambda renvoie une réponse non valide à. CloudFront Suivez les instructions de cette section pour prendre les mesures nécessaires pour revoir votre fonction et vous assurer que votre réponse est conforme aux CloudFront exigences. 

CloudFront valide la réponse d'une fonction Lambda de deux manières :
+ **La réponse Lambda doit se conformer à la structure d'objet requise.** Voici des exemples de mauvaise structure d'objet : impossible d'analyser JSON, champs obligatoires manquants et la réponse contient un objet non valide. Pour de plus amples informations, veuillez consulter [Structure d'événement Lambda@Edge](lambda-event-structure.md).
+ **La réponse doit inclure uniquement les valeurs d'objet valides.** Une erreur se produit si la réponse inclut un objet valide mais dont les valeurs ne sont pas prises en charge. Les exemples incluent les éléments suivants : ajout ou mise à jour d'en-têtes non autorisés ou en lecture seule (voir [Restrictions sur les fonctions périphériques](edge-functions-restrictions.md)), dépassement des limitations de taille du corps (voir *Limites sur la taille de la réponse générée dans la rubrique Lambda@Edge [Erreurs](lambda-generating-http-responses.md#lambda-generating-http-responses-errors)*) et les caractères ou les valeurs non valables (voir [Structure d'événement Lambda@Edge](lambda-event-structure.md)).

Lorsque Lambda renvoie une réponse non valide à CloudFront, des messages d'erreur sont écrits CloudWatch dans des fichiers journaux qui sont CloudFront redirigés vers la région où la fonction Lambda a été exécutée. C'est le comportement par défaut auquel envoyer les fichiers journaux en CloudWatch cas de réponse non valide. Toutefois, si vous avez associé une fonction Lambda à une fonction Lambda CloudFront avant son lancement, il est possible qu'elle ne soit pas activée pour votre fonction. Pour plus d'informations, consultez la section *Déterminez si votre compte transmet les fichiers journaux à CloudWatch* plus loin dans la rubrique.

CloudFront envoie les fichiers journaux vers la région correspondant à l'endroit où votre fonction a été exécutée, dans le groupe de journaux associé à votre distribution. Les groupes de journaux ont le format suivant :`/aws/cloudfront/LambdaEdge/DistributionId`, où *DistributionId* est l'ID de votre distribution. Pour déterminer la région dans laquelle se trouvent les fichiers CloudWatch journaux, consultez la section *Détermination de la région Lambda @Edge* plus loin dans cette rubrique.

Si l'erreur est reproductible, vous pouvez créer une nouvelle demande qui entraîne l'erreur, puis rechercher l'identifiant de la demande dans une CloudFront réponse ayant échoué (`X-Amz-Cf-Id`en-tête) afin de localiser un seul échec dans les fichiers journaux. L'entrée du fichier journal inclut des informations susceptibles de vous aider à identifier les raisons pour lesquelles l'erreur est renvoyée, et affiche aussi l'ID de demande Lambda correspondant, ce qui vous permet d'analyser la cause première dans le cadre d'une seule demande.

Si une erreur est intermittente, vous pouvez utiliser les journaux d' CloudFront accès pour trouver l'identifiant d'une demande qui a échoué, puis rechercher dans CloudWatch les journaux les messages d'erreur correspondants. Pour plus d'informations, consultez la section précédente, *Détermination du type d'échec*.

## Dépannage des erreurs d’exécution de fonction Lambda@Edge
<a name="lambda-edge-testing-debugging-execution-errors"></a>

Si le problème provient d'une erreur d'exécution Lambda, il peut être utile de créer des instructions de journalisation pour les fonctions Lambda, d'écrire des messages dans des fichiers CloudWatch journaux qui surveillent l'exécution de votre fonction CloudFront et déterminent si elle fonctionne comme prévu. Vous pouvez ensuite rechercher ces instructions dans les fichiers CloudWatch journaux pour vérifier que votre fonction fonctionne.

**Note**  
Même si vous n'avez pas modifié votre fonction Lambda@Edge, les mises à jour de l'environnement d'exécution de la fonction Lambda peuvent l'affecter et renvoyer une erreur d'exécution. Pour plus d'informations sur les tests et la migration vers une version ultérieure, consultez [Prochaines mises à jour de l'environnement d'exécution AWS Lambda et AWS Lambda @Edge](https://aws.amazon.com/blogs/compute/upcoming-updates-to-the-aws-lambda-execution-environment/).

## Définition de la région Lambda@Edge
<a name="lambda-edge-testing-debugging-determine-region"></a>

Pour connaître les régions dans lesquelles votre fonction Lambda @Edge reçoit du trafic, consultez les métriques de la fonction sur la CloudFront console du. AWS Management Console Les statistiques sont affichées pour chaque AWS région. Sur la même page, vous pouvez choisir une région et afficher les fichiers journaux pour cette région afin de pouvoir rechercher des problèmes. Vous devez consulter les fichiers CloudWatch journaux dans la AWS région appropriée pour voir les fichiers journaux créés lors de l' CloudFront exécution de votre fonction Lambda.

Pour plus d'informations sur l'affichage des graphiques dans la section **Surveillance** de la CloudFront console, consultez[Surveillez CloudFront les métriques avec Amazon CloudWatch](monitoring-using-cloudwatch.md).

## Déterminez si votre compte envoie les journaux vers CloudWatch
<a name="lambda-edge-testing-debugging-cloudwatch-logs-enabled"></a>

Par défaut, CloudFront active la journalisation des réponses de fonction Lambda non valides et envoie les fichiers journaux vers CloudWatch . [Rôles liés à un service pour Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge) Si vous avez ajouté des fonctions Lambda @Edge CloudFront avant la publication de la fonctionnalité de journal des réponses des fonctions Lambda non valide, la journalisation est activée lors de la prochaine mise à jour de votre configuration Lambda @Edge, par exemple en ajoutant un déclencheur. CloudFront 

Vous pouvez vérifier que le transfert des fichiers journaux vers CloudWatch est activé pour votre compte en procédant comme suit :
+ **Vérifiez si les journaux apparaissent dans CloudWatch** — Assurez-vous de regarder dans la région où la fonction Lambda @Edge s'est exécutée. Pour de plus amples informations, veuillez consulter [Définition de la région Lambda@Edge](#lambda-edge-testing-debugging-determine-region).
+ **Déterminez si le rôle lié au service associé existe dans votre compte IAM** : vous devez disposer du rôle IAM `AWSServiceRoleForCloudFrontLogger` dans votre compte. Pour plus d’informations sur ce rôle, consultez [Rôles liés à un service pour Lambda@Edge](lambda-edge-permissions.md#using-service-linked-roles-lambda-edge).

# Suppression des fonctions et des réplicas Lambda@Edge
<a name="lambda-edge-delete-replicas"></a>

Vous pouvez supprimer une fonction Lambda@Edge uniquement lorsque les réplicas de cette fonction ont été supprimés par CloudFront. Les réplicas d'une fonction Lambda sont automatiquement supprimés dans les cas suivants :
+ Après avoir supprimé la dernière association de la fonction de toutes vos distributions CloudFront. Si plusieurs distributions utilisent une fonction, les réplicas ne sont supprimés qu'après avoir supprimé l'association de fonctions de la dernière distribution.
+ Après avoir supprimé la dernière distribution à laquelle une fonction était associée.

Ils sont généralement supprimés en quelques heures. Vous ne pouvez pas supprimer manuellement des réplicas de fonction Lambda@Edge. Cela permet d'éviter la suppression d'un réplica en cours d'utilisation, ce qui entraînerait une erreur.

**Avertissement**  
Ne créez pas d'applications qui utilisent des répliques de fonctions Lambda @Edge en dehors de. CloudFront Ces réplicas sont supprimés lorsque leurs associations avec des distributions sont supprimées, ou lorsque les distributions elles-mêmes sont supprimées. Le réplica dont dépend une application externe pourrait être supprimé sans avertissement, ce qui entraînerait un échec.

**Pour supprimer une association de fonctions Lambda @Edge d'une distribution CloudFront**

1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choisissez l’ID de la distribution qui possède l’association de la fonction Lambda@Edge que vous souhaitez supprimer.

1. Choisissez l’onglet **Comportements**.

1. Sélectionnez le comportement de cache qui contient l’association à la fonction Lambda@Edge que vous souhaitez supprimer, puis choisissez **Modifier**.

1. Sous **Associations de fonctions**, **Type de fonction**, choisissez **Aucune association** pour supprimer l’association de fonctions Lambda@Edge.

1. Sélectionnez **Enregistrer les modifications**.

Après avoir supprimé une association de fonctions Lambda @Edge d'une CloudFront distribution, vous pouvez éventuellement supprimer la fonction Lambda ou sa version de. AWS Lambda Patientez quelques heures après avoir supprimé l’association de la fonction pour permettre le nettoyage des réplicas de la fonction Lambda@Edge. Ensuite, vous pouvez supprimer la fonction à l'aide de la console Lambda, de l'API AWS CLI Lambda ou d'un SDK. AWS 

Vous pouvez également supprimer une *version* spécifique d'une fonction Lambda si aucune CloudFront distribution n'est associée à cette version. Une fois toutes les associations supprimées pour une version de fonction Lambda, patientez quelques heures. Vous pourrez alors supprimer la version de la fonction.

# Structure d'événement Lambda@Edge
<a name="lambda-event-structure"></a>

Les rubriques suivantes décrivent les objets d'événements de demande et de réponse CloudFront transmis à une fonction Lambda @Edge lorsqu'elle est déclenchée.

**Topics**
+ [Sélection de l'origine dynamique](#lambda-event-content-based-routing)
+ [Événements de demande](#lambda-event-structure-request)
+ [Événements de réponse](#lambda-event-structure-response)

## Sélection de l'origine dynamique
<a name="lambda-event-content-based-routing"></a>

Vous pouvez utiliser [le modèle de chemin dans un comportement de cache](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern) pour router les demandes vers une origine, en fonction du chemin et du nom de l'objet demandé, tels que `images/*.jpg`. En utilisant Lambda@Edge, vous pouvez également acheminer des demandes vers une origine en fonction d'autres caractéristiques, comme les valeurs contenues dans les en-têtes de la demande. 

Cette sélection d'origine dynamique peut être utile de diverses façons. Par exemple, vous pouvez répartir les demandes entre des origines de différentes zones géographiques pour vous aider à réaliser un équilibrage de charge international. Ou vous pouvez acheminer de façon sélective des demandes vers différentes origines servant chacune une fonction donnée : gestion du robot, optimisation de la stratégie SEO, authentification, etc. Pour obtenir des exemples de code qui expliquent comment utiliser cette fonctionnalité, consultez [Sélection d'origine dynamique basée sur le contenu – exemples](lambda-examples.md#lambda-examples-content-based-routing-examples).

Dans l'événement de demande CloudFront d'origine, l'`origin`objet de la structure d'événement contient des informations sur l'origine vers laquelle la demande serait acheminée, en fonction du modèle de chemin. Vous pouvez mettre à jour les valeurs de l'objet `origin` pour router une demande vers une autre origine. Quand vous mettez à jour l'objet `origin`, vous n'avez pas besoin de définir l'origine dans la distribution. Vous pouvez également remplacer un objet d'origine Amazon S3 par un objet d'origine personnalisée, et vice versa. Toutefois, vous ne pouvez spécifier qu'une seule origine par demande ; une origine personnalisée ou une origine Amazon S3, mais pas les deux.

## Événements de demande
<a name="lambda-event-structure-request"></a>

Les rubriques suivantes présentent la structure de l'objet qui est transmis à CloudFront une fonction Lambda pour les événements de [demande d'affichage et d'origine](lambda-cloudfront-trigger-events.md). Ces exemples montrent une demande `GET` sans corps. Après les exemples, vous trouverez la liste de tous les champs possibles dans les événements de demande d'utilisateur et d'origine.

**Topics**
+ [Exemple de demande d'utilisateur](#example-viewer-request)
+ [Exemple de demande de l'origine](#example-origin-request)
+ [Champs d'événement de demande](#request-event-fields)

### Exemple de demande d'utilisateur
<a name="example-viewer-request"></a>

L'exemple suivant montre un objet d'événement de demande d'utilisateur.

```
{
  "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": "/"
        }
      }
    }
  ]
}
```

### Exemple de demande de l'origine
<a name="example-origin-request"></a>

L'exemple suivant montre un objet d'événement de demande d'origine.

```
{
  "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": "/"
        }
      }
    }
  ]
}
```

### Champs d'événement de demande
<a name="request-event-fields"></a>

Les données d'objet d'événement de demande sont contenues dans deux sous-objets : `config` (`Records.cf.config`) et `request` (`Records.cf.request`). Les listes suivantes décrivent les champs de chaque sous-objet.

#### Champs de l’objet config
<a name="request-event-fields-config"></a>

La liste suivante décrit les champs figurant dans l’objet `config` (`Records.cf.config`).

**`distributionDomainName` (lecture seule)**  
Nom de domaine de la distribution qui est associée à la demande.

**`distributionID` (lecture seule)**  
ID de la distribution qui est associée à la demande.

**`eventType` (lecture seule)**  
Type de déclencheur associé à la demande : `viewer-request` ou `origin-request`.

**`requestId` (lecture seule)**  
Chaîne cryptée qui identifie de manière unique une viewer-to-CloudFront demande. La valeur `requestId` apparaît également dans les journaux d'accès de CloudFront en tant que `x-edge-request-id`. Pour plus d’informations, consultez [Journaux d'accès (journaux standard)](AccessLogs.md) et [Champs du fichier journal](standard-logs-reference.md#BasicDistributionFileFormat).

#### Champs de l'objet de demande
<a name="request-event-fields-request"></a>

La liste suivante décrit les champs figurant dans l’objet `request` (`Records.cf.request`).

**`clientIp` (lecture seule)**  
Adresse IP de l'utilisateur qui a émis la requête. Si l'utilisateur a utilisé un proxy HTTP ou un équilibreur de charge pour envoyer la demande, la valeur correspond à l'adresse IP du proxy ou de l'équilibreur de charge.

**en-têtes (lecture/écriture)**  
En-têtes de la requête. Remarques :  
+ Les clés figurant dans l’objet `headers` sont les versions en minuscules des noms d’en-têtes HTTP standard. L'utilisation des minuscules vous permet d'accéder aux valeurs des en-têtes sans tenir compte de la casse.
+ Chaque objet d’en-tête (par exemple, `headers["accept"]` ou `headers["host"]`) est un tableau de paires clé-valeur. Pour un en-tête donné, le tableau contient une paire clé-valeur pour chaque valeur dans la demande.
+ `key` contient le nom sensible à la casse de l’en-tête tel qu’il apparaissait dans la demande HTTP ; par exemple, `Host`, `User-Agent`, `X-Forwarded-For`, `Cookie`, etc.
+ `value` contient la valeur d'en-tête telle qu'elle apparaissait dans la requête HTTP.
+ Lorsque votre fonction Lambda ajoute ou modifie des en-têtes de demande et que vous n'incluez pas le champ `key` d'en-tête, Lambda@Edge insère automatiquement une clé (`key`) d'en-tête en utilisant le nom d'en-tête que vous fournissez. Quelle que soit la manière dont vous avez formaté le nom d'en-tête, la clé d'en-tête qui est insérée automatiquement est formatée avec une majuscule initiale pour chaque partie, séparée par des tirets (-).

  Par exemple, vous pouvez ajouter un en-tête comme le suivant, sans clé (`key`) d’en-tête :

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

  Dans cet exemple, Lambda@Edge insère automatiquement `"key": "User-Agent"`.
Pour plus d’informations sur les restrictions applicables à l’utilisation d’en-têtes, consultez [Restrictions sur les fonctions périphériques](edge-functions-restrictions.md).

**`method` (lecture seule)**  
Méthode HTTP de la demande.

**`querystring` (lecture/écriture)**  
Chaîne de requête, le cas échéant, dans la demande. Si la demande n'inclut pas de chaîne de requête, l'objet d'événement inclut quand-même `querystring` avec une valeur vide. Pour plus d’informations sur les chaînes de requête, consultez [Mise en cache de contenu basée sur les paramètres de chaîne de requête](QueryStringParameters.md).

**`uri` (lecture/écriture)**  
Chemin d'accès relatif de l'objet demandé. Si votre fonction Lambda modifie la valeur `uri`, notez ce qui suit :  
+ La nouvelle valeur `uri` doit commencer par une barre oblique (/).
+ Lorsqu'une fonction modifie la valeur `uri`, cela change l'objet que l'utilisateur demande.
+ Lorsqu'une fonction modifie la valeur `uri`, cela *ne modifie pas* le comportement de cache pour la demande ou l'origine vers laquelle la demande est envoyée.

**`body` (lecture/écriture)**  
Corps de la requête HTTP. La structure `body` peut contenir les champs suivants :    
**`inputTruncated` (lecture seule)**  
Indicateur booléen qui indique si le corps a été tronqué par Lambda@Edge. Pour plus d’informations, consultez [Restrictions relatives au corps de la requête avec l'option Inclure le corps](lambda-at-edge-function-restrictions.md#lambda-at-edge-restrictions-request-body).  
**`action` (lecture/écriture)**  
L'action que vous avez l'intention de prendre avec le corps. Les options pour l'`action`sont les suivantes :  
+ `read-only:` Il s'agit de l'option par défaut. Au moment de renvoyer la réponse à partir de la fonction Lambda, si `action` est en lecture seule, Lambda@Edge ignore les modifications apportée à `encoding` ou à `data`.
+ `replace:` À préciser lorsque vous souhaitez remplacer le corps envoyé à l'origine.  
**`encoding` (lecture/écriture)**  
L'encodage pour le corps. Lorsque Lambda@Edge expose le corps à la fonction Lambda, il convertit d'abord le corps en base64-encoding. Si vous choisissez `replace` comme `action` pour remplacer le corps, vous pouvez choisir d'utiliser l'encodage `base64` (option par défaut) ou `text`. Si vous précisez `encoding` comme `base64`, mais que le corps n'est pas valide base64, CloudFront renvoie une erreur.  
**`data` (lecture/écriture)**  
Le contenu du corps de requête. 

**`origin` (lecture/écriture) (événements d'origine uniquement)**  
Origine vers laquelle envoyer la demande. La structure `origin` doit contenir *une unique origine*, qui peut être une origine personnalisée ou une origine Amazon S3.  
Selon le type d’origine que vous spécifiez (origine personnalisée ou origine Amazon S3), vous devez indiquer les champs suivants dans votre demande :    
**`customHeaders` (lecture/écriture) (origines personnalisées et Amazon S3)**  
(Facultatif) Vous pouvez inclure des en-têtes personnalisés dans la demande en spécifiant un nom et une valeur d’en-tête pour chacun d’eux. Vous ne pouvez pas ajouter des en-têtes non autorisés et un en-tête portant le même nom ne peut pas être présent dans `Records.cf.request.headers`. Les [notes sur les en-têtes de demande](#request-event-fields-request-headers) s'appliquent également aux en-têtes personnalisés. Pour plus d’informations, consultez [En-têtes personnalisés qui ne CloudFront peuvent pas être ajoutés aux demandes d'origine](add-origin-custom-headers.md#add-origin-custom-headers-denylist) et [Restrictions sur les fonctions périphériques](edge-functions-restrictions.md).  
**`domainName` (lecture/écriture) (origines personnalisées et Amazon S3)**  
Nom de domaine de l’origine. Le nom de domaine ne peut pas être vide.  
+ **Pour les origines personnalisées** – Spécifiez un nom de domaine DNS, tel que `www.example.com`. Le nom de domaine ne peut pas inclure un signe deux-points (:) et ne peut pas être une adresse IP. Le nom du domaine peut contenir jusqu’à 253 caractères.
+ **Pour les origines Amazon S3** – Spécifiez le nom de domaine DNS du compartiment Amazon S3, tel que `amzn-s3-demo-bucket.s3.eu-west-1.amazonaws.com`. Il peut comporter jusqu'à 128 caractères, qui doivent tous être en minuscules.  
**`path` (lecture/écriture) (origines personnalisées et Amazon S3)**  
Chemin de répertoire à l’origine où la demande doit localiser le contenu. Ce chemin doit commencer par une barre oblique (/) mais ne doit pas se terminer par une barre oblique (par exemple, il ne doit pas se terminer par `example-path/`). Pour les origines personnalisées uniquement, le chemin doit être codé par URL et avoir une longueur maximale de 255 caractères.  
**`keepaliveTimeout` (lecture/écriture) (origines personnalisées uniquement)**  
Combien de temps, en secondes, cela CloudFront devrait essayer de maintenir la connexion à l'origine après avoir reçu le dernier paquet de la réponse. La valeur doit être un nombre compris entre 1 et 120 inclus.  
**`port` (lecture/écriture) (origines personnalisées uniquement)**  
Le port auquel vous CloudFront devez vous connecter à votre point d'origine personnalisé. Il doit s'agir du port 80, du port 443 ou d'un port compris entre 1 024 et 65 535.  
**`protocol` (lecture/écriture) (origines personnalisées uniquement)**  
Protocole de connexion à utiliser CloudFront lors de la connexion à votre point d'origine. La valeur peut être `http` ou `https`.  
**`readTimeout` (lecture/écriture) (origines personnalisées et Amazon S3)**  
Combien de temps, en secondes, CloudFront doit attendre une réponse après avoir envoyé une demande à votre origine. Cela spécifie également la durée pendant laquelle CloudFront doit attendre après avoir reçu un paquet d'une réponse et avant de recevoir le paquet suivant. La valeur doit être un nombre compris entre 1 et 120 inclus.  
Si vous avez besoin d’un quota plus élevé, consultez [Délai de réponse par origine](cloudfront-limits.md#limits-web-distributions).  
**`responseCompletionTimeout` (lecture/écriture) (origines personnalisées et Amazon S3)**  
Durée (en secondes) pendant laquelle une demande provenant CloudFront de l'origine peut rester ouverte et attendre une réponse. Si la réponse complète n'est pas reçue de l'origine à ce moment-là, CloudFront met fin à la connexion.  
La valeur de `responseCompletionTimeout` doit être supérieure ou égale à la valeur de `readTimeout`. En définissant cette valeur sur 0, vous effacez toute valeur précédemment définie et rétablissez la valeur par défaut. Vous pouvez également obtenir le même résultat en supprimant le champ `responseCompletionTimeout` de la demande d’événement.   
**`sslProtocols` (lecture/écriture) (origines personnalisées uniquement)**  
 SSL/TLS Protocole minimal à CloudFront utiliser lors de l'établissement d'une connexion HTTPS avec votre point d'origine. Il peut s'agir des valeurs suivantes : `TLSv1.2`, `TLSv1.1`, `TLSv1` ou `SSLv3`.  
**`authMethod` (lecture/écriture) (origines Amazon S3 uniquement)**  
Si vous utilisez une [identité d'accès à l'origine (OAI)](private-content-restricting-access-to-s3.md#private-content-restricting-access-to-s3-oai), définissez ce champ sur `origin-access-identity`. Si vous n'utilisez pas d'OAI, configurez-le sur `none`. Si vous définissez `authMethod` sur `origin-access-identity`, il existe plusieurs exigences :   
+ Vous devez spécifier le paramètre `region` (voir le champ suivant).
+ Vous devez utiliser la même identité d'accès à l'origine lorsque vous changez l'origine Amazon S3 de la demande.
+ Vous ne pouvez pas utiliser d'identité d'accès à l'origine lorsque vous remplacez l'origine personnalisée de la demande par une origine Amazon S3.
Ce champ ne prend pas en charge le [contrôle d'accès à l'origine (OAC)](private-content-restricting-access-to-s3.md).  
**`region` (lecture/écriture) (origines Amazon S3 uniquement)**  
La AWS région de votre compartiment Amazon S3. Cette option n'est requise que lorsque vous définissez `authMethod` sur `origin-access-identity`.

## Événements de réponse
<a name="lambda-event-structure-response"></a>

Les rubriques suivantes présentent la structure de l'objet qui est CloudFront transmis à une fonction Lambda pour les événements de [réponse du visualiseur et de l'origine](lambda-cloudfront-trigger-events.md). Après les exemples, vous trouverez la liste de tous les champs possibles dans les événements de réponse d'utilisateur et d'origine.

**Topics**
+ [Exemple de réponse de l'origine](#lambda-event-structure-response-origin)
+ [Exemple de réponse de l'utilisateur](#lambda-event-structure-response-viewer)
+ [Champs d'événement de réponse](#response-event-fields)

### Exemple de réponse de l'origine
<a name="lambda-event-structure-response-origin"></a>

L'exemple suivant montre un objet d'événement de réponse de l'origine.

```
{
  "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"
        }
      }
    }
  ]
}
```

### Exemple de réponse de l'utilisateur
<a name="lambda-event-structure-response-viewer"></a>

L'exemple suivant montre un objet d'événement de réponse de l'utilisateur.

```
{
  "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"
        }
      }
    }
  ]
}
```

### Champs d'événement de réponse
<a name="response-event-fields"></a>

Les données d'objet d'événement de réponse sont contenues dans trois sous-objets : `config` (`Records.cf.config`), `request` (`Records.cf.request`) et `response` (`Records.cf.response`). Pour plus d’informations sur les champs de l’objet de demande, consultez [Champs de l'objet de demande](#request-event-fields-request). Les listes suivantes décrivent les champs figurant dans les sous-objets `config` et `response`.

#### Champs de l’objet config
<a name="response-event-fields-config"></a>

La liste suivante décrit les champs figurant dans l’objet `config` (`Records.cf.config`).

**`distributionDomainName` (lecture seule)**  
Nom de domaine de la distribution qui est associée à la réponse.

**`distributionID` (lecture seule)**  
ID de la distribution qui est associée à la réponse.

**`eventType` (lecture seule)**  
Type de déclencheur associé à la réponse : `origin-response` ou `viewer-response`.

**`requestId` (lecture seule)**  
Chaîne cryptée qui identifie de manière unique la viewer-to-CloudFront demande à laquelle cette réponse est associée. La `requestId` valeur apparaît également dans les journaux CloudFront d'accès sous la forme`x-edge-request-id`. Pour plus d’informations, consultez [Journaux d'accès (journaux standard)](AccessLogs.md) et [Champs du fichier journal](standard-logs-reference.md#BasicDistributionFileFormat).

#### Champs de l'objet de réponse
<a name="response-event-fields-response"></a>

La liste suivante décrit les champs figurant dans l’objet `response` (`Records.cf.response`). Pour obtenir des informations sur l’utilisation d’une fonction Lambda@Edge pour générer une réponse HTTP, consultez [Génération de réponses HTTP dans les déclencheurs de demande](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).

**`headers` (lecture/écriture)**  
En-têtes de la réponse. Remarques :  
+ Les clés figurant dans l’objet `headers` sont les versions en minuscules des noms d’en-têtes HTTP standard. L'utilisation des minuscules vous permet d'accéder aux valeurs des en-têtes sans tenir compte de la casse.
+ Chaque objet d’en-tête (par exemple, `headers["content-type"]` ou `headers["content-length"]`) est un tableau de paires clé-valeur. Pour un en-tête donné, le tableau contient une paire clé-valeur pour chaque valeur de la réponse.
+ `key` contient le nom sensible à la casse de l’en-tête tel qu’il apparaît dans la réponse HTTP ; par exemple, `Content-Type`, `Content-Length`, `Cookie`, etc.
+ `value` contient la valeur d'en-tête telle qu'elle apparaît dans la réponse HTTP.
+ Lorsque votre fonction Lambda ajoute ou modifie des en-têtes de réponse et que vous n'incluez pas le champ `key` d'en-tête, Lambda@Edge insère automatiquement une clé (`key`) d'en-tête en utilisant le nom d'en-tête que vous fournissez. Quelle que soit la manière dont vous avez formaté le nom d'en-tête, la clé d'en-tête qui est insérée automatiquement est formatée avec une majuscule initiale pour chaque partie, séparée par des tirets (-).

  Par exemple, vous pouvez ajouter un en-tête comme le suivant, sans clé (`key`) d’en-tête :

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

  Dans cet exemple, Lambda@Edge insère automatiquement `"key": "Content-Type"`.
Pour plus d’informations sur les restrictions applicables à l’utilisation d’en-têtes, consultez [Restrictions sur les fonctions périphériques](edge-functions-restrictions.md).

**`status`**  
Code de statut HTTP de la réponse.

**`statusDescription`**  
Description de l’état HTTP de la réponse.

# Utilisation des demandes et des réponses
<a name="lambda-generating-http-responses"></a>

Pour utiliser les demandes et réponses Lambda@Edge, consultez les rubriques suivantes :

**Topics**
+ [Utilisation des fonctions Lambda@Edge avec le basculement d’origine](#lambda-and-origin-failover)
+ [Génération de réponses HTTP dans les déclencheurs de demande](#lambda-generating-http-responses-in-requests)
+ [Mise à jour des réponses HTTP dans des déclencheurs de réponse de l’origine](#lambda-updating-http-responses)
+ [Accès au corps de requête en choisissant l’option Inclure le corps](#lambda-include-body-access)

## Utilisation des fonctions Lambda@Edge avec le basculement d’origine
<a name="lambda-and-origin-failover"></a>

Vous pouvez utiliser les fonctions Lambda @Edge avec des CloudFront distributions que vous avez configurées avec des groupes d'origine, par exemple, pour le basculement d'origine que vous configurez afin de garantir une haute disponibilité. Pour utiliser une fonction Lambda avec un groupe d'origine, spécifiez la fonction dans une requête d'origine ou un déclencheur de réponse de l'origine pour un groupe d'origine lorsque vous créez le comportement de cache.

Pour plus d’informations, consultez les ressources suivantes :
+ **Création d’un groupe d’origines :** [Création d’un groupe d’origine](high_availability_origin_failover.md#concept_origin_groups.creating)
+ **Comment fonctionne le basculement d'origine avec Lambda@Edge:** [Utilisation du basculement d'origine avec les fonctions Lambda@Edge](high_availability_origin_failover.md#concept_origin_groups.lambda)

## Génération de réponses HTTP dans les déclencheurs de demande
<a name="lambda-generating-http-responses-in-requests"></a>

Lorsque CloudFront vous recevez une demande, vous pouvez utiliser une fonction Lambda pour générer une réponse HTTP qui est CloudFront renvoyée directement au visualiseur sans transmettre la réponse à l'origine. La génération de réponses HTTP réduit la charge sur le serveur d'origine, et aussi généralement la latence pour l'utilisateur.

Les scénarios courants pour générer des réponses HTTP sont les suivants :
+ Renvoi d'une petite page web à l'utilisateur
+ Renvoi d'un code de statut HTTP 301 ou 302 pour rediriger l'utilisateur vers une autre page web
+ Renvoi d'un code de statut HTTP 401 lorsque l'utilisateur ne s'est pas authentifié

Une fonction Lambda@Edge peut générer une réponse HTTP lorsque les événements CloudFront suivants se produisent :

**Événements de demande utilisateur**  
Lorsqu'une fonction est déclenchée par un événement de demande du spectateur, CloudFront renvoie la réponse au visualiseur sans la mettre en cache.

**Événements de demande à l'origine**  
Lorsqu'une fonction est déclenchée par un événement de demande d' CloudFront origine, recherche dans le cache périphérique une réponse précédemment générée par la fonction.   
+ Si la réponse se trouve dans le cache, la fonction n'est pas exécutée et CloudFront renvoie la réponse mise en cache au visualiseur.
+ Si la réponse ne se trouve pas dans le cache, la fonction est exécutée et CloudFront retourne la réponse à l'utilisateur et la met dans le cache.

Pour voir un exemple de code permettant de générer des réponses HTTP, consultez [Exemples de fonctions Lambda@Edge](lambda-examples.md). Vous pouvez également remplacer les réponses HTTP dans les déclencheurs de réponse. Pour plus d’informations, consultez [Mise à jour des réponses HTTP dans des déclencheurs de réponse de l’origine](#lambda-updating-http-responses).

### Modèle de programmation
<a name="lambda-generating-http-responses-programming-model"></a>

Cette section décrit le modèle de programmation permettant d'utiliser Lambda@Edge pour générer des réponses HTTP.

**Topics**
+ [Objet Réponse](#lambda-generating-http-responses-object)
+ [Erreurs](#lambda-generating-http-responses-errors)
+ [Champs obligatoires](#lambda-generating-http-responses-required-fields)

#### Objet Réponse
<a name="lambda-generating-http-responses-object"></a>

La réponse que vous renvoyez en tant que paramètre `result` de la méthode `callback` doit avoir la structure suivante (notez que seul le champ `status` est requis).

```
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'
};
```

L'objet de réponse peut inclure les valeurs suivantes :

**`body`**  
Le corps, le cas échéant, que vous CloudFront souhaitez renvoyer dans la réponse générée.

**`bodyEncoding`**  
Encodage de la valeur que vous avez spécifiée dans `body`. Les seuls encodages valides sont `text` et `base64`. Si vous incluez `body` dans l'`response`objet mais que vous l'omettez`bodyEncoding`, CloudFront traite le corps comme du texte.  
Si vous spécifiez `bodyEncoding` comme `base64`, mais que le corps n'est pas un base64 valide, CloudFront renvoie une erreur.

**`headers`**  
En-têtes que vous CloudFront souhaitez renvoyer dans la réponse générée. Notez ce qui suit :  
+ Les clés figurant dans l’objet `headers` sont les versions en minuscules des noms d’en-têtes HTTP standard. L'utilisation des minuscules vous permet d'accéder aux valeurs des en-têtes sans tenir compte de la casse.
+ Chaque en-tête (par exemple, `headers["accept"]` ou `headers["host"]`) est un tableau de paires clé-valeur. Pour un en-tête donné, le tableau contient une paire clé-valeur pour chaque valeur de la réponse générée.
+ `key` (facultatif) est le nom de l'en-tête sensible à la casse tel qu'il s'affiche dans une demande HTTP, par exemple, `accept` ou `host`.
+ Indiquez `value` comme valeur d'en-tête.
+ Si vous n'incluez pas la partie clé d'en-tête de la paire clé-valeur, Lambda@Edge insère automatiquement une clé d'en-tête à l'aide du nom d'en-tête que vous fournissez. Quelle que soit la manière dont vous avez formaté le nom d'en-tête, la clé d'en-tête qui est insérée est formatée automatiquement avec une majuscule initiale pour les différentes parties séparées par des tirets (-).

  Par exemple, vous pouvez ajouter un en-tête comme suit, sans clé d'en-tête : `'content-type': [{ value: 'text/html;charset=UTF-8' }]`

  Dans cet exemple, Lambda@Edge crée la clé d'en-tête suivante : `Content-Type`.
Pour plus d’informations sur les restrictions applicables à l’utilisation d’en-têtes, consultez [Restrictions sur les fonctions périphériques](edge-functions-restrictions.md).

**`status`**  
Le code d'état HTTP . Fournissez le code d'état sous forme de chaîne. CloudFront utilise le code d'état fourni pour les opérations suivantes :  
+ Renvoi dans la réponse
+ Cache dans le cache CloudFront périphérique, lorsque la réponse a été générée par une fonction déclenchée par un événement de demande d'origine
+ Connectez-vous CloudFront [Journaux d'accès (journaux standard)](AccessLogs.md)
Si la valeur `status` n'est pas comprise entre 200 et 599, CloudFront renvoie une erreur à l'utilisateur.

**`statusDescription`**  
Description que vous souhaitez CloudFront renvoyer dans la réponse, pour accompagner le code d'état HTTP. Vous n'avez pas besoin d'utiliser de descriptions standard, telles que `OK` pour un code de statut HTTP 200.

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

Voici des erreurs possibles pour les réponses HTTP générées.

**La réponse contient un corps et un code de statut HTTP 204 (Pas de contenu)**  
Lorsqu'une fonction est déclenchée par une demande d'affichage, CloudFront renvoie un code d'état HTTP 502 (Bad Gateway) au visualiseur lorsque les deux conditions suivantes sont vraies :  
+ La valeur du code `status` est 204 (Pas de contenu)
+ La réponse inclut une valeur pour `body`
Cela vient du fait que Lambda@Edge impose la restriction facultative incluse dans la RFC 2616, qui stipule qu'une réponse `HTTP 204` n'a pas besoin d'inclure de corps de message.

**Restrictions concernant la taille de la réponse générée**  
La taille maximale d'une réponse générée par une fonction Lambda dépend de l'événement qui a déclenché la fonction :  
+ **Événements de demande utilisateur** – 40 Ko
+ **Événements de demande à l'origine ** – 1 Mo
Si la réponse est supérieure à la taille autorisée, CloudFront renvoie un code d'état HTTP 502 (Bad Gateway) au visualiseur.

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

Le champ `status` est obligatoire. 

Tous les autres champs sont facultatifs.

## Mise à jour des réponses HTTP dans des déclencheurs de réponse de l’origine
<a name="lambda-updating-http-responses"></a>

Lorsque CloudFront vous recevez une réponse HTTP du serveur d'origine, si un déclencheur de réponse d'origine est associé au comportement du cache, vous pouvez modifier la réponse HTTP pour remplacer ce qui a été renvoyé par l'origine.

Les scénarios courants pour mettre à jour des réponses HTTP sont les suivants :
+ Modification du statut sur HTTP 200 et création d'un contenu de corps statique à renvoyer à l'utilisateur lorsqu'une origine renvoie un code de statut d'erreur (4xx ou 5xx). Pour un exemple de code, consultez [Exemple : utilisation d’un déclencheur de réponse de l’origine pour mettre à jour le code de statut d’erreur sur 200](lambda-examples.md#lambda-examples-custom-error-static-body).
+ Modification du statut pour définir un code de statut HTTP 301 ou HTTP 302, afin de rediriger l'utilisateur vers un autre site web lorsqu'une origine renvoie un code de statut d'erreur (4xx ou 5xx). Pour un exemple de code, consultez [Exemple : utilisation d’un déclencheur de réponse de l’origine pour mettre à jour le code de statut d’erreur sur 302](lambda-examples.md#lambda-examples-custom-error-new-site).

**Note**  
La fonction doit renvoyer une valeur d'état comprise entre `200` et `599` (inclus), sinon elle CloudFront renvoie une erreur au visualiseur.

Vous pouvez également remplacer les réponses HTTP dans les événements de requête utilisateur et à l'origine. Pour de plus amples informations, veuillez consulter [Génération de réponses HTTP dans les déclencheurs de demande](#lambda-generating-http-responses-in-requests).

Lorsque vous utilisez la réponse HTTP, Lambda@Edge n'expose pas le corps renvoyé par le serveur d'origine au déclencheur de réponse de l'origine. Vous pouvez générer un corps de contenu statique en lui attribuant la valeur souhaitée, ou supprimer le corps à l'intérieur de la fonction en définissant une valeur vide. Si vous n'actualisez pas le champ du corps dans votre fonction, le corps d'origine renvoyé par le serveur d'origine est renvoyé à l'utilisateur.

## Accès au corps de requête en choisissant l’option Inclure le corps
<a name="lambda-include-body-access"></a>

Vous pouvez décider que Lambda@Edge expose le corps dans une demande pour des méthodes HTTP accessibles en écriture (POST, PUT, DELETE, etc.) afin que vous puissiez y accéder dans vos fonctions Lambda. Vous pouvez choisir un accès en lecture seule ou vous pouvez préciser que vous remplacerez le corps.

Pour activer cette option, choisissez **Include Body (Inclure corps)** lorsque vous créez un déclencheur CloudFront pour votre fonction qui correspond à un pour un événement de demande utilisateur ou de demande d'origine. Pour plus d’informations, consultez [Ajout de déclencheurs pour une fonction Lambda@Edge](lambda-edge-add-triggers.md), ou pour en savoir plus sur l’utilisation de **Include Body (Inclure le corps)** avec votre fonction, consultez [Structure d'événement Lambda@Edge](lambda-event-structure.md).

Les scénarios lorsque vous êtes susceptibles de vouloir utiliser cette fonction incluent les éléments suivants :
+ Traitement des formulaires Web, comme « Contactez-nous », sans renvoyer les données saisies par le client aux serveurs d'origine.
+ Collecte des données de balise web envoyées par les navigateurs des utilisateurs et traitement de ces données en périphérie.

Pour un exemple de code, consultez [Exemples de fonctions Lambda@Edge](lambda-examples.md).

**Note**  
Si le corps de la demande est grand, Lambda@Edge le tronque. Pour plus d’informations sur la taille maximale et la troncature, consultez [Restrictions relatives au corps de la requête avec l'option Inclure le corps](lambda-at-edge-function-restrictions.md#lambda-at-edge-restrictions-request-body).

# Exemples de fonctions Lambda@Edge
<a name="lambda-examples"></a>

Consultez les exemples suivants pour utiliser les fonctions Lambda avec Amazon. CloudFront

**Note**  
Si vous choisissez l’environnement d’exécution Node.js 18 ou une version ultérieure pour votre fonction Lambda@Edge, un fichier `index.mjs` est créé automatiquement. Pour utiliser les exemples de code suivants, renommez plutôt le fichier `index.mjs` en `index.js`.

**Topics**
+ [Exemples généraux](#lambda-examples-general-examples)
+ [Génération de réponses : exemples](#lambda-examples-generated-response-examples)
+ [Chaînes de requête - exemples](#lambda-examples-query-string-examples)
+ [Personnalisation de contenu à l'aide des en-têtes Pays ou Type d'appareil – exemples](#lambda-examples-redirecting-examples)
+ [Sélection d'origine dynamique basée sur le contenu – exemples](#lambda-examples-content-based-routing-examples)
+ [Mise à jour des statuts d’erreur : exemples](#lambda-examples-update-error-status-examples)
+ [Accès au corps de requête - exemples](#lambda-examples-access-request-body-examples)

## Exemples généraux
<a name="lambda-examples-general-examples"></a>

Les exemples suivants montrent les méthodes courantes d'utilisation de Lambda @Edge dans. CloudFront

**Topics**
+ [Exemple : A/B test](#lambda-examples-a-b-testing)
+ [Exemple : remplacement d’un en-tête de réponse](#lambda-examples-overriding-response-header)

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

Vous pouvez utiliser l'exemple suivant pour tester deux versions différentes d'une image sans créer de redirections ni modifier l'URL. Cet exemple lit les cookies dans la demande de l'utilisateur et modifie l'URL de la demande en conséquence. Si le spectateur n'envoie pas de cookie avec l'une des valeurs attendues, l'exemple assigne de manière aléatoire le spectateur à l' URLsune des valeurs.

------
#### [ 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
```

------

### Exemple : remplacement d’un en-tête de réponse
<a name="lambda-examples-overriding-response-header"></a>

L'exemple suivant montre comment changer la valeur d'un en-tête de réponse en fonction de la valeur d'un autre en-tête.

------
#### [ 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
```

------

## Génération de réponses : exemples
<a name="lambda-examples-generated-response-examples"></a>

Les exemples suivants illustrent l’utilisation de Lambda@Edge pour générer des réponses.

**Topics**
+ [Exemple : traitement de contenu statique (réponse générée)](#lambda-examples-static-web-server)
+ [Exemple : génération d’une redirection HTTP (réponse générée)](#lambda-examples-http-redirect)

### Exemple : traitement de contenu statique (réponse générée)
<a name="lambda-examples-static-web-server"></a>

L'exemple suivant montre comment utiliser une fonction Lambda pour traiter le contenu statique d'un site web, ce qui réduit la charge sur le serveur d'origine et réduit la latence globale. 

**Note**  
Vous pouvez générer des réponses HTTP pour les événements de requête utilisateur ou de requête à l'origine. Pour de plus amples informations, veuillez consulter [Génération de réponses HTTP dans les déclencheurs de demande](lambda-generating-http-responses.md#lambda-generating-http-responses-in-requests).  
Vous pouvez également remplacer ou supprimer le corps de la réponse HTTP dans les événements de réponse de l’origine. Pour de plus amples informations, veuillez consulter [Mise à jour des réponses HTTP dans des déclencheurs de réponse de l’origine](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
```

------

### Exemple : génération d’une redirection HTTP (réponse générée)
<a name="lambda-examples-http-redirect"></a>

L'exemple suivant montre comment générer une redirection HTTP.

**Note**  
Vous pouvez générer des réponses HTTP pour les événements de requête utilisateur ou de requête à l'origine. Pour de plus amples informations, veuillez consulter [Génération de réponses HTTP dans les déclencheurs de demande](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
```

------

## Chaînes de requête - exemples
<a name="lambda-examples-query-string-examples"></a>

Les exemples suivants montrent comment utiliser Lambda@Edge avec des chaînes de requête.

**Topics**
+ [Exemple : ajout d’un en-tête basé sur un paramètre de chaîne de requête](#lambda-examples-header-based-on-query-string)
+ [Exemple : normalisation des paramètres de chaîne de requête pour améliorer le taux d’accès au cache](#lambda-examples-normalize-query-string-parameters)
+ [Exemple : redirection des utilisateurs non authentifiés vers une page de connexion](#lambda-examples-redirect-to-signin-page)

### Exemple : ajout d’un en-tête basé sur un paramètre de chaîne de requête
<a name="lambda-examples-header-based-on-query-string"></a>

L'exemple suivant montre comment obtenir la paire clé-valeur d'un paramètre de chaîne de requête, puis ajouter un en-tête en fonction de ces valeurs.

------
#### [ 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
```

------

### Exemple : normalisation des paramètres de chaîne de requête pour améliorer le taux d’accès au cache
<a name="lambda-examples-normalize-query-string-parameters"></a>

L'exemple suivant montre comment améliorer le taux de réussite de votre cache en apportant les modifications suivantes aux chaînes de requête avant de CloudFront transférer les demandes à votre origine :
+ Classez par ordre alphabétique les paires clé-valeur selon le nom du paramètre.
+ Modifiez la casse des paires clé-valeur en minuscules.

Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur les paramètres de chaîne de requête](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
```

------

### Exemple : redirection des utilisateurs non authentifiés vers une page de connexion
<a name="lambda-examples-redirect-to-signin-page"></a>

L'exemple suivant montre comment rediriger des utilisateurs vers une page de connexion s'ils n'ont pas saisi leurs informations d'identification.

------
#### [ 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
```

------

## Personnalisation de contenu à l'aide des en-têtes Pays ou Type d'appareil – exemples
<a name="lambda-examples-redirecting-examples"></a>

Les exemples suivants illustrent une méthode d’utilisation de Lambda@Edge pour personnaliser le comportement en fonction de l’emplacement ou du type d’appareil utilisé par l’utilisateur.

**Topics**
+ [Exemple : redirection de demandes utilisateur vers une URL spécifique à un pays](#lambda-examples-redirect-based-on-country)
+ [Exemple : gestion de différentes versions d’un objet en fonction de l’appareil](#lambda-examples-vary-on-device-type)

### Exemple : redirection de demandes utilisateur vers une URL spécifique à un pays
<a name="lambda-examples-redirect-based-on-country"></a>

L'exemple suivant montre comment générer une réponse de redirection HTTP avec une URL propre à un pays et renvoyer la réponse à l'utilisateur. Ceci s'avère utile lorsque vous souhaitez fournir des réponses propres à un pays. Exemples :
+ Si vous avez des sous-domaines propres à un pays, comme us.example.com et tw.example.com, vous pouvez générer une réponse de redirection lorsqu'un utilisateur demande example.com.
+ Si vous diffusez une vidéo, mais que vous ne disposez pas de droits pour diffuser le contenu dans un pays spécifique, vous pouvez rediriger les utilisateurs de ce pays vers une page qui explique pourquoi ils ne peuvent regarder la vidéo. 

Remarques :
+ Vous devez configurer votre distribution pour être mise en cache en fonction de l'en-tête `CloudFront-Viewer-Country`. Pour de plus amples informations, veuillez consulter [Mise en cache basée sur des en-têtes de demande sélectionnés](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).
+ CloudFront ajoute l'`CloudFront-Viewer-Country`en-tête après l'événement de demande du spectateur. Pour utiliser cet exemple, vous devez créer un déclencheur pour l’événement de demande à l’origine.

------
#### [ 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
```

------

### Exemple : gestion de différentes versions d’un objet en fonction de l’appareil
<a name="lambda-examples-vary-on-device-type"></a>

L'exemple suivant montre comment servir différentes versions d'un objet en fonction du type d'appareil employé par l'utilisateur, par exemple, un appareil mobile ou une tablette. Remarques :
+ Vous devez configurer votre distribution pour être mise en cache en fonction des en-têtes `CloudFront-Is-*-Viewer`. Pour de plus amples informations, veuillez consulter [Mise en cache basée sur des en-têtes de demande sélectionnés](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders).
+ CloudFront ajoute les `CloudFront-Is-*-Viewer` en-têtes après l'événement de demande du spectateur. Pour utiliser cet exemple, vous devez créer un déclencheur pour l’événement de demande à l’origine.

------
#### [ 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
```

------

## Sélection d'origine dynamique basée sur le contenu – exemples
<a name="lambda-examples-content-based-routing-examples"></a>

Les exemples suivants illustrent une méthode d’utilisation de Lambda@Edge pour acheminer vers différentes origines en fonction des informations contenues dans la demande.

**Topics**
+ [Exemple : utilisation d’un déclencheur de demande à l’origine pour passer d’une origine personnalisée à une origine Amazon S3](#lambda-examples-content-based-S3-origin-based-on-query)
+ [Exemple : utilisation d’un déclencheur de demande à l’origine pour modifier la région de l’origine Amazon S3](#lambda-examples-content-based-S3-origin-request-trigger)
+ [Exemple : utilisation d’un déclencheur de demande à l’origine pour passer d’une origine Amazon S3 à une origine personnalisée](#lambda-examples-content-based-custom-origin-request-trigger)
+ [Exemple : utilisation d’un déclencheur de demande à l’origine pour transférer progressivement le trafic d’un compartiment Amazon S3 à un autre](#lambda-examples-content-based-gradual-traffic-transfer)
+ [Exemple : utilisation d’un déclencheur de demande à l’origine pour modifier le nom de domaine de l’origine en fonction de l’en-tête du pays](#lambda-examples-content-based-geo-header)

### Exemple : utilisation d’un déclencheur de demande à l’origine pour passer d’une origine personnalisée à une origine Amazon S3
<a name="lambda-examples-content-based-S3-origin-based-on-query"></a>

Cette fonction explique comment un déclencheur de demande à l'origine peut être utilisé pour passer d'une origine personnalisée à une origine Amazon S3 à partir de laquelle le contenu est récupéré en fonction des propriétés de la demande.

------
#### [ 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
```

------

### Exemple : utilisation d’un déclencheur de demande à l’origine pour modifier la région de l’origine Amazon S3
<a name="lambda-examples-content-based-S3-origin-request-trigger"></a>

Cette fonction explique comment un déclencheur de demande à l'origine peut être utilisé pour modifier l'origine Amazon S3 à partir de laquelle le contenu est récupéré en fonction des propriétés de la demande.

Dans cet exemple, nous utilisons la valeur de l'en-tête `CloudFront-Viewer-Country` pour mettre à jour le nom de domaine de compartiment S3 en spécifiant un compartiment dans une région plus proche de l'utilisateur. Cela peut être utile à plusieurs égards :
+ Cela réduit la latence lorsque la région spécifiée est plus proche du pays de l'utilisateur.
+ Il est possible de contrôler les données en s'assurant qu'elles sont distribuées depuis une origine qui se trouve dans le pays de provenance de la demande.

Pour utiliser cet exemple, vous devez procéder comme suit :
+ Vous devez configurer votre distribution à mettre en cache en fonction de l'en-tête `CloudFront-Viewer-Country`. Pour de plus amples informations, veuillez consulter [Mise en cache basée sur des en-têtes de demande sélectionnés](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardHeaders). 
+ Créez un déclencheur pour cette fonction dans l'événement de demande d'origine. CloudFrontajoute l'`CloudFront-Viewer-Country`en-tête après l'événement de demande du visualiseur. Pour utiliser cet exemple, vous devez vous assurer que la fonction s'exécute pour une demande d'origine.

**Note**  
L’exemple de code suivant utilise la même identité d’accès d’origine (OAI) pour tous les compartiments S3 que vous utilisez comme origine. Pour plus d’informations, consultez [Identité d’accès d’origine](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
```

------

### Exemple : utilisation d’un déclencheur de demande à l’origine pour passer d’une origine Amazon S3 à une origine personnalisée
<a name="lambda-examples-content-based-custom-origin-request-trigger"></a>

Cette fonction explique comment un déclencheur de demande à l'origine peut être utilisé pour modifier l'origine personnalisée à partir de laquelle le contenu est récupéré, en fonction des propriétés de la demande.

------
#### [ 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
```

------

### Exemple : utilisation d’un déclencheur de demande à l’origine pour transférer progressivement le trafic d’un compartiment Amazon S3 à un autre
<a name="lambda-examples-content-based-gradual-traffic-transfer"></a>

Cette fonction explique comment vous pouvez transférer progressivement le trafic d’un compartiment Amazon S3 à un autre de manière contrôlée.

------
#### [ 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
```

------

### Exemple : utilisation d’un déclencheur de demande à l’origine pour modifier le nom de domaine de l’origine en fonction de l’en-tête du pays
<a name="lambda-examples-content-based-geo-header"></a>

Cette fonction explique comment vous pouvez modifier le nom de domaine de l'origine en fonction de l'en-tête `CloudFront-Viewer-Country` afin que le contenu soit transmis depuis une origine plus proche du pays de l'utilisateur.

La mise en œuvre de cette fonctionnalité pour votre distribution peut avoir les avantages suivants :
+ Réduction de la latence lorsque la région spécifiée est plus proche du pays de l'utilisateur
+ Assurance de la souveraineté des données en veillant à ce que les données soient distribuées depuis une origine qui se trouve dans le pays d'où vient la demande

Notez que pour activer cette fonctionnalité, vous devez configurer votre distribution pour qu'elle soit mise en cache en fonction de l'en-tête `CloudFront-Viewer-Country`. Pour de plus amples informations, veuillez consulter [Mise en cache basée sur des en-têtes de demande sélectionnés](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
```

------

## Mise à jour des statuts d’erreur : exemples
<a name="lambda-examples-update-error-status-examples"></a>

Les exemples suivants fournissent des conseils sur l’utilisation de Lambda@Edge pour modifier le statut d’erreur qui est renvoyé aux utilisateurs.

**Topics**
+ [Exemple : utilisation d’un déclencheur de réponse de l’origine pour mettre à jour le code de statut d’erreur sur 200](#lambda-examples-custom-error-static-body)
+ [Exemple : utilisation d’un déclencheur de réponse de l’origine pour mettre à jour le code de statut d’erreur sur 302](#lambda-examples-custom-error-new-site)

### Exemple : utilisation d’un déclencheur de réponse de l’origine pour mettre à jour le code de statut d’erreur sur 200
<a name="lambda-examples-custom-error-static-body"></a>

Cette fonction explique comment vous pouvez mettre à jour le statut de la réponse sur 200 et générer un contenu de corps statique à renvoyer à l'utilisateur dans le scénario suivant :
+ La fonction est déclenchée dans une réponse de l'origine.
+ Le statut de la réponse du serveur d’origine est un code de statut d’erreur (4xx ou 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
```

------

### Exemple : utilisation d’un déclencheur de réponse de l’origine pour mettre à jour le code de statut d’erreur sur 302
<a name="lambda-examples-custom-error-new-site"></a>

Cette fonction explique comment vous pouvez mettre à jour le code de statut HTTP sur 302 pour rediriger le trafic vers un autre chemin (comportement de cache) qui possède une autre origine configurée. Remarques :
+ La fonction est déclenchée dans une réponse de l'origine.
+ Le statut de la réponse du serveur d’origine est un code de statut d’erreur (4xx ou 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
```

------

## Accès au corps de requête - exemples
<a name="lambda-examples-access-request-body-examples"></a>

Les exemples suivants illustrent l’utilisation de Lambda@Edge pour utiliser des demandes POST.

**Note**  
Pour utiliser ces exemples, vous devez activer l'option *Inclure le corps* dans l'association de fonction Lambda de la distribution. Elle n'est pas activée par défaut.  
Pour activer ce paramètre dans la CloudFront console, cochez la case **Inclure le corps** dans l'association de **fonctions Lambda**.
Pour activer ce paramètre dans l' CloudFront API ou avec CloudFormation, définissez le `IncludeBody` champ sur `true` in`LambdaFunctionAssociation`.

**Topics**
+ [Exemple : utilisation d’un déclencheur de demande pour lire un formulaire HTML](#lambda-examples-access-request-body-examples-read)
+ [Exemple : utilisation d’un déclencheur de demande pour modifier un formulaire HTML](#lambda-examples-access-request-body-examples-replace)

### Exemple : utilisation d’un déclencheur de demande pour lire un formulaire HTML
<a name="lambda-examples-access-request-body-examples-read"></a>

Cette fonction montre comment vous pouvez traiter le corps d'une requête POST générée par un formulaire HTML (formulaire web), tel que « Contactez-nous ». Par exemple, vous pouvez avoir un formulaire HTML comme le suivant :

```
<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>
```

Pour l'exemple de fonction qui suit, la fonction doit être déclenchée dans une requête d'utilisateur CloudFront ou une requête d'origine.

------
#### [ 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
```

------

### Exemple : utilisation d’un déclencheur de demande pour modifier un formulaire HTML
<a name="lambda-examples-access-request-body-examples-replace"></a>

Cette fonction montre comment vous pouvez modifier le corps d'une requête POST générée par un formulaire HTML (formulaire web). La fonction est déclenchée dans une demande de CloudFront visualisation ou une demande d'origine.

------
#### [ 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)
```

------