Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet
Ein *Zuordnung von Ereignisquellen* ist eine Lambda-Ressource, die Elemente aus Stream- und Warteschlangen-basierten Diensten liest und eine Funktion mit Stapeln von Datensätzen aufruft. Innerhalb einer Zuordnung von Ereignisquellen fragen Ressourcen, sogenannte *Event-Poller*, aktiv nach neuen Nachrichten ab und rufen Funktionen auf. Standardmäßig skaliert Lambda Ereignisabfragen automatisch, aber für bestimmte Ereignisquellentypen können Sie den [Bereitstellungsmodus](#invocation-eventsourcemapping-provisioned-mode) verwenden, um die Mindest- und Höchstanzahl von Event-Pollern zu steuern, die für Ihre Zuordnung von Ereignisquellen vorgesehen sind.
Die folgenden Dienste verwenden Zuordnungen von Ereignisquellen, um Lambda-Funktionen aufzurufen:
+ [Amazon DocumentDB (mit MongoDB-Kompatibilität) (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)
+ [Selbstverwaltetes Apache Kafka](with-kafka.md)
+ [Amazon-Simple-Queue-Service (Amazon SQS)](with-sqs.md)
**Warnung**
Zuordnung von Lambda-Ereignisquellen verarbeiten jedes Ereignis mindestens einmal und es kann zu einer doppelten Verarbeitung von Datensätzen kommen. Um mögliche Probleme im Zusammenhang mit doppelten Ereignissen zu vermeiden, empfehlen wir Ihnen dringend, Ihren Funktionscode idempotent zu machen. Weitere Informationen finden Sie im Knowledge Center unter [Wie mache ich meine Lambda-Funktion idempotent](https://repost.aws/knowledge-center/lambda-function-idempotent)?. AWS
## Wie unterscheiden sich Zuordnungen von Ereignisquellen von direkten Auslösern
*Einige AWS-Services können Lambda-Funktionen mithilfe von Triggern direkt aufrufen.* Diese Dienste leiten Ereignisse an Lambda weiter und die Funktion wird sofort aufgerufen, wenn das angegebene Ereignis eintritt. Trigger eignen sich für diskrete Ereignisse und die Verarbeitung in Echtzeit. Wenn Sie [mit der Lambda-Konsole einen Trigger erstellen](lambda-services.md#lambda-invocation-trigger), interagiert die Konsole mit dem entsprechenden AWS Dienst, um die Ereignisbenachrichtigung für diesen Dienst zu konfigurieren. Der Auslöser wird tatsächlich von dem Dienst gespeichert und verwaltet, der die Ereignisse generiert, nicht von Lambda. Hier sind einige Beispiele für Dienste, die Auslöser zum Aufrufen von Lambda-Funktionen verwenden:
+ **Amazon Simple Storage Service (Amazon S3):** Ruft eine Funktion auf, wenn ein Objekt in einem Bucket erstellt, gelöscht oder geändert wird. Weitere Informationen finden Sie unter [Tutorial: Verwenden eines Amazon-S3-Auslösers zum Aufrufen einer Lambda-Funktion](with-s3-example.md).
+ **Amazon Simple Notification Service (Amazon SNS):** Ruft eine Funktion auf, wenn eine Nachricht in einem SNS-Thema veröffentlicht wird. Weitere Informationen finden Sie unter [Tutorial: Verwendung AWS Lambda mit Amazon Simple Notification Service](with-sns-example.md).
+ **Amazon API Gateway:** Ruft eine Funktion auf, wenn eine API-Anfrage an einen bestimmten Endpunkt gestellt wird. Weitere Informationen finden Sie unter [Aufrufen einer Lambda-Funktion über einen Amazon API Gateway-Endpunkt](services-apigateway.md).
Zuordnungen von Ereignisquellen sind Lambda-Ressourcen, die innerhalb des Lambda-Service erstellt und verwaltet werden. Zuordnungen von Ereignisquellen sind für die Verarbeitung umfangreicher Streaming-Daten oder Nachrichten aus Warteschlangen konzipiert. Die stapelweise Verarbeitung von Datensätzen aus einem Stream oder einer Warteschlange ist effizienter als die Verarbeitung einzelner Datensätze.
## Batching-Verhalten
Standardmäßig batcht eine Ereignisquellenzuordnung Datensätze in einer einzigen Nutzlast, die Lambda an Ihre Funktion sendet. Um das Batching-Verhalten zu optimieren, können Sie ein Batching-Fenster ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) und eine Batch-Größe ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize)) konfigurieren. Ein Batch-Fenster ist die maximale Zeitspanne zur Erfassung von Datensätzen in einer einzigen Nutzlast. Eine Batch-Größe ist die maximale Anzahl von Datensätzen in einem einzigen Batch. Lambda ruft Ihre Funktion auf, wenn eines der folgenden drei Kriterien erfüllt ist:
+ **Das Batching-Fenster erreicht seinen Maximalwert.** Das standardmäßige Batch-Fensterverhalten unterscheidet sich je nach Ereignisquelle.
+ **Für Kinesis-, DynamoDB- und Amazon SQS SQS-Ereignisquellen:** Das Standard-Batch-Fenster beträgt 0 Sekunden. Das bedeutet, dass Lambda Ihre Funktion aufruft, sobald Datensätze verfügbar sind. Um ein Batching-Fenster festzulegen, konfigurieren Sie `MaximumBatchingWindowInSeconds`. Sie können diesen Parameter auf einen beliebigen Wert zwischen 0 und 300 Sekunden in Schritten von 1 Sekunde einstellen. Wenn Sie ein Stapelverarbeitungsfenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Funktionsaufruf abgeschlossen ist.
+ **Für Amazon-MSK-, selbstverwaltete Apache-Kafka-, Amazon-MQ- und Amazon-DocumentDB-Ereignisquellen:** Das standardmäßige Batching-Fenster beträgt 500 ms. Sie können `MaximumBatchingWindowInSeconds` auf einen beliebigen Wert von 0 Sekunden bis 300 Sekunden in Sekundenschritten einstellen. Wenn Sie im Bereitstellungsmodus für Kafka-Zuordnungen von Ereignisquellen ein Batching-Fenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Batch abgeschlossen ist. Wenn Sie ein Batching-Fenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Funktionsaufruf abgeschlossen ist. Um die Latenz bei der Verwendung von Kafka-Zuordnungen von Ereignisquellen im Bereitstellungsmodus zu minimieren, setzen Sie `MaximumBatchingWindowInSeconds` auf 0. Diese Einstellung stellt sicher, dass Lambda unmittelbar nach Abschluss des aktuellen Funktionsaufrufs mit der Verarbeitung des nächsten Batches beginnt. Weitere Informationen zur Verarbeitung mit niedriger Latenz finden Sie unter [Niedrige Latenz für Apache-Kafka](with-kafka-low-latency.md).
+ **Für die Ereignisquellen Amazon MQ und Amazon DocumentDB:** Das standardmäßige Batching-Fenster beträgt 500 ms. Sie können `MaximumBatchingWindowInSeconds` auf einen beliebigen Wert von 0 Sekunden bis 300 Sekunden in Sekundenschritten einstellen. Ein Batch-Fenster beginnt, sobald der erste Datensatz eintrifft.
**Anmerkung**
Da Sie `MaximumBatchingWindowInSeconds` nur in Sekundenschritten ändern können, können Sie nicht zu dem Standard-Batch-Fenster von 500 ms zurückkehren, nachdem Sie es geändert haben. Um das Standard-Batch-Fenster wiederherzustellen, müssen Sie eine neue Ereignisquellenzuordnung erstellen.
+ **Die Batch-Größe wird erreicht.** Die minimale Batch-Größe beträgt 1. Die Standard- und die maximale Batch-Größe hängen von der Ereignisquelle ab. Weitere Informationen zu diesen Werten finden Sie unter [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize)-Spezifikation für die `CreateEventSourceMapping`-API-Operation.
+ **Die Nutzlastgröße erreicht [6 MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).** Sie können dieses Limit nicht ändern.
Das folgende Diagramm verdeutlicht diese Bedingungen. Angenommen, ein Batch-Fenster beginnt bei `t = 7` Sekunden. Im ersten Szenario erreicht das Batch-Fenster sein Maximum von 40 Sekunden bei `t = 47` Sekunden nach dem Erfassen von 5 Datensätzen. Im zweiten Szenario erreicht die Batch-Größe 10, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster früh endet. Im dritten Szenario wird die maximale Nutzlastgröße erreicht, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster frühzeitig endet.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/batching-window.png)
Wir empfehlen Ihnen, mit verschiedenen Stapel- und Datensatzgrößen zu testen, damit die Abfragefrequenz jeder Ereignisquelle darauf abgestimmt ist, wie schnell Ihre Funktion ihre Aufgabe erledigen kann. Der [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)`BatchSize`Parameter steuert die maximale Anzahl von Datensätzen, die bei jedem Aufruf an Ihre Funktion gesendet werden können. Eine höhere Stapelgröße kann den mit dem Aufruf-Overhead über eine größere Datensatzgruppe hinweg oft effizienter verarbeiten und Ihren Durchsatz erhöhen.
Lambda wartet mit dem Senden des nächsten zu verarbeitenden Stapels nicht, bis ggf. konfigurierte [Erweiterungen](lambda-extensions.md) abgeschlossen sind. Anders ausgedrückt: Ihre Erweiterungen werden möglicherweise weiter ausgeführt, während Lambda den nächsten Stapel von Datensätzen verarbeitet. Dies kann zu Drosselungsproblemen führen, wenn Sie gegen eine Einstellung oder gegen einen Grenzwert im Zusammenhang mit der [Parallelität](lambda-concurrency.md) Ihres Kontos verstoßen. Um zu erkennen, ob möglicherweise ein Problem vorliegt, müssen Sie Ihre Funktionen überwachen sowie überprüfen, ob für Ihre Zuordnung von Ereignisquellen unerwartet hohe [Parallelitätsmetriken](monitoring-concurrency.md#general-concurrency-metrics) vorliegen. Aufgrund der kurzen Zeit zwischen den Aufrufen kann Lambda kurzzeitig eine höhere Gleichzeitigkeitsnutzung als die Anzahl der Shards melden. Dies kann sogar für Lambda-Funktionen ohne Erweiterungen gelten.
Wenn Ihre Funktion einen Fehler zurückgibt, verarbeitet die Ereignisquellenzuordnung standardmäßig das gesamte Batch erneut, bis die Funktion erfolgreich ist oder die Elemente im Batch ablaufen. Um eine ordnungsgemäße Verarbeitung zu gewährleisten, unterbricht die Ereignisquellenzuordnung die Verarbeitung für den betroffenen Shard, bis der Fehler behoben ist. Für Stream-Quellen (DynamoDB und Kinesis) können Sie die maximale Anzahl von Wiederholungsversuchen von Lambda konfigurieren, wenn Ihre Funktion einen Fehler zurückgibt. Service-Fehler oder Drosselungen, bei denen der Stapel Ihre Funktion nicht erreicht, zählen nicht zu den Wiederholungsversuchen. Sie können die Zuordnung von Ereignisquellen auch so konfigurieren, dass ein Aufrufdatensatz an ein [Ziel](invocation-async-retain-records.md#invocation-async-destinations) gesendet wird, wenn ein Ereignisbatch verworfen wird.
## Modus bereitgestellter Kapazität
Lambda-Ereignisquellenzuordnungen verwenden Ereignisabfragen, um Ihre Ereignisquelle nach neuen Nachrichten abzufragen. Standardmäßig verwaltet Lambda die automatische Skalierung dieser Poller auf der Grundlage des Nachrichtenvolumens. Wenn der Nachrichtenverkehr zunimmt, erhöht Lambda automatisch die Anzahl der Event-Poller, um die Last zu bewältigen und reduziert sie, wenn der Verkehr abnimmt.
Im Bereitstellungsmodus können Sie den Durchsatz Ihrer Ereignisquellenzuordnung feinabstimmen, indem Sie Mindest- und Höchstgrenzen für dedizierte Abfrageressourcen definieren, die bereit sind, die erwarteten Datenverkehrsmuster zu verarbeiten. Diese Ressourcen werden dreimal schneller automatisch skaliert, um plötzliche Spitzen im Ereignisverkehr zu bewältigen, und bieten eine 16-mal höhere Kapazität zur Verarbeitung von Millionen von Ereignissen. Auf diese Weise können Sie reaktionsschnelle ereignisgesteuerte Workloads mit strengen Leistungsanforderungen erstellen.
In Lambda ist ein Event Poller eine Recheneinheit mit Durchsatzmöglichkeiten, die je nach Art der Ereignisquelle variieren. Bei Amazon MSK und selbstverwaltetem Apache Kafka kann jeder Event Poller bis zu 5% MB/sec des Durchsatzes oder bis zu 5 gleichzeitige Aufrufe verarbeiten. Wenn Ihre Ereignisquelle beispielsweise eine durchschnittliche Nutzlast von 1 MB erzeugt und die durchschnittliche Dauer Ihrer Funktion 1 Sekunde beträgt, kann ein einziger Kafka-Event-Poller 5 MB/sec Durchsatz- und 5 gleichzeitige Lambda-Aufrufe unterstützen (vorausgesetzt, es gibt keine Payload-Transformation). Für Amazon SQS kann jeder Event Poller bis zu 1 MB/sec Durchsatz oder bis zu 10 gleichzeitige Aufrufe verarbeiten. Bei der Verwendung des Bereitstellungsmodus fallen zusätzliche Kosten an, die von Ihrer Nutzung des Event-Pollers abhängen. Details zu den Preisen finden Sie unter [AWS Lambda -Preise](https://aws.amazon.com/lambda/pricing/).
Der Bereitstellungsmodus ist für Amazon MSK, selbstverwaltete Apache Kafka- und Amazon SQS SQS-Ereignisquellen verfügbar. Während Sie mit den Gleichzeitigkeitseinstellungen die Skalierung Ihrer Funktion steuern können, haben Sie im Bereitstellungsmodus die Kontrolle über den Durchsatz Ihrer Zuordnung von Ereignisquellen. Um eine maximale Leistung zu gewährleisten, müssen Sie möglicherweise beide Einstellungen unabhängig voneinander anpassen.
Der Bereitstellungsmodus ist ideal für Echtzeitanwendungen, die eine konstante Latenz bei der Ereignisverarbeitung erfordern, z. B. Finanzdienstleister, die Marktdatenfeeds verarbeiten, E-Commerce-Plattformen, die personalisierte Empfehlungen in Echtzeit bereitstellen, und Spieleunternehmen, die Live-Spielerinteraktionen verwalten.
Jeder Event Poller unterstützt unterschiedliche Durchsatzkapazitäten:
+ Für Amazon MSK und selbstverwalteten Apache Kafka: bis zu 5% Durchsatz oder bis zu 5 MB/sec gleichzeitige Aufrufe
+ Für Amazon SQS: bis zu 1 MB/sec Durchsatz oder bis zu 10 gleichzeitige Aufrufe oder bis zu 10 SQS-Polling-API-Aufrufe pro Sekunde.
Für Amazon SQS SQS-Ereignisquellenzuordnungen können Sie die Mindestanzahl von Pollern zwischen 2 und 200 mit einer Standardeinstellung von 2 und die maximale Anzahl zwischen 2 und 2.000 mit einer Standardeinstellung von 200 festlegen. Lambda skaliert die Anzahl der Event-Poller zwischen Ihrem konfigurierten Minimum und Maximum und fügt schnell bis zu 1.000 Parallelität pro Minute hinzu, um eine konsistente Verarbeitung Ihrer Ereignisse mit niedriger Latenz zu gewährleisten.
Für Kafka-Ereignisquellenzuordnungen können Sie die Mindestanzahl von Pollern zwischen 1 und 200 mit dem Standardwert 1 und die Höchstanzahl zwischen 1 und 2.000 mit einem Standardwert von 200 festlegen. Lambda skaliert die Anzahl der Event-Poller auf der Grundlage Ihres Event-Backlogs in Ihrem Thema zwischen Ihrem konfigurierten Minimum und Maximum, um eine Verarbeitung Ihrer Ereignisse mit geringer Latenz zu ermöglichen.
Beachten Sie, dass für Amazon SQS SQS-Ereignisquellen die Einstellung für maximale Parallelität nicht im Bereitstellungsmodus verwendet werden kann. Wenn Sie den Bereitstellungsmodus verwenden, steuern Sie die Parallelität über die Einstellung „Maximale Anzahl von Event-Pollers“.
Weitere Informationen zur Konfiguration des Bereitstellungsmodus finden Sie in folgenden Abschnitten:
+ [Konfiguration des Bereitstellungsmodus für Amazon MSK-Ereignisquellenzuordnungen](kafka-scaling-modes.md)
+ [Konfiguration des Bereitstellungsmodus für selbstverwaltete Apache-Kafka-Ereignisquellen-Zuordnungen](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [Verwenden des Bereitstellungsmodus mit Amazon SQS SQS-Ereignisquellenzuordnungen](with-sqs.md#sqs-provisioned-mode)
Um die Latenz im Bereitstellungsmodus zu minimieren, setzen Sie den Wert auf 0. `MaximumBatchingWindowInSeconds` Diese Einstellung stellt sicher, dass Lambda unmittelbar nach Abschluss des aktuellen Funktionsaufrufs mit der Verarbeitung des nächsten Batches beginnt. Weitere Informationen zur Verarbeitung mit niedriger Latenz finden Sie unter [Niedrige Latenz für Apache-Kafka](with-kafka-low-latency.md).
Nachdem Sie den Bereitstellungsmodus konfiguriert haben, können Sie die Verwendung von Event-Pollern für Ihren Workload beobachten, indem Sie die `ProvisionedPollers`-Metrik überwachen. Weitere Informationen finden Sie unter [Metriken zur Zuordnung von Ereignisquellen](monitoring-metrics-types.md#event-source-mapping-metrics).
## API für die Ereignisquellenzuordnung
Um eine Ereignisquelle mit der [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) oder einem [AWS -SDK](https://aws.amazon.com/getting-started/tools-sdks/) zu verwalten, können Sie die folgenden API-Operationen verwenden:
+ [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)
# Verwendung von Tags für Zuordnungen von Ereignisquellen
Sie können Zuordnungen von Ereignisquellen taggen, um Ihre Ressourcen zu organisieren und zu verwalten. Tags sind frei formulierte Schlüssel-Wert-Paare, die mit Ihren Ressourcen verknüpft sind und von AWS-Services unterstützt werden. Weitere Informationen zu Anwendungsfällen für Tags finden Sie unter [Allgemeine Tagging-Strategien](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) im *Tagging AWS Resources and Tag Editor Guide*.
Zuordnungen von Ereignisquellen sind mit Funktionen verknüpft, die ihre eigenen Tags haben können. Zuordnungen von Ereignisquellen erben nicht automatisch Tags von Funktionen. Sie können die AWS Lambda API verwenden, um Tags anzuzeigen und zu aktualisieren. Sie können auch Tags anzeigen und aktualisieren, während Sie eine bestimmte Ereignisquellenzuordnung in der Lambda-Konsole verwalten, einschließlich solcher, die den Bereitstellungsmodus für Amazon SQS verwenden.
## Erforderliche Berechtigungen zum Arbeiten mit Tags
Um einer AWS Identity and Access Management -(IAM)-Identität (Benutzer, Gruppe oder Rolle) das Lesen oder Setzen von Tags auf einer Ressource zu ermöglichen, gewähren Sie ihr die entsprechenden Berechtigungen:
+ **lambda: ListTags** —Wenn eine Ressource Tags enthält, gewähren Sie diese Berechtigung jedem, der sie aufrufen muss. `ListTags` Für Funktionen mit Tags ist diese Berechtigung auch für `GetFunction` erforderlich.
+ **lambda: TagResource** —Erteilen Sie diese Berechtigung jedem, der bei create ein Tag aufrufen `TagResource` oder ausführen muss.
Optional können Sie erwägen, auch die **lambda: UntagResource** -Berechtigung zu erteilen, um `UntagResource` Aufrufe der Ressource zuzulassen.
Weitere Informationen finden Sie unter [Identitätsbasierte IAM-Richtlinien für Lambda](access-control-identity-based.md).
## Verwendung von Tags mit der Lambda-Konsole
Sie können die Lambda-Konsole verwenden, um Ereignisquellenzuordnungen mit Tags zu erstellen, Tags zu vorhandenen Ereignisquellenzuordnungen hinzuzufügen und Ereignisquellenzuordnungen nach Tag zu filtern, einschließlich der im Bereitstellungsmodus für Amazon SQS konfigurierten.
Wenn Sie einen Auslöser für unterstützte Stream- und Warteschlangen-basierte Dienste über die Lambda-Konsole hinzufügen, erstellt Lambda automatisch eine Zuordnung von Ereignisquellen. Weitere Informationen zu diesen Ereignisquellen finden Sie unter [Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet](invocation-eventsourcemapping.md). Sie benötigen die folgenden Voraussetzungen, um eine Zuordnung von Ereignisquellen in der Konsole zu erstellen:
+ Eine -Funktion
+ Eine Ereignisquelle von einem betroffenen Dienst.
Sie können die Tags als Teil derselben Benutzeroberfläche hinzufügen, die Sie zum Erstellen oder Aktualisieren von Triggern verwenden.
**So fügen Sie ein Tag hinzu, wenn Sie eine Zuordnung von Ereignisquellen erstellen**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie den Namen Ihrer Funktion aus.
1. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add trigger (Trigger hinzufügen)**.
1. Wählen Sie unter **Auslöserkonfiguration** in der Dropdownliste den Namen des Dienstes aus, aus dem Ihre Ereignisquelle stammt.
1. Geben Sie die Kernkonfiguration für Ihre Ereignisquelle an. Weitere Informationen zur Konfiguration Ihrer Ereignisquelle finden Sie im Abschnitt für den entsprechenden Dienst unter [Lambda mit Ereignissen aus anderen Diensten aufrufen AWS](lambda-services.md).
1. Wählen Sie unter **Konfiguration der Zuordnung von Ereignisquellen** die Option **Zusätzliche Einstellungen** aus.
1. Wählen Sie unter **Tags** die Option **Neuen Tag hinzufügen** aus
1. Geben Sie im Feld **Schlüssel** Ihren Tag-Schlüssel ein. *Informationen zu Tagging-Einschränkungen finden Sie unter Beschränkungen und Anforderungen für die [Benennung von Tags im Tagging Resources and Tag Editor](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) Guide. AWS *
1. Wählen Sie **Hinzufügen** aus.
**So fügen Sie Tags zu einer bestehenden Zuordnung von Ereignisquellen hinzu**
1. Öffnen Sie die [Zuordnungen von Ereignisquellen](https://console.aws.amazon.com/lambda/home#/event-source-mappings) in der Lambda-Konsole.
1. Wählen Sie aus der Ressourcenliste die **UUID** für die Zuordnung von Ereignisquellen aus, die Ihrem **Funktions**- und **Ereignisquellen-ARN** entspricht.
1. Wählen Sie in der Registerkartenliste unter dem **Konfigurationsbereich Allgemein** die Option **Tags**.
1. Wählen Sie **Tags verwalten** aus.
1. Wählen Sie **Neues Tag hinzufügen** aus.
1. Geben Sie im Feld **Schlüssel** Ihren Tag-Schlüssel ein. Informationen zu Einschränkungen beim Taggen finden Sie unter [Beschränkungen und Anforderungen für die Benennung von Tags im Leitfaden für AWS Tag-Ressourcen](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) *und Tag-Editor*.
1. Wählen Sie **Speichern**.
**So filtern Sie Zuordnungen von Ereignisquellen nach Tag**
1. Öffnen Sie die [Zuordnungen von Ereignisquellen](https://console.aws.amazon.com/lambda/home#/event-source-mappings) in der Lambda-Konsole.
1. Wählen Sie das Suchfeld.
1. Wählen Sie in der Dropdown-Liste Ihren Tagschlüssel unter der **Tag**-Unterüberschrift aus.
1. Wählen Sie **Verwenden: „Tag-Name“**, um alle Zuordnungen von Ereignisquellen zu sehen, die mit dieser Taste gekennzeichnet sind oder wählen Sie einen **Operator**, um weiter nach Werten zu filtern.
1. Wählen Sie Ihren Tag-Wert aus, um nach einer Kombination aus Tag-Schlüssel und -Wert zu filtern.
Das Suchfeld unterstützt auch die Suche nach Tag-Schlüsseln. Geben Sie den Namen eines Schlüssels ein, um ihn in der Liste zu finden.
## Verwenden von Tags mit dem AWS CLI
Mit der Lambda-API können Sie Tags zu vorhandenen Lambda-Ressourcen, einschließlich Zuordnungen von Ereignisquellen, hinzufügen und entfernen. Sie können beim Erstellen einer Zuordnung von Ereignisquellen auch Tags hinzufügen, sodass Sie eine Ressource während ihres gesamten Lebenszyklus mit Tags versehen können.
### Aktualisieren von Tags mit dem Lambda-Tag APIs
Sie können Tags für unterstützte Lambda-Ressourcen über die [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)und [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API-Operationen hinzufügen und entfernen.
Sie können diese Operationen mit der Taste AWS CLI aufrufen. Um Tags einer vorhandenen Ressource hinzuzufügen, verwenden Sie den folgenden `tag-resource`-Befehl. In diesem Beispiel werden zwei Tags hinzugefügt, eines mit dem Schlüssel *Department* und eines mit dem Schlüssel*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Mit dem Befehl `untag-resource` können Sie Tags entfernen. In diesem Beispiel wird das Tag mit dem Schlüssel entfernt*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Hinzufügen von Tags beim Erstellen einer Zuordnung von Ereignisquellen
Verwenden Sie die [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)API-Operation, um eine neue Lambda-Ereignisquellenzuordnung mit Tags zu erstellen. Geben Sie den Parameter `Tags` an. Sie können diesen Vorgang mit dem `create-event-source-mapping` AWS CLI Befehl und der `--tags` Option aufrufen. Weitere Informationen zum CLI-Befehl finden Sie [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)in der *AWS CLI Befehlsreferenz*.
Vergewissern Sie sich vor der Verwendung des `Tags`-Parameters mit `CreateEventSourceMapping`, dass Ihre Rolle neben den üblichen Berechtigungen, die für diesen Vorgang erforderlich sind, auch die Berechtigung hat, Ressourcen zu taggen. Weitere Informationen zu den Berechtigungen für das Tagging finden Sie unter [Erforderliche Berechtigungen zum Arbeiten mit Tags](#esm-tags-required-permissions).
### Tags mit dem Lambda-Tag anzeigen APIs
Um die Tags anzuzeigen, die auf eine bestimmte Lambda-Ressource angewendet werden, verwenden Sie die `ListTags`-API-Operation. Weitere Informationen finden Sie unter [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Sie können diesen Vorgang mit dem `list-tags` AWS CLI Befehl aufrufen, indem Sie einen ARN (Amazon Resource Name) angeben.
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtern von Ressourcen nach Tag
Sie können den AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API-Vorgang verwenden, um Ihre Ressourcen nach Tags zu filtern. Die `GetResources`-Operation empfängt bis zu 10 Filter, wobei jeder Filter einen Tag-Schlüssel und bis zu 10 Tag-Werte enthält. Sie stellen `GetResources` mit einem `ResourceType` zur Verfügung, um nach bestimmten Ressourcentypen zu filtern.
Sie können diesen Vorgang mit dem `get-resources` AWS CLI Befehl aufrufen. Beispiele für die Verwendung von `get-resources` finden Sie unter [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) in der *AWS -CLI-Befehlsreferenz*.