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.
Amazon MQ ist ein verwalteter Message-Broker-Service für Apache ActiveMQ
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 auf, eine Lambda-Ressource, die Nachrichten von Ihrem Broker liest und die Funktion synchron aufruft.
Warnung
Lambda-Ereignisquellenzuordnungen 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
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. Für ActiveMQ begrenzt der Lambda-Service die Anzahl der gleichzeitigen Ausführungsumgebungen auf fünf. Für RabbitMQ ist die Anzahl der gleichzeitigen Ausführungsumgebungen auf 1 begrenzt. Selbst wenn Sie die reservierten oder bereitgestellten Parallelitätseinstellungen Ihrer Funktion ändern, stellt der Lambda-Service keine weiteren Ausführungsumgebungen zur Verfügung. Wenn Sie eine Erhöhung der standardmäßigen maximalen Parallelität beantragen möchten, wenden Sie sich an AWS Support.
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
ActiveMQ unterstützt. Für RabbitMQ wird nur der PLAIN -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 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 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. Bei privaten VPCs benötigt Ihre Lambda-Funktion Zugriff auf die VPC, um Nachrichten zu empfangen. Weitere Informationen finden Sie unter Netzwerkkonfiguration an späterer Stelle in diesem Thema.
-
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
auf der Apache-ActiveMQ-Website und virtuelle Hosts 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 und Broker-Architektur von Rabbit MQ 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
TextMessageund BytesMessageunterstützt. Lambda unterstützt auch benutzerdefinierte JMS-Eigenschaften. Weitere Informationen zum OpenWire Protokoll finden Sie OpenWire 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
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 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.
Abschnitte
Konsumentengruppe von Lambda
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.
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.
Beispiel Amazon-MQ-Datensatzereignisse
Anmerkung
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.
Berechtigungen für die Ausführungsrolle
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:
Anmerkung
Wenn Sie einen verschlüsselten, von Kunden verwalteten Schlüssel verwenden, fügen Sie auch die kms:Decrypt-Berechtigung hinzu.
Netzwerkkonfiguration
Um Lambda über die Zuordnung von Ereignisquellen Vollzugriff auf Ihren Broker 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.
Bei der Erstellung eines Amazon-MQ-Brokers wird das Flag PubliclyAccessible standardmäßig auf „false“ festgelegt. Damit Ihr Broker eine öffentliche IP-Adresse erhält, muss das Flag PubliclyAccessible auf „true“ festgelegt werden.
Eine bewährte Methode für die Verwendung von Amazon MQ mit Lambda besteht darin, AWS PrivateLink VPC-Endpunkte zu verwenden und Ihrer Lambda-Funktion Zugriff auf die VPC Ihres Brokers zu gewähren. Stellen Sie einen Endpunkt für Lambda und, nur für ActiveMQ, einen Endpunkt für AWS Security Token Service () bereit.AWS STS Wenn Ihr Broker Authentifizierung verwendet, stellen Sie auch einen Endpunkt für bereit. AWS Secrets Manager Weitere Informationen hierzu finden Sie unter Arbeiten mit VPC-Endpunkten.
Alternativ können Sie in jedem öffentlichen Subnetz in der VPC, die Ihren Amazon MQ-Broker enthält, ein NAT-Gateway konfigurieren. Weitere Informationen finden Sie unter Aktivieren Sie den Internetzugang für mit VPN verbundene Lambda-Funktionen.
Wenn Sie eine Ereignisquellenzuordnung für einen Amazon MQ-Broker erstellen, prüft Lambda, ob Elastic Network Interfaces (ENIs) bereits für die Subnetze und Sicherheitsgruppen der VPC Ihres Brokers vorhanden sind. Wenn Lambda vorhandene ENIs findet, versucht es, sie wiederzuverwenden. Andernfalls erstellt Lambda neue ENIs, um eine Verbindung zur Ereignisquelle herzustellen und Ihre Funktion aufzurufen.
Anmerkung
Lambda-Funktionen werden immer in VPCs ausgeführt, die dem Lambda-Service gehören. Diese VPCs werden automatisch vom Service verwaltet und sind für Kunden nicht sichtbar. Sie können Ihre Funktion auch mit einer Amazon VPC verbinden. In beiden Fällen hat die VPC-Konfiguration Ihrer Funktion keinen Einfluss auf die Zuordnung der Ereignisquelle. Nur die Konfiguration der VPC der Ereignisquelle bestimmt, wie Lambda eine Verbindung zu Ihrer Ereignisquelle herstellt.
VPC-Sicherheitsgruppenregeln
Konfigurieren Sie die Sicherheitsgruppen für die Amazon VPC, die Ihren Cluster enthält, mit den folgenden Regeln (mindestens):
-
Regeln für eingehenden Datenverkehr: Lassen Sie den gesamten Datenverkehr am Broker-Port für die Sicherheitsgruppe, die für Ihre Ereignisquelle angegeben ist, innerhalb der eigenen Sicherheitsgruppe zu. ActiveMQ verwendet standardmäßig Port 61617. RabbitMQ verwendet standardmäßig Port 5671.
-
Ausgehende Regeln - Erlauben Sie allen Datenverkehr auf Port 443 für alle Ziele. Lassen Sie den gesamten Datenverkehr am Broker-Port innerhalb der eigenen Sicherheitsgruppe zu. ActiveMQ verwendet standardmäßig Port 61617. RabbitMQ verwendet standardmäßig Port 5671.
-
Wenn Sie VPC-Endpunkte anstelle eines NAT-Gateways verwenden, müssen die Sicherheitsgruppen, die mit den VPC-Endpunkten verknüpft sind, den gesamten eingehenden Datenverkehr für Port 443 von den Sicherheitsgruppen der Ereignisquelle zulassen.
Arbeiten mit VPC-Endpunkten
Wenn Sie VPC-Endpunkte verwenden, werden API-Aufrufe zum Aufrufen Ihrer Funktion mithilfe der ENIs über diese Endpunkte geleitet. Der Lambda-Serviceprinzipal muss alle Funktionen aufrufenlambda:InvokeFunction, die diese ENIs verwenden. Darüber hinaus muss der Lambda-Serviceprinzipal für ActiveMQ Rollen aufrufensts:AssumeRole, die die ENIs verwenden.
Standardmäßig haben VPC-Endpoints offene IAM-Richtlinien. Es hat sich bewährt, diese Richtlinien so einzuschränken, dass nur bestimmte Prinzipale die erforderlichen Aktionen über diesen Endpunkt ausführen können. Um sicherzustellen, dass Ihre Ereignisquellenzuordnung Ihre Lambda-Funktion aufrufen kann, muss die VPC-Endpunktrichtlinie zulassen, dass das Lambda-Serviceprinzip aufgerufen wird lambda:InvokeFunction und, für ActiveMQ,. sts:AssumeRole Wenn Sie Ihre VPC-Endpunktrichtlinien so einschränken, dass sie nur API-Aufrufe zulassen, die ihren Ursprung in Ihrer Organisation haben, verhindert, dass die Zuordnung der Ereignisquellen ordnungsgemäß funktioniert.
Die folgenden VPC-Endpunktrichtlinien zeigen, wie der erforderliche Zugriff für AWS STS und Lambda-Endpoints gewährt wird.
Beispiel VPC-Endpunktrichtlinie — AWS STS Endpunkt (nur ActiveMQ)
{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Beispiel VPC-Endpunktrichtlinie — Lambda-Endpunkt
{ "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Wenn Ihr Amazon MQ-Broker Authentifizierung verwendet, können Sie auch die VPC-Endpunktrichtlinie für den Secrets Manager Manager-Endpunkt einschränken. Um die Secrets Manager Manager-API aufzurufen, verwendet Lambda Ihre Funktionsrolle, nicht den Lambda-Serviceprinzipal. Das folgende Beispiel zeigt eine Secrets Manager Manager-Endpunktrichtlinie.
Beispiel VPC-Endpunktrichtlinie — Secrets Manager Manager-Endpunkt
{ "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Effect": "Allow", "Principal": { "AWS": [ "customer_function_execution_role_arn" ] }, "Resource": "customer_secret_arn" } ] }
Fügen Sie Berechtigungen hinzu und erstellen Sie die Zuordnung der Ereignisquellen
Erstellen Sie ein Ereignisquellen-Zuweisung, 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 aus Amazon MQ zu konfigurieren, fügen Sie die erforderlichen Berechtigungen hinzu und erstellen Sie einen MQ-Trigger in der Lambda-Konsole.
Um Berechtigungen hinzuzufügen und einen Trigger zu erstellen
Öffnen Sie die Seite Funktionen
der Lambda-Konsole. -
Wählen Sie den Namen einer Funktion aus.
-
Wählen Sie die Registerkarte Konfiguration und dann Berechtigungen aus.
-
Wählen Sie unter Rollenname den Link zu Ihrer Ausführungsrolle aus. Dieser Link öffnet die Rolle in der IAM-Konsole.
-
Wählen Sie Berechtigungen hinzufügen und dann Inline-Richtlinie erstellen aus.
-
Wählen Sie im Richtlinieneditor JSON aus. Geben Sie die folgende Richtlinie ein: Ihre Funktion benötigt diese Berechtigungen, um von einem Amazon MQ-Broker lesen zu können.
{ "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:DecryptBerechtigung hinzufügen. -
Wählen Sie Weiter aus. Geben Sie einen Richtliniennamen ein und wählen Sie dann Richtlinie erstellen aus.
-
Kehren Sie zu Ihrer Funktion in der Lambda-Konsole zurück. Wählen Sie unter Function overview (Funktionsübersicht) die Option Add trigger (Trigger hinzufügen).
-
Wählen Sie den MQ-Triggertyp.
-
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.
API für die Ereignisquellen-Zuweisung
Um eine Ereignisquelle mit der AWS Command Line Interface (AWS CLI) oder einem AWS
Verwenden Sie den create-event-source-mappingBefehl, um die Zuordnung der Ereignisquelle mit AWS Command Line Interface (AWS CLI) zu erstellen.
Der folgende AWS CLI Beispielbefehl erstellt eine Ereignisquelle, die eine Lambda-Funktion mit dem Namen einem auf Amazon MQ RabbitMQ basierenden Broker namens MQ-Example-Function zuordnet. ExampleMQBroker Der Befehl stellt außerdem den Namen des virtuellen Hosts und einen geheimen Secrets-Manager-ARN bereit, der die Broker-Anmeldeinformationen speichert.
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:mq:us-east-1:123456789012:broker:ExampleMQBroker:b-24cacbb4-b295-49b7-8543-7ce7ce9dfb98 \
--function-name arn:aws:lambda:us-east-1:123456789012:function:MQ-Example-Function \
--queues ExampleQueue \
--source-access-configuration Type=VIRTUAL_HOST,URI="/" Type=BASIC_AUTH,URI=arn:aws:secretsmanager:us-east-1:123456789012:secret:ExampleMQBrokerUserPassword-xPBMTt \Die Ausgabe sollte folgendermaßen aussehen:
{ "UUID": "91eaeb7e-c976-1234-9451-8709db01f137", "BatchSize": 100, "EventSourceArn": "arn:aws:mq:us-east-1:123456789012:broker:ExampleMQBroker:b-b4d492ef-bdc3-45e3-a781-cd1a3102ecca", "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:MQ-Example-Function", "LastModified": 1601927898.741, "LastProcessingResult": "No records processed", "State": "Creating", "StateTransitionReason": "USER_INITIATED", "Queues": [ "ExampleQueue" ], "SourceAccessConfigurations": [ { "Type": "BASIC_AUTH", "URI": "arn:aws:secretsmanager:us-east-1:123456789012:secret:ExampleMQBrokerUserPassword-xPBMTt" } ] }
Mit dem update-event-source-mapping Befehl können Sie zusätzliche Optionen konfigurieren, z. B. wie Lambda Batches verarbeitet und wann Datensätze verworfen werden sollen, die nicht verarbeitet werden können. Der folgende Beispielbefehl aktualisiert eine Ereignisquellen-Zuweisung auf eine Stapelgröße von 2.
aws lambda update-event-source-mapping \
--uuid 91eaeb7e-c976-1234-9451-8709db01f137 \
--batch-size 2Die Ausgabe sollte folgendermaßen aussehen:
{ "UUID": "91eaeb7e-c976-1234-9451-8709db01f137", "BatchSize": 2, "EventSourceArn": "arn:aws:mq:us-east-1:123456789012:broker:ExampleMQBroker:b-b4d492ef-bdc3-45e3-a781-cd1a3102ecca", "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:MQ-Example-Function", "LastModified": 1601928393.531, "LastProcessingResult": "No records processed", "State": "Updating", "StateTransitionReason": "USER_INITIATED" }
Lambda aktualisiert diese Einstellungen asynchron. Die Ausgabe spiegelt keine Änderungen wider, bis dieser Vorgang abgeschlossen ist. Verwenden Sie den get-event-source-mapping-Befehl, um den aktuellen Status Ihrer Ressource anzuzeigen.
aws lambda get-event-source-mapping \
--uuid 91eaeb7e-c976-4939-9451-8709db01f137Die Ausgabe sollte folgendermaßen aussehen:
{ "UUID": "91eaeb7e-c976-4939-9451-8709db01f137", "BatchSize": 2, "EventSourceArn": "arn:aws:mq:us-east-1:123456789012:broker:ExampleMQBroker:b-b4d492ef-bdc3-45e3-a781-cd1a3102ecca", "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:MQ-Example-Function", "LastModified": 1601928393.531, "LastProcessingResult": "No records processed", "State": "Enabled", "StateTransitionReason": "USER_INITIATED" }
Fehler bei der Ereignisquellen-Zuweisung
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
Anmerkung
Lambda unterstützt keine benutzerdefinierten Richtlinien für die erneute Bereitstellung. Stattdessen verwendet Lambda eine Richtlinie mit den Standardwerten von der Seite Redelivery PolicymaximumRedeliveries
Konfigurationsparameter für Amazon MQ und RabbitMQ
Alle Lambda-Ereignisquelltypen verwenden dieselben CreateEventSourceMappingUpdateEventSourceMappingAPI-Operationen. Allerdings gelten nur einige der Parameter für Amazon MQ und RabbitMQ.
Ereignisquellparameter, die für Amazon MQ und RabbitMQ gelten | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Parameter | Erforderlich | Standard | Hinweise | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
BatchSize |
N |
100 |
Höchstwert: 10 000. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enabled |
N |
true |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
FunctionName |
Y |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
FilterCriteria |
N |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
MaximumBatchingWindowInSeconds |
N |
500 ms |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Warteschlangen |
N |
Der Name der zu verwendenden Zielwarteschlange des Amazon-MQ-Brokers. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
SourceAccessConfigurations |
N |
Für ActiveMQ BASIC_AUTH-Anmeldeinformationen. Für RabbitMQ können sowohl BASIC_AUTH Anmeldeinformationen als auch VIRTUAL_HOST Informationen enthalten sein. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
