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 MQ **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). Amazon MQ ist ein verwalteter Message-Broker-Service für [Apache ActiveMQ](https://activemq.apache.org/) und [RabbitMQ](https://www.rabbitmq.com). Mit einem *Message Broker* können Software-Anwendungen und -Komponenten mithilfe verschiedener Programmiersprachen, Betriebssysteme und formeller Messaging-Protokolle entweder über Themen- oder Queue-Ereigniszielen miteinander kommunizieren. Amazon MQ kann auch Amazon-Elastic-Compute-Cloud-(Amazon-EC2)-Instances in Ihrem Namen verwalten, indem es ActiveMQ- oder RabbitMQ-Broker installiert und verschiedene Netzwerktopologien und andere Infrastrukturanforderungen bereitstellt. Verwenden Sie eine Lambda-Funktion, um Datensätze von Ihrem Amazon-MQ-Message-Broker zu verarbeiten. Lambda ruft Ihre Funktion über ein [Ereignisquellen-Zuweisung](invocation-eventsourcemapping.md) auf, eine Lambda-Ressource, die Nachrichten von Ihrem Broker liest und die Funktion [synchron](invocation-sync.md) aufruft. **Warnung** Zuordnungen 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 Das Amazon-MQ-Ereignisquellen-Zuweisung hat die folgenden Konfigurationseinschränkungen: + Parallelität – Lambda-Funktionen, die eine Amazon MQ-Zuordnung von Ereignisquellen verwenden, haben eine Standardeinstellung für maximale [Parallelität](lambda-concurrency.md). Für ActiveMQ begrenzt der Lambda-Service die Anzahl der gleichzeitigen Ausführungsumgebungen auf fünf pro Amazon MQ-Zuordnung von Ereignisquellen. Für RabbitMQ ist die Anzahl der gleichzeitigen Ausführungsumgebungen auf 1 pro Amazon MQ-Zuordnung von Ereignisquellen begrenzt. Selbst wenn Sie die reservierten oder bereitgestellten Parallelitätseinstellungen Ihrer Funktion ändern, stellt der Lambda-Service keine weiteren Ausführungsumgebungen zur Verfügung. Um eine Erhöhung der standardmäßigen maximalen Parallelität für eine einzelne Amazon MQ MQ-Ereignisquellenzuordnung zu beantragen, wenden Sie sich an Support die UUID der Ereignisquellenzuweisung sowie an die Region. Da Erhöhungen auf der Ebene der spezifischen Zuordnung von Ereignisquellen und nicht auf der Ebene des Kontos oder der Region vorgenommen werden, müssen Sie für jede Zuordnung von Ereignisquellen manuell eine Skalierungserhöhung anfordern. + Kontoübergreifend – Lambda unterstützt keine kontoübergreifende Verarbeitung. Sie können Lambda nicht zur Verarbeitung von Datensätzen von einem Amazon-MQ-Message Broker verwenden, der sich in einem anderen  AWS-Konto befindet. + Authentifizierung — Für ActiveMQ wird nur [SimpleAuthenticationPlugin](https://activemq.apache.org/security#simple-authentication-plugin)ActiveMQ unterstützt. Für RabbitMQ wird nur der [PLAIN](https://www.rabbitmq.com/access-control.html#mechanisms)-Authentifizierungsmechanismus unterstützt. Benutzer müssen es verwenden, AWS Secrets Manager um ihre Anmeldeinformationen zu verwalten. Weitere Informationen zur ActiveMQ-Authentifizierung finden Sie unter [Integrieren von ActiveMQ-Brokern mit LDAP](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/security-authentication-authorization.html) im *Amazon-MQ-Entwicklerhandbuch*. + Verbindungskontingent – Broker haben eine maximale Anzahl zulässiger Verbindungen pro Wire-Level-Protokoll. Dieses Kontingent basiert auf dem Instance-Typ des Brokers. Weitere Informationen finden Sie im Abschnitt [Broker](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-limits.html#broker-limits) in **Kontingente in Amazon MQ** im *Amazon-MQ-Entwicklerhandbuch*. + Konnektivität – Sie können Broker in einer öffentlichen oder privaten Virtual Private Cloud (VPC) erstellen. Für private Zwecke VPCs benötigt Ihre Lambda-Funktion Zugriff auf die VPC, um Nachrichten zu empfangen. Weitere Informationen finden Sie unter [Konfigurieren Sie die Netzwerksicherheit](process-mq-messages-with-lambda.md#process-mq-messages-with-lambda-networkconfiguration), weiter unten in diesem Abschnitt. + Ereignisziele – Es werden nur Warteschlangenziele unterstützt. Sie können jedoch ein virtuelles Thema verwenden, das sich intern wie ein Thema verhält, während es mit Lambda als eine Warteschlange interagiert. Weitere Informationen finden Sie unter [virtuelle Ziele](https://activemq.apache.org/virtual-destinations) auf der Apache-ActiveMQ-Website und [virtuelle Hosts](https://www.rabbitmq.com/vhosts.html) auf der RabbitMQ-Website. + Netzwerktopologie – Für ActiveMQ wird nur ein Einzelinstance- oder Standby-Broker pro Ereignisquellen-Zuweisung unterstützt. Für RabbitMQ wird nur eine Einzelinstance-Broker- oder Cluster-Bereitstellung pro Ereignisquellen-Zuweisung unterstützt. Single-Instance-Broker benötigen einen Failover-Endpunkt. Weitere Informationen zu diesen Broker-Bereitstellungsmodi finden Sie unter [Aktive MQ-Broker-Architektur](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-broker-architecture.html) und [Broker-Architektur von Rabbit MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-broker-architecture.html) im *Entwicklerhandbuch für Amazon MQ*. + Protokolle – Die unterstützten Protokolle hängen vom Typ der Amazon-MQ-Integration ab. + Für ActiveMQ-Integrationen verwendet Lambda Nachrichten mithilfe des OpenWire/Java Message Service (JMS) -Protokolls. Es werden keine anderen Protokolle unterstützt, um Nachrichten zu verbrauchen. Innerhalb des JMS-Protokolls werden nur [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.6.0/html/classactivemq_1_1commands_1_1_active_m_q_text_message.html) und [https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html](https://activemq.apache.org/components/cms/api_docs/activemqcpp-3.9.0/html/classactivemq_1_1commands_1_1_active_m_q_bytes_message.html) unterstützt. Lambda unterstützt auch benutzerdefinierte JMS-Eigenschaften. Weitere Informationen zum OpenWire Protokoll finden Sie [OpenWire](https://activemq.apache.org/openwire.html)auf der Apache ActiveMQ-Website. + Bei RabbitMQ-Integrationen verbraucht Lambda Nachrichten mit dem AMQP-0-9-1-Protokoll. Es werden keine anderen Protokolle unterstützt, um Nachrichten zu verbrauchen. Weitere Informationen zur Implementierung des AMQP 0-9-1-Protokolls durch RabbitMQ finden Sie im [Kompletten AMQ-0-9-1-Referenzhandbuch](https://www.rabbitmq.com/amqp-0-9-1-reference.html) auf der RabbitMQ-Website. Lambda unterstützt automatisch die neuesten Versionen von ActiveMQ und RabbitMQ, die Amazon MQ unterstützt. Die neuesten unterstützten Versionen finden Sie in den [ Amazon-MQ-Versionshinweisen](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-release-notes.html) im *Amazon-MQ-Entwicklerhandbuch*. **Anmerkung** Amazon MQ hat standardmäßig ein wöchentliches Wartungsfenster für Broker. Während dieses Zeitfensters sind Broker nicht verfügbar. Für Broker ohne Standby kann Lambda während dieses Fensters keine Nachrichten verarbeiten. **Topics** + [Verstehen der Lambda-Verbrauchergruppe für Amazon MQ](#services-mq-configure) + [Konfiguration der Amazon MQ-Ereignisquelle für Lambda](process-mq-messages-with-lambda.md) + [Parameter für die Zuordnung von Ereignisquellen](services-mq-params.md) + [Ereignisse aus einer Amazon MQ-Ereignisquelle filtern](with-mq-filtering.md) + [Beheben Sie Fehler Amazon MQ-Zuordnung von Ereignisquellen](services-mq-errors.md) ## Verstehen der Lambda-Verbrauchergruppe für Amazon MQ Um mit Amazon MQ zu interagieren, erstellt Lambda eine Verbrauchergruppe, die aus Ihren Amazon-MQ-Brokern lesen kann. Die Verbrauchergruppe wird mit derselben ID wie die Ereignisquellen-Zuweisung-UUID erstellt. Für Amazon-MQ-Ereignisquellen batcht Lambda Datensätze und sendet sie in einer einzigen Nutzlast an Ihre Funktion. Um das Verhalten zu steuern, können Sie das Batch-Fenster und die Batch-Größe konfigurieren. Lambda pullt Nachrichten, bis es die Nutzlastgröße von maximal 6 MB verarbeitet, das Batch-Fenster abläuft oder die Anzahl der Datensätze die volle Batch-Größe erreicht. Weitere Informationen finden Sie unter [Batching-Verhalten](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Die Konsumentengruppe ruft die Nachrichten als ein BLOB von Bytes ab, base64-codiert sie dann in eine einzelne JSON-Nutzlast und ruft dann Ihre Funktion auf. Wenn Ihre Funktion einen Fehler für eine der Nachrichten in einem Batch zurückgibt, wiederholt Lambda den gesamten Nachrichtenbatch, bis die Verarbeitung erfolgreich ist oder die Nachrichten ablaufen. **Anmerkung** Während Lambda-Funktionen in der Regel ein maximales Timeout-Limit von 15 Minuten haben, unterstützen Ereignisquellenzuordnungen für Amazon MSK, selbstverwaltetes Apache Kafka, Amazon DocumentDB, Amazon MQ für ActiveMQ und RabbitMQ nur Funktionen mit einem maximalen Timeout-Limit von 14 Minuten. Diese Einschränkung stellt sicher, dass die Ereignisquellenzuordnung Funktionsfehler und Wiederholungsversuche ordnungsgemäß verarbeiten kann. Sie können die Parallelitätsnutzung einer bestimmten Funktion mithilfe der `ConcurrentExecutions` Metrik in Amazon CloudWatch überwachen. Weitere Hinweise zur Gleichzeitigkeitsskalierung finden Sie unter [Konfigurieren reservierter Gleichzeitigkeit für eine Funktion](configuration-concurrency.md). **Example Amazon-MQ-Datensatzereignisse** ``` { "eventSource": "aws:mq", "eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:test:b-9bcfa592-423a-4942-879d-eb284b418fc8", "messages": [ { "messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1", "messageType": "jms/text-message", "deliveryMode": 1, "replyTo": null, "type": null, "expiration": "60000", "priority": 1, "correlationId": "myJMSCoID", "redelivered": false, "destination": { "physicalName": "testQueue" }, "data":"QUJDOkFBQUE=", "timestamp": 1598827811958, "brokerInTime": 1598827811958, "brokerOutTime": 1598827811959, "properties": { "index": "1", "doAlarm": "false", "myCustomProperty": "value" } }, { "messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1", "messageType": "jms/bytes-message", "deliveryMode": 1, "replyTo": null, "type": null, "expiration": "60000", "priority": 2, "correlationId": "myJMSCoID1", "redelivered": false, "destination": { "physicalName": "testQueue" }, "data":"LQaGQ82S48k=", "timestamp": 1598827811958, "brokerInTime": 1598827811958, "brokerOutTime": 1598827811959, "properties": { "index": "1", "doAlarm": "false", "myCustomProperty": "value" } } ] } ``` ``` { "eventSource": "aws:rmq", "eventSourceArn": "arn:aws:mq:us-east-2:111122223333:broker:pizzaBroker:b-9bcfa592-423a-4942-879d-eb284b418fc8", "rmqMessagesByQueue": { "pizzaQueue::/": [ { "basicProperties": { "contentType": "text/plain", "contentEncoding": null, "headers": { "header1": { "bytes": [ 118, 97, 108, 117, 101, 49 ] }, "header2": { "bytes": [ 118, 97, 108, 117, 101, 50 ] }, "numberInHeader": 10 }, "deliveryMode": 1, "priority": 34, "correlationId": null, "replyTo": null, "expiration": "60000", "messageId": null, "timestamp": "Jan 1, 1970, 12:33:41 AM", "type": null, "userId": "AIDACKCEVSQ6C2EXAMPLE", "appId": null, "clusterId": null, "bodySize": 80 }, "redelivered": false, "data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ==" } ] } } ``` Im RabbitMQ-Beispiel ist `pizzaQueue` der Name der RabbitMQ-Warteschlange und `/` der Name des virtuellen Hosts. Beim Empfang von Nachrichten listet die Ereignisquelle Nachrichten unter `pizzaQueue::/` auf. # Konfiguration der Amazon MQ-Ereignisquelle für Lambda **Topics** + [Konfigurieren Sie die Netzwerksicherheit](#process-mq-messages-with-lambda-networkconfiguration) + [Die Zuordnung von Ereignisquellen erstellen](#services-mq-eventsourcemapping) ## Konfigurieren Sie die Netzwerksicherheit Um Lambda über die Zuordnung von Ereignisquellen Vollzugriff auf Amazon MQ zu gewähren, muss Ihr Broker entweder einen öffentlichen Endpunkt (öffentliche IP-Adresse) verwenden oder Sie müssen Zugriff auf die Amazon-VPC gewähren, in der Sie den Broker erstellt haben. Wenn Sie Amazon MQ mit Lambda verwenden, erstellen Sie [AWS PrivateLink VPC-Endpunkte](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html), die Ihrer Funktion Zugriff auf die Ressourcen in Ihrer Amazon VPC bieten. **Anmerkung** AWS PrivateLink VPC-Endpunkte sind für Funktionen mit Ereignisquellenzuordnungen erforderlich, die den Standardmodus (auf Abruf) für Ereignisabfragen verwenden. Wenn Ihre Ereignisquellenzuordnung den [Bereitstellungsmodus](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) verwendet, müssen Sie keine AWS PrivateLink VPC-Endpunkte konfigurieren. Erstellen Sie einen Endpunkt, der den Zugriff auf die folgenden Ressourcen ermöglicht: + Lambda – Erstellen Sie einen Endpunkt für den Lambda-Serviceprinzipal. + AWS STS — Erstellen Sie einen Endpunkt für den, damit ein Service Principal eine Rolle AWS STS in Ihrem Namen übernehmen kann. + Secrets Manager – Wenn Ihr Broker Secrets Manager zum Speichern von Anmeldeinformationen verwendet, erstellen Sie einen Endpunkt für Secrets Manager. Alternativ konfigurieren Sie ein NAT-Gateway auf jedem öffentlichen Subnetz in der Amazon VPC. Weitere Informationen finden Sie unter [Aktivieren Sie den Internetzugang für VPC-verbundene Lambda-Funktionen](configuration-vpc-internet.md). Wenn Sie eine Ereignisquellenzuordnung für Amazon MQ erstellen, prüft Lambda, ob Elastic Network Interfaces (ENIs) bereits für die für Ihre Amazon VPC konfigurierten Subnetze und Sicherheitsgruppen vorhanden sind. Wenn Lambda feststellt, dass sie vorhanden ENIs sind, versucht es, sie wiederzuverwenden. Andernfalls erstellt Lambda neue, ENIs um eine Verbindung zur Ereignisquelle herzustellen und Ihre Funktion aufzurufen. **Anmerkung** Lambda-Funktionen werden immer intern ausgeführt, die dem Lambda-Dienst VPCs gehören. Die VPC-Konfiguration Ihrer Funktion hat keinen Einfluss auf die Zuordnung von Ereignisquellen. Nur die Netzwerkkonfiguration der Ereignisquelle bestimmt, wie Lambda sich mit Ihrer Ereignisquelle verbindet. Konfigurieren Sie die Sicherheitsgruppen für die Amazon VPC, die Ihren Broker enthält. Standardmäßig verwendet Amazon MQ die folgenden Ports: `61617` (Amazon MQ für ActiveMQ) und `5671` (Amazon MQ für RabbitMQ). + Eingehende Regeln – Erlauben Sie den gesamten Datenverkehr auf dem Standard-Broker-Port für die Sicherheitsgruppe, die mit Ihrer Ereignisquelle verbunden ist. Alternativ können Sie eine selbstreferenzierende Regel für Sicherheitsgruppen verwenden, um den Zugriff von Instances innerhalb derselben Sicherheitsgruppe zuzulassen. + Regeln für ausgehenden Datenverkehr — Lassen Sie den gesamten Datenverkehr über den Port `443` für externe Ziele zu, wenn Ihre Funktion mit Diensten kommunizieren muss. AWS Alternativ können Sie auch eine selbstreferenzierende Sicherheitsgruppenregel verwenden, um den Zugriff auf den Broker einzuschränken, wenn Sie nicht mit anderen Diensten kommunizieren müssen. AWS + Amazon VPC-Endpunkt-Eingangsregeln – Wenn Sie einen Amazon VPC-Endpunkt verwenden, muss die Sicherheitsgruppe, die mit Ihrem Amazon VPC-Endpunkt verbunden ist, eingehenden Verkehr auf Port `443` von der Broker-Sicherheitsgruppe zulassen. Wenn Ihr Broker Authentifizierung verwendet, können Sie auch die Endpunktrichtlinie für den Secrets Manager-Endpunkt einschränken. Für den Aufruf der Secrets Manager-API verwendet Lambda Ihre Funktionsrolle und nicht den Lambda-Serviceprinzipal. **Example VPC-Endpunktrichtlinie – Secrets Manager-Endpunkt** ``` { "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws::iam::123456789012:role/my-role" ] }, "Resource": "arn:aws::secretsmanager:us-west-2:123456789012:secret:my-secret" } ] } ``` Wenn Sie Amazon VPC-Endpunkte verwenden, AWS leitet Ihre API-Aufrufe zum Aufrufen Ihrer Funktion über das Elastic Network Interface (ENI) des Endpunkts weiter. Der Lambda-Serviceprinzipal muss alle Rollen und Funktionen aufrufen`lambda:InvokeFunction`, die diese ENIs verwenden. Standardmäßig verfügen Amazon VPC-Endpunkte über offene IAM-Richtlinien, die einen umfassenden Zugriff auf Ressourcen ermöglichen. Es empfiehlt sich, diese Richtlinien auf die Durchführung der erforderlichen Aktionen über diesen Endpunkt zu beschränken. Um sicherzustellen, dass Ihre Zuordnung von Ereignisquellen Ihre Lambda-Funktion aufrufen kann, muss die VPC-Endpunktrichtlinie dem Lambda-Serviceprinzipal erlauben, `sts:AssumeRole` und `lambda:InvokeFunction` aufzurufen. Wenn Sie Ihre VPC-Endpunktrichtlinien so einschränken, dass nur API-Aufrufe zugelassen werden, die aus Ihrem Unternehmen stammen, kann die Zuordnung von Ereignisquellen nicht richtig funktionieren, weshalb in diesen Richtlinien `"Resource": "*"` erforderlich ist. Die folgenden Beispiel-VPC-Endpunktrichtlinien zeigen, wie der erforderliche Zugriff auf den Lambda-Serviceprinzipal für die AWS STS - und Lambda-Endpunkte gewährt wird. **Example VPC-Endpunktrichtlinie — AWS STS Endpunkt** ``` { "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` **Example VPC-Endpunktrichtlinie – Lambda-Endpunkt** ``` { "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] } ``` ## Die Zuordnung von Ereignisquellen erstellen Erstellen Sie ein [Ereignisquellen-Zuweisung](invocation-eventsourcemapping.md), um Lambda anzuweisen, Datensätze aus einem Amazon-MQ-Broker an eine Lambda-Funktion zu senden. Sie können mehrere Ereignisquellen-Zuweisungen erstellen, um gleiche Daten mit mehreren Funktionen oder Elemente aus mehreren Streams mit nur einer Funktion zu verarbeiten. Um Ihre Funktion für das Lesen von Amazon MQ zu konfigurieren, fügen Sie die erforderlichen Berechtigungen hinzu und erstellen einen **MQ**-Auslöser in der Lambda-Konsole. Um Datensätze von einem Amazon-MQ-Broker zu lesen, benötigt Ihre Lambda-Funktion die folgenden Berechtigungen, die ihrer Ausführungsrolle hinzugefügt werden: Sie gewähren Lambda die Erlaubnis, mit Ihrem Amazon MQ-Broker und den zugrunde liegenden Ressourcen zu interagieren, indem Sie Ihrer Funktions[ausführungsrolle](lambda-intro-execution-role.md) Berechtigungsanweisungen hinzufügen: + [mq: DescribeBroker](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-http-methods) + [Manager für Geheimnisse: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) + [ec2: CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html) + [ec2: DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html) + [ec2: DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html) + [ec2: DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) + [ec2: DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) + [ec2: DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html) + [Protokolle: CreateLogGroup](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html) + [Protokolle: CreateLogStream](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogStream.html) + [Protokolle: PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) **Anmerkung** Wenn Sie einen verschlüsselten, von Kunden verwalteten Schlüssel verwenden, fügen Sie auch die `[kms:Decrypt](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#clusters-clusterarn-bootstrap-brokersget)`-Berechtigung hinzu. **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 **Add permissions** (Berechtigungen hinzufügen) und dann **Create inline policy** (Inline-Richtlinie erstellen) aus. ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/inline-policy.png) 1. Wählen Sie im Abschnitt **Richtlinien-Editor** **JSON** aus. Geben Sie die folgende Richtlinie ein: Ihre Funktion benötigt diese Berechtigungen, um von einem Amazon MQ-Broker zu lesen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "mq:DescribeBroker", "secretsmanager:GetSecretValue", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } ``` ------ **Anmerkung** Wenn Sie einen verschlüsselten, vom Kunden verwalteten Schlüssel verwenden, müssen Sie auch die `kms:Decrypt`-Berechtigung hinzufügen. 1. Wählen Sie **Weiter** aus. Geben Sie einen Richtliniennamen ein und wählen Sie anschließend **Create policy** (Richtlinie erstellen) aus. 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 den **MQ**-Auslösertyp. 1. Konfigurieren Sie die erforderlichen Optionen und wählen Sie dann **Add** (Hinzufügen) aus. Lambda unterstützt die folgenden Optionen für Amazon-MQ-Ereignisquellen. + **MQ-Broker** – Wählen Sie einen Amazon-MQ-Broker aus. + **Batchgröße** – Legen Sie die maximale Anzahl von Nachrichten fest, die in einem einzelnen Batch abgerufen werden sollen. + **Name der Warteschlange** – Geben Sie die zu konsumierende Amazon-MQ-Warteschlange ein. + **Konfiguration des Zugriffs** – Geben Sie die Informationen zum virtuellen Host und das Secrets Manager-Geheimnis ein, in dem Ihre Broker-Anmeldeinformationen gespeichert sind. + **Auslöser aktivieren** – Deaktivieren Sie den Auslöser, um die Verarbeitung von Datensätzen anzuhalten. Um den Auslöser zu aktivieren oder zu deaktivieren (oder zu löschen), wählen Sie den **MQ**-Auslöser im Designer aus. Verwenden Sie zum Neukonfigurieren des Auslösers die API-Vorgänge für die Ereignisquellen-Zuweisung. # Parameter für die Zuordnung von Ereignisquellen Alle Lambda-Ereignisquellentypen verwenden dieselben API-Operationen [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) und [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html). Allerdings gelten nur einige der Parameter für Amazon MQ und RabbitMQ. | Parameter | Erforderlich | Standard | Hinweise | | --- | --- | --- | --- | | BatchSize | N | 100 | Höchstwert: 10 000. | | Enabled | N | true | Keine | | FunctionName | Y | N/A | Keine | | FilterCriteria | N | N/A | [Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet](invocation-eventfiltering.md) | | MaximumBatchingWindowInSeconds | N | 500 ms | [Batching-Verhalten](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) | | Warteschlangen | N | N/A | Der Name der zu verwendenden Zielwarteschlange des Amazon-MQ-Brokers. | | SourceAccessConfigurations | N | N/A | Für ActiveMQ BASIC\$1AUTH-Anmeldeinformationen. Für RabbitMQ können sowohl BASIC\$1AUTH Anmeldeinformationen als auch VIRTUAL\$1HOST Informationen enthalten sein. | # Ereignisse aus einer Amazon MQ-Ereignisquelle filtern 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 MQ-Ereignisquellen. **Anmerkung** Amazon-MQ-Zuordnungen von Ereignisquellen unterstützen nur das Filtern nach dem `data`-Schlüssel. **Topics** + [Grundlagen der Amazon MQ-Ereignisfilterung](#filtering-AMQ) ## Grundlagen der Amazon MQ-Ereignisfilterung Angenommen, Ihre Amazon-MQ-Nachrichtenwarteschlange enthält Nachrichten entweder im gültigen JSON-Format oder als einfache Zeichenfolgen. Ein Beispieldatensatz würde wie folgt aussehen, wobei die Daten im `data`-Feld in eine Base64-kodierte Zeichenfolge umgewandelt wurden. ------ #### [ ActiveMQ ] ``` { "messageID": "ID:b-9bcfa592-423a-4942-879d-eb284b418fc8-1---mq---us-east-2.amazonaws.com.rproxy.goskope.com-37557-1234520418293-4:1:1:1:1", "messageType": "jms/text-message", "deliveryMode": 1, "replyTo": null, "type": null, "expiration": "60000", "priority": 1, "correlationId": "myJMSCoID", "redelivered": false, "destination": { "physicalName": "testQueue" }, "data":"QUJDOkFBQUE=", "timestamp": 1598827811958, "brokerInTime": 1598827811958, "brokerOutTime": 1598827811959, "properties": { "index": "1", "doAlarm": "false", "myCustomProperty": "value" } } ``` ------ #### [ RabbitMQ ] ``` { "basicProperties": { "contentType": "text/plain", "contentEncoding": null, "headers": { "header1": { "bytes": [ 118, 97, 108, 117, 101, 49 ] }, "header2": { "bytes": [ 118, 97, 108, 117, 101, 50 ] }, "numberInHeader": 10 }, "deliveryMode": 1, "priority": 34, "correlationId": null, "replyTo": null, "expiration": "60000", "messageId": null, "timestamp": "Jan 1, 1970, 12:33:41 AM", "type": null, "userId": "AIDACKCEVSQ6C2EXAMPLE", "appId": null, "clusterId": null, "bodySize": 80 }, "redelivered": false, "data": "eyJ0aW1lb3V0IjowLCJkYXRhIjoiQ1pybWYwR3c4T3Y0YnFMUXhENEUifQ==" } ``` ------ Sowohl für Active MQ- als auch für Rabbit MQ-Broker können Sie die Ereignisfilterung verwenden, um Datensätze anhand des `data`-Schlüssels zu filtern. Angenommen, Ihre Amazon-MQ-Warteschlange enthält Nachrichten im folgenden JSON-Format. ``` { "timeout": 0, "IPAddress": "203.0.113.254" } ``` Um nur die Datensätze zu filtern, bei denen das `timeout`-Feld größer als 0 ist, würde das `FilterCriteria`-Objekt wie folgt aussehen. ``` { "Filters": [ { "Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0] } } ] } }" } ] } ``` Zur Verdeutlichung sehen Sie hier den Wert des Filter-`Pattern` in reinem JSON. ``` { "data": { "timeout": [ { "numeric": [ ">", 0 ] } ] } } ``` 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. ``` { "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } } ``` ------ #### [ 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:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \ --filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}' ``` 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": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}' ``` 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": "{ \"data\" : { \"timeout\" : [ { \"numeric\": [ \">\", 0 ] } ] } }"}]}' ``` ------ #### [ 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: '{ "data" : { "timeout" : [ { "numeric": [ ">", 0 ] } ] } }' ``` ------ Mit Amazon MQ können Sie auch Datensätze filtern, bei denen die Nachricht eine einfache Zeichenfolge ist. Angenommen, Sie möchten nur Datensätze verarbeiten, bei denen die Meldung mit „Ergebnis:“ beginnt. Das `FilterCriteria`-Objekt würde wie folgt aussehen. ``` { "Filters": [ { "Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }" } ] } ``` Zur Verdeutlichung sehen Sie hier den Wert des Filter-`Pattern` in reinem JSON. ``` { "data": [ { "prefix": "Result: " } ] } ``` 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. ``` { "data" : [ { "prefix": "Result: " } ] } ``` ------ #### [ 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:mq:us-east-2:123456789012:broker:my-broker:b-8ac7cc01-5898-482d-be2f-a6b596050ea8 \ --filter-criteria '{"Filters": [{"Pattern": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}' ``` 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": "{ \"data\" : [ { \"prefix\": \"Result: \" } ] }"}]}' ``` ------ #### [ 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: '{ "data" : [ { "prefix": "Result " } ] }' ``` ------ Amazon-MQ-Nachrichten müssen UTF-8-kodierte Zeichenfolgen sein (entweder einfache Zeichenfolgen oder im JSON-Format). Das liegt daran, dass Lambda Byte-Arrays von Amazon MQ vor Anwendung der Filterkriterien in UTF-8 dekodiert. Wenn Ihre Nachrichten eine andere Kodierung nutzen, z. B. UTF-16 oder ASCII, oder das Nachrichtenformat nicht dem `FilterCriteria`-Format entspricht, verarbeitet Lambda nur Metadatenfilter. In der folgenden Tabelle ist das Verhalten zusammengefasst: | -Format der eingehenden Nachricht | Filtermusterformat für Nachrichteneigenschaften | 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 filtert (nur für die anderen Metadateneigenschaften) basierend auf Ihren Filterkriterien. | | Gültiges JSON | Einfache Zeichenfolge | Lambda filtert (nur für die anderen Metadateneigenschaften) basierend auf Ihren Filterkriterien. | | 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. | | Nicht UTF-8-kodierte Zeichenfolge | JSON, einfache Zeichenfolge oder kein Muster | Lambda filtert (nur für die anderen Metadateneigenschaften) basierend auf Ihren Filterkriterien. | # Beheben Sie Fehler Amazon MQ-Zuordnung von Ereignisquellen Wenn eine Lambda-Funktion auf einen nicht behebbaren Fehler stößt, stoppt Ihr Amazon-MQ-Konsument die Verarbeitung von Datensätzen. Alle anderen Konsumenten können die Verarbeitung fortsetzen, sofern sie nicht auf denselben Fehler stoßen. Um die potenzielle Ursache für einen gestoppten Konsumenten zu ermitteln, überprüfen Sie das `StateTransitionReason`-Feld in den Rücksendedetails Ihres `EventSourceMapping` auf einen der folgenden Codes: **`ESM_CONFIG_NOT_VALID`** Die Konfiguration der Ereignisquellen-Zuweisung ist ungültig. **`EVENT_SOURCE_AUTHN_ERROR`** Lambda konnte die Ereignisquelle nicht authentifizieren. **`EVENT_SOURCE_AUTHZ_ERROR`** Lambda verfügt nicht über die erforderlichen Berechtigungen für den Zugriff auf die Ereignisquelle. **`FUNCTION_CONFIG_NOT_VALID`** Die Konfiguration der Funktion ist ungültig. Datensätze bleiben auch unbearbeitet, wenn Lambda sie aufgrund ihrer Größe fallen lässt. Die Größenbeschränkung für Lambda-Datensätze beträgt 6 MB. Um Nachrichten bei Funktionsfehlern erneut zuzustellen, können Sie eine Warteschlange für unzustellbare Nachrichten (DLQ) verwenden. Weitere Informationen finden Sie unter [Erneute Zustellung von Nachrichten und DLQ-Handhabung](https://activemq.apache.org/message-redelivery-and-dlq-handling) auf der Apache-ActiveMQ-Website und [Zuverlässigkeits-Leitfaden](https://www.rabbitmq.com/reliability.html) auf der RabbitMQ-Website. **Anmerkung** Lambda unterstützt keine benutzerdefinierten Richtlinien für die erneute Bereitstellung. Stattdessen verwendet Lambda eine Richtlinie mit den Standardwerten von der Seite [Richtlinie für erneute Zustellung](https://activemq.apache.org/redelivery-policy) auf der Apache-ActiveMQ-Website, wobei `maximumRedeliveries` auf 6 gesetzt ist.