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.
# Verwenden von Lambda mit Amazon SQS
**Anmerkung**
Wenn Sie Daten an ein anderes Ziel als eine Lambda-Funktion senden oder die Daten vor dem Senden anreichern möchten, finden Sie weitere Informationen unter [Amazon EventBridge Pipes](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html).
Mit einer Lambda-Funktion können Sie Nachrichten in einer Amazon-SQS-Warteschlange (Amazon Simple Queue Service) verarbeiten. Lambda unterstützt sowohl [Standard-Warteschlangen](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html) als auch [First-In-First-Out-Warteschlangen](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html) (FIFO) für [Zuordnungen von Ereignisquellen](invocation-eventsourcemapping.md). Sie können den Bereitstellungsmodus auch verwenden, um spezielle Abfrageressourcen für Ihre Amazon SQS SQS-Ereignisquellenzuordnungen zuzuweisen. [Die Lambda-Funktion und die Amazon SQS SQS-Warteschlange müssen sich in derselben befinden AWS-Region, obwohl sie sich unterscheiden können. AWS-Konten](with-sqs-cross-account-example.md)
Bei der Verarbeitung von Amazon-SQS-Nachrichten müssen Sie eine Logik für teilweise Batch-Antworten implementieren, um zu verhindern, dass versucht wird, erfolgreich verarbeitete Nachrichten erneut zu verarbeiten, wenn einige Nachrichten in einem Batch fehlschlagen. Das [Batch Processor Utility](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) von Powertools for AWS Lambda vereinfacht diese Implementierung, indem es automatisch die Logik der partiellen Batch-Antwort verarbeitet, wodurch die Entwicklungszeit reduziert und die Zuverlässigkeit verbessert wird.
**Topics**
+ [
## Verständnis des Polling- und Batching-Verhaltens für Amazon-SQS-Zuordnungen von Ereignisquellen
](#sqs-polling-behavior)
+ [
## Verwenden des Bereitstellungsmodus mit Amazon SQS SQS-Ereignisquellenzuordnungen
](#sqs-provisioned-mode)
+ [
## Konfiguration des Bereitstellungsmodus für die Zuordnung von Amazon SQS SQS-Ereignisquellen
](#sqs-configuring-provisioned-mode)
+ [
## Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis
](#example-standard-queue-message-event)
+ [
## Beispiel für ein FIFO-Warteschlangen-Nachrichtenereignis
](#sample-fifo-queues-message-event)
+ [
# Erstellen und Konfigurieren einer Amazon SQS-Zuordnung von Ereignisquellen
](services-sqs-configure.md)
+ [
# Konfiguration des Skalierungsverhaltens für SQS-Zuordnungen von Ereignisquellen
](services-sqs-scaling.md)
+ [
# Behandlung von Fehlern für eine SQS-Ereignisquelle in Lambda
](services-sqs-errorhandling.md)
+ [
# Lambdaparameter für Amazon-SQS-Zuordnungen von Ereignisquellen
](services-sqs-parameters.md)
+ [
# Verwendung der Ereignisfilterung mit einer Amazon-SQS-Ereignisquelle
](with-sqs-filtering.md)
+ [
# Tutorial: Verwenden von Lambda mit Amazon SQS
](with-sqs-example.md)
+ [
# Tutorial: Verwenden einer kontoübergreifenden Amazon SQS SQS-Warteschlange als Ereignisquelle
](with-sqs-cross-account-example.md)
## Verständnis des Polling- und Batching-Verhaltens für Amazon-SQS-Zuordnungen von Ereignisquellen
Mit Amazon-SQS-Zuordnungen von Ereignisquellen fragt Lambda die Warteschlange ab und ruft Ihre Funktion [synchron](invocation-sync.md) mit einem Ereignis auf. Jedes Ereignis kann einen Batch von mehreren Nachrichten aus der Warteschlange enthalten. Lambda empfängt diese Ereignisse jeweils stapelweise und ruft Ihre Funktion für jeden Stapel einmal auf. Wenn Ihre Funktion einen Batch erfolgreich verarbeitet, löscht Lambda deren Nachrichten aus der Warteschlange.
Wenn Lambda einen Batch empfängt, bleiben die Nachrichten in der Warteschlange, werden aber für die Dauer der [Zeitbeschränkung für die Sichtbarkeit](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) der Warteschlange ausgeblendet. Wenn Ihre Funktion alle Nachrichten im Batch erfolgreich verarbeitet hat, löscht Lambda die Nachrichten aus der Warteschlange. Wenn Ihre Funktion bei der Verarbeitung eines Batches auf einen Fehler stößt, werden standardmäßig alle Nachrichten in diesem Batch nach Ablauf des Zeitlimits für die Sichtbarkeit wieder in der Warteschlange sichtbar. Deshalb muss der Funktionscode in der Lage sein, dieselbe Nachricht mehrmals ohne unbeabsichtigte Begleiterscheinungen zu verarbeiten.
**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
Um zu verhindern, dass Lambda eine Nachricht mehrfach verarbeitet, können Sie entweder Ihre Ereignisquellenzuordnung so konfigurieren, dass [Batch-Elementfehler](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) in Ihre Funktionsantwort aufgenommen werden, oder Sie können die [DeleteMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)API verwenden, um Nachrichten aus der Warteschlange zu entfernen, wenn Ihre Lambda-Funktion sie erfolgreich verarbeitet.
Weitere Informationen zu Konfigurationsparametern, die Lambda für SQS-Zuordnungen von Ereignisquellen unterstützt, finden Sie unter [Erstellen einer SQS-Zuordnung von Ereignisquellen](services-sqs-configure.md#events-sqs-eventsource).
## Verwenden des Bereitstellungsmodus mit Amazon SQS SQS-Ereignisquellenzuordnungen
Für Workloads, bei denen Sie den Durchsatz Ihrer Zuordnung von Ereignisquellen optimieren müssen, können Sie den Bereitstellungsmodus verwenden. Im Bereitstellungsmodus definieren Sie Mindest- und Höchstgrenzen für die Anzahl der bereitgestellten Ereignis-Poller. Diese bereitgestellten Event-Poller sind auf Ihre Zuordnung von Ereignisquellen ausgerichtet und können unerwartete Nachrichtenspitzen durch reaktionsschnelle Autoskalierung bewältigen. Die mit dem Bereitstellungsmodus konfigurierte Amazon SQS SQS-Ereignisquellenzuweisung skaliert dreimal schneller (bis zu 1.000 gleichzeitige Aufrufe pro Minute) und unterstützt eine 16-mal höhere Parallelität (bis zu 20.000 gleichzeitige Aufrufe) als die standardmäßige Amazon SQS SQS-Funktion zur Zuordnung von Ereignisquellen. Wir empfehlen, den Bereitstellungsmodus für ereignisgesteuerte Amazon SQS SQS-Workloads zu verwenden, für die strenge Leistungsanforderungen gelten, z. B. Finanzdienstleister, die Marktdatenfeeds verarbeiten, E-Commerce-Plattformen, die personalisierte Empfehlungen in Echtzeit bereitstellen, und Spieleunternehmen, die Live-Spielerinteraktionen verwalten. Die Verwendung des Bereitstellungsmodus verursacht zusätzliche Kosten. [Eine detaillierte Preisgestaltung finden Sie unter Preise.AWS Lambda](https://aws.amazon.com/lambda/pricing/)
Jeder Event Poller im Bereitstellungsmodus kann bis zu 1 MB/s Durchsatz, bis zu 10 gleichzeitige Aufrufe oder bis zu 10 Amazon SQS-Polling-API-Aufrufe pro Sekunde verarbeiten. Der Bereich der akzeptierten Werte für die Mindestanzahl von Event-Pollern (MinimumPollers) liegt zwischen 2 und 200, der Standardwert ist 2. Der Bereich der akzeptierten Werte für die maximale Anzahl von Event-Pollern (MaximumPollers) liegt zwischen 2 und 2.000, der Standardwert ist 200. MaximumPollers muss größer oder gleich sein MinimumPollers.
### Ermittlung der erforderlichen Event-Poller
Um die Anzahl der Ereignisabfragen zu schätzen, die erforderlich sind, um eine optimale Nachrichtenverarbeitungsleistung sicherzustellen, wenn Sie den Bereitstellungsmodus für SQS ESM verwenden, erfassen Sie die folgenden Metriken für Ihre Anwendung: maximale SQS-Ereignisse pro Sekunde, die eine Verarbeitung mit niedriger Latenz erfordern, durchschnittliche Größe der SQS-Ereignisnutzlast, durchschnittliche Lambda-Funktionsdauer und konfigurierte Batchgröße.
Zunächst können Sie anhand der folgenden Formel die Anzahl der SQS-Ereignisse pro Sekunde (EPS) schätzen, die von einem Event Poller für Ihren Workload unterstützt werden:
```
EPS per event poller =
minimum(
ceiling(1024 / average event size in KB),
ceiling(10 / average function duration in seconds) * batch size,
min(100, 10 * batch size)
)
```
Anschließend können Sie anhand der folgenden Formel die Anzahl der mindestens erforderlichen Poller berechnen. Diese Berechnung stellt sicher, dass Sie ausreichend Kapazität bereitstellen, um Ihren Spitzenverkehrsanforderungen gerecht zu werden.
```
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
```
Stellen Sie sich einen Workload mit einer Standard-Batchgröße von 10, einer durchschnittlichen Ereignisgröße von 3 KB, einer durchschnittlichen Funktionsdauer von 100 ms und der Anforderung, 1.000 Ereignisse pro Sekunde zu verarbeiten, vor. In diesem Szenario unterstützt jeder Event Poller ungefähr 100 Ereignisse pro Sekunde (EPS). Daher sollten Sie die Mindestanzahl an Pollern auf 10 festlegen, um Ihren Anforderungen an den Spitzenverkehr angemessen gerecht zu werden. Wenn Ihr Workload dieselben Eigenschaften hat, aber eine durchschnittliche Funktionsdauer von 1 Sekunde hat, unterstützt jeder Poller nur 10 EPS. Sie müssen also mindestens 100 Poller konfigurieren, um 1.000 Ereignisse pro Sekunde bei niedriger Latenz zu unterstützen.
Wir empfehlen die Verwendung einer Standard-Batchgröße von 10 oder höher, um die Effizienz von Event-Pollern im Bereitstellungsmodus zu maximieren. Höhere Batchgrößen ermöglichen es jedem Poller, mehr Ereignisse pro Aufruf zu verarbeiten, was den Durchsatz und die Kosteneffizienz verbessert. Berücksichtigen Sie bei der Planung Ihrer Event-Poller-Kapazität potenzielle Verkehrsspitzen und ziehen Sie in Betracht, den MinimumPollers-Wert etwas höher als das berechnete Minimum festzulegen, um einen Puffer bereitzustellen. Überwachen Sie außerdem Ihre Workload-Merkmale im Zeitverlauf, da Änderungen der Nachrichtengröße, der Funktionsdauer oder der Verkehrsmuster möglicherweise Anpassungen an Ihrer Event-Poller-Konfiguration erforderlich machen, um eine optimale Leistung und Kosteneffizienz zu gewährleisten. Für eine genaue Kapazitätsplanung empfehlen wir, Ihre spezifische Arbeitslast zu testen, um den tatsächlichen Gewinn pro Leistung zu ermitteln, den jeder Event Poller erzielen kann.
## Konfiguration des Bereitstellungsmodus für die Zuordnung von Amazon SQS SQS-Ereignisquellen
Sie können den Bereitstellungsmodus für Ihre Amazon SQS SQS-Ereignisquellenzuordnung mithilfe der Konsole oder der Lambda-API konfigurieren.
**So konfigurieren Sie den Bereitstellungsmodus für eine bestehende Amazon SQS SQS-Ereignisquellenzuordnung (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion mit der Amazon SQS SQS-Ereignisquellenzuordnung aus, für die Sie den Bereitstellungsmodus konfigurieren möchten.
1. Wählen Sie **Konfiguration** und anschließend **Auslöser** aus.
1. **Wählen Sie die Amazon SQS SQS-Ereignisquellenzuordnung aus, für die Sie den Bereitstellungsmodus konfigurieren möchten, und klicken Sie dann auf Bearbeiten.**
1. Wählen Sie unter **Konfiguration der Zuordnung von Ereignisquellen** die Option **Bereitstellungsmodus konfigurieren** aus.
+ Geben Sie für **Minimum Event Pollers** einen Wert zwischen 2 und 200 ein. Wenn Sie keinen Wert angeben, wählt Lambda den Standardwert 2.
+ Geben Sie für **Maximum Event Pollers** einen Wert zwischen 2 und 2.000 ein. Dieser Wert muss größer oder gleich Ihrem Wert für **Minimum Event Pollers** sein. Wenn Sie keinen Wert angeben, wählt Lambda einen Standardwert von 200.
1. Wählen Sie **Speichern**.
Sie können den Bereitstellungsmodus programmgesteuert mithilfe des `ProvisionedPollerConfig` Objekts in Ihrem konfigurieren. `EventSourceMappingConfiguration` Der folgende `UpdateEventSourceMapping` CLI-Befehl konfiguriert beispielsweise einen `MinimumPollers` Wert von 5 und einen `MaximumPollers` Wert von 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
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.
Um den Bereitstellungsmodus zu deaktivieren und zum Standardmodus (auf Abruf) zurückzukehren, können Sie den folgenden `UpdateEventSourceMapping` CLI-Befehl verwenden:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
**Anmerkung**
Der Bereitstellungsmodus kann nicht in Verbindung mit der Einstellung für maximale Parallelität verwendet werden. Wenn Sie den Bereitstellungsmodus verwenden, steuern Sie die maximale Parallelität durch die maximale Anzahl von Event-Pollern.
Weitere Informationen zur Konfiguration des Bereitstellungsmodus finden Sie unter. [Erstellen und Konfigurieren einer Amazon SQS-Zuordnung von Ereignisquellen](services-sqs-configure.md)
## Beispiel für ein Standard-Warteschlangen-Nachrichtenereignis
**Example Amazon-SQS-Nachrichtenereignis (Standardwarteschlange)**
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {
"myAttribute": {
"stringValue": "myValue",
"stringListValues": [],
"binaryListValues": [],
"dataType": "String"
}
},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
},
{
"messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
"receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082650636",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082650649"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
}
]
}
```
Lambda fragt standardmäßig bis zu 10 Nachrichten in Ihrer Warteschlange sofort ab und sendet diesen Batch an die Funktion. Damit die Funktion nicht mit einer kleinen Anzahl von Datensätzen aufgerufen wird, können Sie die Ereignisquelle so konfigurieren, dass die Datensätze bis zu 5 Minuten lang gepuffert werden, indem Sie ein Batch-Fenster konfigurieren. Vor dem Aufrufen der Funktion fragt Lambda weiter Nachrichten aus der Standardwarteschlange ab, bis das Batch-Fenster abläuft, das [Nutzlastkontingent pro Aufruf](gettingstarted-limits.md) erreicht ist oder die konfigurierte maximale Batch-Größe erreicht ist.
Wenn Sie ein Batch-Fenster verwenden und Ihre SQS-Warteschlange sehr wenig Datenverkehr enthält, wartet Lambda möglicherweise bis zu 20 Sekunden, bevor Sie Ihre Funktion aufruft. Dies gilt auch, wenn Sie ein Batch-Fenster unter 20 Sekunden festlegen.
**Anmerkung**
In Java können beim Deserialisieren von JSON Nullzeigerfehler auftreten. Dies könnte daran liegen, dass die Groß- und Kleinschreibung von „Records“ und „eventSourceARN“ vom JSON-Objektmapper konvertiert wird.
## Beispiel für ein FIFO-Warteschlangen-Nachrichtenereignis
Bei FIFO-Warteschlangen enthalten Datensätze zusätzliche Attribute, die mit der Deduplizierung und Sequenzierung zusammenhängen.
**Example Amazon-SQS-Nachrichtenereignis (FIFO-Warteschlange)**
```
{
"Records": [
{
"messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
"receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1573251510774",
"SequenceNumber": "18849496460467696128",
"MessageGroupId": "1",
"SenderId": "AIDAIO23YVJENQZJOL4VO",
"MessageDeduplicationId": "1",
"ApproximateFirstReceiveTimestamp": "1573251510774"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
"awsRegion": "us-east-2"
}
]
}
```
# Erstellen und Konfigurieren einer Amazon SQS-Zuordnung von Ereignisquellen
Um Amazon-SQS-Nachrichten mit Lambda zu verarbeiten, konfigurieren Sie Ihre Warteschlange mit den entsprechenden Einstellungen und erstellen Sie dann eine Lambda-Zuordnung von Ereignisquellen.
**Topics**
+ [
## Konfigurieren einer Warteschlange zur Verwendung mit Lambda
](#events-sqs-queueconfig)
+ [
## Einrichten von Lambda-Ausführungsrollenberechtigungen
](#events-sqs-permissions)
+ [
## Erstellen einer SQS-Zuordnung von Ereignisquellen
](#events-sqs-eventsource)
## Konfigurieren einer Warteschlange zur Verwendung mit Lambda
Wenn Sie noch nicht über eine Amazon-SQS-Warteschlange verfügen, [erstellen Sie eine](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html) als Ereignisquelle für Ihre Lambda-Funktion. [Die Lambda-Funktion und die Amazon SQS SQS-Warteschlange müssen sich in derselben befinden AWS-Region, obwohl sie sich unterscheiden können. AWS-Konten](with-sqs-cross-account-example.md)
Damit Ihre Funktion genügend Zeit hat, um jeden Stapel von Datensätzen zu verarbeiten, setzen Sie die Zeitüberschreitung für die [Sichtbarkeit der Ausgangswarteschlange](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) auf mindestens das Sechsfache der [Konfigurationszeitüberschreitung](configuration-timeout.md) Ihrer Funktion. Diese zusätzliche Zeit ermöglicht es für Lambda, einen erneuten Versuch zu machen, wenn die Funktion gedrosselt wird, während ein früherer Batch verarbeitet wird.
**Anmerkung**
Das Timeout Ihrer Funktion muss kleiner oder gleich dem Sichtbarkeits-Timeout der Warteschlange sein. Lambda validiert diese Anforderung, wenn Sie eine Zuordnung von Ereignisquellen erstellen oder aktualisieren, und gibt einen Fehler zurück, wenn das Funktions-Timeout das Sichtbarkeits-Timeout der Warteschlange überschreitet.
Wenn Lambda bei der Verarbeitung eines Stapels auf einen Fehler stößt, kehren standardmäßig alle Nachrichten in diesem Stapel in die Warteschlange zurück. Nach dem [Sichtbarkeits-Timeout](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) werden die Nachrichten wieder für Lambda sichtbar. Sie können Ihre Zuordnung von Ereignisquellen so konfigurieren, dass Sie [partielle Batch-Antworten](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) verwenden, um nur die fehlgeschlagenen Nachrichten an die Warteschlange zurückzugeben. Wenn Ihre Funktion eine Nachricht mehrmals nicht verarbeiten kann, kann Amazon SQS sie außerdem an eine [Warteschlange für unzustellbare Nachrichten](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) senden. Wir empfehlen, das `maxReceiveCount` in der [Redrive-Richtlinie](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues) Ihrer Quellwarteschlange auf mindestens 5 zu setzen. Dadurch erhält Lambda einige Chancen, es erneut zu versuchen, bevor fehlgeschlagene Nachrichten direkt an die Warteschlange für unzustellbare Nachrichten gesendet werden.
## Einrichten von Lambda-Ausführungsrollenberechtigungen
Die [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS verwaltete Richtlinie umfasst die Berechtigungen, die Lambda benötigt, um aus Ihrer Amazon SQS SQS-Warteschlange zu lesen. Sie können diese verwaltete Richtlinie der [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion hinzufügen.
Wenn Sie optional eine verschlüsselte Warteschlange verwenden, müssen Sie Ihrer Ausführungsrolle auch die folgende Berechtigung hinzufügen:
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
## Erstellen einer SQS-Zuordnung von Ereignisquellen
Erstellen Sie ein Ereignisquellen-Mapping, um Lambda anzuweisen, Elemente aus Ihrer Warteschlange an eine Lambda-Funktion zu senden. Sie können mehrere Ereignisquellen-Zuweisungen zum Verarbeiten von Elementen aus mehreren Warteschlangen mit nur einer Funktion erstellen. Wenn Lambda die Zielfunktion aufruft, kann das Ereignis mehrere Elemente bis zu einer konfigurierbaren maximalen *Batch-Größe* enthalten.
Um Ihre Funktion so zu konfigurieren, dass sie aus Amazon SQS liest, fügen Sie die [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS verwaltete Richtlinie Ihrer Ausführungsrolle hinzu. Erstellen Sie anschließend mithilfe der folgenden Schritte eine Zuordnung der **SQS**-Ereignisquellen von der Konsole aus.
**So fügen Sie Berechtigungen hinzu und erstellen einen Auslöser**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie den Namen einer Funktion aus.
1. Wählen Sie die Registerkarte **Konfiguration** und dann **Berechtigungen** aus.
1. Wählen Sie unter **Rollenname** den Link zu Ihrer Ausführungsrolle. Dieser Link öffnet die Rolle in der IAM-Konsole.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/execution-role.png)
1. Wählen Sie **Berechtigungen hinzufügen** aus und wählen Sie dann **Richtlinien direkt anhängen** aus.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/attach-policies.png)
1. Geben Sie im Suchfeld `AWSLambdaSQSQueueExecutionRole` ein. Fügen Sie diese Richtlinie zu Ihrer Ausführungsrolle hinzu. Dies ist eine AWS verwaltete Richtlinie, die die Berechtigungen enthält, die Ihre Funktion zum Lesen aus einer Amazon SQS SQS-Warteschlange benötigt. Weitere Informationen zu dieser Richtlinie finden Sie [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)in der *Referenz zu AWS verwalteten Richtlinien.*
1. Gehen Sie zurück zu Ihrer Funktion in der Lambda-Konsole. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add trigger (Trigger hinzufügen)**.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/add-trigger.png)
1. Wählen Sie einen Auslösertyp aus.
1. Konfigurieren Sie die erforderlichen Optionen und wählen Sie dann **Add** (Hinzufügen) aus.
Lambda unterstützt die folgenden Konfigurationsoptionen für Amazon-SQS-Ereignisquellen:
**SQS Queue**
Die Amazon-SQS-Warteschlange, aus der Datensätze gelesen werden sollen. [Die Lambda-Funktion und die Amazon SQS SQS-Warteschlange müssen sich in derselben befinden AWS-Region, obwohl sie sich unterscheiden können. AWS-Konten](with-sqs-cross-account-example.md)
**Aktivieren von Auslösern**
Der Status der Zuordnung von Ereignisquellen. **Enable trigger** (Auslöser aktivieren) ist standardmäßig ausgewählt.
**Batch-Größe**
Die maximale Anzahl der Datensätze, die in jedem Stapel an die Funktion gesendet werden sollen. Bei einer Standardwarteschlange können dies bis zu 10.000 Datensätze sein. Bei einer FIFO-Warteschlange liegt der Höchstwert bei 10. Bei einer Stapelgröße über 10 müssen Sie das Stapelfenster (`MaximumBatchingWindowInSeconds`) zusätzlich auf mindestens 1 Sekunde festlegen.
Konfigurieren Sie Ihr [Funktions-Timeout](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts) so, dass genügend Zeit bleibt, um einen ganzen Stapel von Elementen zu verarbeiten. Wenn die Verarbeitung bestimmter Elemente lange Zeit in Anspruch nimmt, wählen Sie eine kleinere Batch-Größe. Eine große Batchgröße kann die Effizienz für Workloads erhöhen, die sehr schnell sind oder viel Overhead aufweisen. Wenn Sie [reservierte Nebenläufigkeit](configuration-concurrency.md) für Ihre Funktion konfigurieren, legen Sie mindestens fünf gleichzeitige Ausführungen fest, um das Risiko von Drosselungsfehlern zu senken, wenn Lambda die Funktion aufruft.
Lambda übergibt alle Datensätze im Batch in einem einzigen Aufruf an die Funktion, solange die Gesamtgröße der Ereignisse nicht das [Nutzlastkontingent pro Aufruf](gettingstarted-limits.md) für synchrone Aufrufe überschreitet (6 MB). Sowohl Lambda als auch Amazon SQS generieren Metadaten für jeden Datensatz. Diese zusätzlichen Metadaten werden auf die Gesamtnutzlastgröße angerechnet und können dazu führen, dass die Gesamtzahl der in einem Batch gesendeten Datensätze niedriger ist als die konfigurierte Batch-Größe. Die Metadatenfelder, die Amazon SQS sendet, können in der Länge variabel sein. Weitere Informationen zu den Amazon SQS-Metadatenfeldern finden Sie in der Dokumentation zum [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API-Betrieb in der *Amazon Simple Queue Service API-Referenz.*
**Batchfenster**
Die maximale Zeitspanne zur Erfassung von Datensätzen vor dem Aufruf der Funktion in Sekunden. Dies gilt nur für Standardwarteschlangen.
Wenn Sie ein Stapelfenster von mehr als 0 Sekunden verwenden, müssen Sie die erhöhte Verarbeitungszeit im [Sichtbarkeits-Timeout](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) Ihrer Warteschlange berücksichtigen. Wir empfehlen, das Sichtbarkeits-Timeout Ihrer Warteschlange auf das Sechsfache Ihres [Funktions-Timeouts](configuration-timeout.md) plus den Wert von `MaximumBatchingWindowInSeconds` festzulegen. Dies gibt Ihrer Lambda-Funktion Zeit, jeden Ereignis-Batch zu verarbeiten und es im Falle eines Drosselungsfehlers erneut zu versuchen.
Wenn Nachrichten verfügbar werden, beginnt Lambda, Nachrichten stapelweise zu verarbeiten. Lambda beginnt mit der gleichzeitigen Verarbeitung von fünf Stapeln mit fünf gleichzeitigen Aufrufen Ihrer Funktion. Wenn Nachrichten noch verfügbar sind, addiert Lambda bis zu 300 gleichzeitige Aufrufe Ihrer Funktion pro Minute, bis zu einem Maximum von 1.250 gleichzeitigen Aufrufen. Im Bereitstellungsmodus kann jeder Event Poller bis zu 1 MB/s Durchsatz, bis zu 10 gleichzeitige Aufrufe oder bis zu 10 Amazon SQS-Polling-API-Aufrufe pro Sekunde verarbeiten. Lambda skaliert die Anzahl der Event-Poller zwischen Ihrem konfigurierten Minimum und Maximum und fügt schnell bis zu 1.000 gleichzeitige Aufrufe pro Minute hinzu, um eine Verarbeitung Ihrer Amazon SQS SQS-Ereignisse mit geringer Latenz zu gewährleisten. Sie steuern Skalierung und Parallelität über diese minimalen und maximalen Event-Poller-Einstellungen. Weitere Informationen über Funktionsskalierung und Parallelität finden Sie unter. [Verstehen der Skalierung von Lambda-Funktionen](lambda-concurrency.md)
Um mehr Nachrichten zu verarbeiten, können Sie Ihre Lambda-Funktion für einen höheren Durchsatz optimieren. Weitere Informationen finden Sie unter [Grundlegendes zur AWS Lambda Skalierung mit Amazon SQS SQS-Standardwarteschlangen](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.).
**Filterkriterien**
Verwenden Sie Filterkriterien, um zu steuern, welche Ereignisse Lambda zur Verarbeitung an Ihre Funktion sendet. Weitere Informationen finden Sie unter [Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet](invocation-eventfiltering.md).
**Maximale Parallelität**
Die maximale Anzahl der gleichzeitigen Funktionen, die die Ereignisquelle aufrufen kann. Kann nicht verwendet werden, wenn der Bereitstellungsmodus aktiviert ist. Weitere Informationen finden Sie unter [Konfigurieren der maximalen Gleichzeitigkeit für Amazon-SQS-Ereignisquellen](services-sqs-scaling.md#events-sqs-max-concurrency).
**Modus bereitgestellter Kapazität**
Wenn diese Option aktiviert ist, werden spezielle Abfrageressourcen für Ihre Ereignisquellenzuordnung zugewiesen. Sie können die minimale (2-200) und die maximale (2-2000) Anzahl von Event-Pollern konfigurieren. Jeder Event Poller kann bis zu 1 MB/sec Durchsatz, bis zu 10 gleichzeitige Aufrufe oder bis zu 10 Amazon SQS-Polling-API-Aufrufe pro Sekunde verarbeiten.
Hinweis: Sie können den Bereitstellungsmodus und die Option Maximale Parallelität nicht zusammen verwenden. Wenn der Bereitstellungsmodus aktiviert ist, verwenden Sie die Einstellung für maximale Polleranzahl, um die Parallelität zu steuern.
# Konfiguration des Skalierungsverhaltens für SQS-Zuordnungen von Ereignisquellen
Sie können das Skalierungsverhalten Ihrer Amazon SQS SQS-Ereignisquellenzuordnungen entweder über die Einstellungen für maximale Parallelität oder durch die Aktivierung des Bereitstellungsmodus steuern. Diese Optionen schließen sich gegenseitig aus.
Standardmäßig skaliert Lambda Event-Poller automatisch auf der Grundlage des Nachrichtenvolumens. Wenn Sie den Bereitstellungsmodus aktivieren, weisen Sie eine Mindest- und Höchstzahl an dedizierten Abfrageressourcen zu, die bereit sind, die erwarteten Datenverkehrsmuster zu verarbeiten. Auf diese Weise können Sie die Leistung Ihrer Ereignisquellenzuordnung auf zwei Arten optimieren:
+ Standardmodus (Standard): Lambda verwaltet die Skalierung automatisch, wobei mit einer kleinen Anzahl von Pollern begonnen und je nach Arbeitslast nach oben oder unten skaliert wird.
+ Bereitgestellter Modus: Sie konfigurieren dedizierte Abfrageressourcen mit Mindest- und Höchstgrenzen, was eine dreimal schnellere Skalierung und eine bis zu 16-mal höhere Verarbeitungskapazität ermöglicht.
Bei Standardwarteschlangen verwendet Lambda [Langabfrage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling), um eine Warteschlange so lange abzufragen, bis sie aktiv wird. Wenn Nachrichten verfügbar sind, beginnt Lambda mit der gleichzeitigen Verarbeitung von fünf Stapeln mit fünf gleichzeitigen Aufrufen Ihrer Funktion. Wenn Nachrichten weiterhin verfügbar sind, erhöht Lambda die Anzahl der Prozesse, die Batches lesen, um bis zu 300 gleichzeitige Aufrufe pro Minute. Die maximale Anzahl von Aufrufen, die eine Ereignisquellenzuordnung gleichzeitig verarbeiten kann, beträgt 1.250. Wenn der Verkehr gering ist, reduziert Lambda die Verarbeitung auf fünf gleichzeitige Aufrufe und kann auf bis zu zwei gleichzeitige Aufrufe optimiert werden, um die Amazon SQS SQS-Aufrufe und die entsprechenden Kosten zu reduzieren. Diese Optimierung ist jedoch nicht verfügbar, wenn Sie die Einstellung für maximale Gleichzeitigkeit aktivieren.
Bei FIFO-Warteschlangen sendet Lambda Nachrichten in der Reihenfolge, in der sie empfangen wurden, an Ihre Funktion. Wenn Sie eine Nachricht an eine FIFO-Warteschlange senden, geben Sie eine [Nachrichtengruppen-ID](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) an. Amazon SQS stellt sicher, dass Nachrichten in derselben Gruppe in der Reihenfolge an Lambda übermittelt werden. Wenn Lambda Ihre Nachrichten in Batches liest, kann jeder Batch Nachrichten aus mehr als einer Nachrichtengruppe enthalten, aber die Reihenfolge der Nachrichten bleibt erhalten. Wenn die Funktion einen Fehler zurückgibt, führt sie alle Wiederholungsversuche für die betroffenen Nachrichten aus, bevor Lambda weitere Nachrichten von derselben Gruppe erhält.
Im Bereitstellungsmodus kann jeder Event Poller bis zu 1 MB/sec Durchsatz, bis zu 10 gleichzeitige Aufrufe oder bis zu 10 Amazon SQS-Polling-API-Aufrufe pro Sekunde verarbeiten. 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 Amazon SQS SQS-Ereignisse mit niedriger Latenz zu gewährleisten. Die Verwendung des Bereitstellungsmodus verursacht zusätzliche Kosten. [Eine detaillierte Preisgestaltung finden Sie unter Preise.AWS Lambda](https://aws.amazon.com/lambda/pricing/) Jeder Event Poller verwendet [lange Abfragen](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html) in Ihrer SQS-Warteschlange mit bis zu 10 Abfragen pro Sekunde, wodurch Kosten für SQS-API-Anfragen anfallen. Weitere Informationen finden Sie unter [Amazon SQS SQS-Preise](https://aws.amazon.com/sqs/pricing/ ). Sie steuern Skalierung und Parallelität über diese minimalen und maximalen Event-Poller-Einstellungen, anstatt die Einstellung für maximale Parallelität zu verwenden, da diese Optionen nicht zusammen verwendet werden können.
**Anmerkung**
Sie können die Einstellung für maximale Parallelität und den Bereitstellungsmodus nicht gleichzeitig verwenden. Wenn der Bereitstellungsmodus aktiviert ist, steuern Sie die Skalierung und Parallelität Ihrer Amazon SQS SQS-Ereignisquellenzuordnung durch die minimale und maximale Anzahl von Event-Pollern.
## Konfigurieren der maximalen Gleichzeitigkeit für Amazon-SQS-Ereignisquellen
Sie können die Einstellung für die maximale Gleichzeitigkeit verwenden, um das Skalierungsverhalten für Ihre SQS-Ereignisquellen zu steuern. Beachten Sie, dass die maximale Parallelität nicht verwendet werden kann, wenn der Bereitstellungsmodus aktiviert ist. Die Einstellung für die maximale Gleichzeitigkeit begrenzt die Anzahl der gleichzeitigen Instances der Funktion, die eine Amazon-SQS-Ereignisquelle aufrufen kann. Die maximale Gleichzeitigkeit ist eine Einstellung auf der Ebene der Ereignisquelle. Wenn Sie einer Funktion mehrere Amazon-SQS-Ereignisquellen zugeordnet haben, kann jede Ereignisquelle eine separate Einstellung für die maximale Gleichzeitigkeit haben. Sie können die maximale Parallelität verwenden, um zu verhindern, dass eine Warteschlange die gesamte [reservierte Gleichzeitigkeit](configuration-concurrency.md) der Funktion oder den Rest des [Gleichzeitigkeitskontingents des Kontos](gettingstarted-limits.md) verwendet. Für die Konfiguration der maximalen Gleichzeitigkeit auf einer Amazon-SQS-Ereignisquelle fallen keine Gebühren an.
Wichtig ist, dass maximale und reservierte Parallelität zwei unabhängige Einstellungen sind. Setzen Sie die maximale Parallelität nicht höher als die reservierte Parallelität der Funktion. Wenn Sie maximale Parallelität konfigurieren, stellen Sie sicher, dass die reservierte Parallelität Ihrer Funktion größer oder gleich der gesamten maximalen Parallelität für alle Amazon SQS-Ereignisquellen auf der Funktion ist. Andernfalls könnte Lambda Ihre Nachrichten drosseln.
Wenn die Gleichzeitigkeitsquote Ihres Kontos auf den Standardwert von 1 000 eingestellt ist, kann eine Amazon-SQS-Zuordnung von Ereignisquellen skaliert werden, um Funktionsinstanzen bis zu diesem Wert aufzurufen, es sei denn, Sie geben eine maximale Gleichzeitigkeit an.
Wenn Sie eine Erhöhung der standardmäßigen Gleichzeitigkeitsquote Ihres Kontos erhalten, kann Lambda möglicherweise keine gleichzeitigen Funktionsinstanzen bis zur neuen Kontingente aufrufen. Standardmäßig kann Lambda so skaliert werden, dass bis zu 1.250 gleichzeitige Funktionsinstanzen für eine Amazon-SQS-Zuordnung von Ereignisquellen aufgerufen werden. Wenn dies für Ihren Anwendungsfall nicht ausreicht, wenden Sie sich an den AWS Support, um eine Erhöhung der Parallelität der Amazon SQS SQS-Ereignisquellenzuordnungen für Ihr Konto zu besprechen.
**Anmerkung**
Bei FIFO-Warteschlangen werden gleichzeitige Aufrufe entweder durch die Anzahl der [Nachrichtengruppen IDs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) (`messageGroupId`) oder durch die Einstellung für maximale Parallelität begrenzt — je nachdem, welcher Wert niedriger ist. Wenn Sie beispielsweise über sechs Nachrichtengruppen verfügen IDs und die maximale Parallelität auf 10 festgelegt ist, kann Ihre Funktion maximal sechs gleichzeitige Aufrufe haben.
Sie können die maximale Gleichzeitigkeit für neue und vorhandene Zuordnung von Ereignisquellen in Amazon SQS konfigurieren.
**Konfigurieren der maximalen Gleichzeitigkeit mithilfe der Lambda-Konsole**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie den Namen einer Funktion aus.
1. Wählen Sie unter **Function overview** (Funktionsübersicht) die Option **SQS** aus. Dadurch wird die Registerkarte **Configuration** (Konfiguration) geöffnet.
1. Wählen Sie den Amazon-SQS-Auslöser aus und klicken Sie auf **Edit** (Bearbeiten).
1. Geben Sie für **Maximum concurrency** (Maximale Gleichzeitigkeit) eine Zahl zwischen 2 und 1 000 ein. Um die maximale Gleichzeitigkeit zu deaktivieren, lassen Sie das Feld leer.
1. Wählen Sie **Speichern**.
**Konfigurieren Sie die maximale Parallelität mit der () AWS Command Line Interface AWS CLI**
Verwenden Sie den Befehl [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) mit der Option `--scaling-config` . Beispiel:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config '{"MaximumConcurrency":5}'
```
Um die maximale Gleichzeitigkeit zu deaktivieren, geben Sie einen leeren Wert für `--scaling-config` ein:
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config "{}"
```
**Konfigurieren der maximalen Gleichzeitigkeit mithilfe der Lambda-API**
Verwenden Sie die [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)Aktion [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)oder mit einem [ScalingConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ScalingConfig.html)Objekt.
# Behandlung von Fehlern für eine SQS-Ereignisquelle in Lambda
Um Fehler im Zusammenhang mit einer SQS-Ereignisquelle zu behandeln, verwendet Lambda automatisch eine Wiederholungsstrategie mit einer Backoff-Strategie. Sie können das Verhalten bei der Fehlerbehandlung auch anpassen, indem Sie Ihre SQS-Zuordnung von Ereignisquellen so konfigurieren, dass sie [partielle Batch-Antworten](#services-sqs-batchfailurereporting) zurückgibt.
## Backoff-Strategie für fehlgeschlagene Aufrufe
Wenn ein Aufruf fehlschlägt, versucht Lambda, den Aufruf zu wiederholen, während eine Backoff-Strategie implementiert wird. Die Backoff-Strategie unterscheidet sich geringfügig, je nachdem, ob Lambda den Fehler aufgrund eines Fehlers in Ihrem Funktionscode oder aufgrund einer Drosselung festgestellt hat.
+ Wenn Ihr **Funktionscode** den Fehler verursacht hat, stoppt Lambda die Verarbeitung und versucht erneut, den Aufruf zu starten. In der Zwischenzeit zieht sich Lambda allmählich zurück und reduziert die Menge der Gleichzeitigkeit, die Ihrer Amazon SQS-Zuordnung von Ereignisquellen zugewiesen wird. Nachdem die Zeitspanne für die Sichtbarkeit Ihrer Warteschlange abgelaufen ist, wird die Nachricht wieder in der Warteschlange erscheinen.
+ Wenn der Aufruf aufgrund von **Drosselung** fehlschlägt, setzt Lambda schrittweise Wiederholungsversuche zurück, indem es die Menge der Gleichzeitigkeit reduziert, die Ihrer Zuordnung von Ereignisquellen in Amazon SQS zugewiesen ist. Lambda fährt fort, die Nachricht erneut zu versuchen, bis der Zeitstempel der Nachricht das Sichtbarkeits-Timeout Ihrer Warteschlange überschreitet, an welchem Punkt Lambda die Nachricht verwirft.
## Implementierung von partiellen Batch-Antworten
Wenn die Lamda-Funktion während der Verarbeitung eines Batches auf einen Fehler stößt, werden standardmäßig alle Nachrichten in diesem Batch wieder in der Warteschlange sichtbar, einschließlich Nachrichten, die Lambda erfolgreich verarbeitet hat. Infolgedessen kann es passieren, dass die Funktion dieselbe Nachricht mehrmals verarbeitet.
Damit nicht erfolgreich bearbeiten Nachrichten in einem fehlgeschlagenen Batch erneut verarbeitet werden, können Sie die Zuordnung von Ereignisquellen so konfigurieren, dass nur die fehlgeschlagenen Nachrichten wieder sichtbar werden. Dies wird als partielle Batch-Antwort bezeichnet. Um partielle Batch-Antworten zu aktivieren, geben Sie `ReportBatchItemFailures` bei der Konfiguration Ihrer Ereignisquellenzuordnung die entsprechende [FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html#lambda-UpdateEventSourceMapping-request-FunctionResponseTypes)Aktion an. Dadurch kann die Funktion einen Teilerfolg zurückgeben, was die Anzahl unnötiger Wiederholungsversuche für Datensätze reduzieren kann.
**Anmerkung**
Das [Batch Processor Utility](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) von Powertools for AWS Lambda verarbeitet die gesamte partielle Batch-Antwortlogik automatisch. Dieses Tool vereinfacht die Implementierung von Batch-Verarbeitungsmustern und reduziert den Bedarf an benutzerdefiniertem Code, der für die korrekte Behandlung von Fehlern bei Batch-Elementen erforderlich ist. Es ist für Python, Java, Typescript und .NET verfügbar.
Wenn `ReportBatchItemFailures` aktiviert ist, [skaliert Lambda die Nachrichtenabfrage nicht herunter,](#services-sqs-backoff-strategy) wenn Funktionsaufrufe fehlschlagen. Wenn Sie erwarten, dass einige Nachrichten ausfallen – und Sie nicht möchten, dass sich diese Fehler auf die Nachrichtenverarbeitungsrate auswirken – verwenden Sie `ReportBatchItemFailures`.
**Anmerkung**
Berücksichtigen Sie bei Verwendung von partiellen Batch-Antworten Folgendes:
Wenn die Funktion eine Ausnahme ausgibt, gilt der gesamte Batch als fehlgeschlagen.
Wenn Sie dieses Feature mit einer FIFO-Warteschlange verwenden, sollte Ihre Funktion die Verarbeitung von Nachrichten nach dem ersten Fehler beenden und alle fehlgeschlagenen und nicht verarbeiteten Nachrichten in `batchItemFailures` zurückgeben. Das hilft, die Reihenfolge der Nachrichten in der Warteschlange beizubehalten.
**So aktivieren Sie partielle Batchberichterstattung**
1. Sehen Sie sich die [bewährten Methoden für die Implementierung von partiellen Batch-Antworten](https://docs.aws.amazon.com/prescriptive-guidance/latest/lambda-event-filtering-partial-batch-responses-for-sqs/best-practices-partial-batch-responses.html) an.
1. Führen Sie den folgenden Befehl aus, um `ReportBatchItemFailures` für Ihre Funktion zu aktivieren. Führen Sie den Befehl aus, um die UUID Ihrer Ereignisquellenzuordnung abzurufen. [list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) AWS CLI
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```
1. Aktualisieren Sie Ihren Funktionscode, um alle Ausnahmen abzufangen und fehlgeschlagene Nachrichten in einer `batchItemFailures`-JSON-Antwort zurückzugeben. Die `batchItemFailures` Antwort muss eine Liste von Nachrichten als IDs `itemIdentifier` JSON-Werte enthalten.
Nehmen wir beispielsweise an, Sie haben einen Stapel von fünf Nachrichten mit Nachricht IDs `id1``id2`,`id3`,`id4`, und`id5`. Die Funktion verarbeitet erfolgreich `id1`, `id3` und `id5`. Damit die Nachrichten `id2` und `id4` in der Warteschlange wieder sichtbar werden, sollte Ihre Funktion folgende Antwort zurückgeben:
```
{
"batchItemFailures": [
{
"itemIdentifier": "id2"
},
{
"itemIdentifier": "id4"
}
]
}
```
Hier sind einige Beispiele für Funktionscode, der die Liste der fehlgeschlagenen Nachrichten IDs im Batch zurückgibt:
------
#### [ .NET ]
**SDK für .NET**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von SQS-Batchelementfehlern mit Lambda unter Verwendung von .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace sqsSample;
public class Function
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
List batchItemFailures = new List();
foreach(var message in evnt.Records)
{
try
{
//process your message
await ProcessMessageAsync(message, context);
}
catch (System.Exception)
{
//Add failed message identifier to the batchItemFailures list
batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId});
}
}
return new SQSBatchResponse(batchItemFailures);
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
if (String.IsNullOrEmpty(message.Body))
{
throw new Exception("No Body in SQS Message.");
}
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
}
```
------
#### [ Go ]
**SDK für Go V2**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von SQS-Batchelementfehlern mit Lambda unter Verwendung von Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, message := range sqsEvent.Records {
if len(message.Body) > 0 {
// Your message processing condition here
fmt.Printf("Successfully processed message: %s\n", message.Body)
} else {
// Message processing failed
fmt.Printf("Failed to process message %s\n", message.MessageId)
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId})
}
}
sqsBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return sqsBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK für Java 2.x**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse;
import java.util.ArrayList;
import java.util.List;
public class ProcessSQSMessageBatch implements RequestHandler {
@Override
public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
List batchItemFailures = new ArrayList();
for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
try {
//process your message
} catch (Exception e) {
//Add failed message identifier to the batchItemFailures list
batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
}
}
return new SQSBatchResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK für JavaScript (v3)**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von SQS-Batch-Elementfehlern mit Lambda unter Verwendung von. JavaScript
```
// Node.js 20.x Lambda runtime, AWS SDK for Javascript V3
export const handler = async (event, context) => {
const batchItemFailures = [];
for (const record of event.Records) {
try {
await processMessageAsync(record, context);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return { batchItemFailures };
};
async function processMessageAsync(record, context) {
if (record.body && record.body.includes("error")) {
throw new Error("There is an error in the SQS Message.");
}
console.log(`Processed message: ${record.body}`);
}
```
Melden von SQS-Batch-Elementfehlern mit Lambda unter Verwendung von. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda';
export const handler = async (event: SQSEvent, context: Context): Promise => {
const batchItemFailures: SQSBatchItemFailure[] = [];
for (const record of event.Records) {
try {
await processMessageAsync(record);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return {batchItemFailures: batchItemFailures};
};
async function processMessageAsync(record: SQSRecord): Promise {
if (record.body && record.body.includes("error")) {
throw new Error('There is an error in the SQS Message.');
}
console.log(`Processed message ${record.body}`);
}
```
------
#### [ PHP ]
**SDK für PHP**
Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von SQS-Batchelementfehlern mit Lambda unter Verwendung von PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
$this->logger->info("Processing SQS records");
$records = $event->getRecords();
foreach ($records as $record) {
try {
// Assuming the SQS message is in JSON format
$message = json_decode($record->getBody(), true);
$this->logger->info(json_encode($message));
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$this->markAsFailed($record);
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords SQS records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK für Python (Boto3)**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
if event:
batch_item_failures = []
sqs_batch_response = {}
for record in event["Records"]:
try:
print(f"Processed message: {record['body']}")
except Exception as e:
batch_item_failures.append({"itemIdentifier": record['messageId']})
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
```
------
#### [ Ruby ]
**SDK für Ruby**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda-with-batch-item-handling).
Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'json'
def lambda_handler(event:, context:)
if event
batch_item_failures = []
sqs_batch_response = {}
event["Records"].each do |record|
begin
# process message
rescue StandardError => e
batch_item_failures << {"itemIdentifier" => record['messageId']}
end
end
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
end
end
```
------
#### [ Rust ]
**SDK für Rust**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Melden von Fehlern bei SQS-Batchelementen mit Lambda unter Verwendung von Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::sqs::{SqsBatchResponse, SqsEvent},
sqs::{BatchItemFailure, SqsMessage},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn process_record(_: &SqsMessage) -> Result<(), Error> {
Err(Error::from("Error processing message"))
}
async fn function_handler(event: LambdaEvent) -> Result {
let mut batch_item_failures = Vec::new();
for record in event.payload.records {
match process_record(&record).await {
Ok(_) => (),
Err(_) => batch_item_failures.push(BatchItemFailure {
item_identifier: record.message_id.unwrap(),
}),
}
}
Ok(SqsBatchResponse {
batch_item_failures,
})
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(function_handler)).await
}
```
------
Wenn die fehlgeschlagenen Ereignisse nicht in die Warteschlange zurückkehren, finden Sie weitere Informationen unter [Wie behebe ich Probleme mit der Lambda-Funktion ReportBatchItemFailures SQS](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sqs-report-batch-item-failures/)? im AWS Knowledge Center.
### Erfolgs- und Misserfolgsbedingungen
Lambda behandelt einen Batch als komplett erfolgreich, wenn die Funktion eines der folgenden Elemente zurückgibt:
+ Eine leere `batchItemFailures`-Liste
+ Eine ungültige `batchItemFailures`-Liste
+ Ein leeres `EventResponse`
+ Ein ungültiges `EventResponse`
Lambda behandelt einen Batch als komplett fehlgeschlagen, wenn die Funktion eines der folgenden Elemente zurückgibt:
+ Eine ungültige JSON-Antwort
+ Eine leere Zeichenfolge `itemIdentifier`
+ Ein ungültiges `itemIdentifier`
+ Ein `itemIdentifier` mit einem falschen Schlüsselnamen
+ Einen `itemIdentifier`-Wert mit einer Nachrichten-ID, die nicht existiert
### CloudWatch Metriken
Um festzustellen, ob Ihre Funktion Fehler bei Chargenartikeln korrekt meldet, können Sie die Amazon SQS-Metriken `NumberOfMessagesDeleted` und die `ApproximateAgeOfOldestMessage` Amazon SQS-Metriken in Amazon CloudWatch überwachen.
+ `NumberOfMessagesDeleted` verfolgt die Anzahl der Nachrichten, die aus der Warteschlange entfernt wurden. Wenn der Wert auf 0 sinkt, ist dies ein Zeichen dafür, dass die Funktionsantwort fehlgeschlagene Nachrichten nicht korrekt zurückgibt.
+ `ApproximateAgeOfOldestMessage` verfolgt, wie lange die älteste Nachricht in der Warteschlange geblieben ist. Ein starker Anstieg dieser Metrik kann darauf hinweisen, dass die Funktion fehlgeschlagene Nachrichten nicht korrekt zurückgibt.
### Verwendung von Powertools für AWS Lambda die Batch-Verarbeitung
Das Batchverarbeitungsprogramm von Powertools for verarbeitet AWS Lambda automatisch die Logik für partielle Batch-Antworten und reduziert so die Komplexität der Implementierung von Batch-Fehlerberichten. Hier sind Beispiele für die Verwendung des Batch-Prozessors:
**Python**
Umfassende Beispiele und Anweisungen zur Einrichtung finden Sie in der [Dokumentation zum Batch-Prozessor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Verarbeitung von Amazon SQS SQS-Nachrichten mit AWS Lambda Batch-Prozessor.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import SQSEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.SQS)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Umfassende Beispiele und Anweisungen zur Einrichtung finden Sie in der [Dokumentation zum Batch-Prozessor](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Verarbeitung von Amazon SQS SQS-Nachrichten mit AWS Lambda Batch-Prozessor.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { SQSEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.SQS);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: SQSEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
# Lambdaparameter für Amazon-SQS-Zuordnungen von Ereignisquellen
Alle Lambda-Ereignisquelltypen verwenden dieselben [CreateEventSourceMapping[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)API-Operationen. Allerdings gelten nur einige der Parameter für Amazon SQS.
| Parameter | Erforderlich | Standard | Hinweise |
| --- | --- | --- | --- |
| BatchSize | N | 10 | Bei Standardwarteschlangen beträgt der Maximalwert 10 000. Bei FIFO-Warteschlangen beträgt der Maximalwert 10. |
| Aktiviert | N | true | Keine |
| EventSourceArn | Y | – | Der ARN des Datenstroms oder eines Stream-Konsumenten |
| FunctionName | Y | – | Keine |
| FilterCriteria | N | – | [Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet](invocation-eventfiltering.md) |
| FunctionResponseTypes | N | – | Damit Ihre Funktion bestimmte Fehler in einem Batch meldet, beziehen Sie den Wert `ReportBatchItemFailures` in `FunctionResponseTypes` ein. Weitere Informationen finden Sie unter [Implementierung von partiellen Batch-Antworten](services-sqs-errorhandling.md#services-sqs-batchfailurereporting). |
| MaximumBatchingWindowInSeconds | N | 0 | Das Batching-Fenster wird für FIFO-Warteschlangen nicht unterstützt |
| ProvisionedPollerConfig | N | – | Konfiguriert die minimale (2-200) und maximale (2-2000) Anzahl von dedizierten Event-Pollern für die SQS-Ereignisquellenzuordnung. Jeder Poller kann bis zu 1 MB/sec Durchsatz und 10 gleichzeitige Aufrufe verarbeiten. |
| ScalingConfig | N | – | [Konfigurieren der maximalen Gleichzeitigkeit für Amazon-SQS-Ereignisquellen](services-sqs-scaling.md#events-sqs-max-concurrency) |
# Verwendung der Ereignisfilterung mit einer Amazon-SQS-Ereignisquelle
Sie können die Ereignisfilterung verwenden, um zu steuern, welche Datensätze aus einem Stream oder einer Warteschlange Lambda an Ihre Funktion sendet. Allgemeine Informationen über die Funktionsweise der Ereignisfilterung finden Sie unter [Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet](invocation-eventfiltering.md).
Dieser Abschnitt konzentriert sich auf die Ereignisfilterung für Amazon-SQS-Ereignisquellen.
**Anmerkung**
Amazon-SQS-Zuordnungen von Ereignisquellen unterstützen nur das Filtern nach dem `body`-Schlüssel.
**Topics**
+ [
## Grundlagen der Amazon-SQS-Ereignisfilterung
](#filtering-SQS)
## Grundlagen der Amazon-SQS-Ereignisfilterung
Angenommen, Ihre Amazon-SQS-Warteschlange enthält Nachrichten im folgenden JSON-Format.
```
{
"RecordNumber": 1234,
"TimeStamp": "yyyy-mm-ddThh:mm:ss",
"RequestCode": "AAAA"
}
```
Ein Beispieldatensatz für diese Warteschlange würde wie folgt aussehen.
```
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "{\n "RecordNumber": 1234,\n "TimeStamp": "yyyy-mm-ddThh:mm:ss",\n "RequestCode": "AAAA"\n}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:my-queue",
"awsRegion": "us-west-2"
}
```
Um anhand des Inhalts Ihrer Amazon-SQS-Nachrichten zu filtern, verwenden Sie den `body`-Schlüssel im Amazon-SQS-Nachrichtendatensatz. Angenommen, Sie möchten nur die Datensätze verarbeiten, bei denen `RequestCode` in Ihrer Amazon-SQS-Nachricht „BBBB“ ist. Das `FilterCriteria`-Objekt würde wie folgt aussehen.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"
}
]
}
```
Zur Verdeutlichung sehen Sie hier den Wert des Filter-`Pattern` in reinem JSON.
```
{
"body": {
"RequestCode": [ "BBBB" ]
}
}
```
Sie können Ihren Filter mithilfe der Konsole, AWS CLI oder einer AWS SAM-Vorlage hinzufügen.
------
#### [ Console ]
Um diesen Filter mithilfe der Konsole hinzuzufügen, folgen Sie den Anweisungen unter [Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (Konsole)](invocation-eventfiltering.md#filtering-console) und geben Sie die folgende Zeichenfolge für die **Filterkriterien** ein.
```
{ "body" : { "RequestCode" : [ "BBBB" ] } }
```
------
#### [ AWS CLI ]
Um eine neue Zuordnung von Ereignisquellen mit diesen Filterkriterien über die AWS Command Line Interface (AWS CLI) zu erstellen, führen Sie den folgenden Befehl aus.
```
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": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
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": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
------
#### [ AWS SAM ]
Um diesen Filter mit der AWS SAM hinzuzufügen, fügen Sie das folgende Snippet zur YAML-Vorlage für Ihre Ereignisquelle hinzu.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RequestCode" : [ "BBBB" ] } }'
```
------
Angenommen, Sie möchten, dass Ihre Funktion nur die Datensätze verarbeitet, bei denen `RecordNumber` größer als 9999 ist. Das `FilterCriteria`-Objekt würde wie folgt aussehen.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"
}
]
}
```
Zur Verdeutlichung sehen Sie hier den Wert des Filter-`Pattern` in reinem JSON.
```
{
"body": {
"RecordNumber": [
{
"numeric": [ ">", 9999 ]
}
]
}
}
```
Sie können Ihren Filter mithilfe der Konsole, AWS CLI oder einer AWS SAM-Vorlage hinzufügen.
------
#### [ Console ]
Um diesen Filter mithilfe der Konsole hinzuzufügen, folgen Sie den Anweisungen unter [Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (Konsole)](invocation-eventfiltering.md#filtering-console) und geben Sie die folgende Zeichenfolge für die **Filterkriterien** ein.
```
{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }
```
------
#### [ AWS CLI ]
Um eine neue Zuordnung von Ereignisquellen mit diesen Filterkriterien über die AWS Command Line Interface (AWS CLI) zu erstellen, führen Sie den folgenden Befehl aus.
```
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": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
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": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Um diesen Filter mit der AWS SAM hinzuzufügen, fügen Sie das folgende Snippet zur YAML-Vorlage für Ihre Ereignisquelle hinzu.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }'
```
------
Für Amazon SQS kann der Nachrichtenkörper eine beliebige Zeichenfolge sein. Dies kann jedoch problematisch sein, wenn die `FilterCriteria` erwarten, dass `body` ein gültiges JSON-Format hat. Umgekehrt gilt dasselbe – wenn der Textkörper der eingehenden Nachricht ein JSON-Format aufweist, die Filterkriterien jedoch erwarten, dass `body` eine einfache Zeichenfolge ist, kann dies zu unbeabsichtigtem Verhalten führen.
Um dieses Problem zu vermeiden, stellen Sie sicher, dass das Körperformat in Ihren `FilterCriteria` mit dem erwarteten Format von `body` in den Nachrichten übereinstimmt, die Sie von Ihrer Warteschlange erhalten. Bevor Sie Ihre Nachrichten filtern, wertet Lambda automatisch das Format des Körpers der eingehenden Nachricht und Ihres Filtermusters für `body` aus. Wenn es keine Übereinstimmung gibt, verwirft Lambda die Nachricht. In der folgenden Tabelle ist diese Auswertung zusammengefasst:
| `body`-Format der eingehenden Nachricht | `body`-Format des Filtermusters | Resultierende Aktion |
| --- | --- | --- |
| Einfache Zeichenfolge | Einfache Zeichenfolge | Lambda filtert basierend auf Ihren Filterkriterien. |
| Einfache Zeichenfolge | Kein Filtermuster für Dateneigenschaften | Lambda filtert (nur für die anderen Metadateneigenschaften) basierend auf Ihren Filterkriterien. |
| Einfache Zeichenfolge | Gültiges JSON | Lambda verwirft die Nachricht. |
| Gültiges JSON | Einfache Zeichenfolge | Lambda verwirft die Nachricht. |
| Gültiges JSON | Kein Filtermuster für Dateneigenschaften | Lambda filtert (nur für die anderen Metadateneigenschaften) basierend auf Ihren Filterkriterien. |
| Gültiges JSON | Gültiges JSON | Lambda filtert basierend auf Ihren Filterkriterien. |
# Tutorial: Verwenden von Lambda mit Amazon SQS
In diesem Tutorial erstellen Sie eine Lambda-Funktion, die Nachrichten aus einer Warteschlange von [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) verarbeitet. Die Lambda-Funktion wird ausgeführt, wenn der Warteschlange eine neue Nachricht hinzugefügt wird. Die Funktion schreibt die Nachrichten in einen Amazon CloudWatch Logs-Stream. Das folgende Diagramm zeigt die AWS -Ressourcen, die Sie zur Durchführung des Tutorials verwenden.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_resources.png)
Führen Sie für dieses Tutorial die folgenden Schritte aus:
1. Erstellen Sie eine Lambda-Funktion, die Nachrichten in CloudWatch Logs schreibt.
1. Erstellen einer Amazon SQS-Warteschlange
1. Erstellen Sie eine Zuordnung von Ereignisquellen in Lambda. Die Zuordnung von Ereignisquellen liest die Amazon-SQS-Warteschlange und ruft Ihre Lambda-Funktion auf, wenn eine neue Nachricht hinzugefügt wird.
1. Testen Sie das Setup, indem Sie Nachrichten zu Ihrer Warteschlange hinzufügen und die Ergebnisse in CloudWatch Logs überwachen.
## Voraussetzungen
### Installieren Sie das AWS Command Line Interface
Wenn Sie das noch nicht installiert haben AWS Command Line Interface, folgen Sie den Schritten unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), um es zu installieren.
Das Tutorial erfordert zum Ausführen von Befehlen ein Befehlszeilenterminal oder eine Shell. Verwenden Sie unter Linux und macOS Ihre bevorzugte Shell und Ihren bevorzugten Paketmanager.
**Anmerkung**
In Windows werden einige Bash-CLI-Befehle, die Sie häufig mit Lambda verwenden (z. B. `zip`), von den integrierten Terminals des Betriebssystems nicht unterstützt. Um eine in Windows integrierte Version von Ubuntu und Bash zu erhalten, [installieren Sie das Windows-Subsystem für Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Erstellen der Ausführungsrolle
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps1.png)
Eine [Ausführungsrolle](lambda-intro-execution-role.md) ist eine AWS Identity and Access Management (IAM-) Rolle, die einer Lambda-Funktion Zugriff AWS-Services und Ressourcen gewährt. Damit Ihre Funktion Elemente aus Amazon SQS lesen kann, fügen Sie die **AWSLambdaSQSQueueExecutionRole**Berechtigungsrichtlinie bei.
**So erstellen Sie eine Ausführungsrolle und fügen eine Amazon-SQS-Berechtigungsrichtlinie hinzu**
1. Öffnen Sie die Seite [Roles (Rollen)](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole.
1. Wählen Sie **Rolle erstellen** aus.
1. Wählen Sie unter **Vertrauenswürdiger Entitätstyp** die Option **AWS -Service** aus.
1. Wählen Sie unter **Anwendungsfall** die Option **Lambda** aus.
1. Wählen Sie **Weiter** aus.
1. Geben Sie im Suchfeld **Berechtigungsrichtlinien** die Zeichenfolge **AWSLambdaSQSQueueExecutionRole** ein.
1. Wählen Sie die **AWSLambdaSQSQueueExecutionRole**Richtlinie aus und klicken Sie dann auf **Weiter**.
1. Geben Sie unter **Rollendetails** für **Rollenname** den Namen **lambda-sqs-role** ein und wählen Sie anschließend **Rolle erstellen** aus.
Schreiben Sie sich nach der Erstellung der Rolle den Amazon-Ressourcennamen (ARN) Ihrer Ausführungsrolle auf. Sie werden ihn in späteren Schritten noch benötigen.
## Erstellen der Funktion
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps2.png)
Erstellen Sie eine Lambda-Funktion, die Ihre Amazon-SQS-Nachrichten verarbeitet. Der Funktionscode protokolliert den Hauptteil der Amazon SQS-Nachricht in CloudWatch Logs.
Dieses Tutorial verwendet die Runtime Node.js 24, aber wir haben auch Beispielcode in anderen Runtime-Sprachen bereitgestellt. Sie können die Registerkarte im folgenden Feld auswählen, um Code für die gewünschte Laufzeit anzusehen. Der JavaScript Code, den Sie in diesem Schritt verwenden, befindet sich im ersten Beispiel, das auf der **JavaScript**Registerkarte angezeigt wird.
------
#### [ .NET ]
**SDK für .NET**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SqsIntegrationSampleCode
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
foreach (var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**SDK für Go V2**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package integration_sqs_to_lambda
import (
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.SQSEvent) error {
for _, record := range event.Records {
err := processMessage(record)
if err != nil {
return err
}
}
fmt.Println("done")
return nil
}
func processMessage(record events.SQSMessage) error {
fmt.Printf("Processed message %s\n", record.Body)
// TODO: Do interesting work based on the new message
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK für Java 2.x**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;
public class Function implements RequestHandler {
@Override
public Void handleRequest(SQSEvent sqsEvent, Context context) {
for (SQSMessage msg : sqsEvent.getRecords()) {
processMessage(msg, context);
}
context.getLogger().log("done");
return null;
}
private void processMessage(SQSMessage msg, Context context) {
try {
context.getLogger().log("Processed message " + msg.getBody());
// TODO: Do interesting work based on the new message
} catch (Exception e) {
context.getLogger().log("An error occurred");
throw e;
}
}
}
```
------
#### [ JavaScript ]
**SDK für JavaScript (v3)**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sqs-to-lambda).
Konsumieren eines SQS-Ereignisses mit Lambda unter Verwendung. JavaScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message) {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Konsumieren eines SQS-Ereignisses mit Lambda unter Verwendung. TypeScript
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, Context, SQSHandler, SQSRecord } from "aws-lambda";
export const functionHandler: SQSHandler = async (
event: SQSEvent,
context: Context
): Promise => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message: SQSRecord): Promise {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**SDK für PHP**
Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
foreach ($event->getRecords() as $record) {
$body = $record->getBody();
// TODO: Do interesting work based on the new message
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK für Python (Boto3)**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for message in event['Records']:
process_message(message)
print("done")
def process_message(message):
try:
print(f"Processed message {message['body']}")
# TODO: Do interesting work based on the new message
except Exception as err:
print("An error occurred")
raise err
```
------
#### [ Ruby ]
**SDK für Ruby**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].each do |message|
process_message(message)
end
puts "done"
end
def process_message(message)
begin
puts "Processed message #{message['body']}"
# TODO: Do interesting work based on the new message
rescue StandardError => err
puts "An error occurred"
raise err
end
end
```
------
#### [ Rust ]
**SDK für Rust**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Nutzen eines SQS-Ereignisses mit Lambda unter Verwendung von Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
event.payload.records.iter().for_each(|record| {
// process the record
tracing::info!("Message body: {}", record.body.as_deref().unwrap_or_default())
});
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**So erstellen Sie eine Node.js-Lambda-Funktion**
1. Erstellen Sie ein Verzeichnis für das Projekt und wechseln Sie dann zu diesem Verzeichnis.
```
mkdir sqs-tutorial
cd sqs-tutorial
```
1. Kopieren Sie den JavaScript Beispielcode in eine neue Datei mit dem Namen`index.js`.
1. Erstellen Sie ein Bereitstellungspaket mit dem folgenden `zip`-Befehl.
```
zip function.zip index.js
```
1. Erstellen Sie eine Lambda-Funktion mithilfe des AWS CLI -Befehls [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Geben Sie für den `role`-Parameter den ARN der Ausführungsrolle ein, die Sie zuvor erstellt haben.
**Anmerkung**
Die Lambda-Funktion und die Amazon-SQS-Warteschlange müssen sich in demselben AWS-Region befinden.
```
aws lambda create-function --function-name ProcessSQSRecord \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-sqs-role
```
## Testen der Funktion
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps3.png)
Rufen Sie Ihre Lambda-Funktion manuell mit dem `invoke` AWS CLI Befehl und einem Amazon SQS SQS-Beispielereignis auf.
**So rufen Sie die Lambda-Funktion mit einem Beispielereignis auf**
1. Speichern Sie die folgende JSON als Datei mit dem Namen `input.json`. Dieser JSON-Code simuliert ein Ereignis, das so ggf. von Amazon SQS an Ihre Lambda-Funktion gesendet wird, wobei `"body"` die tatsächliche Nachricht aus der Warteschlange enthält. In diesem Beispiel lautet die Nachricht `"test"`.
**Example Amazon-SQS-Ereignis**
Dies ist ein Testereignis. Nachricht und Kontonummer müssen nicht geändert werden.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:my-queue",
"awsRegion": "us-east-1"
}
]
}
```
1. [Führen Sie den folgenden Invoke-Befehl aus.](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) AWS CLI Dieser Befehl gibt CloudWatch Logs in der Antwort zurück. Weitere Informationen über das Abrufen von Protokollen finden Sie unter [Zugriffs-Logs mit dem AWS CLI](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-cli).
```
aws lambda invoke --function-name ProcessSQSRecord --payload file://input.json out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
Die **cli-binary-format** Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface -Benutzerhandbuch für Version 2*.
1. Suchen Sie in der Antwort nach dem Protokoll `INFO`. Dort protokolliert die Lambda-Funktion den Nachrichtentext. Sie sollten Protokolle sehen, die wie folgt aussehen:
```
2023-09-11T22:45:04.271Z 348529ce-2211-4222-9099-59d07d837b60 INFO Processed message test
2023-09-11T22:45:04.288Z 348529ce-2211-4222-9099-59d07d837b60 INFO done
```
## Erstellen einer Amazon-SQS-Warteschlange
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps4.png)
Erstellen Sie eine Amazon-SQS-Warteschlange, die die Lambda-Funktion als Ereignisquelle verwenden kann. Die Lambda-Funktion und die Amazon-SQS-Warteschlange müssen sich in demselben AWS-Region befinden.
**So erstellen Sie eine Warteschlange**
1. Öffnen Sie die [Amazon-SQS-Konsole](https://console.aws.amazon.com/sqs).
1. Wählen Sie **Create queue** (Warteschlange erstellen) aus.
1. Geben Sie einen Namen für die Warteschlange ein. Übernehmen Sie bei allen anderen Optionen die Standardeinstellungen.
1. Wählen Sie **Create queue** (Warteschlange erstellen) aus.
Notieren Sie sich nach dem Erstellen der Warteschlange ihren ARN. Sie benötigen ihn im nächsten Schritt, um die Warteschlange Ihrer Lambda-Funktion zuzuordnen.
## Konfigurieren der Ereignisquelle
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps5.png)
Verbinden Sie die Amazon-SQS-Warteschlange mit Ihrer Lambda-Funktion, indem Sie eine [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md) erstellen. Die Zuordnung von Ereignisquellen liest die Amazon-SQS-Warteschlange und ruft Ihre Lambda-Funktion auf, wenn eine neue Nachricht hinzugefügt wird.
Verwenden Sie den Befehl, um eine Zuordnung zwischen Ihrer Amazon SQS SQS-Warteschlange und Ihrer Lambda-Funktion zu erstellen. [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Beispiel:
```
aws lambda create-event-source-mapping --function-name ProcessSQSRecord --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:111122223333:my-queue
```
Verwenden Sie den Befehl, um eine Liste Ihrer Ereignisquellenzuordnungen abzurufen. [list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/lambda/list-event-source-mappings.html) Beispiel:
```
aws lambda list-event-source-mappings --function-name ProcessSQSRecord
```
## Senden einer Testnachricht
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps6.png)
**So senden Sie eine Amazon-SQS-Nachricht an die Lambda-Funktion**
1. Öffnen Sie die [Amazon-SQS-Konsole](https://console.aws.amazon.com/sqs).
1. Wählen Sie die Warteschlange aus, die Sie zuvor erstellt haben.
1. Wählen Sie **Nachrichten senden und empfangen**.
1. Geben Sie unter **Nachrichtentext** eine Testnachricht ein (z. B. „Dies ist eine Testnachricht.“).
1. Klicken Sie auf **Send Message (Nachricht senden)**.
Lambda fragt die Warteschlange nach Aktualisierungen ab. Wenn eine neue Nachricht vorliegt, ruft Lambda Ihre Funktion mit diesen neuen Ereignisdaten aus der Warteschlange auf. Wenn der Funktions-Handler ohne Ausnahmen zurückgegeben wird, betrachtet Lambda die Nachricht als erfolgreich verarbeitet und beginnt mit dem Lesen neuer Nachrichten in der Warteschlange. Nach erfolgreicher Verarbeitung einer Nachricht löscht Lambda diese automatisch aus der Warteschlange. Wenn der Handler eine Ausnahme auslöst, betrachtet Lambda den Nachrichten-Batch als nicht erfolgreich verarbeitet und Lambda ruft die Funktion mit demselben Nachrichten-Batch auf.
## Überprüfen Sie die Protokolle CloudWatch
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/sqs_tut_steps7.png)
**So vergewissern Sie sich, dass die Funktion die Nachricht verarbeitet hat**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die SQSRecord Funktion „**Verarbeiten**“.
1. Wählen Sie **Überwachen** aus.
1. Wählen Sie ** CloudWatch Protokolle anzeigen**.
1. Wählen Sie in der CloudWatch Konsole den **Protokollstream** für die Funktion aus.
1. Suchen Sie das Protokoll `INFO`. Dort protokolliert die Lambda-Funktion den Nachrichtentext. Sie sollten die Nachricht sehen, die Sie über die Amazon-SQS-Warteschlange gesendet haben. Beispiel:
```
2023-09-11T22:49:12.730Z b0c41e9c-0556-5a8b-af83-43e59efeec71 INFO Processed message this is a test message.
```
## Bereinigen Ihrer Ressourcen
Sie können jetzt die Ressourcen, die Sie für dieses Tutorial erstellt haben, löschen, es sei denn, Sie möchten sie behalten. Durch das Löschen von AWS Ressourcen, die Sie nicht mehr verwenden, vermeiden Sie unnötige Kosten für Ihre AWS-Konto.
**So löschen Sie die Ausführungsrolle**
1. Öffnen Sie die Seite [Roles](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole.
1. Wählen Sie die von Ihnen erstellte Ausführungsrolle aus.
1. Wählen Sie **Löschen** aus.
1. Geben Sie den Namen der Rolle in das Texteingabefeld ein und wählen Sie **Delete** (Löschen) aus.
**So löschen Sie die Lambda-Funktion:**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion aus, die Sie erstellt haben.
1. Wählen Sie **Aktionen**, **Löschen** aus.
1. Geben Sie **confirm** in das Texteingabefeld ein und wählen Sie **Delete** (Löschen) aus.
**So löschen Sie die Amazon-SQS-Warteschlange**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon SQS SQS-Konsole unter [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/).
1. Wählen Sie die Warteschlange aus, die Sie erstellt haben.
1. Wählen Sie **Löschen** aus.
1. Geben Sie **confirm** in das Texteingabefeld ein.
1. Wählen Sie **Löschen** aus.
# Tutorial: Verwenden einer kontoübergreifenden Amazon SQS SQS-Warteschlange als Ereignisquelle
In diesem Tutorial erstellen Sie eine Lambda-Funktion, die Nachrichten aus einer Amazon Simple Queue Service (Amazon SQS) -Warteschlange in einem anderen Konto verarbeitet. AWS Dieses Tutorial umfasst zwei AWS Konten: **Konto A** bezieht sich auf das Konto, das Ihre Lambda-Funktion enthält, und **Konto B bezieht sich auf das Konto**, das die Amazon SQS SQS-Warteschlange enthält.
## Voraussetzungen
### Installieren Sie das AWS Command Line Interface
Wenn Sie das noch nicht installiert haben AWS Command Line Interface, folgen Sie den Schritten unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), um es zu installieren.
Das Tutorial erfordert zum Ausführen von Befehlen ein Befehlszeilenterminal oder eine Shell. Verwenden Sie unter Linux und macOS Ihre bevorzugte Shell und Ihren bevorzugten Paketmanager.
**Anmerkung**
In Windows werden einige Bash-CLI-Befehle, die Sie häufig mit Lambda verwenden (z. B. `zip`), von den integrierten Terminals des Betriebssystems nicht unterstützt. Um eine in Windows integrierte Version von Ubuntu und Bash zu erhalten, [installieren Sie das Windows-Subsystem für Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Erstellen der Ausführungsrolle (Konto A)
Erstellen Sie in **Konto A** eine [Ausführungsrolle](lambda-intro-execution-role.md), die Ihrer Funktion den Zugriff auf die erforderlichen AWS Ressourcen gewährt.
**So erstellen Sie eine Ausführungsrolle**
1. Öffnen Sie die [Seite Rollen](https://console.aws.amazon.com/iam/home#/roles) in der AWS Identity and Access Management (IAM-) Konsole.
1. Wählen Sie **Rolle erstellen** aus.
1. Erstellen Sie eine Rolle mit den folgenden Eigenschaften.
+ **Vertrauenswürdige Entität** – **AWS Lambda**.
+ **Berechtigungen** – **AWSLambdaSQSQueueExecutionRole**
+ **Role name (Name der Rolle** – **cross-account-lambda-sqs-role**
Die **AWSLambdaSQSQueueExecutionRole**Richtlinie verfügt über die Berechtigungen, die die Funktion zum Lesen von Elementen aus Amazon SQS und zum Schreiben von Protokollen in Amazon CloudWatch Logs benötigt.
## Erstellen Sie die Funktion (Account A)
Erstellen Sie in **Konto A** eine Lambda-Funktion, die Ihre Amazon SQS-Nachrichten verarbeitet. Die Lambda-Funktion und die Amazon-SQS-Warteschlange müssen sich in demselben AWS-Region befinden.
Das folgende Codebeispiel für Node.js schreibt jede Nachricht in ein Protokoll in CloudWatch Logs.
**Example index.mjs**
```
export const handler = async function(event, context) {
event.Records.forEach(record => {
const { body } = record;
console.log(body);
});
return {};
}
```
**So erstellen Sie die Funktion**
**Anmerkung**
Mit diesen Schritten wird eine Node.js-Funktion erstellt. Für andere Sprachen sind die Schritte ähnlich, aber einige Details unterscheiden sich.
1. Speichern Sie das Codebeispiel als Datei mit dem Namen `index.mjs`.
1. Erstellen Sie ein Bereitstellungspaket.
```
zip function.zip index.mjs
```
1. Erstellen Sie die Funktion mit dem Befehl `create-function` AWS Command Line Interface (AWS CLI). Ersetzen Sie `arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role` durch den ARN der Ausführungsrolle, die Sie zuvor erstellt haben.
```
aws lambda create-function --function-name CrossAccountSQSExample \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role
```
## Testen Sie die Funktion (Konto A)
Testen Sie in **Konto A** Ihre Lambda-Funktion manuell mithilfe des `invoke` AWS CLI Befehls und eines Amazon SQS SQS-Beispielereignisses.
Wenn der Handler normal und ohne Ausnahmen zurückkehrt, betrachtet Lambda die Nachricht als erfolgreich verarbeitet und beginnt mit dem Lesen neuer Nachrichten in der Warteschlange. Nach erfolgreicher Verarbeitung einer Nachricht löscht Lambda diese automatisch aus der Warteschlange. Wenn der Handler eine Ausnahme auslöst, betrachtet Lambda den Nachrichten-Batch als nicht erfolgreich verarbeitet und Lambda ruft die Funktion mit demselben Nachrichten-Batch auf.
1. Speichern Sie die folgende JSON als Datei mit dem Namen `input.txt`.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:example-queue",
"awsRegion": "us-east-1"
}
]
}
```
Das vorangehende JSON simuliert ein Ereignis, das Amazon SQS an Ihre Lambda-Funktion senden könnte, wobei `"body"` die tatsächliche Nachricht aus der Warteschlange enthält.
1. Führen Sie den Befehl `invoke` AWS CLI aus.
```
aws lambda invoke --function-name CrossAccountSQSExample \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
Die **cli-binary-format** Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface -Benutzerhandbuch für Version 2*.
1. Überprüfen Sie die Ausgabe in der Datei `outputfile.txt`.
## Erstellen einer Amazon SQS-Warteschlange (Konto B)
Erstellen Sie in **Konto B** eine Amazon SQS-Warteschlange, die die Lambda-Funktion in **Konto A** als Ereignisquelle verwenden kann. Die Lambda-Funktion und die Amazon-SQS-Warteschlange müssen sich in demselben AWS-Region befinden.
**So erstellen Sie eine Warteschlange**
1. Öffnen Sie die [Amazon-SQS-Konsole](https://console.aws.amazon.com/sqs).
1. Wählen Sie **Create queue** (Warteschlange erstellen) aus.
1. Erstellen Sie eine Warteschlange mit den folgenden Eigenschaften.
+ **Typ** – **Standard**
+ **Name (Name** – **LambdaCrossAccountQueue**
+ **Konfiguration** – Behalten Sie die Standardeinstellungen bei.
+ **Zugriffsrichtlinie** – Wählen Sie **Advanced** (Erweitert). Fügen Sie die folgende JSON-Richtlinie ein. Ersetzen Sie die folgenden Werte:
+ `111122223333`: AWS-Konto ID für **Konto A**
+ `444455556666`: AWS-Konto ID für **Konto B**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue"
}
]
}
```
------
Diese Richtlinie gewährt der Lambda-Ausführungsrolle in **Konto A** Berechtigungen zur Nutzung von Nachrichten aus dieser Amazon-SQS-Warteschlange.
1. Zeichnen Sie nach dem Erstellen der Warteschlange ihren Amazon-Ressourcennamen (ARN) auf. Sie benötigen ihn im nächsten Schritt, um die Warteschlange Ihrer Lambda-Funktion zuzuordnen.
## Konfigurieren Sie die Ereignisquelle (Konto A)
Erstellen Sie in **Konto A eine** Ereignisquellenzuordnung zwischen der Amazon SQS SQS-Warteschlange in **Konto B** und Ihrer Lambda-Funktion, indem Sie den folgenden `create-event-source-mapping` AWS CLI Befehl ausführen. Ersetzen Sie `arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue` durch den ARN der Amazon-SQS-Warteschlange, die Sie im vorherigen Schritt erstellt haben.
```
aws lambda create-event-source-mapping --function-name CrossAccountSQSExample --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
Führen Sie den folgenden Befehl aus, um eine Liste Ihrer Ereignisquellen-Zuweisung abzurufen.
```
aws lambda list-event-source-mappings --function-name CrossAccountSQSExample \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
## Testen der Einrichtung
Sie können die Einrichtung nun wie folgt testen:
1. In **Konto B** öffnen Sie die [Amazon-SQS-Konsole](https://console.aws.amazon.com/sqs).
1. Wählen Sie **LambdaCrossAccountQueue**, was Sie zuvor erstellt haben.
1. Wählen Sie **Nachrichten senden und empfangen**.
1. Geben Sie unter **Nachrichtentext** eine Testnachricht ein.
1. Klicken Sie auf **Send Message (Nachricht senden)**.
Ihre Lambda-Funktion**Konto A**sollte die Nachricht erhalten. Lambda wird die Warteschlange weiterhin nach Updates abfragen. Wenn eine neue Nachricht vorliegt, ruft Lambda Ihre Funktion mit diesen neuen Ereignisdaten aus der Warteschlange auf. Ihre Funktion wird in Amazon ausgeführt und erstellt Protokolle CloudWatch. Sie können die Protokolle in der [CloudWatch -Konsole](https://console.aws.amazon.com/cloudwatch) ansehen.
## Bereinigen Ihrer Ressourcen
Sie können jetzt die Ressourcen, die Sie für dieses Tutorial erstellt haben, löschen, es sei denn, Sie möchten sie behalten. Indem Sie AWS Ressourcen löschen, die Sie nicht mehr verwenden, vermeiden Sie unnötige Kosten für Ihre AWS-Konto.
In :**Konto A**Bereinigen Sie Ihre Ausführungsrolle und Lambda-Funktion.
**So löschen Sie die Ausführungsrolle**
1. Öffnen Sie die Seite [Roles](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole.
1. Wählen Sie die von Ihnen erstellte Ausführungsrolle aus.
1. Wählen Sie **Löschen** aus.
1. Geben Sie den Namen der Rolle in das Texteingabefeld ein und wählen Sie **Delete** (Löschen) aus.
**So löschen Sie die Lambda-Funktion:**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion aus, die Sie erstellt haben.
1. Wählen Sie **Aktionen**, **Löschen** aus.
1. Geben Sie **confirm** in das Texteingabefeld ein und wählen Sie **Delete** (Löschen) aus.
In :**Konto B**Bereinigen Sie die Amazon SQS SQS-Warteschlange.
**So löschen Sie die Amazon-SQS-Warteschlange**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon SQS SQS-Konsole unter [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/).
1. Wählen Sie die Warteschlange aus, die Sie erstellt haben.
1. Wählen Sie **Löschen** aus.
1. Geben Sie **confirm** in das Texteingabefeld ein.
1. Wählen Sie **Löschen** aus.