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 de sources d'événements pour les éléments suivants : Services AWS

  • 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 différents Services AWS. 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 ORed combinés. 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 la liste des clés de filtrage des données et des exemples de modèles de filtre pris en charge pour chacune d'entre elles Service AWS, reportez-vous àUtilisation de filtres avec différents Services AWS.

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 EventBridge les règles Amazon et utilise la même syntaxe que. EventBridge Pour plus d'informations, consultez les modèles EventBridge d'événements Amazon dans le guide de EventBridge l'utilisateur Amazon.

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 »

« Nom » : [{"equals-ignore-case« : « alice »}]

And

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

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

Ou

PaymentType est « Crédit » ou « Débit »

PaymentType« : [« Crédit », « Débit"]

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« : [{« existe » : vrai}]

N’existe pas

ProductName n'existe pas

ProductName« : [{« existe » : faux}]

Commence par

La région se trouve aux États-Unis

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

Se termine par

FileName se termine par une extension .png.

FileName« : [{« suffixe » : « .png »}]

Note

Comme pour les chaînes EventBridge, Lambda utilise une character-by-character correspondance exacte sans pliage en majuscules ni aucune autre normalisation des chaînes. 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 différents Services AWS.

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 de source d'événements avec ces critères de filtre à l'aide de 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 create-event-source-mappingcommande crée un nouveau mappage de source d'événements Amazon SQS pour la fonction my-function avec la valeur spécifiée. FilterCriteria

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 lors d'un list-event-source-mappingsappel. Lambda renvoie également l'UUID dans la réponse de la CLI. create-event-source-mapping

Pour supprimer les critères de filtre d'une source d'événement, vous pouvez exécuter la update-event-source-mappingcommande suivante avec un FilterCriteria objet 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 du AWS CLI, voirUtilisation de filtres avec différents Services AWS.

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

Supposons que vous souhaitiez configurer une source d'événements 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 AWS SAM modèle pour un mappage de sources d'événements, consultez la EventSourcesection du guide du AWS SAM développeur. Pour plus d'exemples de création de filtres d'événements à l'aide AWS SAM de modèles, consultezUtilisation de filtres avec différents Services AWS.

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.

Une fois que vous avez chiffré votre objet de critères de filtre, vous pouvez afficher sa version en texte brut à l'aide d'un appel d'GetEventSourceMappingAPI. 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 FilterCriteria champ dans la réponse aux appels. ListEventSourceMappings Ce champ s’affiche plutôt sous la forme null. Pour connaître la vraie valeur deFilterCriteria, utilisez l'GetEventSourceMappingAPI.

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. Vous n'avez pas besoin d'inclure EventSourceArn les sources d'événements Kafka autogérées car elles n'ont pas de. EventSourceArn

  • kms:Decrypt— Doit également être accordé au principal qui a l'intention d'utiliser la clé pour afficher les critères de filtrage en texte brut dans les appels GetEventSourceMappingd'DeleteEventSourceMappingAPI.

  • 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 l'utiliser AWS CloudTrail pour suivre les AWS KMS demandes que Lambda effectue en votre nom. Pour des exemples CloudTrail d'événements, voirSurveillance 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 AWS KMS politique clé
{ "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 CreateEventSourceMapping AWS CLI commande 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 de source d'événements, utilisez plutôt la UpdateEventSourceMapping AWS CLI commande. 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 AWS CloudFormation modèle, utilisez la KMSKeyArn propriété du type de AWS::Lambda::EventSourceMapping ressource. 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 clair dans un appel d'DeleteEventSourceMappingAPI GetEventSourceMappingou un appel d'API, vous devez disposer d'kms:Decryptautorisations.

À compter du 6 août 2024, le FilterCriteria champ n'apparaît plus dans les AWS CloudTrail journaux provenant de CreateEventSourceMappinget dans UpdateEventSourceMappingles appels d'DeleteEventSourceMappingAPI 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 clair en réponse aux appels d'GetEventSourceMappingAPI si vous êtes autorisé à kms:Decrypt utiliser la bonne clé KMS.

Dans l' AWS CloudTrail exemple d'entrée de journal suivant pour un CreateEventSourceMapping appel, FilterCriteria apparaît comme 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, le FilterCriteria champ CloudTrail n'apparaîtra pas du tout 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' AWS CloudTrail exemple d'entrée de journal suivant pour un CreateEventSourceMapping appel, FilterCriteria apparaît comme 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, le FilterCriteria champ CloudTrail n'apparaîtra pas du tout 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 différents Services AWS

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 chacune des clés prises en charge Service AWS.

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.