

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.

# Création et configuration d’un mappage des sources d’événements Amazon SQS
<a name="services-sqs-configure"></a>

Pour traiter les messages Amazon SQS avec Lambda, configurez votre file d’attente avec les paramètres appropriés, puis créez un mappage des sources d’événements Lambda.

**Topics**
+ [Configuration d’une file d’attente à utiliser avec Lambda](#events-sqs-queueconfig)
+ [Configuration des autorisations de rôle d’exécution Lambda](#events-sqs-permissions)
+ [Création d’un mappage des sources d’événements SQS](#events-sqs-eventsource)

## Configuration d’une file d’attente à utiliser avec Lambda
<a name="events-sqs-queueconfig"></a>

Si vous n’avez pas encore de file d’attente Amazon SQS, [créez-en une](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html) à utiliser en tant que source d’événement pour votre fonction Lambda. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)

Pour laisser à votre fonction le temps de traiter chaque lot d’enregistrements, définissez le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de la file d’attente source à au moins six fois le [délai de configuration](configuration-timeout.md) sur votre fonction. Le délai supplémentaire permet à Lambda d’effectuer une nouvelle tentative si l’exécution de la fonction est limitée pendant le traitement d’un lot précédent.

**Note**  
Le délai d’expiration de votre fonction doit être inférieur ou égal au délai d’expiration de visibilité de la file d’attente. Lambda valide cette exigence lorsque vous créez ou mettez à jour un mappage des sources d’événements, et renvoie une erreur si le délai d’expiration de la fonction dépasse le délai d’expiration de visibilité de la file d’attente.

Par défaut, si Lambda rencontre une erreur à un moment donné lors du traitement d’un lot, tous les messages de ce lot retournent dans la file d’attente. Après le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html), les messages redeviennent visibles pour Lambda. Vous pouvez configurer le mappage des sources d’événements pour utiliser les [réponses par lots partielles](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) afin que seuls les messages ayant échoué soient renvoyés dans la file d’attente. En outre, en cas d’échec répété du traitement d’un message, Amazon SQS peut envoyer celui-ci à une [file d’attente de lettres mortes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Nous vous recommandons de définir `maxReceiveCount` sur la [stratégie de redirection](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues) de votre file d’attente source sur au moins 5. Cela donne à Lambda la possibilité d’effectuer quelques tentatives avant d’envoyer les messages ayant échoué directement à la file d’attente de lettres mortes.

## Configuration des autorisations de rôle d’exécution Lambda
<a name="events-sqs-permissions"></a>

La politique [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gérée inclut les autorisations dont Lambda a besoin pour lire depuis votre file d'attente Amazon SQS. Vous pouvez ajouter cette politique gérée au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction.

En option, si vous utilisez une file d’attente chiffrée, vous devez également ajouter l’autorisation suivante à votre rôle d’exécution :
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)

## Création d’un mappage des sources d’événements SQS
<a name="events-sqs-eventsource"></a>

Créez un mappage de source d’événement pour indiquer à Lambda d’envoyer des éléments de votre file d’attente à une fonction Lambda. Vous pouvez créer plusieurs mappages de source d’événement pour traiter des éléments de plusieurs files d’attente avec une seule fonction. Quand Lambda invoque la fonction cible, l’événement peut contenir plusieurs éléments, jusqu’à une *taille de lot* maximale configurable.

Pour configurer votre fonction afin qu'elle puisse lire depuis Amazon SQS, associez la politique [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gérée à votre rôle d'exécution. Créez ensuite un mappage des sources d’événements **SQS** à partir de la console en suivant les étapes suivantes.

**Pour ajouter des autorisations et créer un déclencheur**

1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.

1. Choisissez le nom d’une fonction.

1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).

1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.  
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role.png)

1. Choisissez **Ajouter des autorisations**, puis **Attacher des politiques**.  
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/attach-policies.png)

1. Dans le champ de recherche, entrez `AWSLambdaSQSQueueExecutionRole`. Ajoutez cette politique à votre rôle d’exécution. Il s'agit d'une politique AWS gérée qui contient les autorisations dont votre fonction a besoin pour lire depuis une file d'attente Amazon SQS. Pour plus d'informations sur cette politique, consultez [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)la *référence des politiques AWS gérées*.

1. Revenez à votre fonction dans la console Lambda. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.  
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-trigger.png)

1. Choisissez un type de déclencheur.

1. Configurez les options requises, puis choisissez **Add (Ajouter)**.

Lambda prend en charge les options de configuration suivantes pour les sources d’événements Amazon SQS :

**File d’attente SQS**  
La file d’attente Amazon SQS à partir de laquelle lire les enregistrements. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)

**Activation du déclencheur**  
L’état du mappage des sources d’événements. **Activez le déclencheur** est sélectionné par défaut.

**Taille de lot**  
Le nombre maximum d’enregistrements à envoyer à la fonction dans chaque lot. Pour une file d’attente standard, cela peut aller jusqu’à 10 000 registres. Pour une file d’attente FIFO, le maximum est de 10. Pour une taille de lot supérieure à 10, vous devez également définir la fenêtre de lot (`MaximumBatchingWindowInSeconds`) sur au moins 1 seconde.  
Configurez le [délai d’attente de votre fonction](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts) de façon à laisser suffisamment de temps pour traiter le lot entier d’éléments. Si les éléments sont longs à traiter, choisissez une taille de lot plus petite. Une grande taille de lot peut améliorer l’efficacité pour des charges de travail qui sont très rapides ou qui induisent beaucoup d’efforts supplémentaires. Si vous configurez une [simultanéité réservée](configuration-concurrency.md) sur votre fonction, définissez un minimum de cinq exécutions simultanées pour réduire le risque d’erreurs de limitation lorsque Lambda invoque votre fonction.  
Lambda transmet tous les registres du lot à la fonction en un seul appel, tant que la taille totale des événements ne dépasse pas le [quota de taille des données utiles d’invocation](gettingstarted-limits.md) pour une invocation synchrone (6 Mo). Des métadonnées sont générées par Lambda et Amazon SQS pour chaque registre. Ces métadonnées supplémentaires sont comptabilisées dans la taille de charge utile totale, ce qui peut entraîner l’envoi dans un lot d’un nombre total d’enregistrements inférieur à la taille du lot configuré. Les champs de métadonnées qu’Amazon SQS envoie peuvent être de longueur variable. Pour plus d'informations sur les champs de métadonnées Amazon SQS, consultez la documentation relative aux opérations d'[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API dans le manuel *Amazon Simple Queue Service API Reference*.

**Fenêtre de lot**  
Intervalle de temps maximal (en secondes) pour collecter des enregistrements avant d’invoquer la fonction. Cela s’applique uniquement aux files d’attente standards.  
Si vous utilisez une fenêtre de lot supérieure à 0 seconde, vous devez tenir compte de l’augmentation du temps de traitement dans le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de votre file d’attente. Nous vous recommandons de paramétrer votre délai de visibilité de file d’attente à six fois le [délai d’expiration de la fonction](configuration-timeout.md), en plus de la valeur de `MaximumBatchingWindowInSeconds`. Cela permet à votre fonction Lambda de traiter chaque lot d’événements et de réessayer en cas d’erreur de limitation.  
Lorsque les messages sont disponibles, Lambda commence à les traiter par lots. Lambda commence à traiter cinq lots à la fois avec cinq invocations simultanés de votre fonction. Si les messages sont toujours disponibles, Lambda ajoute jusqu'à 300 appels simultanés de votre fonction par minute, jusqu'à un maximum de 1 250 appels simultanés. En mode provisionné, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/s du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. Lambda adapte le nombre de sondeurs d'événements entre le minimum et le maximum configurés, en ajoutant rapidement jusqu'à 1 000 appels simultanés par minute afin de fournir un traitement à faible latence de vos événements Amazon SQS. Vous pouvez contrôler la mise à l'échelle et la simultanéité grâce à ces paramètres minimaux et maximaux d'un sondeur d'événements. Pour en savoir plus sur la mise à l'échelle et la simultanéité des fonctions, consultez[Présentation de la mise à l’échelle de fonction Lambda](lambda-concurrency.md).  
Pour traiter plus de messages, vous pouvez optimiser votre fonction Lambda pour un débit plus élevé. Pour plus d'informations, consultez [Comprendre comment s' AWS Lambda adapte aux files d'attente standard Amazon SQS.](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.)

**Critères de filtrage**  
Ajoutez des critères de filtrage pour contrôler les événements que Lambda envoie à votre fonction pour traitement. Pour de plus amples informations, veuillez consulter [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).

**Simultanéité maximum**  
Le nombre maximum de fonctions simultanées que la source d’événement peut invoquer. Ne peut pas être utilisé lorsque le mode provisionné est activé. Pour de plus amples informations, veuillez consulter [Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency).

**Mode alloué**  
Lorsque cette option est activée, alloue des ressources de sondage dédiées au mappage des sources de votre événement. Vous pouvez configurer le nombre minimum (2-200) et maximum (2-2000) de sondeurs d'événements. Chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde.  
Remarque : vous ne pouvez pas utiliser simultanément le mode provisionné et la simultanéité maximale. Lorsque le mode provisionné est activé, utilisez le paramètre du nombre maximum de sondeurs pour contrôler la simultanéité.