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. # Verwendung von Lambda mit selbstverwaltetem Apache Kafka In diesem Thema wird die Verwendung von Lambda mit einem selbstverwalteten Kafka-Cluster beschrieben. In der AWS Terminologie umfasst ein selbstverwalteter Cluster auch nicht AWS gehostete Kafka-Cluster. Sie können Ihren Kafka-Cluster beispielsweise bei einem Cloud-Anbieter wie [Confluent Cloud](https://www.confluent.io/confluent-cloud/) oder [Redpanda](https://www.redpanda.com/) hosten. In diesem Kapitel wird erklärt, wie Sie einen selbstverwalteten Apache-Kafka-Cluster als Ereignisquelle für Ihre Lambda-Funktion verwenden. Der allgemeine Prozess zur Integration von selbstverwaltetem Apache Kafka mit Lambda umfasst die folgenden Schritte: 1. **[Cluster- und Netzwerkeinrichtung](with-kafka-cluster-network.md)** – Richten Sie zunächst Ihren selbstverwalteten Apache-Kafka-Cluster mit der richtigen Netzwerkkonfiguration ein, damit Lambda auf Ihren Cluster zugreifen kann. 1. **[Einrichtung der Zuordnung von Ereignisquellen](with-kafka-configure.md)** – Erstellen Sie anschließend die Ressource der [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md), die Lambda benötigt, um Ihren Apache-Kafka-Cluster sicher mit Ihrer Funktion zu verbinden. 1. **[Einrichtung von Funktionen und Berechtigungen](with-kafka-permissions.md)** – Stellen Sie abschließend sicher, dass Ihre Funktion korrekt eingerichtet ist und über die erforderlichen Berechtigungen in ihrer [Ausführungsrolle](lambda-intro-execution-role.md) verfügt. Apache Kafka als Ereignisquelle funktioniert ähnlich wie die Verwendung von Amazon Simple Queue Service (Amazon SQS) oder Amazon Kinesis. Lambda fragt intern neue Nachrichten von der Ereignisquelle ab und ruft dann synchron die Ziel-Lambda-Funktion auf. Lambda liest die Nachrichten in Batches und stellt diese Ihrer Funktion als Ereignisnutzlast zur Verfügung. Die maximale Batchgröße ist konfigurierbar (Standardeinstellung: 100 Nachrichten). Weitere Informationen finden Sie unter [Batching-Verhalten](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Um den Durchsatz Ihrer selbstverwalteten Apache Kafka-Zuordnungen von Ereignisquellen zu optimieren, konfigurieren Sie den Bereitstellungsmodus. Im Bereitstellungsmodus können Sie die minimale und maximale Anzahl von Event-Pollern definieren, die Zuordnung von Ereignisquellen zugewiesen werden. Dies kann die Fähigkeit Ihrer Zuordnung von Ereignisquellen verbessern, unerwartete Nachrichtenspitzen zu bewältigen. Weitere Informationen finden Sie unter [Bereitstellungsmodus](kafka-scaling-modes.md#kafka-provisioned-mode). **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 Für Kafka-basierte Ereignisquellen unterstützt Lambda die Verarbeitung von Steuerungsparametern wie Batch-Fenster und -Größe. Weitere Informationen finden Sie unter [Batching-Verhalten](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching). Ein Beispiel für die Verwendung von selbstverwaltetem Kafka als Ereignisquelle finden Sie im Compute-Blog unter [Verwenden von selbst gehostetem Apache Kafka als Ereignisquelle](https://aws.amazon.com/blogs/compute/using-self-hosted-apache-kafka-as-an-event-source-for-aws-lambda/) für. AWS Lambda AWS **Topics** + [Beispielereignis](#smaa-sample-event) + [Konfiguration Ihres selbstverwalteten Apache-Kafka-Clusters und -Netzwerks für Lambda](with-kafka-cluster-network.md) + [Konfigurieren von Rollenberechtigungen für Lambda-Ausführungen](with-kafka-permissions.md) + [Konfigurieren von selbstverwalteten Apache Kafka-Ereignisquellen für Lambda](with-kafka-configure.md) ## Beispielereignis Lambda sendet den Batch von Nachrichten im Ereignisparameter, wenn es Ihre Lambda-Funktion aufruft. Die Ereignisquelle enthält ein Array von Nachrichten. Jedes Array-Element enthält Details zum Kafka-Thema und Kafka-Partitions-ID, zusammen mit einem Zeitstempel und einer base64-codierten Nachricht. ``` { "eventSource": "SelfManagedKafka", "bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092", "records":{ "mytopic-0":[ { "topic":"mytopic", "partition":0, "offset":15, "timestamp":1545084650987, "timestampType":"CREATE_TIME", "key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", "value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==", "headers":[ { "headerKey":[ 104, 101, 97, 100, 101, 114, 86, 97, 108, 117, 101 ] } ] } ] } } ``` # Konfiguration Ihres selbstverwalteten Apache-Kafka-Clusters und -Netzwerks für Lambda Um Ihre Lambda-Funktion mit Ihrem selbstverwalteten Apache-Kafka-Cluster zu verbinden, müssen Sie Ihren Cluster und das Netzwerk, in dem er sich befindet, korrekt konfigurieren. Auf dieser Seite wird beschrieben, wie Sie Ihren Cluster und Ihr Netzwerk konfigurieren. Wenn Ihr Cluster und Ihr Netzwerk bereits ordnungsgemäß konfiguriert sind, lesen Sie unter [Konfigurieren von selbstverwalteten Apache Kafka-Ereignisquellen für Lambda](with-kafka-configure.md) nach, wie Sie die Zuordnung von Ereignisquellen konfigurieren. **Topics** + [Einrichten eines selbstverwalteten Apache Kafka-Clusters](#kafka-cluster-setup) + [Konfigurieren der Netzwerksicherheit](#services-kafka-vpc-config) ## Einrichten eines selbstverwalteten Apache Kafka-Clusters Sie können Ihren selbstverwalteten Apache-Kafka-Cluster bei Cloud-Anbietern wie [Confluent Cloud](https://www.confluent.io/confluent-cloud/) oder [Redpanda](https://www.redpanda.com/) hosten oder ihn in Ihrer eigenen Infrastruktur ausführen. Stellen Sie sicher, dass Ihr Cluster ordnungsgemäß konfiguriert ist und über das Netzwerk zugänglich ist, mit dem Ihre Lambda-Zuordnung von Ereignisquellen verbunden wird. ## Konfigurieren der Netzwerksicherheit Um Lambda vollen Zugriff auf selbstverwaltetes Apache Kafka über Ihre Zuordnung von Ereignisquellen zu ermöglichen, muss Ihr Cluster entweder einen öffentlichen Endpunkt (öffentliche IP-Adresse) verwenden oder Sie müssen Zugriff auf die Amazon VPC gewähren, in der Sie den Cluster erstellt haben. Wenn Sie selbstverwaltetes Apache Kafka 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 Zuordnungen von Ereignisquellen erforderlich, die den Standardmodus (auf Abruf) für Ereignisabfragen verwenden. Wenn Ihre Zuordnung von Ereignisquellen den [bereitgestellten Modus](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 AWS STS, damit ein Serviceprinzipal eine Rolle in Ihrem Namen übernehmen kann. + Secrets Manager – Wenn Ihr Cluster 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 Zuordnung von Ereignisquellen für selbstverwaltetes Apache Kafka erstellen, prüft Lambda, ob Elastic-Network-Schnittstelle (ENI) für die für Ihre Amazon VPC konfigurierten Subnetze und Sicherheitsgruppen bereits vorhanden sind. Findet Lambda vorhandene ENIs, versucht es, diese wiederzuverwenden. Andernfalls erstellt Lambda neue ENIs, um eine Verbindung mit der Ereignisquelle herzustellen und Ihre Funktion aufzurufen. **Anmerkung** Lambda-Funktionen werden immer in einer VPCs ausgeführt, die dem Lambda-Service gehört. 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 Cluster enthält. Standardmäßig verwendet der selbstverwaltete Apache Kafka die folgenden Ports: `9092`. + 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 – Erlauben Sie den gesamten Datenverkehr an Port `443` für externe Ziele, wenn Ihre Funktion mit AWS-Services kommunizieren muss. Alternativ können Sie auch eine selbstreferenzierende Regel für Sicherheitsgruppen verwenden, um den Zugriff auf den Broker einzuschränken, wenn Sie nicht mit anderen AWS-Services kommunizieren müssen. + Regeln für eingehenden Datenverkehr auf Amazon-VPC-Endpunkten – 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 Cluster-Sicherheitsgruppe zulassen. Wenn Ihr Cluster eine 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, leitet AWS Ihre API-Aufrufe weiter, um Ihre Funktion über die Elastic-Network-Schnittstelle (ENI) des Endpunkts aufzurufen. Der Prinzipal des Lambda-Dienstes muss `lambda:InvokeFunction` für alle Rollen und Funktionen aufrufen, die diese ENI 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": "*" } ] } ``` # Konfigurieren von Rollenberechtigungen für Lambda-Ausführungen Neben dem [Zugriff auf Ihren selbstverwalteten Kafka-Cluster](kafka-cluster-auth.md) benötigt Ihre Lambda-Funktion auch Berechtigungen, um verschiedene API-Aktionen auszuführen. Sie fügen diese Berechtigungen zur [Ausführungsrolle](lambda-intro-execution-role.md) der Funktion hinzu. Wenn Ihre Benutzer Zugriff auf API-Aktionen benötigen, fügen Sie der Identitätsrichtlinie für den AWS Identity and Access Management (IAM) -Benutzer oder die Rolle die erforderlichen Berechtigungen hinzu. **Topics** + [Benötigte Lambda-Funktionsberechtigungen](#smaa-api-actions-required) + [Optionale Lambda-Funktionsberechtigungen](#smaa-api-actions-optional) + [Hinzufügen von Berechtigungen zu Ihrer Ausführungsrolle](#smaa-permissions-add-policy) + [Gewähren von Benutzerzugriff mit einer IAM-Richtlinie](#smaa-permissions-add-users) ## Benötigte Lambda-Funktionsberechtigungen Um Protokolle in einer Protokollgruppe in Amazon CloudWatch Logs zu erstellen und zu speichern, muss Ihre Lambda-Funktion in ihrer Ausführungsrolle über die folgenden Berechtigungen verfügen: + [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) ## Optionale Lambda-Funktionsberechtigungen Ihre Lambda-Funktion benötigt möglicherweise auch Berechtigungen für Folgendes: + Beschreiben Ihres Secrets-Manager-Secrets + Greifen Sie auf Ihren AWS Key Management Service (AWS KMS) vom Kunden verwalteten Schlüssel zu. + Zugriff auf Ihre Amazon VPC + Senden von Datensätzen zu fehlgeschlagenen Aufrufen an ein Ziel ### Secrets Manager und AWS KMS Berechtigungen Abhängig von der Art der Zugriffskontrolle, die Sie für Ihre Kafka-Broker konfigurieren, benötigt Ihre Lambda-Funktion möglicherweise die Erlaubnis, auf Ihr Secrets Manager-Geheimnis zuzugreifen oder Ihren vom AWS KMS Kunden verwalteten Schlüssel zu entschlüsseln. Um auf diese Ressourcen zuzugreifen, muss die Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen besitzen: + [Secretsmanager: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) + [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) ### VPC-Berechtigungen Wenn nur Benutzer innerhalb einer VPC auf Ihren selbstverwalteten Apache-Kafka-Cluster zugreifen können, muss Ihre Lambda-Funktion die Berechtigung zum Zugriff auf Ihre Amazon-VPC-Ressourcen haben. Zu diesen Ressourcen gehören Ihre VPC, Subnetze, Sicherheitsgruppen und Netzwerkschnittstellen. Um auf diese Ressourcen zuzugreifen, muss die Ausführungsrolle Ihrer Funktion die folgenden Berechtigungen besitzen: + [ec2: CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html) + [ec2: DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html) + [ec2: DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html) + [ec2: DeleteNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkInterface.html) + [ec2: DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) + [ec2: DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) ## Hinzufügen von Berechtigungen zu Ihrer Ausführungsrolle [Um auf andere AWS Dienste zuzugreifen, die Ihr selbstverwalteter Apache Kafka-Cluster verwendet, verwendet Lambda die Berechtigungsrichtlinien, die Sie in der Ausführungsrolle Ihrer Lambda-Funktion definieren.](lambda-intro-execution-role.md) Standardmäßig ist es Lambda nicht gestattet, die erforderlichen oder optionalen Aktionen für einen selbstverwalteten Apache-Kafka-Cluster durchzuführen. Sie müssen diese Aktionen in einer [IAM-Vertrauensrichtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) für Ihre Ausführungsrolle erstellen und definieren. In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen können, die Lambda den Zugriff auf Ihre Amazon-VPC-Ressourcen erlaubt. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] } ``` ------ ## Gewähren von Benutzerzugriff mit einer IAM-Richtlinie Standardmäßig haben Benutzer und Rollen keine Berechtigung zum Ausführen von [Ereignisquellen-API-Vorgängen](invocation-eventsourcemapping.md#event-source-mapping-api). Um Benutzern in Ihrem Unternehmen oder Ihrem Konto Zugriff zu gewähren, erstellen oder aktualisieren Sie eine identitätsbasierte Richtlinie. *Weitere Informationen finden Sie unter [Steuern des Zugriffs auf AWS Ressourcen mithilfe von Richtlinien im IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html).* Informationen zur Behebung von Authentifizierungs- und Autorisierungsfehlern finden Sie unter [Fehlerbehebung bei der Kafka-Zuordnung von Ereignisquellen](with-kafka-troubleshoot.md). # Konfigurieren von selbstverwalteten Apache Kafka-Ereignisquellen für Lambda Um einen selbstverwalteten Apache-Kafka-Cluster als Ereignisquelle für Ihre Lambda-Funktion zu verwenden, erstellen Sie eine [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md), die die beiden Ressourcen miteinander verbindet. Auf dieser Seite wird beschrieben, wie Sie eine Zuordnung von Ereignisquellen für selbstverwaltetes Apache Kafka erstellen. Auf dieser Seite wird davon ausgegangen, dass Sie Ihren Kafka-Cluster und das Netzwerk, in dem er sich befindet, bereits ordnungsgemäß konfiguriert haben. Wenn Sie Ihren Cluster oder Ihr Netzwerk einrichten müssen, finden Sie entsprechende Informationen unter [Konfiguration Ihres selbstverwalteten Apache-Kafka-Clusters und -Netzwerks für Lambda](with-kafka-cluster-network.md). **Topics** + [Verwenden eines selbstverwalteten Apache-Kafka-Clusters als Ereignisquelle](#kafka-esm-overview) + [Konfiguration der Cluster-Authentifizierungsmethoden in Lambda](kafka-cluster-auth.md) + [Erstellen einer Lambda-Zuordnung von Ereignisquellen für eine selbstverwaltete Apache-Kafka-Ereignisquelle](kafka-esm-create.md) + [Alle Konfigurationsparameter für selbstverwaltete Apache-Kafka-Ereignisquellen in Lambda](kafka-esm-parameters.md) ## Verwenden eines selbstverwalteten Apache-Kafka-Clusters als Ereignisquelle Wenn Sie Ihren Apache Kafka-Cluster oder Amazon MSK als Auslöser für Ihre Lambda-Funktion hinzufügen, wird der Cluster als [Ereignisquelle](invocation-eventsourcemapping.md) verwendet. Lambda liest Ereignisdaten aus den Kafka-Themen, die Sie wie `Topics` in einer [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)Anfrage angeben, basierend auf der von Ihnen angegebenen [Startposition](kafka-starting-positions.md). Nach erfolgreicher Verarbeitung wird Ihr Kafka-Thema Ihrem Kafka-Cluster zugeordnet. Lambda liest Nachrichten sequentiell für jede Kafka-Themenpartition. Eine einzelne Lambda-Nutzlast kann Nachrichten von mehreren Partitionen enthalten. Wenn mehr Datensätze verfügbar sind, setzt Lambda die Verarbeitung von Datensätzen stapelweise fort, basierend auf dem BatchSize Wert, den Sie in einer [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)Anfrage angeben, bis Ihre Funktion das Thema eingeholt hat. Nachdem Lambda jeden Batch verarbeitet hat, werden die Offsets der Nachrichten in diesem Batch festgeschrieben. 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. Sie können Datensätze, bei denen alle Wiederholungsversuche fehlschlagen, zur späteren Verarbeitung an ein Ausfallziel senden. **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. # Konfiguration der Cluster-Authentifizierungsmethoden in Lambda Lambda unterstützt mehrere Methoden zur Authentifizierung mit Ihrem selbstverwalteten Apache-Kafka-Cluster. Stellen Sie sicher, dass Sie den Kafka-Cluster für die Verwendung einer der folgenden unterstützten Authentifizierungsmethoden konfigurieren. Weitere Informationen zur Sicherheit von Kafka finden Sie unter [Sicherheit](http://kafka.apache.org/documentation.html#security) in der Kafka-Dokumentation. ## SASL/SCRAM-Authentifizierung Lambda unterstützt die Authentifizierung Simple Authentication und Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) mit Transport Layer Security (TLS) -Verschlüsselung (). `SASL_SSL` Lambda sendet die verschlüsselten Anmeldeinformationen zur Authentifizierung mit dem Cluster. Lambda unterstützt SASL/SCRAM mit Klartext () `SASL_PLAINTEXT` nicht. Weitere Informationen zur SASL/SCRAM Authentifizierung finden Sie unter [RFC](https://tools.ietf.org/html/rfc5802) 5802. Lambda unterstützt auch die SASL/PLAIN Authentifizierung. Da dieser Mechanismus Anmeldeinformationen im Klartext verwendet, muss die Verbindung zum Server TLS-Verschlüsselung verwenden, um sicherzustellen, dass die Anmeldeinformationen geschützt sind. Für die SASL-Authentifizierung speichern Sie die Anmeldeinformationen als Secret in AWS Secrets Manager. Weitere Informationen zur Verwendung von Secrets Manager finden Sie unter [Create an AWS Secrets Manager Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) im *AWS Secrets Manager Benutzerhandbuch*. **Wichtig** Um Secrets Manager für die Authentifizierung zu verwenden, müssen Geheimnisse in derselben AWS Region wie Ihre Lambda-Funktion gespeichert werden. ## Gegenseitige TLS-Authentifizierung Gegenseitige TLS (mTLS) bietet eine bidirektionale Authentifizierung zwischen Client und Server. Der Client sendet ein Zertifikat an den Server, damit der Server den Client überprüfen kann, und der Server sendet ein Zertifikat an den Client, damit der Client den Server überprüfen kann. Im selbstverwalteten Apache Kafka fungiert Lambda als Client. Sie konfigurieren ein Client-Zertifikat (als Secret in Secrets Manager), um Lambda für Ihre Kafka-Broker zu authentifizieren. Das Client-Zertifikat muss von einer Zertifizierungsstelle im Trust Store des Servers signiert sein. Der Kafka-Cluster sendet ein Serverzertifikat an Lambda, um die Kafka-Broker für Lambda zu authentifizieren. Das Serverzertifikat kann ein öffentliches CA-Zertifikat oder ein privat CA/self-signed certificate. The public CA certificate must be signed by a certificate authority (CA) that's in the Lambda trust store. For a private CA/self signiertes Zertifikat sein. Sie konfigurieren das Root-CA-Zertifikat des Servers (als geheim in Secrets Manager). Lambda verwendet das Root-Zertifikat, um die Kafka-Broker zu verifizieren. Weitere Informationen über mTLS finden Sie unter [Vorstellung von gegenseitiger TLS-Authentifizierung für Amazon MSK als Ereignisquelle](https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-msk-as-an-event-source). ## Konfigurieren des Client-Zertifikat-Secrets Das Secret CLIENT\$1CERTIFICATE\$1TLS\$1AUTH erfordert ein Zertifikatfeld und ein Feld für einen privaten Schlüssel. Für einen verschlüsselten privaten Schlüssel erfordert das Secret ein Passwort für den privaten Schlüssel. Sowohl das Zertifikat als auch der private Schlüssel müssen im PEM-Format vorliegen. **Anmerkung** Lambda unterstützt die Verschlüsselungsalgorithmen mit privaten Schlüsseln [PBES1](https://datatracker.ietf.org/doc/html/rfc2898/#section-6.1)(aber nicht PBES2). Das Zertifikatfeld muss eine Liste von Zertifikaten enthalten, beginnend mit dem Client-Zertifikat, gefolgt von etwaigen Zwischenzertifikaten und endend mit dem Root-Zertifikat. Jedes Zertifikat muss in einer neuen Zeile mit der folgenden Struktur beginnen: ``` -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ``` Secrets Manager unterstützt Secrets von bis zu 65 536 Bytes, was genügend Platz für lange Zertifikatsketten bietet. Der private Schlüssel muss im Format [PKCS \$18](https://datatracker.ietf.org/doc/html/rfc5208) mit folgender Struktur vorliegen: ``` -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- ``` Verwenden Sie für einen verschlüsselten privaten Schlüssel die folgende Struktur: ``` -----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY----- ``` Im folgenden Beispiel sehen Sie den Inhalt eines Secrets für mTLS-Authentifizierung mit einem verschlüsselten privaten Schlüssel. Fügen Sie für einen verschlüsselten privaten Schlüssel das Passwort für den privaten Schlüssel in das Secret ein. ``` {"privateKeyPassword":"testpassword", "certificate":"-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey":"-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" } ``` ## Konfigurieren des Secrets des Server-Root-CA-Zertifikats Sie erstellen dieses Secret, wenn Ihre Kafka-Broker TLS-Verschlüsselung mit Zertifikaten verwenden, die von einer privaten CA signiert wurden. Sie können die TLS-Verschlüsselung für die VPC- SASL/SCRAM, SASL/PLAIN oder mTLS-Authentifizierung verwenden. Das Secret des Server-Root-CA-Zertifikats erfordert ein Feld, das das Root-CA-Zertifikat des Kafka-Brokers im PEM-Format enthält. Das folgende Beispiel zeigt die Struktur des Secrets. ``` {"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" } ``` # Erstellen einer Lambda-Zuordnung von Ereignisquellen für eine selbstverwaltete Apache-Kafka-Ereignisquelle Zum Erstellen einer Zuordnung von Ereignisquellen können Sie die Lambda-Konsole, die [AWS Command Line Interface (CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) oder ein [AWS SDK](https://aws.amazon.com/getting-started/tools-sdks/) verwenden. Mit den folgenden Schritten in der Konsole fügen Sie einen selbstverwalteten Apache-Kafka-Cluster als Auslöser für Ihre Lambda-Funktion hinzu. Im Hintergrund wird dadurch eine Zuordnung von Ereignisquellen erstellt. ## Voraussetzungen + Selbstverwaltetes Apache-Kafka-Cluster. Lambda unterstützt Apache Kafka Version 0.10.1.0 und höher. + Eine [Ausführungsrolle mit der](lambda-intro-execution-role.md) Berechtigung, auf die AWS Ressourcen zuzugreifen, die Ihr selbstverwalteter Kafka-Cluster verwendet. ## Hinzufügen eines selbstverwalteten Kafka-Clusters (Konsole) Befolgen Sie diese Schritte, um Ihren selbstverwalteten Apache-Kafka-Cluster und ein Kafka-Thema als Auslöser für Ihre Lambda-Funktion hinzuzufügen. **So fügen Sie Ihrer Lambda-Funktion (Konsole) einen Apache-Kafka-Auslöser hinzu** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen Ihrer Lambda-Funktion aus. 1. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add trigger (Trigger hinzufügen)**. 1. Führen Sie unter **Auslöser-Konfiguration** die folgenden Schritte aus: 1. Wählen Sie den **Apache-Kafka**-Auslösertyp. 1. Geben Sie für **Bootstrap-Server** die Host- und Portpaaradresse eines Kafka-Brokers in Ihrem Cluster ein und wählen Sie dann **Hinzufügen**. Wiederholen Sie den Vorgang für jeden Kafka-Broker im Cluster. 1. Geben Sie für **Themenname** den Namen des Kafka-Themas ein, das zum Speichern von Datensätzen im Cluster verwendet wird. 1. Wenn Sie den Bereitstellungsmodus konfigurieren, geben Sie einen Wert für **Minimale Anzahl von Ereignisabfragen**, einen Wert für **Maximale Anzahl an Ereignisabfragen** und einen optionalen Wert ein, PollerGroupName um die Gruppierung mehrerer ESMs innerhalb derselben Ereignisquellen-VPC anzugeben. 1. (Optional) Geben Sie für **Batchgröße** die maximale Anzahl von Datensätzen ein, die in einem einzelnen Batch empfangen werden sollen. 1. Geben Sie für **Batch window** (Batch-Fenster) die maximale Zeit in Sekunden ein, die Lambda mit dem Sammeln von Datensätzen verbringt, bevor die Funktion aufgerufen wird. 1. (Optional) Geben Sie für **Konsumentengruppen-ID** die ID einer Kafka-Konsumentengruppe ein, der Sie beitreten möchten. 1. (Optional) Wählen Sie für **Startposition** die Option **Neueste**, um mit dem Lesen des Streams aus dem letzten Datensatz zu beginnen, **Horizont trimmen**, um mit dem frühesten verfügbaren Datensatz zu beginnen, oder **Am Zeitstempel**, um einen Zeitstempel anzugeben, ab dem mit dem Lesen begonnen werden soll. 1. (Optional) Wählen Sie bei **VPC** die Amazon VPC für Ihren Kafka-Cluster aus. Wählen Sie dann **VPC subnets** (VPC-Subnetze) und **VPC security groups** (VPC-Sicherheitsgruppen) aus. Diese Einstellung ist erforderlich, wenn nur Benutzer innerhalb Ihrer VPC auf Ihre Broker zugreifen. 1. (Optional) Wählen Sie bei **Authentication** (Authentifizierung) die Option **Add** (Hinzufügen) aus und gehen Sie dann folgendermaßen vor: 1. Wählen Sie das Zugriffs- oder Authentifizierungsprotokoll der Kafka-Broker in Ihrem Cluster aus. + **Wenn Ihr Kafka-Broker Authentifizierung verwendet, wählen Sie BASIC\$1AUTH. SASL/PLAIN ** + Wenn Ihr Broker SASL/SCRAM Authentifizierung verwendet, wählen Sie eines der Protokolle. **SASL\$1SCRAM** + Falls Sie die mTLS-Authentifizierung konfigurieren, wählen Sie das Protokoll **CLIENT\$1CERTIFICATE\$1TLS\$1AUTH** aus. 1. Wählen Sie für SASL/SCRAM die mTLS-Authentifizierung den geheimen Schlüssel von Secrets Manager, der die Anmeldeinformationen für Ihren Kafka-Cluster enthält. 1. (Optional) Wählen Sie bei **Encryption** (Verschlüsselung) das Secrets-Manager-Secret aus, das das Root-CA-Zertifikat enthält, das Ihre Kafka-Broker zur TLS-Verschlüsselung verwenden, falls Ihre Kafka-Broker von einer privaten Zertifizierungsstelle signierte Zertifikate verwenden. Diese Einstellung gilt für die TLS-Verschlüsselung für SASL/SCRAM oder SASL/PLAIN und für die mTLS-Authentifizierung. 1. Um den Auslöser zu Testzwecken in einem deaktivierten Zustand zu erstellen (empfohlen), deaktivieren Sie **Auslöser aktivieren**. Um den Auslöser sofort zu aktivieren, wählen Sie **Auslöser aktivieren**. 1. Wählen Sie **hinzufügen** aus, um den Auslöser zu erstellen. ## Selbstverwaltetes Apache-Kafka-Cluster hinzufügen (AWS CLI) Verwenden Sie die folgenden AWS CLI Beispielbefehle, um einen selbstverwalteten Apache Kafka-Trigger für Ihre Lambda-Funktion zu erstellen und anzuzeigen. ### Verwenden von SASL/SCRAM Wenn Kafka-Benutzer über das Internet auf Ihre Kafka-Broker zugreifen, geben Sie das Secrets Manager Manager-Geheimnis an, das Sie für SASL/SCRAM die Authentifizierung erstellt haben. Im folgenden Beispiel wird der [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Befehl verwendet, um eine Lambda-Funktion mit dem Namen einem Kafka-Thema namens `my-kafka-function` zuzuordnen. `AWSKafkaTopic` ``` aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}' ``` ### Verwenden einer VPC Wenn nur Kafka-Benutzer in Ihrer VPC auf Ihre Kafka-Broker zugreifen, müssen Sie Ihre VPC, Subnetze und VPC-Sicherheitsgruppe angeben. Im folgenden Beispiel wird der [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Befehl verwendet, um eine Lambda-Funktion mit dem Namen einem Kafka-Thema namens `my-kafka-function` zuzuordnen. `AWSKafkaTopic` ``` aws lambda create-event-source-mapping \ --topics AWSKafkaTopic \ --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \ --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \ --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}' ``` ### Den Status mit dem anzeigen AWS CLI Im folgenden Beispiel wird der [get-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-event-source-mapping.html) AWS CLI Befehl verwendet, um den Status der von Ihnen erstellten Ereignisquellenzuordnung zu beschreiben. ``` aws lambda get-event-source-mapping --uuid dh38738e-992b-343a-1077-3478934hjkfd7 ``` # Alle Konfigurationsparameter für selbstverwaltete Apache-Kafka-Ereignisquellen in Lambda 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 selbstverwaltetes Apache Kafka, wie in der folgenden Tabelle dargestellt. | Parameter | Erforderlich | Standard | Hinweise | | --- | --- | --- | --- | | BatchSize | N | 100 | Höchstwert: 10 000. | | DestinationConfig | N | – | [Erfassen verworfener Batches für Amazon MSK und selbstverwaltete Apache-Kafka-Ereignisquellen](kafka-on-failure.md) | | Aktiviert | N | Wahr | | | FilterCriteria | N | – | [Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet](invocation-eventfiltering.md) | | FunctionName | Y | – | | | KMSKeyArn | N | – | [Verschlüsselung der Filterkriterien](invocation-eventfiltering.md#filter-criteria-encryption) | | MaximumBatchingWindowInSeconds | N | 500 ms | [Batching-Verhalten](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching) | | ProvisionedPollersConfig | N | `MinimumPollers`: Standardwert von 1, wenn nicht angegeben `MaximumPollers`: Standardwert von 200, wenn nicht angegeben `PollerGroupName`: N/A | [Modus bereitgestellter Kapazität](kafka-scaling-modes.md#kafka-provisioned-mode) | | SelfManagedEventSource | Y | – | Liste der Kafka Broker. Kann nur auf „Erstellen“ festgelegt werden | | SelfManagedKafkaEventSourceConfig | N | Enthält das ConsumerGroupId Feld, das standardmäßig einen eindeutigen Wert hat. | Kann nur auf „Erstellen“ festgelegt werden | | SourceAccessConfigurations | N | Keine Anmeldeinformationen | VPC-Informationen oder Authentifizierungsanmeldeinformationen für den Cluster Für SASL\$1PLAIN, auf BASIC\$1AUTH gesetzt | | StartingPosition | Y | – | AT\$1TIMESTAMP, TRIM\$1HORIZON, oder LATEST Kann nur auf „Erstellen“ festgelegt werden | | StartingPositionTimestamp | N | – | Erforderlich, wenn der Wert auf StartingPosition AT\$1TIMESTAMP gesetzt ist | | Tags (Markierungen) | N | – | [Verwendung von Tags für Zuordnungen von Ereignisquellen](tags-esm.md) | | Topics | Y | – | Themenname Kann nur auf „Erstellen“ festgelegt werden | **Anmerkung** Wenn Sie a angeben`PollerGroupName`, können sich mehrere ESMs innerhalb derselben Amazon VPC die Kapazität der Event Poller Unit (EPU) teilen. Sie können diese Option verwenden, um die Kosten für den Bereitstellungsmodus für Sie zu optimieren. ESMs Anforderungen für die ESM-Gruppierung: ESMs muss sich in derselben Amazon VPC befinden Maximal 100 ESMs pro Befragungsgruppe Die Gesamtzahl der Befragten ESMs in einer Gruppe darf 2000 nicht überschreiten Sie können den aktualisieren`PollerGroupName`, um einen ESM in eine andere Gruppe zu verschieben, oder einen ESM aus einer Gruppe entfernen, indem Sie ihn `PollerGroupName` auf eine leere Zeichenfolge („“) setzen.