Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Contrôle des événements envoyés par Lambda à votre fonction

Mode de mise au point
Contrôle des événements envoyés par Lambda à votre fonction - AWS Lambda

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.

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.

Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Par exemple, vous pouvez ajouter un filtre pour que votre fonction ne traite que les messages Amazon SQS contenant certains paramètres de données. Le filtrage des sources d’événements ne fonctionne qu’avec certains mappages des sources d’événements. Vous pouvez ajouter des filtres aux mappages des sources d’événements pour les Services AWS suivants :

  • Amazon DynamoDB

  • Amazon Kinesis Data Streams

  • Amazon MQ

  • Amazon Managed Streaming for Apache Kafka (Amazon MSK)

  • Self-managed Apache Kafka

  • Amazon Simple Queue Service (Amazon SQS)

Pour obtenir des informations spécifiques sur le filtrage avec des sources d’événements précises, consultez Utilisation de filtres avec des Services AWS différents. Lambda ne prend pas en charge le filtrage d’événements pour Amazon DocumentDB.

Par défaut, vous pouvez définir jusqu’à cinq filtres différents pour un seul mappage des sources d’événements. Vos filtres sont logiquement combinés par OU. Si un enregistrement de votre source d’événement satisfait un ou plusieurs de vos filtres, Lambda inclut l’enregistrement dans le prochain événement qu’il envoie à votre fonction. Si aucun de vos filtres n’est satisfait, Lambda rejette l’enregistrement.

Note

Si vous avez besoin de définir plus de cinq filtres pour une source d’événement, vous pouvez demander une augmentation de quota jusqu’à dix filtres pour chaque source d’événement. Si vous tentez d’ajouter plus de filtres que votre quota actuel ne le permet, Lambda renvoie une erreur lorsque vous essayez de créer la source d’événement.

Présentation des principes de base du filtrage d’événements

Un objet (FilterCriteria) de critères de filtre est une structure composée d’une liste de filtres (Filters). Chaque filtre est une structure qui définit un modèle de filtrage d’événements (Pattern). Un modèle est une représentation sous forme de chaîne d’une règle de filtre JSON. La structure d’un objet FilterCriteria est la suivante.

{ "Filters": [ { "Pattern": "{ \"Metadata1\": [ rule1 ], \"data\": { \"Data1\": [ rule2 ] }}" } ] }

Pour plus de clarté, voici la valeur du Pattern de filtre étendu en JSON simple :

{ "Metadata1": [ rule1 ], "data": { "Data1": [ rule2 ] } }

Votre modèle de filtrage peut inclure des propriétés de métadonnées, des propriétés de données ou les deux. Les paramètres de métadonnées disponibles et le format des paramètres de données varient en fonction de l’objet Service AWS qui sert de source d’événements. Par exemple, supposons que votre mappage des sources d’événements reçoit l’enregistrement suivant d’une file d’attente Amazon SQS :

{ "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d", "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...", "body": "{\n "City": "Seattle",\n "State": "WA",\n "Temperature": "46"\n}", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082649183", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082649185" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" }
  • Les propriétés de métadonnées sont les champs contenant des informations sur l’événement qui a créé l’enregistrement. Dans l’exemple d’enregistrement Amazon SQS, les propriétés de métadonnées comprennent des champs tels que messageID, eventSourceArn et awsRegion.

  • Les propriétés de données sont les champs de l’enregistrement contenant les données de votre flux ou file d’attente. Dans l’exemple d’événement Amazon SQS, la clé du champ de données est body et les propriétés de données sont les champs City State et Temperature.

Les différents types de sources d’événements utilisent des valeurs clés différentes pour leurs champs de données. Pour filtrer sur les propriétés de données, assurez-vous d’utiliser la bonne clé dans le modèle de votre filtre. Pour obtenir une liste des clés de filtrage des données et voir des exemples de modèles de filtrage pour chaque Service AWS pris en charge, reportez-vous à Utilisation de filtres avec des Services AWS différents.

Le filtrage d’événements peut gérer le filtrage JSON à plusieurs niveaux. Par exemple, considérez le fragment suivant d’un enregistrement provenant d’un flux DynamoDB :

"dynamodb": { "Keys": { "ID": { "S": "ABCD" } "Number": { "N": "1234" }, ... }

Supposons que vous vouliez traiter uniquement les enregistrements dont la valeur de la clé de tri Number est 4 567. Dans ce cas, votre objet FilterCriteria se présente comme suit :

{ "Filters": [ { "Pattern": "{ \"dynamodb\": { \"Keys\": { \"Number\": { \"N\": [ "4567" ] } } } }" } ] }

Pour plus de clarté, voici la valeur du Pattern de filtre étendu en JSON simple :

{ "dynamodb": { "Keys": { "Number": { "N": [ "4567" ] } } } }

Traitement des enregistrements ne répondant pas aux critères de filtrage

La manière dont Lambda gère les enregistrements qui ne répondent pas à vos critères de filtre dépend de la source de l’événement.

  • Pour Amazon SQS, si un message ne répond pas à vos critères de filtre, Lambda supprime automatiquement le message de la file d’attente. Vous n’avez pas besoin de supprimer manuellement ces messages dans Amazon SQS.

  • Pour Kineses et DynamoDB, après que vos critères de filtre ont évalué un enregistrement, l’itérateur de flux avance au-delà de cet enregistrement. Si l’enregistrement ne répond pas à vos critères de filtre, vous n’avez pas besoin de supprimer manuellement l’enregistrement de la source de votre événement. Après la période de conservation, Kinesis et DynamoDB suppriment automatiquement ces anciens enregistrements. Si vous souhaitez que les enregistrements soient supprimés plus tôt, consultez Modification de la période de conservation des données.

  • Pour les messages Amazon MSK, Apache Kafka autogéré et Amazon MQ, Lambda supprime les messages qui ne correspondent pas à tous les champs inclus dans le filtre. Pour Amazon MSK et Apache Kafka autogéré, Lambda valide les décalages pour les messages correspondants et non correspondants après avoir invoqué la fonction avec succès. Pour Amazon MQ, Lambda accuse réception des messages correspondants après avoir correctement invoqué la fonction et reconnaît les messages non correspondants lors du filtrage.

Syntaxe des règles de filtrage

Pour les règles de filtrage, Lambda prend en charge les règles Amazon EventBridge et utilise la même syntaxe que ce dernier. Pour plus d’informations, consultez Amazon EventBridge event patterns dans le Guide de l’utilisateur Amazon EventBridge.

Voici un récapitulatif de tous les opérateurs de comparaison disponibles pour le filtrage d’événement Lambda.

Opérateur de comparaison Exemple Syntaxe des règles

Null

UserID est null

"UserID": [ null ]

Vide

LastName est vide

"LastName": [""]

Égal à

Le nom est « Alice »

"Name": [ "Alice" ]

Est égal à (ignorer les majuscules)

Le nom est « Alice »

"Name": [ { "equals-ignore-case": "alice" } ]

And

Le lieu est « New York » et le jour est « Monday »

"Location": [ "New York" ], "Day": ["Monday"]

Ou

PaymentType est « Credit » ou « Debit »

"PaymentType": [ "Credit", "Debit"]

Ou (plusieurs champs)

Location est « New York », ou Day est « Monday ».

"$or": [ { "Location": [ "New York" ] }, { "Day": [ "Monday" ] } ]

Pas

La météo est tout sauf « Raining »

"Weather": [ { "anything-but": [ "Raining" ] } ]

Numérique (égal)

Le prix est de 100

"Price": [ { "numeric": [ "=", 100 ] } ]

Numérique (plage)

Le prix est supérieur à 10 et inférieur ou égal à 20

"Price": [ { "numeric": [ ">", 10, "<=", 20 ] } ]

Existe

ProductName existe

"ProductName": [ { "exists": true } ]

N’existe pas

ProductName n’existe pas

"ProductName": [ { "exists": false } ]

Commence par

La région se trouve aux États-Unis

"Region": [ {"prefix": "us-" } ]

Se termine par

FileName se termine par l’extension .png.

"FileName": [ { "suffix": ".png" } ]

Note

Comme EventBridge, pour les chaînes, Lambda utilise une correspondance exacte caractère par caractère sans changement de casse ou autre type de normalisation de chaîne. Pour les nombres, Lambda utilise également une représentation par chaîne. Par exemple, 300, 300,0 et 3.0e2 ne sont pas considérés égaux.

Notez que l’opérateur Exists ne fonctionne que sur les nœuds feuilles de votre source d’événements JSON. Il ne tient pas compte des nœuds intermédiaires. Par exemple, avec le JSON suivant, le modèle de filtre { "person": { "address": [ { "exists": true } ] } }" ne trouverait aucune correspondance, car "address" est un nœud intermédiaire.

{ "person": { "name": "John Doe", "age": 30, "address": { "street": "123 Main St", "city": "Anytown", "country": "USA" } } }

Attacher des critères de filtre à un mappage de sources d’événements (console)

Suivez ces étapes pour créer un nouveau mappage de source d’événement avec des critères de filtre à l’aide de la console Lambda.

Pour créer un nouveau mappage de sources d’événements avec des critères de filtre (console)
  1. Ouvrez la page Functions (Fonctions) de la console Lambda.

  2. Choisissez le nom d’une fonction pour laquelle créer un mappage de source d’événements.

  3. Sous Function overview (Vue d’ensemble de la fonction), choisissez Add trigger (Ajouter un déclencheur).

  4. Pour Trigger configuration (Configuration du déclencheur), choisissez un type de déclencheur qui prend en charge le filtrage des événements. Pour obtenir la liste des services pris en charge, reportez-vous à la liste figurant au début de cette page.

  5. Développer Additional settings (Paramètres supplémentaires).

  6. Sous Filter criteria (Critères de filtre), choisissez Add (Ajouter) puis définissez et saisissez vos filtres. Par exemple, vous pouvez saisir ce qui suit.

    { "Metadata" : [ 1, 2 ] }

    Cela indique à Lambda de traiter uniquement les enregistrements où le champ Metadata est égal à 1 ou 2. Vous pouvez continuer à sélectionner Ajouter pour ajouter d’autres filtres jusqu’à la quantité maximale autorisée.

  7. Lorsque vous avez terminé d’ajouter vos filtres, sélectionnez Enregistrer.

Lorsque vous saisissez des critères de filtrage à l’aide de la console, vous n’entrez que le modèle de filtrage et n’avez pas besoin d’indiquer la touche Pattern ni d’échapper aux guillemets. À l’étape 6 des instructions précédentes, { "Metadata" : [ 1, 2 ] } correspond à ce qui suit FilterCriteria.

{ "Filters": [ { "Pattern": "{ \"Metadata\" : [ 1, 2 ] }" } ] }

Après avoir créé le mappage de la source d’événements dans la console, vous pouvez voir les FilterCriteria formatés dans les détails du déclencheur. Pour plus d’exemples de création de filtres d’événements à l’aide de la console, consultez Utilisation de filtres avec des Services AWS différents.

Attacher des critères de filtre à un mappage de sources d’événements (AWS CLI)

Supposons que vous souhaitiez que le mappage d’une source d’événements comporte les suivants  FilterCriteria:

{ "Filters": [ { "Pattern": "{ \"Metadata\" : [ 1, 2 ] }" } ] }

Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.

aws lambda create-event-source-mapping \ --function-name my-function \ --event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \ --filter-criteria '{"Filters": [{"Pattern": "{ \"Metadata\" : [ 1, 2 ]}"}]}'

Cette commande create-event-source-mapping crée un mappage des sources d’événements Amazon SQS pour la fonction my-function avec les FilterCriteria spécifiés.

Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.

aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --filter-criteria '{"Filters": [{"Pattern": "{ \"Metadata\" : [ 1, 2 ]}"}]}'

Notez que pour mettre à jour un mappage de source d’événements, vous avez besoin de son UUID. Vous pouvez obtenir l’UUID à l’aide d’un appel list-event-source-mappings. Lambda renvoie également l’UUID dans la réponse create-event-source-mapping de la CLI.

Pour supprimer les critères de filtre d’une source d’événements, vous pouvez exécuter la commande update-event-source-mapping suivante avec un objet FilterCriteria vide.

aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --filter-criteria "{}"

Pour plus d’exemples de création de filtres d’événements à l’aide de l’objet AWS CLI, consultez Utilisation de filtres avec des Services AWS différents.

Attacher des critères de filtre à un mappage de sources d’événements (AWS SAM)

Supposons que vous vouliez configurer une source d’événements dans AWS SAM pour utiliser les critères de filtre suivants :

{ "Filters": [ { "Pattern": "{ \"Metadata\" : [ 1, 2 ] }" } ] }

Pour ajouter ces critères de filtre à votre mappage des sources d’événements, insérez l’extrait suivant dans le modèle YAML de votre source d’événements.

FilterCriteria: Filters: - Pattern: '{"Metadata": [1, 2]}'

Pour plus d’informations sur la création et la configuration d’un modèle AWS SAM pour un mappage des sources d’événements, consultez la section EventSource du Guide du développeur AWS SAM. Pour plus d’exemples de création de filtres d’événements à l’aide de modèles AWS SAM, consultez Utilisation de filtres avec des Services AWS différents.

Chiffrement des critères de filtre

Par défaut, Lambda ne chiffre pas votre objet de critères de filtre. Dans les cas d’utilisation où vous pouvez inclure des informations sensibles dans votre objet de critères de filtre, vous pouvez utiliser votre propre clé KMS pour les chiffrer.

Après avoir chiffré votre objet de critères de filtre, vous pouvez afficher sa version en texte brut à l’aide d’un appel d’API GetEventSourceMapping. Vous devez disposer des autorisations kms:Decrypt nécessaires pour afficher correctement les critères de filtre en texte brut.

Note

Si votre objet de critères de filtre est chiffré, Lambda expédie la valeur du champ FilterCriteria en réponse aux appels ListEventSourceMappings. Ce champ s’affiche plutôt sous la forme null. Pour connaître la valeur réelle de FilterCriteria, utilisez l’API GetEventSourceMapping.

Pour afficher la valeur déchiffrée de FilterCriteria dans la console, assurez-vous que votre rôle IAM contient des autorisations pour GetEventSourceMapping.

Vous pouvez spécifier votre propre clé KMS via la console, l’API/CLI ou AWS CloudFormation.

Pour chiffrer les critères de filtre à l’aide d’une clé KMS appartenant au client (console)
  1. Ouvrez la page Functions (Fonctions) de la console Lambda.

  2. Choisissez Add trigger (Ajouter déclencheur). Si vous possédez déjà un déclencheur, choisissez l’onglet Configuration, puis sur Déclencheurs. Sélectionnez le déclencheur existant, puis choisissez Modifier.

  3. Cochez la case en regard de Chiffrer avec une clé KMS gérée par le client.

  4. Pour Choisir une clé de chiffrement KMS gérée par le client, sélectionnez une clé activée existante ou créez-en une. Selon l’opération, vous avez besoin de certaines ou de toutes les autorisations suivantes : kms:DescribeKey, kms:GenerateDataKey et kms:Decrypt. Utilisez la stratégie de clé KMS pour octroyer ces autorisations.

Si vous utilisez votre propre clé KMS, les opérations d’API suivantes doivent être autorisées dans la stratégie de clé :

  • kms:Decrypt : doit être octroyé au principal du service Lambda régional (lambda.AWS_region.amazonaws.com). Cela permet à Lambda de déchiffrer les données avec cette clé KMS.

    • Pour éviter un problème des adjoints confus entre services, la stratégie de clé utilise la clé de condition globale aws:SourceArn. La valeur correcte de la clé aws:SourceArn est l’ARN de votre ressource de mappage des sources d’événements. Vous ne pouvez donc l’ajouter à votre stratégie qu’une fois que vous connaissez son ARN. Lambda transmet également les clés aws:lambda:FunctionArn et aws:lambda:EventSourceArn, ainsi que leurs valeurs respectives dans le contexte de chiffrement lors d’une requête de déchiffrement à KMS. Ces valeurs doivent correspondre aux conditions spécifiées dans la stratégie de clé pour que la requête de déchiffrement aboutisse. Il n’est pas nécessaire d’inclure EventSourceArn pour les sources d’événements Kafka autogéré, car elles n’ont pas d’EventSourceArn.

  • kms:Decrypt :doit également être accordé au principal qui a l’intention d’utiliser la clé pour afficher les critères de filtre en texte brut dans les appels d’API GetEventSourceMapping ou DeleteEventSourceMapping.

  • kms:DescribeKey : fournit les détails des clés gérées par le client pour permettre au principal spécifié d’utiliser la clé.

  • kms:GenerateDataKey :permet à Lambda de générer une clé de données pour chiffrer les critères de filtre, au nom du principal spécifié (chiffrement d’enveloppe).

Vous pouvez utiliser AWS CloudTrail pour effectuer le suivi des requêtes AWS KMS que Lambda effectue en votre nom. Pour des exemples d’événements CloudTrail, consultez Surveillance de vos clés de chiffrement pour Lambda.

Nous recommandons également d’utiliser la clé de condition kms:ViaService pour limiter l’utilisation de la clé KMS aux requêtes ne provenant que de Lambda. La valeur de cette clé est le principal de service Lambda régional (lambda.AWS_region.amazonaws.com). Voici un exemple de stratégie de clé qui accorde toutes les autorisations pertinentes :

Exemple politique de clé AWS KMS
{ "Version": "2012-10-17", "Id": "example-key-policy-1", "Statement": [ { "Sid": "Allow Lambda to decrypt using the key", "Effect": "Allow", "Principal": { "Service": "lambda.us-east-1.amazonaws.com" }, "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "ArnEquals" : { "aws:SourceArn": [ "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:<esm_uuid>" ] }, "StringEquals": { "kms:EncryptionContext:aws:lambda:FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:test-function", "kms:EncryptionContext:aws:lambda:EventSourceArn": "arn:aws:sqs:us-east-1:123456789012:test-queue" } } }, { "Sid": "Allow actions by an AWS account on the key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow use of the key to specific roles", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/ExampleRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringEquals" : { "kms:ViaService": "lambda.us-east-1.amazonaws.com" } } } ] }

Pour utiliser votre propre clé KMS afin de chiffrer les critères de filtre, vous pouvez également utiliser la commande CreateEventSourceMapping de l’AWS CLI suivante. Spécifiez l’ARN de la clé KMS avec l’option --kms-key-arn.

aws lambda create-event-source-mapping --function-name my-function \ --maximum-batching-window-in-seconds 60 \ --event-source-arn arn:aws:sqs:us-east-1:123456789012:my-queue \ --filter-criteria "{\"filters\": [{\"pattern\": \"{\"a\": [\"1\", \"2\"]}\" }]}" \ --kms-key-arn arn:aws:kms:us-east-1:123456789012:key/055efbb4-xmpl-4336-ba9c-538c7d31f599

Si vous disposez déjà d’un mappage des sources d’événements, utilisez plutôt la commande UpdateEventSourceMapping de l’AWS CLI. Spécifiez l’ARN de la clé KMS avec l’option --kms-key-arn.

aws lambda update-event-source-mapping --function-name my-function \ --maximum-batching-window-in-seconds 60 \ --event-source-arn arn:aws:sqs:us-east-1:123456789012:my-queue \ --filter-criteria "{\"filters\": [{\"pattern\": \"{\"a\": [\"1\", \"2\"]}\" }]}" \ --kms-key-arn arn:aws:kms:us-east-1:123456789012:key/055efbb4-xmpl-4336-ba9c-538c7d31f599

Cette opération remplace toute clé KMS précédemment spécifiée. Si vous spécifiez l’option --kms-key-arn avec un argument vide, Lambda cesse d’utiliser votre clé KMS pour chiffrer les critères de filtre. Au lieu de cela, Lambda revient par défaut à l’utilisation d’une clé appartenant à Amazon.

Pour spécifier votre propre clé KMS dans un modèle AWS CloudFormation, utilisez la propriété KMSKeyArn du type de ressource AWS::Lambda::EventSourceMapping. Par exemple, vous pouvez insérer l’extrait de code suivant dans le modèle YAML de votre source d’événement.

MyEventSourceMapping: Type: AWS::Lambda::EventSourceMapping Properties: ... FilterCriteria: Filters: - Pattern: '{"a": [1, 2]}' KMSKeyArn: "arn:aws:kms:us-east-1:123456789012:key/055efbb4-xmpl-4336-ba9c-538c7d31f599" ...

Pour pouvoir afficher vos critères de filtre chiffrés en texte brut dans un appel d’API GetEventSourceMapping ou DeleteEventSourceMapping, vous devez disposer des autorisations kms:Decrypt.

À compter du 6 août 2024, le champ FilterCriteria n’apparaît plus dans les journaux AWS CloudTrail des appels d’API CreateEventSourceMapping, UpdateEventSourceMapping et DeleteEventSourceMapping si votre fonction n’utilise pas le filtrage des événements. Si votre fonction utilise le filtrage des événements, le champ FilterCriteria apparaît vide ({}). Vous pouvez toujours afficher vos critères de filtre en texte brut en réponse aux appels d’API GetEventSourceMapping si vous disposez des autorisations kms:Decrypt pour la bonne clé KMS.

Dans l’exemple d’entrée de journal AWS CloudTrail suivant pour un appel à CreateEventSourceMapping, FilterCriteria apparaît sous vide ({}), car la fonction utilise le filtrage des événements. C’est le cas même si l’objet FilterCriteria contient des critères de filtre valides que votre fonction utilise activement. Si la fonction n’utilise pas le filtrage des événements, CloudTrail n’affichera pas du tout le champ FilterCriteria dans les entrées du journal.

{ "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:userid1", "arn": "arn:aws:sts::123456789012:assumed-role/Example/example-role", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA987654321EXAMPLE", "arn": "arn:aws:iam::123456789012:role/User1", "accountId": "123456789012", "userName": "User1" }, "webIdFederationData": {}, "attributes": { "creationDate": "2024-05-09T20:35:01Z", "mfaAuthenticated": "false" } }, "invokedBy": "AWS Internal" }, "eventTime": "2024-05-09T21:05:41Z", "eventSource": "lambda.amazonaws.com", "eventName": "CreateEventSourceMapping20150331", "awsRegion": "us-east-2", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "eventSourceArn": "arn:aws:sqs:us-east-2:123456789012:example-queue", "functionName": "example-function", "enabled": true, "batchSize": 10, "filterCriteria": {}, "kMSKeyArn": "arn:aws:kms:us-east-2:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "scalingConfig": {}, "maximumBatchingWindowInSeconds": 0, "sourceAccessConfigurations": [] }, "responseElements": { "uUID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "batchSize": 10, "maximumBatchingWindowInSeconds": 0, "eventSourceArn": "arn:aws:sqs:us-east-2:123456789012:example-queue", "filterCriteria": {}, "kMSKeyArn": "arn:aws:kms:us-east-2:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:example-function", "lastModified": "May 9, 2024, 9:05:41 PM", "state": "Creating", "stateTransitionReason": "USER_INITIATED", "functionResponseTypes": [], "eventSourceMappingArn": "arn:aws:lambda:us-east-2:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb" }, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "sessionCredentialFromConsole": "true" }

Dans l’exemple d’entrée de journal AWS CloudTrail suivant pour un appel à CreateEventSourceMapping, FilterCriteria apparaît sous vide ({}), car la fonction utilise le filtrage des événements. C’est le cas même si l’objet FilterCriteria contient des critères de filtre valides que votre fonction utilise activement. Si la fonction n’utilise pas le filtrage des événements, CloudTrail n’affichera pas du tout le champ FilterCriteria dans les entrées du journal.

{ "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:userid1", "arn": "arn:aws:sts::123456789012:assumed-role/Example/example-role", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA987654321EXAMPLE", "arn": "arn:aws:iam::123456789012:role/User1", "accountId": "123456789012", "userName": "User1" }, "webIdFederationData": {}, "attributes": { "creationDate": "2024-05-09T20:35:01Z", "mfaAuthenticated": "false" } }, "invokedBy": "AWS Internal" }, "eventTime": "2024-05-09T21:05:41Z", "eventSource": "lambda.amazonaws.com", "eventName": "CreateEventSourceMapping20150331", "awsRegion": "us-east-2", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "eventSourceArn": "arn:aws:sqs:us-east-2:123456789012:example-queue", "functionName": "example-function", "enabled": true, "batchSize": 10, "filterCriteria": {}, "kMSKeyArn": "arn:aws:kms:us-east-2:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "scalingConfig": {}, "maximumBatchingWindowInSeconds": 0, "sourceAccessConfigurations": [] }, "responseElements": { "uUID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "batchSize": 10, "maximumBatchingWindowInSeconds": 0, "eventSourceArn": "arn:aws:sqs:us-east-2:123456789012:example-queue", "filterCriteria": {}, "kMSKeyArn": "arn:aws:kms:us-east-2:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:example-function", "lastModified": "May 9, 2024, 9:05:41 PM", "state": "Creating", "stateTransitionReason": "USER_INITIATED", "functionResponseTypes": [], "eventSourceMappingArn": "arn:aws:lambda:us-east-2:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb" }, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "sessionCredentialFromConsole": "true" }

Utilisation de filtres avec des Services AWS différents

Les différents types de sources d’événements utilisent des valeurs clés différentes pour leurs champs de données. Pour filtrer sur les propriétés de données, assurez-vous d’utiliser la bonne clé dans le modèle de votre filtre. Le tableau suivant indique les clés de filtrage pour chaque Service AWS pris en charge.

Service AWS Clé de filtrage
DynamoDB dynamodb
Kinesis data
Amazon MQ data
Amazon MSK value
Self-managed Apache Kafka value
Amazon SQS body

Les sections suivantes donnent des exemples de modèles de filtre pour différents types de sources d’événements. Elles fournissent également des définitions des formats de données entrantes pris en charge et des formats de corps de modèle de filtre pour chaque service pris en charge.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.