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.
# Procédure de traitement par Lambda des enregistrements provenant de sources d’événements basées sur des flux et des files d’attente
Un *mappage des sources d’événements* est une ressource Lambda qui lit des éléments à partir de services basés sur des flux et des files d’attente et qui invoque une fonction avec des lots d’enregistrements. Dans le cadre d’un mappage des sources d’événements, des ressources appelées *sondeurs d’événements* interrogent activement les nouveaux messages et invoquent des fonctions. Par défaut, Lambda adapte automatiquement les sondeurs d’événements, mais pour certains types de sources d’événements, vous pouvez utiliser le [mode alloué](#invocation-eventsourcemapping-provisioned-mode) pour contrôler le nombre minimum et maximum de sondeurs d’événements dédiés votre mappage des sources d’événements.
Les services suivants utilisent des mappages des sources d’événements pour invoquer des fonctions Lambda :
+ [Amazon DocumentDB (compatible avec MongoDB) (Amazon DocumentDB)](with-documentdb.md)
+ [Amazon DynamoDB](with-ddb.md)
+ [Amazon Kinesis](with-kinesis.md)
+ [Amazon MQ](with-mq.md)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](with-msk.md)
+ [Self-managed Apache Kafka](with-kafka.md)
+ [Amazon Simple Queue Service (Amazon SQS)](with-sqs.md)
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
## Différence entre les mappages de sources d’événements et les déclencheurs directs
*Certains Services AWS peuvent appeler directement des fonctions Lambda à l'aide de déclencheurs.* Ces services envoient des événements à Lambda, et la fonction est invoquée aussitôt que l’événement spécifié se produit. Les déclencheurs sont adaptés aux événements discrets et au traitement en temps réel. Lorsque vous [créez un déclencheur à l'aide de la console Lambda](lambda-services.md#lambda-invocation-trigger), celle-ci interagit avec le AWS service correspondant pour configurer la notification d'événement sur ce service. Le déclencheur est en fait stocké et géré par le service qui génère les événements, et non par Lambda. Voici quelques exemples de services qui utilisent des déclencheurs pour invoquer des fonctions Lambda :
+ **Amazon Simple Storage Service (Amazon S3) :** invoque une fonction lorsqu’un objet est créé, supprimé ou modifié dans un compartiment. Pour de plus amples informations, veuillez consulter [Didacticiel : utilisation d’un déclencheur Amazon S3 pour invoquer une fonction Lambda](with-s3-example.md).
+ **Amazon Simple Notification Service (Amazon SNS) :** invoque une fonction lorsqu’un message est publié dans une rubrique SNS. Pour de plus amples informations, veuillez consulter [Tutoriel : Utilisation AWS Lambda avec Amazon Simple Notification Service](with-sns-example.md).
+ **Amazon API Gateway :** invoque une fonction lorsqu’une requête d’API est envoyée à un point de terminaison spécifique. Pour de plus amples informations, veuillez consulter [Invocation d’une fonction Lambda à l’aide d’un point de terminaison Amazon API Gateway](services-apigateway.md).
Les mappages des sources d’événements sont des ressources Lambda créées et gérées au sein du service Lambda. Les mappages des sources d’événements sont conçus pour traiter de gros volumes de données en streaming ou de messages provenant de files d’attente. Le traitement par lots des enregistrements d’un flux ou d’une file d’attente est plus efficace que le traitement individuel des enregistrements.
## Comportement de traitement par lots
Par défaut, un mappage de source d’événements regroupe des enregistrements dans une même charge utile que Lambda envoie à votre fonction. Pour affiner le comportement du traitement par lots, vous pouvez configurer une fenêtre de traitement par lots ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) et une taille de lot ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize)). Une fenêtre de traitement par lots représente l’intervalle de temps maximal pour collecter des enregistrements dans une même charge utile. La taille d’un lot est le nombre maximal d’enregistrements dans un même lot. Lambda invoque votre fonction en présence de l’un des trois critères suivants :
+ **La fenêtre de traitement par lots atteint sa valeur maximale.** Le comportement par défaut de la fenêtre de traitement par lots varie selon la source d’événement spécifique.
+ **Pour les sources d’événements Kinesis, DynamoDB et Amazon SQS :** la fenêtre de traitement par lot par défaut est de 0 seconde. Cela signifie que Lambda invoque votre fonction dès que des enregistrements sont disponibles. Pour définir une fenêtre de traitement par lots, configurez `MaximumBatchingWindowInSeconds`. Vous pouvez configurer ce paramètre à n’importe quelle valeur comprise entre 0 et 300 secondes par incréments d’1 seconde. Si vous configurez une fenêtre de traitement par lots, la fenêtre suivante commence dès que l’invocation de fonction précédente est terminée.
+ **Pour les sources d’événements Amazon MSK, Apache Kafka autogérées, Amazon MQ et Amazon DocumentDB :** la fenêtre de traitement par lots par défaut est de 500 ms. Vous pouvez configurer `MaximumBatchingWindowInSeconds` à n’importe quelle valeur comprise entre 0 et 300 secondes par incréments de secondes. En mode provisionné pour les mappages des sources d’événements Kafka, lorsque vous configurez une fenêtre de traitement par lots, la fenêtre suivante commence dès que le lot précédent est terminé. Dans les mappages des sources d’événements Kafka non provisionnés, si vous configurez une fenêtre de traitement par lots, la fenêtre suivante commence dès que l’invocation de fonction précédente est terminée. Pour minimiser la latence lors de l’utilisation des mappages des sources d’événements Kafka en mode provisionné, définissez `MaximumBatchingWindowInSeconds` sur 0. Ce paramètre garantit que Lambda commencera à traiter le lot suivant immédiatement après avoir terminé l’invocation de fonction en cours. Pour plus d’informations sur le traitement à faible latence, consultez [Apache Kafka à faible latence](with-kafka-low-latency.md).
+ **Pour les sources d’événements Amazon MQ et Amazon DocumentDB :** la fenêtre de traitement par lots par défaut est de 500 ms. Vous pouvez configurer `MaximumBatchingWindowInSeconds` à n’importe quelle valeur comprise entre 0 et 300 secondes par incréments de secondes. Une fenêtre de traitement par lots commence dès l’arrivée du premier registre.
**Note**
Étant donné que vous ne pouvez modifier `MaximumBatchingWindowInSeconds` que par incréments de secondes, vous ne pouvez pas revenir à la fenêtre de traitement par lots par défaut de 500 ms après l’avoir modifiée. Pour restaurer la fenêtre de traitement par lots par défaut, vous devez créer un mappage de source d’événement.
+ **La taille du lot est atteinte.** La taille minimale du lot est de 1. La taille par défaut et la taille maximale du lot dépendent de la source d’événement. Pour plus d’informations sur ces valeurs, consultez la spécification [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) pour l’opération de l’API `CreateEventSourceMapping`.
+ **La taille de la charge utile atteint [6 Mo](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).** Vous ne pouvez pas modifier cette limite.
Le diagramme suivant illustre ces trois conditions. Supposons qu’une fenêtre de traitement par lots commence à `t = 7` secondes. Dans le premier scénario, la fenêtre de traitement par lots atteint son maximum de 40 secondes à `t = 47` secondes après avoir accumulé 5 enregistrements. Dans le second scénario, la taille du lot atteint 10 avant l’expiration de la fenêtre de traitement par lots, de sorte que la fenêtre de traitement par lots se termine plus tôt. Dans le troisième scénario, la taille maximale de la charge utile est atteinte avant l’expiration de la fenêtre de traitement par lots, de sorte que la fenêtre de traitement par lots se termine plus tôt.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/batching-window.png)
Nous vous recommandons de tester différentes tailles de lots et d’enregistrements afin que la fréquence d’interrogation de chaque source d’événement soit adaptée à la rapidité avec laquelle votre fonction est en mesure d’accomplir sa tâche. Le [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)`BatchSize`paramètre contrôle le nombre maximum d'enregistrements qui peuvent être envoyés à votre fonction à chaque appel. Une taille de lot plus grande peut souvent absorber plus efficacement l’invocation sur un plus large ensemble d’enregistrements, ce qui accroît votre débit.
Lambda envoi le prochain lot pour traitement sans attendre que les [extensions](lambda-extensions.md) configurées soient terminées. En d’autres termes, vos extensions peuvent continuer à s’exécuter pendant que Lambda traite le prochain lot d’enregistrements. Cela peut causer des problèmes de limitation si vous enfreignez l’un des paramètres ou l’une des limites de [simultanéité](lambda-concurrency.md) de votre compte. Pour détecter s’il s’agit d’un problème éventuel, surveillez vos fonctions et vérifiez si vous observez des [métriques de simultanéité](monitoring-concurrency.md#general-concurrency-metrics) plus élevées que prévu pour votre mappage des sources d’événements. En raison de la brièveté des intervalles entre les invocations, Lambda peut brièvement signaler une utilisation simultanée supérieure au nombre de partitions. Cela peut être vrai même pour les fonctions Lambda sans extensions.
Par défaut, si votre fonction renvoie une erreur, le mappage de la source d’événements retraite l’ensemble du lot jusqu’à ce que la fonction réussisse ou que les éléments du lot arrivent à expiration. Pour s’assurer d’un traitement dans l’ordre, le mappage de la source d’événement met en pause le traitement dans la partition concernée jusqu’à la résolution de l’erreur. Pour les sources de flux (DynamoDB et Kinesis), vous pouvez configurer le nombre maximal de tentatives que Lambda effectue lorsque votre fonction renvoie une erreur. Les erreurs de service ou les limitations où le lot n’atteint pas votre fonction ne comptent pas dans les tentatives de réessai. Vous pouvez également configurer le mappage des sources d’événements pour qu’il envoie un enregistrement d’invocation à une [destination](invocation-async-retain-records.md#invocation-async-destinations) lorsqu’il rejette un lot d’événements.
## Mode alloué
Les mappages des sources d’événements Lambda utilisent des sondeurs d’événements pour interroger votre source d’événements à la recherche de nouveaux messages. Par défaut, Lambda gère le dimensionnement automatique de ces sondeurs en fonction du volume des messages. Lorsque le trafic de messages augmente, Lambda augmente automatiquement le nombre de sondeurs d’événements pour gérer la charge, et le réduit lorsque le trafic diminue.
En mode provisionné, vous pouvez affiner le débit du mappage de vos sources d'événements en définissant des limites minimales et maximales pour les ressources de sondage dédiées qui restent prêtes à gérer les modèles de trafic attendus. Ces ressources évoluent automatiquement 3 fois plus vite pour faire face aux pics soudains de trafic d'événements et fournissent une capacité 16 fois supérieure pour traiter des millions d'événements. Cela vous permet de créer des charges de travail hautement réactives axées sur les événements avec des exigences de performance strictes.
Dans Lambda, un sondeur d'événements est une unité de calcul dont les capacités de débit varient selon le type de source d'événements. Pour Amazon MSK et Apache Kafka autogéré, chaque sondeur d'événements peut gérer jusqu'à 5 % MB/sec du débit ou jusqu'à 5 appels simultanés. Par exemple, si la source de votre événement produit une charge utile moyenne de 1 Mo et que la durée moyenne de votre fonction est de 1 seconde, un seul sondeur d'événements Kafka peut prendre en charge 5 MB/sec débits et 5 appels Lambda simultanés (en supposant qu'il n'y ait aucune transformation de charge utile). Pour Amazon SQS, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit ou jusqu'à 10 appels simultanés. L'utilisation du mode provisionné entraîne des coûts supplémentaires en fonction de l'utilisation de votre sondeur d'événements. Pour plus d’informations sur la tarification, consultez [Tarification AWS Lambda](https://aws.amazon.com/lambda/pricing/).
Le mode provisionné est disponible pour les sources d'événements Amazon MSK, Apache Kafka autogérées et Amazon SQS. Alors que les paramètres de simultanéité vous permettent de contrôler la mise à l’échelle de votre fonction, le mode alloué vous permet de contrôler le débit de votre mappage des sources d’événements. Pour garantir des performances optimales, vous devrez peut-être ajuster les deux paramètres indépendamment.
Le mode provisionné est idéal pour les applications en temps réel nécessitant une latence constante pour le traitement des événements, telles que les sociétés de services financiers traitant les flux de données du marché, les plateformes de commerce électronique fournissant des recommandations personnalisées en temps réel et les sociétés de jeux gérant les interactions avec les joueurs en direct.
Chaque sondeur d'événements prend en charge une capacité de débit différente :
+ Pour Amazon MSK et Apache Kafka autogéré : jusqu'à 5 % MB/sec du débit ou jusqu'à 5 appels simultanés
+ Pour Amazon SQS : jusqu'à 1 % MB/sec de débit ou jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation SQS par seconde.
Pour les mappages de sources d'événements Amazon SQS, vous pouvez définir le nombre minimum de sondeurs entre 2 et 200 avec une valeur par défaut de 2, et le nombre maximum entre 2 et 2 000 avec une valeur par défaut de 200. 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 cohérent et à faible latence de vos événements.
Pour les mappages de sources d'événements Kafka, vous pouvez définir le nombre minimum de sondeurs entre 1 et 200 avec une valeur par défaut de 1, et le nombre maximum entre 1 et 2 000 avec une valeur par défaut de 200. Lambda adapte le nombre de sondeurs d'événements entre le minimum et le maximum configurés en fonction de votre historique d'événements dans votre rubrique afin de garantir un traitement à faible latence de vos événements.
Notez que pour les sources d'événements Amazon SQS, le paramètre de simultanéité maximale ne peut pas être utilisé en mode provisionné. Lorsque vous utilisez le mode provisionné, vous contrôlez la simultanéité par le biais du paramètre Nombre maximal de sondeurs d'événements.
Pour plus d’informations sur la configuration du mode alloué, reportez-vous aux sections suivantes :
+ [Configuration du mode alloué pour les mappages des sources d’événements Amazon MSK](kafka-scaling-modes.md)
+ [Configuration du mode alloué pour les mappages des source d’événement Apache Kafka autogéré](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [Utilisation du mode provisionné avec les mappages de sources d'événements Amazon SQS](with-sqs.md#sqs-provisioned-mode)
Pour minimiser le temps de latence en mode provisionné, définissez ce paramètre `MaximumBatchingWindowInSeconds` sur 0. Ce paramètre garantit que Lambda commencera à traiter le lot suivant immédiatement après avoir terminé l’invocation de fonction en cours. Pour plus d’informations sur le traitement à faible latence, consultez [Apache Kafka à faible latence](with-kafka-low-latency.md).
Après avoir configuré le mode alloué, vous pouvez observer l’utilisation des sondeurs d’événements pour votre charge de travail en surveillant la métrique `ProvisionedPollers`. Pour de plus amples informations, veuillez consulter [Métriques de mappage des sources d’événements](monitoring-metrics-types.md#event-source-mapping-metrics).
## API de mappage de la source d’événement
Pour gérer une source d’événement à l’aide de la [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) ou d’un [AWS SDK](https://aws.amazon.com/getting-started/tools-sdks/), vous pouvez utiliser les opérations d’API suivantes :
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)
# Utilisation des balises dans les mappages des sources d’événements
Vous pouvez étiqueter les mappages des sources d’événements pour organiser et gérer vos ressources. Les balises sont des paires clé-valeur de forme libre associées à vos ressources prises en charge par l’ensemble des ressources Services AWS. Pour plus d'informations sur les cas d'utilisation des balises, consultez la section [Stratégies de balisage courantes dans le guide des AWS](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) *ressources de balisage et de l'éditeur de balises*.
Les mappages des sources d’événements sont associés à des fonctions, qui peuvent avoir leurs propres balises. Les mappages des sources d’événements n’héritent pas automatiquement des balises des fonctions. Vous pouvez utiliser l' AWS Lambda API pour afficher et mettre à jour les balises. Vous pouvez également consulter et mettre à jour les balises tout en gérant un mappage de source d'événement spécifique dans la console Lambda, y compris ceux utilisant le mode provisionné pour Amazon SQS.
## Autorisations requises pour l’utilisation des balises
Pour autoriser une identité Gestion des identités et des accès AWS (IAM) – utilisateur, groupe ou rôle – à afficher ou marquer les ressources, accordez-lui les autorisations correspondantes :
+ **lambda : ListTags** —Lorsqu' une ressource possède des balises, accordez cette autorisation à tous ceux qui ont besoin de `ListTags` l'utiliser. Pour les fonctions balisées, cette autorisation est également nécessaire pour `GetFunction`.
+ **lambda : TagResource** —Accordez cette autorisation à toute personne ayant besoin d'appeler `TagResource` ou d'exécuter un tag lors de la création.
Vous pouvez éventuellement envisager d'accorder également l'UntagResourceautorisation **lambda :** pour autoriser les `UntagResource` appels à la ressource.
Pour de plus amples informations, veuillez consulter [Politiques IAM basées sur l’identité pour Lambda](access-control-identity-based.md).
## Utilisation des balises avec la console Lambda
Vous pouvez utiliser la console Lambda pour créer des mappages de sources d'événements comportant des balises, ajouter des balises aux mappages de sources d'événements existants et filtrer les mappages de sources d'événements par balise, y compris ceux configurés en mode provisionné pour Amazon SQS.
Lorsque vous ajoutez un déclencheur pour les services basés sur les flux et les files d’attente pris en charge à l’aide de la console Lambda, Lambda crée automatiquement un mappage des sources d’événements. Pour plus d’informations sur ces sources d’événements, consultez [Procédure de traitement par Lambda des enregistrements provenant de sources d’événements basées sur des flux et des files d’attente](invocation-eventsourcemapping.md). Pour créer un mappage des sources d’événement dans la console, vous devez disposer des éléments suivants :
+ Une fonction .
+ Une source d’événement provenant d’un service concerné.
Vous pouvez ajouter les balises dans le cadre de l’interface utilisateur que vous utilisez pour créer ou mettre à jour des déclencheurs.
**Pour ajouter une balise lors de la création d’un mappage des sources d’événements**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de votre fonction .
1. Sous **Function overview** (Vue d’ensemble de la fonction), choisissez **Add trigger** (Ajouter un déclencheur).
1. Sous **Configuration du déclencheur**, dans la liste déroulante, choisissez le nom du service dont provient votre source d’événement.
1. Fournissez la configuration de base de votre source d’événements. Pour plus d’informations sur la configuration de votre source d’événements, consultez la section relative au service correspondant dans [Invoquer Lambda avec des événements provenant d'autres services AWS](lambda-services.md).
1. Sous **Configuration du mappage des sources d’événements**, sélectionnez **Paramètres supplémentaires**.
1. Sous **Balises**, choisissez **Ajouter une nouvelle balise**.
1. Dans le champ **Clé**, saisissez la clé de votre balise. Pour plus d'informations sur les restrictions relatives au balisage, consultez la section [Limites et exigences relatives au nommage des balises](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) dans le Guide des * AWS ressources de balisage et de l'éditeur de balises*.
1. Choisissez **Ajouter**.
**Pour ajouter des balises à un mappage des sources d’événements existant**
1. Ouvrez la page [Mappages des sources d’événements](https://console.aws.amazon.com/lambda/home#/event-source-mappings) dans la console Lambda.
1. Dans la liste des ressources, choisissez l’**UUID** du mappage des sources d’événements correspondant à l’**ARN de la source d’événement** et de la **fonction**.
1. Dans la liste des onglets située sous le **volet de configuration générale**, choisissez **Balises**.
1. Choisissez **Gérer les balises**.
1. Choisissez **Add new tag** (Ajouter une nouvelle balise).
1. Dans le champ **Clé**, saisissez la clé de votre balise. Pour plus d'informations sur les restrictions relatives au balisage, consultez la section [Limites et exigences relatives au nommage des balises](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) dans le Guide des * AWS ressources de balisage et de l'éditeur de balises*.
1. Choisissez **Enregistrer**.
**Pour filtrer les mappages des sources d’événements par balise**
1. Ouvrez la page [Mappages des sources d’événements](https://console.aws.amazon.com/lambda/home#/event-source-mappings) dans la console Lambda.
1. Cliquez sur la barre de recherche.
1. Dans la liste déroulante, sélectionnez votre clé de balise sous le sous-titre **Balises**.
1. Sélectionnez **Utiliser : « tag-name »** pour afficher tous les mappages des sources d’événéments étiquetés avec cette touche, ou choisissez un **Opérateur** pour affiner le filtrage en fonction de la valeur.
1. Sélectionnez votre valeur de balise pour appliquer un filtre combinant la clé et la valeur de la balise.
La zone de recherche prend également en charge la recherche de clés de balise. Saisissez le nom d’une clé pour la rechercher dans la liste.
## Utilisation de balises avec AWS CLI
Vous pouvez ajouter et supprimer des balises sur les ressources Lambda existantes, mappages de sources d’événéments inclus, avec l’API Lambda. Il est également possible d’ajouter des balises lors de la création d’un mappage des sources d’événements, vous permettant ainsi de conserver une ressource balisée tout au long de son cycle de vie.
### Mise à jour des balises avec la balise Lambda APIs
Vous pouvez ajouter et supprimer des balises pour les ressources Lambda prises en charge par le biais des opérations [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)et de l'[UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API.
Vous pouvez appeler ces opérations par l’intermédiaire de l’ AWS CLI. Pour ajouter des balises à une ressource existante, utilisez la commande `tag-resource`. Cet exemple ajoute deux balises, l'une avec la clé *Department* et l'autre avec la clé*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Pour supprimer des balises, utilisez la commande `untag-resource`. Cet exemple supprime la balise contenant la clé*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Ajout de balises lors de la création d’un mappage des sources d’événements
Pour créer un nouveau mappage de source d'événements Lambda avec des balises, utilisez l'opération [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)API. Spécifiez le paramètre `Tags`. Vous pouvez appeler cette opération à l'aide de la `create-event-source-mapping` AWS CLI commande et de l'`--tags`option. Pour plus d'informations sur la commande CLI, consultez [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)la *référence des AWS CLI commandes*.
Avant d’utiliser le paramètre `Tags` avec `CreateEventSourceMapping`, vérifiez que votre rôle dispose de l’autorisation d’étiqueter les ressources en plus des autorisations habituelles nécessaires à cette opération. Pour plus d’informations sur les autorisations requises pour l’étiquetage, consultez [Autorisations requises pour l’utilisation des balises](#esm-tags-required-permissions).
### Afficher les tags avec le tag Lambda APIs
Pour afficher les balises associées à une ressource Lambda spécifique, utilisez l’opération d’API `ListTags`. Pour de plus amples informations, veuillez consulter [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Vous pouvez appeler cette opération à l'aide de la `list-tags` AWS CLI commande en fournissant un ARN (Amazon Resource Name).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtrage de ressources par balise
Vous pouvez utiliser le fonctionnement de l' AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API pour filtrer vos ressources par balises. L’opération `GetResources` reçoit jusqu’à 10 filtres, chaque filtre contenant une clé de balise et jusqu’à 10 valeurs de balise. Vous fournissez `GetResources`avec un `ResourceType` pour filtrer par certains types de ressources.
Vous pouvez appeler cette opération à l'aide de la `get-resources` AWS CLI commande. Pour des exemples d’utilisation de `get-resources`, consultez [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) dans la *Référence des commandes de l’AWS CLI*.