Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet

Sie können die Ereignisfilterung verwenden, um zu steuern, welche Datensätze aus einem Stream oder einer Warteschlange Lambda an Ihre Funktion sendet. Sie können zum Beispiel einen Filter hinzufügen, damit Ihre Funktion nur Amazon-SQS-Nachrichten verarbeitet, die bestimmte Datenparameter enthalten. Die Ereignisfilterung funktioniert nur mit der bestimmten Zuordnung von Ereignisquellen. Sie können den Zuordnungen von Ereignisquellen Filter für Folgendes hinzufügen: AWS-Services

• Amazon-DynamoDB

• Amazon Kinesis Data Streams

• Amazon MQ

• Amazon Managed Streaming for Apache Kafka (Amazon MSK)

• Selbstverwaltetes Apache Kafka

• Amazon-Simple-Queue-Service (Amazon SQS)

Spezifische Informationen zum Filtern mit bestimmten Ereignisquellen finden Sie unter Verwenden von Filtern mit unterschiedlichen AWS-Services. Lambda unterstützt keine Ereignisfilterung für Amazon DocumentDB.

Standardmäßig können Sie bis zu fünf verschiedene Filter für eine einzelne Zuordnung von Ereignisquellen definieren. Ihre Filter gehören logisch ORed zusammen. Wenn ein Datensatz aus Ihrer Ereignisquelle einen oder mehrere Ihrer Filter erfüllt, nimmt Lambda den Datensatz in das nächste Ereignis auf, das es an Ihre Funktion sendet. Wenn keiner Ihrer Filter erfüllt ist, verwirft Lambda den Datensatz.

Anmerkung

Wenn Sie mehr als fünf Filter für eine Ereignisquelle definieren müssen, können Sie eine Kontingenterhöhung auf bis zu 10 Filter für jede Ereignisquelle beantragen. Wenn Sie versuchen, mehr Filter hinzuzufügen, als Ihr aktuelles Kontingent erlaubt, wird Lambda einen Fehler zurückgeben, wenn Sie versuchen, die Ereignisquelle zu erstellen.

Grundlagen der Ereignisfilterung verstehen

Ein Filterkriterienobjekt (FilterCriteria) ist eine Struktur, die aus einer Liste von Filtern (Filters) besteht. Jeder Filter ist eine Struktur, die ein Ereignisfiltermuster (Pattern) definiert. Ein Muster ist eine Zeichenkette, die eine JSON-Filterregel darstellt. Die Struktur eines FilterCriteria-Objekts ist wie folgt.

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

Zur Verdeutlichung sehen Sie hier den Wert des Filter-Pattern in reinem JSON.

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

Ihr Filtermuster kann Metadateneigenschaften, Dateneigenschaften oder beides enthalten. Die verfügbaren Metadaten-Parameter und das Format der Daten-Parameter variieren je nach dem AWS-Service , der als Ereignisquelle fungiert. Nehmen wir zum Beispiel an, dass Ihre Zuordnung von Ereignisquellen den folgenden Datensatz von einer Amazon-SQS-Warteschlange empfängt:

{
    "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"
}

• Metadateneigenschaften sind die Felder, die Informationen über das Ereignis enthalten, das den Datensatz erstellt hat. Im Beispiel für den Amazon-SQS-Datensatz umfassen die Metadateneigenschaften Felder wie messageID, eventSourceArn und awsRegion.

• Dateneigenschaften sind die Felder des Datensatzes, die die Daten aus Ihrem Stream oder Ihrer Warteschlange enthalten. Im Amazon-SQS-Ereignisbeispiel ist der Schlüssel für das Datenfeld body, und die Dateneigenschaften sind die Felder City, State und Temperature.

Verschiedene Arten von Ereignisquellen verwenden unterschiedliche Schlüsselwerte für ihre Datenfelder. Um nach Dateneigenschaften zu filtern, müssen sie den richtigen Schlüssel in Ihrem Filtermuster verwenden. Eine Liste der Datenfilterschlüssel und Beispiele für Filtermuster für die einzelnen unterstützten AWS-Service Schlüssel finden Sie Verwenden von Filtern mit unterschiedlichen AWS-Services unter.

Die Ereignisfilterung kann mehrstufige JSON-Filterung verarbeiten. Betrachten Sie zum Beispiel das folgende Fragment eines Datensatzes aus einem DynamoDB-Stream:

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

Angenommen, Sie möchten nur die Datensätze verarbeiten, bei denen die Number des Sortierschlüssels 4567 ist. In diesem Fall würde Ihr FilterCriteria-Objekt wie folgt aussehen:

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

Zur Verdeutlichung sehen Sie hier den Wert des Filter-Pattern in reinem JSON.

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

Umgang mit Datensätzen, die die Filterkriterien nicht erfüllen

Die Art und Weise, wie Lambda mit Datensätzen umgeht, die Ihren Filterkriterien nicht entsprechen, hängt von der Ereignisquelle ab.

• Bei Amazon SQS entfernt Lambda die Nachricht automatisch aus der Warteschlange, wenn die Nachricht Ihren Filterkriterien nicht entspricht. Sie müssen diese Nachrichten in Amazon SQS nicht manuell löschen.

• Bei Kinesis und DynamoDB schreitet der Stream-Iterator nach der Auswertung eines Datensatzes durch Ihre Filterkriterien über diesen Datensatz hinaus. Wenn der Datensatz Ihre Filterkriterien nicht erfüllt, müssen Sie den Datensatz nicht manuell aus Ihrer Ereignisquelle löschen. Nach Ablauf der Aufbewahrungsfrist löschen Kinesis und DynamoDB diese alten Datensätze automatisch. Wenn Sie möchten, dass Datensätze früher gelöscht werden, lesen Sie Ändern des Zeitraums der Datenaufbewahrung.

• Bei Amazon MSK-, selbstverwalteten Apache-Kafka- und Amazon MQ-Nachrichten verwirft Lambda Nachrichten, die nicht allen im Filter enthaltenen Feldern entsprechen. Bei Amazon MSK und selbstverwaltetem Apache Kafka schreibt Lambda Offsets für übereinstimmende und nicht übereinstimmende Nachrichten fest, nachdem die Funktion erfolgreich aufgerufen wurde. Bei Amazon MQ bestätigt Lambda übereinstimmende Nachrichten nach erfolgreichem Aufruf der Funktion und bestätigt nicht übereinstimmende Nachrichten beim Filtern.

Filterregelsyntax

Für Filterregeln unterstützt Lambda die EventBridge Amazon-Regeln und verwendet dieselbe Syntax wie EventBridge. Weitere Informationen finden Sie unter Amazon EventBridge Event Patterns im EventBridge Amazon-Benutzerhandbuch.

Im Folgenden finden Sie eine Zusammenfassung aller Vergleichsoperatoren, die für die Lambda-Ereignisfilterung verfügbar sind.

Vergleichsoperator	Beispiel	Regelsyntax
Null	UserID is null	"UserID": [ null ]
Leer	LastName ist leer	"LastName": [""]
Gleichheitszeichen	Name is "Alice"	"Name": [ "Alice" ]
Gleich (Groß-/Kleinschreibung ignorieren)	Name is "Alice"	„Name“: [{"equals-ignore-case„: „Alice“}]
And	Location is "New York" and Day is "Monday"	"Location": [ "New York" ], "Day": ["Monday"]
Oder	PaymentType ist „Kredit“ oder „Lastschrift“	"PaymentType„: [„Kredit“, „Lastschrift"]
Oder (mehrere Felder)	Location is "New York", or Day is "Monday".	"$or": [ { "Location": [ "New York" ] }, { "Day": [ "Monday" ] } ]
Nicht	Weather is anything but "Raining"	"Weather": [ { "anything-but": [ "Raining" ] } ]
Numeric (equals)	Price is 100	"Price": [ { "numeric": [ "=", 100 ] } ]
Numeric (range)	Price is more than 10, and less than or equal to 20	"Price": [ { "numeric": [ ">", 10, "<=", 20 ] } ]
Vorhanden	ProductName existiert	"ProductName„: [{„existiert“: wahr}]
Nicht vorhanden	ProductName existiert nicht	"ProductName„: [{„existiert“: falsch}]
Beginnt mit	Region is in the US	"Region": [ {"prefix": "us-" } ]
Endet mit	FileName endet mit der Erweiterung.png.	"FileName„: [{„Suffix“: „.png“}]

Anmerkung

Wie bei EventBridge Zeichenketten verwendet Lambda den exakten character-by-character Abgleich ohne Umschaltung der Groß- und Kleinschreibung oder eine andere Normalisierung von Zeichenketten. Bei Zahlen verwendet Lambda auch eine Zeichenfolgendarstellung. 300, 300,0 und 3,0e2 werden z. B. nicht gleich behandelt.

Beachten Sie, dass der Exists-Operator nur für Blattknoten in Ihrer JSON-Ereignisquelle funktioniert. Es passt nicht zu Zwischenknoten. Bei der folgenden JSON-Datei { "person": { "address": [ { "exists": true } ] } }" würde das Filtermuster beispielsweise keine Übereinstimmung finden, da es sich um einen Zwischenknoten "address" handelt.

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

Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (Konsole)

Führen Sie diese Schritte aus, um eine neue Ereignisquellenzuordnung mit Filterkriterien über die Lambda-Konsole zu erstellen.

Eine neue Ereignisquellenzuordnung mit Filterkriterien erstellen (Konsole)

1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

2. Wählen Sie den Namen einer Funktion aus, für die eine Ereignisquellenzuordnung erstellt werden soll.

3. Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).

4. Wählen Sie bei Trigger configuration (Auslöserkonfiguration) einen Auslösertyp aus, der Ereignisfilterung unterstützt. Eine Liste der unterstützten Services finden Sie in der Liste am Anfang dieser Seite.

5. Erweitern Sie Additional settings (Zusätzliche Einstellungen).

6. Wählen Sie unter Filter criteria (Filterkriterien) die Option Add (Hinzufügen) aus und definieren Sie anschließend Ihre Filter. Sie können z. B. Folgendes eingeben.

   { "Metadata" : [ 1, 2 ] }

   Damit wird Lambda angewiesen, nur Datensätze zu verarbeiten, in denen das Feld Metadata gleich 1 oder 2 ist. Sie können weiterhin Hinzufügen auswählen, um weitere Filter bis zur maximal zulässigen Anzahl hinzuzufügen.

7. Wenn Sie fertig mit dem Hinzufügen Ihrer Filter sind, klicken Sie auf Speichern.

Wenn Sie Filterkriterien über die Konsole eingeben, geben Sie nur das Filtermuster ein und müssen weder den Pattern-Schlüssel noch Escape-Anführungszeichen angeben. In Schritt 6 der Anweisungen oben entspricht { "Metadata" : [ 1, 2 ] } den folgenden FilterCriteria.

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

Nachdem Sie Ihre Ereignisquellenzuordnung in der Konsole erstellt haben, sehen Sie die formatierten FilterCriteria in den Auslöserdetails. Weitere Beispiele zum Erstellen von Ereignisfiltern mithilfe der -Konsole finden Sie unter Verwenden von Filtern mit unterschiedlichen AWS-Services.

Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (AWS CLI)

Angenommen, Sie möchten, dass eine Ereignisquellenzuordnung folgende hat FilterCriteria:

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

Führen Sie den folgenden Befehl aus, um mithilfe der AWS Command Line Interface (AWS CLI) eine neue Zuordnung der Ereignisquelle mit diesen Filterkriterien zu erstellen.

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 ]}"}]}'

Dieser create-event-source-mappingBefehl erstellt eine neue Amazon SQS SQS-Ereignisquellenzuordnung für eine Funktion my-function mit dem angegebenen FilterCriteria Wert.

Führen Sie den folgenden Befehl aus, um diese Filterkriterien zu einer vorhandenen Zuordnung von Ereignisquellen hinzuzufügen.

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

Beachten Sie, dass Sie zum Aktualisieren einer Ereignisquellenzuordnung ihre UUID benötigen. Sie können die UUID aus einem Anruf abrufen. list-event-source-mappings Lambda gibt auch die UUID in der CLI-Antwort zurück. create-event-source-mapping

Um Filterkriterien aus einer Ereignisquelle zu entfernen, können Sie den folgenden update-event-source-mappingBefehl mit einem leeren Objekt ausführen. FilterCriteria

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

Weitere Beispiele für das Erstellen von Ereignisfiltern mithilfe von finden Sie unterVerwenden von Filtern mit unterschiedlichen AWS-Services. AWS CLI

Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (AWS SAM)

Angenommen, Sie möchten eine Ereignisquelle so konfigurieren AWS SAM , dass sie die folgenden Filterkriterien verwendet:

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

Um diese Filterkriterien zu Ihrer Zuordnung von Ereignisquellen hinzuzufügen, fügen Sie das folgende Snippet in die YAML-Vorlage für Ihre Ereignisquelle ein.

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

Weitere Informationen zum Erstellen und Konfigurieren einer AWS SAM Vorlage für eine Ereignisquellenzuordnung finden Sie im EventSourceAbschnitt des AWS SAM Entwicklerhandbuchs. Weitere Beispiele für die Erstellung von Ereignisfiltern mithilfe von AWS SAM Vorlagen finden Sie unterVerwenden von Filtern mit unterschiedlichen AWS-Services.

Verschlüsselung der Filterkriterien

Standardmäßig verschlüsselt Lambda Ihr Filterkriterienobjekt nicht. In Anwendungsfällen, in denen Sie vertrauliche Informationen in Ihr Filterkriterienobjekt aufnehmen können, können Sie diese mit Ihrem eigenen KMS-Schlüssel verschlüsseln.

Nachdem Sie Ihr Filterkriterienobjekt verschlüsselt haben, können Sie seine Klartextversion mithilfe eines GetEventSourceMappingAPI-Aufrufs anzeigen. Sie müssen über kms:Decrypt-Berechtigungen verfügen, um die Filterkriterien im Klartext anzeigen zu können.

Anmerkung

Wenn Ihr Filterkriterienobjekt verschlüsselt ist, redigiert Lambda den Wert des FilterCriteria Felds in der ListEventSourceMappingsAntwort auf Aufrufe. Stattdessen wird dieses Feld als null angezeigt. Verwenden Sie die APIFilterCriteria, um den wahren Wert von zu ermitteln. GetEventSourceMapping

Um den entschlüsselten Wert von FilterCriteria in der Konsole anzuzeigen, stellen Sie sicher, dass Ihre IAM-Rolle Berechtigungen für enthält. GetEventSourceMapping

Sie können Ihren eigenen KMS-Schlüssel über die Konsole, API/CLI oder AWS CloudFormation angeben.

Um Filterkriterien mit einem kundeneigenen KMS-Schlüssel zu verschlüsseln (Konsole)

1. Öffnen Sie die Seite Funktionen der Lambda-Konsole.

2. Wählen Sie Add trigger. Wenn Sie bereits über einen vorhandenen Trigger verfügen, wählen Sie die Registerkarte Konfiguration und dann Trigger aus. Wählen Sie den vorhandenen Auslöser aus und klicken Sie auf Edit (Bearbeiten).

3. Aktivieren Sie das Kontrollkästchen neben Mit dem vom Kunden verwalteten KMS-Schlüssel verschlüsseln.

4. Wählen Sie für Wählen Sie einen vom Kunden verwalteten KMS-Verschlüsselungsschlüssel einen vorhandenen aktivierten Schlüssel aus oder erstellen Sie einen neuen Schlüssel. Je nach Vorgang benötigen Sie einige oder alle der folgenden Berechtigungen: kms:DescribeKey, kms:GenerateDataKey und kms:Decrypt. Verwenden Sie die KMS-Schlüsselrichtlinie, um diese Berechtigungen zu gewähren.

Wenn Sie Ihren eigenen KMS-Schlüssel verwenden, müssen die folgenden API-Vorgänge in der Schlüsselrichtlinie zugelassen sein:

• kms:Decrypt – Muss dem regionalen Lambda-Serviceprinzipal gewährt werden (lambda.AWS_region.amazonaws.com). Dies ermöglicht Lambda die Entschlüsselung von Daten mit diesem KMS-Schlüssel.

  • Um ein dienstübergreifendes Problem mit verwirrten Stellvertretern zu vermeiden, verwendet die Schlüsselrichtlinie den aws:SourceArn globalen Bedingungsschlüssel. Der richtige Wert des aws:SourceArn-Schlüssels ist der ARN Ihrer Ressource für die Zuordnung von Ereignisquellen. Sie können ihn also erst dann zu Ihrer Richtlinie hinzufügen, wenn Sie den ARN kennen. Lambda leitet auch die aws:lambda:FunctionArn- und aws:lambda:EventSourceArn-Schlüssel und ihre jeweiligen Werte im Verschlüsselungskontext weiter, wenn eine Entschlüsselungsanforderung an KMS gestellt wird. Diese Werte müssen den in der Schlüsselrichtlinie angegebenen Bedingungen entsprechen, damit die Entschlüsselungsanforderung erfolgreich ist. EventSourceArn Für selbstverwaltete Kafka-Ereignisse müssen Sie keine Quellen angeben, da sie keine haben. EventSourceArn

• kms:Decrypt— Muss auch dem Prinzipal gewährt werden, der beabsichtigt, den Schlüssel zur Anzeige der Klartext-Filterkriterien in GetEventSourceMappingunseren API-Aufrufen zu verwenden. DeleteEventSourceMapping

• kms:DescribeKey – Stellt die vom Kunden verwalteten Schlüsseldetails bereit, um dem angegebenen Prinzipal die Verwendung des Schlüssels zu ermöglichen.

• kms:GenerateDataKey – Ermöglicht Lambda die Generierung eines Datenschlüssels zur Verschlüsselung der Filterkriterien im Namen des angegebenen Prinzipals (Umschlagverschlüsselung).

Sie können AWS CloudTrail damit AWS KMS Anfragen verfolgen, die Lambda in Ihrem Namen stellt. CloudTrail Beispielereignisse finden Sie unterÜberwachen Ihrer Verschlüsselungsschlüssel für Lambda.

Wir empfehlen außerdem, den kms:ViaService-Bedingungsschlüssel zu verwenden, um die Verwendung des KMS-Schlüssels nur auf Anfragen von Lambda zu beschränken. Der Wert dieses Schlüssels ist der regionale Lambda-Serviceprinzipal (lambda.AWS_region.amazonaws.com). Im Folgenden finden Sie ein Beispiel für eine Schlüsselrichtlinie, die alle relevanten Berechtigungen gewährt:

Beispiel AWS KMS wichtige Richtlinie

{
    "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"
                }
            }
        }
    ]
}

Um Ihren eigenen KMS-Schlüssel zum Verschlüsseln von Filterkriterien zu verwenden, können Sie auch den folgenden CreateEventSourceMapping AWS CLI Befehl verwenden. Geben Sie den KMS-Schlüssel ARN mit dem --kms-key-arn-Flag an.

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

Wenn Sie bereits über eine Ereignisquellenzuordnung verfügen, verwenden Sie stattdessen den UpdateEventSourceMapping AWS CLI Befehl. Geben Sie den KMS-Schlüssel ARN mit dem --kms-key-arn-Flag an.

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

Dieser Vorgang überschreibt alle zuvor angegebenen KMS-Schlüssel. Wenn Sie das --kms-key-arn-Flag zusammen mit einem leeren Argument angeben, verwendet Lambda Ihren KMS-Schlüssel nicht mehr zum Verschlüsseln von Filterkriterien. Stattdessen verwendet Lambda standardmäßig wieder einen Amazon-eigenen Schlüssel.

Um Ihren eigenen KMS-Schlüssel in einer AWS CloudFormation Vorlage anzugeben, verwenden Sie die KMSKeyArn Eigenschaft des AWS::Lambda::EventSourceMapping Ressourcentyps. Sie können beispielsweise das folgende Snippet in die YAML-Vorlage für Ihre Ereignisquelle einfügen.

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"
    ...

Um Ihre verschlüsselten Filterkriterien in einem GetEventSourceMappingoder DeleteEventSourceMappingAPI-Aufruf im Klartext anzeigen zu können, benötigen Sie entsprechende kms:Decrypt Berechtigungen.

Ab dem 6. August 2024 wird das FilterCriteria Feld nicht mehr in AWS CloudTrail Protokollen von CreateEventSourceMapping, und DeleteEventSourceMappingAPI-Aufrufen angezeigt UpdateEventSourceMapping, wenn Ihre Funktion keine Ereignisfilterung verwendet. Wenn Ihre Funktion die Ereignisfilterung verwendet, wird das FilterCriteria-Feld als leer ({}) angezeigt. Sie können Ihre Filterkriterien in der Antwort auf GetEventSourceMappingAPI-Aufrufe weiterhin im Klartext anzeigen, wenn Sie über kms:Decrypt Berechtigungen für den richtigen KMS-Schlüssel verfügen.

Beispiel für einen CloudTrail Protokolleintrag für Anrufe Create/Update/DeleteEventSourceMapping

Im folgenden AWS CloudTrail Beispiel wird ein Protokolleintrag für einen CreateEventSourceMapping Anruf als leer ({}) FilterCriteria angezeigt, da die Funktion eine Ereignisfilterung verwendet. Dies ist auch dann der Fall, wenn FilterCriteria-Objekt gültige Filterkriterien enthält, die Ihre Funktion aktiv verwendet. Wenn die Funktion keine Ereignisfilterung verwendet, CloudTrail wird das FilterCriteria Feld in Protokolleinträgen überhaupt nicht angezeigt.

{
    "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"
}

Beispiel für einen CloudTrail Protokolleintrag für Anrufe Create/Update/DeleteEventSourceMapping

Im folgenden AWS CloudTrail Beispiel wird ein Protokolleintrag für einen CreateEventSourceMapping Anruf als leer ({}) FilterCriteria angezeigt, da die Funktion eine Ereignisfilterung verwendet. Dies ist auch dann der Fall, wenn FilterCriteria-Objekt gültige Filterkriterien enthält, die Ihre Funktion aktiv verwendet. Wenn die Funktion keine Ereignisfilterung verwendet, CloudTrail wird das FilterCriteria Feld in Protokolleinträgen überhaupt nicht angezeigt.

{
    "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"
}

Verwenden von Filtern mit unterschiedlichen AWS-Services

Verschiedene Arten von Ereignisquellen verwenden unterschiedliche Schlüsselwerte für ihre Datenfelder. Um nach Dateneigenschaften zu filtern, müssen sie den richtigen Schlüssel in Ihrem Filtermuster verwenden. In der folgenden Tabelle sind die Filterschlüssel für jeden unterstützten Schlüssel aufgeführt AWS-Service.

AWS-Service	Filterschlüssel
DynamoDB	dynamodb
Kinesis	data
Amazon MQ	data
Amazon MSK	value
Selbstverwaltetes Apache Kafka	value
Amazon SQS	body

In den folgenden Abschnitten finden Sie Beispiele für Filtermuster für verschiedene Arten von Ereignisquellen. Sie enthalten auch Definitionen der unterstützten Formate für eingehende Daten und Filtermuster für jeden unterstützten Service.

• Verwendung der Ereignisfilterung mit einer DynamoDB-Ereignisquelle

• Verwendung der Ereignisfilterung mit einer Kinesis-Ereignisquelle

• Ereignisse aus einer Amazon MQ-Ereignisquelle filtern

• Verwendung der Ereignisfilterung mit einer Amazon MSK-Ereignisquelle

• Ereignisfilterung mit einer selbstverwalteten Apache-Kafka-Ereignisquelle

• Verwendung der Ereignisfilterung mit einer Amazon-SQS-Ereignisquelle