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.
# Invocation d’une fonction Lambda de manière asynchrone
Plusieurs services Services AWS, tels qu’Amazon Simple Storage Service (Amazon S3) et Amazon Simple Notification Service (Amazon SNS), invoquent des fonctions de manière asynchrone pour traiter les événements. Vous pouvez également invoquer une fonction Lambda de manière asynchrone à l’aide d’AWS Command Line Interface (AWS CLI) ou de l’un des kits SDK AWS. Lorsque vous invoquez une fonction de manière asynchrone, vous n’attendez pas de réponse de la part du code de la fonction. Vous remettez l’événement à Lambda qui se charge du reste. Vous pouvez configurer la façon dont Lambda gère les erreurs, et vous pouvez envoyer des enregistrements d’invocation à une ressource en aval telle qu’Amazon Simple Queue Service (Amazon SQS) ou Amazon EventBridge (EventBridge) pour enchaîner les composants de votre application.
Le diagramme suivant montre des clients invoquant une fonction Lambda de manière asynchrone. Lambda place les événements en file d’attente avant de les envoyer à la fonction.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/features-async.png)
Pour une invocation asynchrone, Lambda place l’événement dans une file d’attente et renvoie une réponse de succès sans plus informations. Un processus distinct lit les événements à partir de la file d’attente et les envoie à votre fonction.
Pour invoquer une fonction Lambda de manière asynchrone à l’aide de l’AWS Command Line Interface (AWS CLI) ou de l’un des kits SDK AWS, définissez le paramètre [InvocationType](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-InvocationType) sur `Event`. L’exemple suivant montre une commande AWS CLI permettant d’invoquer une fonction.
```
aws lambda invoke \
--function-name my-function \
--invocation-type Event \
--cli-binary-format raw-in-base64-out \
--payload '{ "key": "value" }' response.json
```
Vous devriez voir la sortie suivante :
```
{
"StatusCode": 202
}
```
L’option **cli-binary-format** est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Le fichier de sortie (`response.json`) ne contient pas d’informations, mais il est tout de même créé lorsque vous exécutez cette commande. Si Lambda n’est pas en mesure d’ajouter l’événement à la file d’attente, un message d’erreur s’affiche dans la sortie de la commande.
# Méthode de gestion des erreurs et nouvelles tentatives d’invocation asynchrone par Lambda
Lambda gère la file d’attente d’événements asynchrones de votre fonction, et effectue de nouvelles tentatives en cas d’erreur. Si la fonction renvoie une erreur, Lambda tente par défaut de l’exécuter deux fois de plus, avec une minute d’attente entre les deux premières tentatives, et deux minutes entre la deuxième et la troisième tentative. Les erreurs de fonction comprennent des erreurs renvoyées par le code de la fonction et des erreurs renvoyées par l’environnement d’exécution de la fonction, comme les délais d’expiration.
Si la fonction n’a pas suffisamment de simultanéité disponible pour traiter tous les événements, des demandes supplémentaires sont bloquées. Pour les erreurs de limitation (429) et les erreurs système (série 500), Lambda renvoie l’événement dans la file d’attente et tente d’exécuter à nouveau la fonction pendant une période pouvant aller jusqu’à 6 heures par défaut. L’intervalle de nouvelle tentative augmente de manière exponentielle de 1 seconde après la première tentative jusqu’à un maximum de 5 minutes. Si la file d’attente contient de nombreuses entrées, Lambda augmente l’intervalle entre les tentatives et réduit la fréquence des événements de lecture à partir de la file d’attente.
Même si votre fonction ne renvoie pas d’erreur, elle peut recevoir plusieurs fois le même événement de Lambda, car la file d’attente elle-même est cohérente à terme. Si la fonction ne peut pas à prendre en charge les événements entrants, ils peuvent également être supprimés de la file d’attente sans être envoyés à la fonction. Assurez-vous que le code de votre fonction gère correctement les événements dupliqués et que vous avez suffisamment de simultanéité disponible pour gérer toutes les invocations.
Lorsque la file d’attente est très longue, il peut arriver que de nouveaux événements expirent avant que Lambda ait la possibilité de les envoyer à votre fonction. Quand un événement expire ou échoue à toutes les tentatives de traitement, Lambda le supprime. Vous pouvez [configurer la gestion des erreurs](invocation-async-configuring.md) pour une fonction de façon à réduire le nombre de nouvelles tentatives que Lambda effectue, ou à supprimer les événements non traités plus rapidement. Pour capturer les événements supprimés, [configurez une file d’attente de lettres mortes](invocation-async-retain-records.md#invocation-dlq) pour la fonction. Pour capturer les enregistrements des invocations ayant échoué (comme les expirations de délai d’expiration ou les erreurs d’environnement d’exécution), [créez une destination en cas d’échec](invocation-async-retain-records.md#invocation-async-destinations).
# Configuration de la gestion des erreurs pour les invocations asynchrones Lambda
Utilisez les paramètres suivants pour configurer la façon dont Lambda gère les erreurs et les nouvelles tentatives pour les invocations de fonctions asynchrones :
+ [MaximumEventAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html#lambda-PutFunctionEventInvokeConfig-request-MaximumEventAgeInSeconds) : la durée maximale, en secondes, pendant laquelle Lambda conserve un événement dans la file d’attente des événements asynchrones avant de le supprime.
+ [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html#lambda-PutFunctionEventInvokeConfig-request-MaximumRetryAttempts) : le nombre maximum de nouvelles tentatives que Lambda effectue quand la fonction renvoie une erreur.
Utilisez la console Lambda ou l’AWS CLI pour configurer les paramètres de gestion des erreurs sur une fonction, une version ou un alias.
------
#### [ Console ]
**Pour configurer la gestion des erreurs**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez **Configuration**, puis **Asynchronous invocation (Invocation asynchrone)**.
1. Sous **Asynchronous invocation (Invocation asynchrone)**, choisissez **Edit (Modifier)**.
1. Configurez les paramètres suivants.
+ **Maximum age of event** (Âge maximal de l’événement) – Durée maximale, jusqu’à 6 heures, pendant laquelle Lambda conserve un événement dans la file d’attente d’événements asynchrones.
+ **Retry attempts (Nouvelles tentatives)** – Nombre de nouvelles tentatives, entre 0 et 2, que Lambda effectue lorsque la fonction renvoie une erreur.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
Pour configurer l’invocation asynchrone avec l’AWS CLI, utilisez la commande [put-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-function-event-invoke-config.html). L’exemple suivant montre comment configurer une fonction avec un âge d’événement maximal de 1 heure et aucune nouvelle tentative.
```
aws lambda put-function-event-invoke-config \
--function-name error \
--maximum-event-age-in-seconds 3600 \
--maximum-retry-attempts 0
```
La commande `put-function-event-invoke-config` remplace toute configuration existante sur la fonction, la version ou l’alias. Pour configurer une option sans en réinitialiser d’autres, utilisez [update-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-event-invoke-config.html). L’exemple suivant illustre la configuration de Lambda pour l’envoie d’un enregistrement à une file d’attente SQS standard nommée `destination` lorsqu’un événement ne peut pas être traité.
```
aws lambda update-function-event-invoke-config \
--function-name my-function \
--destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-1:123456789012:destination"}}'
```
------
Vous devriez voir la sortie suivante :
```
{
"LastModified": 1573686021.479,
"FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
"MaximumRetryAttempts": 0,
"MaximumEventAgeInSeconds": 3600,
"DestinationConfig": {
"OnSuccess": {},
"OnFailure": {}
}
}
```
Quand un événement d’invocation dépasse l’âge maximum ou échoue à toutes les tentatives, Lambda le supprime. Pour conserver une copie des événements supprimés, configurez une [destination](invocation-async-retain-records.md#invocation-async-destinations) pour les événements ayant échoué.
# Capture des enregistrements d’invocations asynchrones Lambda
Lambda peut envoyer des enregistrements d'appels asynchrones à l'une des entités suivantes. Services AWS
+ **Amazon SQS** : une file d’attente SQS standard
+ **Amazon SNS** : une rubrique SNS standard
+ **Amazon S3** : un compartiment Amazon S3 (uniquement en cas d’échec)
+ **AWS Lambda** : une fonction Lambda
+ **Amazon EventBridge** — Un bus EventBridge événementiel
L’enregistrement d’invocation contient des détails sur la demande et la réponse au format JSON. Vous pouvez configurer des destinations distinctes pour les événements qui ont été traités avec succès et ceux dont le traitement a échoué. Vous pouvez également configurer une file d’attente Amazon SQS ou une rubrique Amazon SNS standard en tant que file d’attente de lettres mortes pour les événements abandonnés. Pour les files d’attente de lettres mortes, Lambda envoie uniquement le contenu de l’événement, sans plus d’informations sur la réponse.
Si Lambda ne parvient pas à envoyer un enregistrement vers une destination que vous avez configurée, il envoie une `DestinationDeliveryFailures` métrique à Amazon. CloudWatch Cela peut se produire si votre configuration inclut un type de destination non pris en charge, tel qu’une file d’attente FIFO Amazon SQS ou une rubrique FIFO Amazon SNS. Des erreurs de remise peuvent également se produire en raison d’erreurs d’autorisations et de limites de taille. Pour plus d’informations sur les métriques d’invocation Lambda, consultez [Métriques d'invocation](monitoring-metrics-types.md#invocation-metrics).
**Note**
Pour empêcher une fonction de se déclencher, vous pouvez définir la simultanéité réservée de la fonction sur zéro. Lorsque vous définissez la simultanéité réservée sur zéro pour une fonction invoquée de manière asynchrone, Lambda commence à envoyer les nouveaux événements à la [file d’attente de lettres mortes](#invocation-dlq) ou à la [destination d’événement](#invocation-async-destinations) en situation d’échec, sans aucune nouvelle tentative. Pour traiter les événements qui ont été envoyés alors que la simultanéité réservée était définie sur zéro, vous devez consommer les événements de la file d’attente de lettres mortes ou de la destination des événements en situation d’échec.
## Ajout d’une destination
Pour retenir les enregistrements des invocations asynchrones, ajoutez une destination à votre fonction. Vous pouvez choisir d’envoyer les invocations réussies ou non à une destination. Chaque fonction peut avoir plusieurs destinations. Vous pouvez donc configurer des destinations distinctes pour les événements réussis et échoués. Chaque enregistrement envoyé à la destination est un document JSON avec des détails sur l’invocation. Comme les paramètres de gestion des erreurs, vous pouvez configurer des destinations au niveau d’une fonction, d’une version de fonction ou d’un alias.
**Astuce**
Vous pouvez également conserver les enregistrements des appels ayant échoué pour les types de mappage de sources d'événements suivants : [Amazon Kinesis, Amazon](kinesis-on-failure-destination.md#kinesis-on-failure-destination-console) [DynamoDB et Apache Kafka (Amazon](services-dynamodb-errors.md) MSK [et Apache Kafka autogéré)](kafka-on-failure.md#kafka-onfailure-destination).
Le tableau suivant répertorie les destinations prises en charge pour les enregistrements d’invocation asynchrones. Pour que Lambda envoie correctement les enregistrements vers la destination que vous avez choisie, assurez-vous que le [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction contient également les autorisations appropriées. Le tableau décrit également comment chaque type de destination reçoit l’enregistrement d’invocation JSON.
| Type de destination | Autorisation obligatoire | Format JSON spécifique à la destination |
| --- | --- | --- |
| File d’attente Amazon SQS | [sqs : SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) | Lambda transmet l’enregistrement d’invocation en tant que `Message` à la destination. |
| Rubrique Amazon SNS | [sns:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html) | Lambda transmet l’enregistrement d’invocation en tant que `Message` à la destination. |
| Compartiment Amazon S3 (uniquement en cas d’échec) | [s3 : PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) [s3 : ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/invocation-async-retain-records.html) |
| Fonction Lambda | [lambda : InvokeFunction](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) | Lambda transmet l’enregistrement d’invocation comme charge utile à la fonction. |
| EventBridge | [événements : PutEvents](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/invocation-async-retain-records.html) |
**Note**
Pour les destinations Amazon S3, si vous avez activé le chiffrement sur le compartiment à l'aide d'une clé KMS, votre fonction a également besoin de l'GenerateDataKeyautorisation [kms :](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html).
**Important**
Lorsque vous utilisez Amazon SNS comme destination, sachez que la taille maximale des messages d’Amazon SNS est limitée à 256 Ko. Si vos données utiles d’invocation asynchrone approchent 1 Mo, l’enregistrement d’invocation (qui inclut les données utiles d’origine ainsi que des métadonnées supplémentaires) peut dépasser la limite d’Amazon SNS et entraîner des échecs de livraison. Envisagez d’utiliser des destinations Amazon SQS ou Amazon S3 pour des données utiles plus importantes.
Les étapes suivantes expliquent comment configurer une destination pour une fonction à l’aide de la console Lambda et de l’ AWS CLI.
------
#### [ Console ]
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add destination (Ajouter une destination)**.
1. Pour **Source**, choisissez **Asynchronous invocation (Invocation asynchrone)**.
1. Pour **Condition** choisissez l’une des options suivantes :
+ **On failure (En cas d’échec)** – Envoyer un enregistrement quand l’événement échoue à toutes les tentatives de traitement ou dépasse l’âge maximal.
+ **On success (En cas de succès)** – Envoyer un enregistrement quand la fonction traite avec succès une invocation asynchrone.
1. Pour **Type de destination**, choisissez le type de ressource qui reçoit l’enregistrement d’invocation.
1. Pour **Destination**, choisissez une ressource.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
Pour configurer une destination à l'aide de AWS CLI, exécutez la commande [update-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-event-invoke-config.html). L’exemple suivant illustre la configuration de Lambda pour l’envoie d’un enregistrement à une file d’attente SQS standard nommée `destination` lorsqu’un événement ne peut pas être traité.
```
aws lambda update-function-event-invoke-config \
--function-name my-function \
--destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-1:123456789012:destination"}}'
```
------
### Pratiques exemplaires en matière de sécurité pour les destinations Amazon S3
La suppression d’un compartiment S3 configuré comme destination sans supprimer la destination de la configuration de votre fonction peut engendrer un risque de sécurité. Si un autre utilisateur connaît le nom de votre compartiment de destination, il peut recréer le compartiment dans son Compte AWS. Les enregistrements des invocations ayant échoué seront envoyés dans son compartiment, exposant potentiellement les données de votre fonction.
**Avertissement**
Pour vous assurer que les enregistrements d'invocation de votre fonction ne peuvent pas être envoyés vers un compartiment S3 d'un autre Compte AWS, ajoutez une condition au rôle d'exécution de votre fonction qui limite `s3:PutObject` les autorisations aux compartiments de votre compte.
L’exemple suivant présente une politique IAM qui limite les autorisations `s3:PutObject` de votre fonction aux seuls compartiments de votre compte. Cette politique donne également à Lambda l’autorisation `s3:ListBucket` dont il a besoin pour utiliser un compartiment S3 comme destination.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3BucketResourceAccountWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*/*",
"arn:aws:s3:::*"
],
"Condition": {
"StringEquals": {
"s3:ResourceAccount": "111122223333"
}
}
}
]
}
```
Pour ajouter une politique d'autorisations au rôle d'exécution de votre fonction à l'aide du AWS Management Console ou AWS CLI, reportez-vous aux instructions des procédures suivantes :
------
#### [ Console ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction Lambda dont vous voulez modifier le rôle d’exécution.
1. Sous l’onglet **Configuration**, sélectionnez **Autorisations**.
1. Sous l’onglet **Rôle d’exécution**, sélectionnez le **Nom du rôle** de votre fonction pour ouvrir la page de console IAM du rôle.
1. Ajoutez une politique d’autorisations de au rôle en procédant comme suit :
1. Dans le volet **Politiques d’autorisations**, choisissez **Ajouter des autorisations**, puis **Créer une politique en ligne**.
1. Dans l’**Éditeur de politique**, sélectionnez **JSON**.
1. Collez la politique que vous souhaitez ajouter dans l’éditeur (en remplacement du JSON existant), puis choisissez **Suivant**.
1. Sous **Détails de la politique**, saisissez un **Nom de la politique**.
1. Choisissez **Create Policy** (Créer une politique).
------
#### [ AWS CLI ]
**Pour ajouter une politique d’autorisations au rôle d’exécution d’une fonction (CLI)**
1. Créez un document de politique JSON avec les autorisations requises et enregistrez-le dans un répertoire local.
1. Utilisez la commande `put-role-policy` de la CLI IAM pour ajouter des autorisations au rôle d’exécution de votre fonction. Exécutez la commande suivante depuis le répertoire dans lequel vous avez enregistré votre document de politique JSON et remplacez le nom du rôle, le nom de la politique et le document de politique par vos propres valeurs.
```
aws iam put-role-policy \
--role-name my_lambda_role \
--policy-name LambdaS3DestinationPolicy \
--policy-document file://my_policy.json
```
------
### Exemple d’enregistrement d’invocation
Quand une invocation correspond à la condition, Lambda envoie à la destination [un document JSON](#destinations-permissions) avec des détails sur l’invocation. L'exemple suivant illustre un enregistrement d’invocation pour un événement dont le traitement a échoué à trois reprises en raison d'une erreur de fonction.
**Example**
```
{
"version": "1.0",
"timestamp": "2019-11-14T18:16:05.568Z",
"requestContext": {
"requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e",
"functionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST",
"condition": "RetriesExhausted",
"approximateInvokeCount": 3
},
"requestPayload": {
"ORDER_IDS": [
"9e07af03-ce31-4ff3-xmpl-36dce652cb4f",
"637de236-e7b2-464e-xmpl-baf57f86bb53",
"a81ddca6-2c35-45c7-xmpl-c3a03a31ed15"
]
},
"responseContext": {
"statusCode": 200,
"executedVersion": "$LATEST",
"functionError": "Unhandled"
},
"responsePayload": {
"errorMessage": "RequestId: e4b46cbf-b738-xmpl-8880-a18cdf61200e Process exited before completing request"
}
}
```
L’enregistrement d’invocation contient des détails sur l’événement, la réponse et la raison pour laquelle l’enregistrement a été envoyé.
### Suivi des demandes vers les destinations
Vous pouvez utiliser AWS X-Ray pour visualiser une vue connectée de chaque demande lorsqu’elle est placée en file d’attente, traitée par une fonction Lambda et transmise au service de destination. Lorsque vous activez le suivi X-Ray pour une fonction ou un service qui invoque une fonction, Lambda ajoute un en-tête X-Ray à la demande et transmet l’en-tête au service de destination. Les traces des services en amont sont automatiquement liées aux traces des fonctions Lambda en aval et des services de destination, créant ainsi une end-to-end vue de l'ensemble de l'application. Pour plus d’informations sur le suivi, consultez [Visualisez les invocations de fonctions Lambda à l'aide de AWS X-Ray](services-xray.md).
## Ajout d’une file d’attente de lettres mortes
Comme alternative à une [destination réservée aux échecs](#invocation-async-destinations), vous pouvez configurer votre fonction avec une file d’attente de lettres mortes pour enregistrer les événements ignorés en vue d’un traitement ultérieur. Une file d’attente de lettres mortes agit de la même manière qu’une destination réservée aux échecs en ce sens qu’elle est utilisée lorsqu’un événement échoue à toutes les tentatives de traitement ou expire sans être traité. Toutefois, vous ne pouvez ajouter ou supprimer une file d’attente de lettres mortes qu’au niveau de la fonction. Les versions de fonctions utilisent les mêmes paramètres de file d’attente de lettres mortes que la version non publiée (\$1LATEST). Les destinations réservées aux échecs prennent également en charge des cibles supplémentaires et incluent des détails sur la réponse de la fonction dans l’enregistrement d’invocation.
Pour retraiter les événements d’une file d’attente de lettres mortes, vous pouvez la définir comme [source d’événements](invocation-eventsourcemapping.md) pour votre fonction Lambda. Vous pouvez également récupérer manuellement les événements.
Vous pouvez choisir une file d’attente Amazon SQS standard ou une rubrique Amazon SNS standanrd pour votre file d’attente de lettres mortes. Les files d’attente FIFO et les rubriques FIFO Amazon SNS ne sont pas prises en charge.
+ [File d’attente Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-create-queue.html) – Une file d’attente conserve les événements qui ont échoué jusqu’à ce qu’ils soient récupérés. Choisissez une file d'attente standard Amazon SQS si vous vous attendez à ce qu'une seule entité, telle qu'une fonction Lambda ou une CloudWatch alarme, traite l'événement défaillant. Pour de plus amples informations, veuillez consulter [Utilisation de Lambda avec Amazon SQS](with-sqs.md).
+ [Rubrique Amazon SNS](https://docs.aws.amazon.com/sns/latest/gsg/CreateTopic.html) – Une rubrique relaie les événements qui ont échoué vers une ou plusieurs destinations. Choisissez une rubrique Amazon SNS standard si vous voulez que plusieurs entités agissent sur un événement ayant échoué. Par exemple, vous pouvez configurer une rubrique pour envoyer des événements à une adresse e-mail, à une fonction Lambda ou à un point de and/or terminaison HTTP. Pour de plus amples informations, veuillez consulter [Invocation des fonctions Lambda à l’aide des notifications Amazon SNS](with-sns.md).
Pour envoyer des événements à une file d’attente ou une rubrique, votre fonction a besoin d’autorisations supplémentaires. Ajoutez une stratégie avec les [autorisations requises](#destinations-permissions) au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Si la file d'attente ou le sujet cible est chiffré à l'aide d'une AWS KMS clé gérée par le client, assurez-vous que le rôle d'exécution de votre fonction et la [politique basée sur les ressources](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) de la clé contiennent les autorisations appropriées.
Après avoir créé la cible et mis à jour votre rôle d’exécution de la fonction, ajoutez la file d’attente de lettres mortes à votre fonction. Vous pouvez configurer plusieurs fonctions pour envoyer des événements à la même cible.
------
#### [ Console ]
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez **Configuration**, puis **Asynchronous invocation (Invocation asynchrone)**.
1. Sous **Asynchronous invocation (Invocation asynchrone)**, choisissez **Edit (Modifier)**.
1. Définissez le **service de file d’attente des lettres mortes** sur **Amazon SQS** ou sur **Amazon SNS**.
1. Choisissez la file d’attente ou la rubrique cible.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
Pour configurer une file d'attente contenant des lettres mortes avec le AWS CLI, utilisez la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande.
```
aws lambda update-function-configuration \
--function-name my-function \
--dead-letter-config TargetArn=arn:aws:sns:us-east-1:123456789012:my-topic
```
------
Lambda envoie l’événement à la file d’attente de lettres mortes en l’état, avec des informations supplémentaires dans les attributs. Vous pouvez utiliser ces informations pour identifier l’erreur que la fonction a renvoyée ou établir une corrélation entre l’événement et des journaux ou une trace AWS X-Ray .
**Attributs de message de file d’attente de lettres mortes**
+ **RequestID** (Chaîne) – ID de la demande d’invocation. IDsLes demandes apparaissent dans les journaux des fonctions. Vous pouvez également utiliser le kit SDK X-Ray pour enregistrer l’ID de demande sur un attribut dans le suivi. Vous pouvez ensuite rechercher des suivis par ID de demande dans la console X-Ray.
+ **ErrorCode**(Numéro) — Le code d'état HTTP.
+ **ErrorMessage**(String) — Les 1 premiers Ko du message d'erreur.
Si Lambda ne parvient pas à envoyer de message à la file d'attente contenant des lettres mortes, il supprime l'événement et émet la métrique. [DeadLetterErrors](monitoring-metrics-types.md) Cela peut se produire en raison d’un manque d’autorisations ou si la taille totale du message est supérieure à la limite de la file d’attente cible ou rubrique. Supposons, par exemple, qu’une notification Amazon SNS dont le corps est proche de 1 Mo déclenche une fonction qui génère une erreur. Dans ce cas, le message peut dépasser la taille maximale autorisée dans la file d’attente de lettres mortes en raison des données d’événement ajoutées par Amazon SNS et de attributs ajoutés par Lambda.
Si vous utilisez Amazon SQS en tant que source d’événement, configurez une file d’attente de lettres mortes sur la file d’attente Amazon SQS elle-même, non sur la fonction Lambda. Pour de plus amples informations, veuillez consulter [Utilisation de Lambda avec Amazon SQS](with-sqs.md).