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 MSK
[Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) ist ein vollständig verwalteter Service, mit dem Sie Anwendungen erstellen und ausführen können, die Apache Kafka zum Verarbeiten von Streamingdaten verwenden. Amazon MSK vereinfacht die Einrichtung, Skalierung und Verwaltung von Kafka-Clustern. Amazon MSK erleichtert auch die Konfiguration Ihrer Anwendung für mehrere Availability Zones und aus Sicherheitsgründen mit AWS Identity and Access Management (IAM).
In diesem Kapitel wird erklärt, wie Sie einen Amazon-MSK-Cluster als Ereignisquelle für Ihre Lambda-Funktion verwenden. Der allgemeine Prozess zur Integration von Amazon MSK mit Lambda umfasst die folgenden Schritte:
1. **[Cluster- und Netzwerk-Setup](with-msk-cluster-network.md)**: Richten Sie zunächst Ihren [Amazon-MSK-Cluster](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) ein. Dazu gehört die richtige Netzwerkkonfiguration, damit Lambda auf Ihren Cluster zugreifen kann.
1. **[Einrichtung der Zuordnung von Ereignisquellen](with-msk-configure.md)**: Erstellen Sie anschließend die Ressource für die [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md), die Lambda benötigt, um Ihren Amazon-MSK-Cluster sicher mit Ihrer Funktion zu verbinden.
1. **[Einrichtung von Funktionen und Berechtigungen](with-msk-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.
**Anmerkung**
Sie können jetzt Ihre Amazon MSK-Ereignisquellenzuordnungen direkt von der Lambda- oder der Amazon MSK-Konsole aus erstellen und verwalten. Beide Konsolen bieten die Option, die Einrichtung der erforderlichen Berechtigungen für die Lambda-Ausführungsrolle automatisch vorzunehmen, um den Konfigurationsprozess zu optimieren.
Beispiele für die Einrichtung einer Lambda-Integration mit einem Amazon MSK-Cluster finden Sie unter [Tutorial: Verwenden einer Amazon-MSK-Zuordnung von Ereignisquellen zum Aufrufen einer Lambda-Funktion](services-msk-tutorial.md) [Verwenden von Amazon MSK als Ereignisquelle für AWS Lambda](https://aws.amazon.com/blogs/compute/using-amazon-msk-as-an-event-source-for-aws-lambda/) im AWS Compute-Blog und [Amazon MSK Lambda-Integration in den Amazon MSK](https://amazonmsk-labs.workshop.aws/en/msklambda.html) Labs.
**Topics**
+ [Beispielereignis](#msk-sample-event)
+ [Konfiguration Ihres Amazon-MSK-Clusters und Ihres Amazon-VPC-Netzwerks für Lambda](with-msk-cluster-network.md)
+ [Konfiguration von Lambda-Berechtigungen für Amazon MSK-Ereignisquellenzuordnungen](with-msk-permissions.md)
+ [Konfigurieren von Amazon MSK-Ereignisquellen für Lambda](with-msk-configure.md)
+ [Tutorial: Verwenden einer Amazon-MSK-Zuordnung von Ereignisquellen zum Aufrufen einer Lambda-Funktion](services-msk-tutorial.md)
## Beispielereignis
Lambda sendet den Batch von Nachrichten im Ereignisparameter, wenn es Ihre Funktion aufruft. Die Ereignisnutzlast enthält ein Array von Meldungen. Jedes Array-Element enthält Details zum Amazon-MSK-Thema und zur Partitions-ID sowie einen Zeitstempel und eine base64-codierte Nachricht.
```
{
"eventSource":"aws:kafka",
"eventSourceArn":"arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2",
"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 Amazon-MSK-Clusters und Ihres Amazon-VPC-Netzwerks für Lambda
Um Ihre AWS Lambda Funktion mit Ihrem Amazon MSK-Cluster zu verbinden, müssen Sie Ihren Cluster und die [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html), in der er sich befindet, korrekt konfigurieren. Auf dieser Seite wird beschrieben, wie Sie Ihren Cluster und Ihre VPC konfigurieren. Wenn Ihr Cluster und Ihre VPC bereits ordnungsgemäß konfiguriert sind, lesen Sie unter [Konfigurieren von Amazon MSK-Ereignisquellen für Lambda](with-msk-configure.md) nach, wie Sie die Zuordnung von Ereignisquellen konfigurieren.
**Topics**
+ [Überblick über die Anforderungen an die Netzwerkkonfiguration für Lambda- und MSK-Integrationen](#msk-network-requirements)
+ [Konfiguration eines NAT-Gateways für eine MSK-Ereignisquelle](#msk-nat-gateway)
+ [Konfiguration von AWS PrivateLink Endpunkten für eine MSK-Ereignisquelle](#msk-vpc-privatelink)
## Überblick über die Anforderungen an die Netzwerkkonfiguration für Lambda- und MSK-Integrationen
Die für eine Lambda- und MSK-Integration erforderliche Netzwerkkonfiguration hängt von der Netzwerkarchitektur Ihrer Anwendung ab. An dieser Integration sind drei Hauptressourcen beteiligt: der Amazon-MSK-Cluster, die Lambda-Funktion und die Lambda-Zuordnung von Ereignisquellen. Jede dieser Ressourcen befindet sich in einer anderen VPC:
+ Ihr Amazon-MSK-Cluster befindet sich normalerweise in einem privaten Subnetz einer VPC, die Sie verwalten.
+ Ihre Lambda-Funktion befindet sich in einer AWS verwalteten VPC, die Lambda gehört.
+ Ihre Lambda-Ereignisquellenzuordnung befindet sich in einer anderen von Lambda AWS verwalteten VPC, getrennt von der VPC, die Ihre Funktion enthält.
Die [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md) ist die Zwischenressource zwischen dem MSK-Cluster und der Lambda-Funktion. Die Zuordnung von Ereignisquellen hat zwei Hauptaufgaben. Zunächst fragt sie Ihren MSK-Cluster nach neuen Nachrichten ab. Anschließend wird Ihre Lambda-Funktion mit diesen Nachrichten aufgerufen. Da sich diese drei Ressourcen unterscheiden VPCs, erfordern sowohl der Abruf- als auch der Aufrufvorgang VPC-übergreifende Netzwerkaufrufe.
Die Anforderungen an die Netzwerkkonfiguration für Ihre Zuordnung von Ereignisquellen hängen davon ab, ob der [Bereitstellungsmodus](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode) oder der On-Demand-Modus verwendet wird, wie im folgenden Diagramm dargestellt:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/MSK-esm-network-overview.png)
Die Art und Weise, wie die Lambda-Zuordnung von Ereignisquellen Ihren MSK-Cluster nach neuen Nachrichten abfragt, ist in beiden Modi dieselbe. Um eine Verbindung zwischen Ihrer Zuordnung von Ereignisquellen und Ihrem MSK-Cluster herzustellen, erstellt Lambda in Ihrem privaten Subnetz eine [Hyperplane-ENI](configuration-vpc.md#configuration-vpc-enis) (oder verwendet eine vorhandene, falls verfügbar), um eine sichere Verbindung herzustellen. Wie im Diagramm dargestellt, verwendet diese Hyperplane-ENI die Subnetz- und Sicherheitsgruppenkonfiguration Ihres MSK-Clusters, nicht Ihre Lambda-Funktion.
Nachdem Sie die Nachricht vom Cluster abgerufen haben, ist die Art und Weise, wie Lambda Ihre Funktion aufruft, in jedem Modus unterschiedlich:
+ Im Bereitstellungsmodus verarbeitet Lambda automatisch die Verbindung zwischen der VPC für die Zuordnung von Ereignisquellen und der Funktions-VPC. Sie benötigen also keine zusätzlichen Netzwerkkomponenten, um Ihre Funktion erfolgreich aufzurufen.
+ Im On-Demand-Modus ruft Ihre Lambda-Zuordnung von Ereignisquellen Ihre Funktion über einen Pfad durch Ihre vom Kunden verwaltete VPC auf. Aus diesem Grund müssen Sie entweder ein [NAT-Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im öffentlichen Subnetz Ihrer VPC oder [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)-Endpunkte im privaten Subnetz der VPC konfigurieren, die Zugriff auf Lambda, [AWS -Security-Token-Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) und optional [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) bieten. Die korrekte Konfiguration einer dieser Optionen ermöglicht eine Verbindung zwischen Ihrer VPC und der von Lambda verwalteten Laufzeit-VPC, die zum Aufrufen Ihrer Funktion erforderlich ist.
Ein NAT-Gateway ermöglicht Ressourcen in Ihrem privaten Subnetz den Zugriff auf das öffentliche Internet. Wenn Sie diese Konfiguration verwenden, durchquert Ihr Datenverkehr das Internet, bevor die Lambda-Funktion aufgerufen wird. AWS PrivateLink Endpunkte ermöglichen es privaten Subnetzen, sich sicher mit AWS Diensten oder anderen privaten VPC-Ressourcen zu verbinden, ohne das öffentliche Internet zu durchqueren. Weitere Informationen zur Konfiguration dieser Ressourcen finden Sie unter [Konfiguration eines NAT-Gateways für eine MSK-Ereignisquelle](#msk-nat-gateway) oder [Konfiguration von AWS PrivateLink Endpunkten für eine MSK-Ereignisquelle](#msk-vpc-privatelink).
Bisher gingen wir davon aus, dass sich Ihr MSK-Cluster in einem privaten Subnetz innerhalb Ihrer VPC befindet, was der häufigste Fall ist. Selbst wenn sich Ihr MSK-Cluster in einem öffentlichen Subnetz innerhalb Ihrer VPC befindet, müssen Sie AWS PrivateLink -Endpunkte konfigurieren, um eine sichere Verbindung zu gewährleisten. In der folgenden Tabelle sind die Anforderungen an die Netzwerkkonfiguration zusammengefasst, je nachdem, wie Sie Ihren MSK-Cluster und die Lambda-Zuordnung von Ereignisquellen konfigurieren:
| Standort des MSK-Clusters (in der vom Kunden verwalteten VPC) | Skalierungsmodus der Lambda-Zuordnung von Ereignisquellen | Erforderliche Netzwerkkonfiguration |
| --- | --- | --- |
| Privates Subnetz | On-Demand-Modus | NAT-Gateway (im öffentlichen Subnetz Ihrer VPC) oder AWS PrivateLink Endpoints (im privaten Subnetz Ihrer VPC), um den Zugriff auf Lambda und optional auf Secrets Manager zu ermöglichen. AWS STS |
| Öffentliches Subnetz | On-Demand-Modus | AWS PrivateLink Endpunkte (im öffentlichen Subnetz Ihrer VPC), um den Zugriff auf Lambda und optional auf Secrets AWS STS Manager zu ermöglichen. |
| Privates Subnetz | Modus bereitgestellter Kapazität | Keine |
| Öffentliches Subnetz | Modus bereitgestellter Kapazität | Keine |
Darüber hinaus müssen die mit Ihrem MSK-Cluster verknüpften Sicherheitsgruppen den Datenverkehr über die richtigen Ports zulassen. Stellen Sie sicher, dass Sie die folgenden Regeln für Sicherheitsgruppen konfiguriert haben:
+ **Regeln für eingehenden Datenverkehr** – Erlauben Sie den gesamten Datenverkehr auf dem standardmäßigen Broker-Port. Der von MSK verwendete Port hängt vom Authentifizierungstyp des Clusters ab: `9098` für IAM-Authentifizierung, `9096` für SASL/SCRAM und `9094` für TLS. 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 über den Port `443` für externe Ziele, wenn Ihre Funktion mit anderen Diensten kommunizieren muss. AWS Alternativ können Sie eine selbstreferenzierende Sicherheitsgruppenregel verwenden, um den Zugriff auf den Broker einzuschränken, wenn Sie nicht mit anderen Diensten kommunizieren müssen. AWS
+ **Regeln für eingehenden Datenverkehr auf Amazon-VPC-Endpunkten** – Wenn Sie einen Amazon-VPC-Endpunkt verwenden, muss die mit dem Endpunkt verbundene Sicherheitsgruppe eingehenden Datenverkehr auf Port `443` von der Sicherheitsgruppe des Clusters zulassen.
## Konfiguration eines NAT-Gateways für eine MSK-Ereignisquelle
Sie können ein NAT-Gateway so konfigurieren, dass Ihre Zuordnung von Ereignisquellen Nachrichten von Ihrem Cluster abfragen und die Funktion über einen Pfad durch Ihre VPC aufrufen kann. Dies ist nur erforderlich, wenn Ihre Zuordnung von Ereignisquellen den On-Demand-Modus verwendet und sich Ihr Cluster in einem privaten Subnetz Ihrer VPC befindet. Wenn sich Ihr Cluster in einem öffentlichen Subnetz Ihrer VPC befindet oder Ihre Zuordnung von Ereignisquellen den Bereitstellungsmodus verwendet, müssen Sie kein NAT-Gateway konfigurieren.
Ein [NAT-Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) ermöglicht Ressourcen in einem privaten Subnetz den Zugriff auf das öffentliche Internet. Wenn Sie eine private Verbindung zu Lambda benötigen, finden Sie stattdessen weitere Informationen unter [Konfiguration von AWS PrivateLink Endpunkten für eine MSK-Ereignisquelle](#msk-vpc-privatelink).
Nachdem Sie Ihr NAT-Gateway konfiguriert haben, müssen Sie die entsprechenden Routing-Tabellen konfigurieren. Dadurch kann der Datenverkehr aus Ihrem privaten Subnetz über das NAT-Gateway in das öffentliche Internet geleitet werden.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/MSK-NAT-Gateway.png)
Die folgenden Schritte führen Sie durch die Konfiguration eines NAT-Gateways über die Konsole. Wiederholen Sie diese Schritte bei Bedarf für jede Availability Zone (AZ).
**So konfigurieren Sie ein NAT-Gateway und das richtige Routing (Konsole)**
1. Folgen Sie den Schritten unter [Erstellen eines NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-working-with.html) und beachten Sie dabei Folgendes:
+ NAT-Gateways sollten sich immer in einem öffentlichen Subnetz befinden. Erstellen Sie NAT-Gateways mit [öffentlicher Konnektivität](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
+ Wenn Ihr MSK-Cluster über mehrere repliziert wird AZs, erstellen Sie ein NAT-Gateway pro AZ. In jeder AZ sollte Ihre VPC beispielsweise ein privates Subnetz mit Ihrem Cluster und ein öffentliches Subnetz mit Ihrem NAT-Gateway haben. Bei einem Setup mit drei AZs haben Sie drei private Subnetze, drei öffentliche Subnetze und drei NAT-Gateways.
1. Nachdem Sie Ihr NAT-Gateway erstellt haben, öffnen Sie die [Amazon VPC-Konsole](https://console.aws.amazon.com/vpc/) und wählen Sie im linken Menü **Routing-Tabellen** aus.
1. Klicken Sie auf **Create Route Table (Routing-Tabelle erstellen)**.
1. Ordnen Sie diese Routing-Tabelle der VPC zu, die Ihren MSK-Cluster enthält. Geben Sie optional einen Namen für Ihre Routing-Tabelle ein.
1. Klicken Sie auf **Create Route Table (Routing-Tabelle erstellen)**.
1. Wählen Sie die Routing-Tabelle aus, die Sie gerade erstellt haben.
1. Wählen Sie auf der Registerkarte **Subnetzzuordnungen** die Option **Subnetzzuordnungen bearbeiten** aus.
+ Ordnen Sie diese Routing-Tabelle dem privaten Subnetz zu, das Ihren MSK-Cluster enthält.
1. Wählen Sie **Routen bearbeiten** aus.
1. Wählen Sie **Route hinzufügen** aus:
1. Geben Sie für **Ziel** die Zeichenfolge `0.0.0.0/0` an.
1. Wählen Sie für **Ziel** die Option **NAT-Gateway** aus.
1. Wählen Sie im Suchfeld das in Schritt 1 erstellte NAT-Gateway aus. Dies sollte das NAT-Gateway in derselben AZ sein wie das private Subnetz, das Ihren MSK-Cluster enthält (das private Subnetz, das Sie dieser Routing-Tabelle in Schritt 6 zugeordnet haben).
1. Wählen Sie **Änderungen speichern ** aus.
## Konfiguration von AWS PrivateLink Endpunkten für eine MSK-Ereignisquelle
Sie können AWS PrivateLink Endpoints so konfigurieren, dass sie Nachrichten von Ihrem Cluster abfragen, und die Funktion über einen Pfad durch Ihre VPC aufrufen. Diese Endpunkte sollten Ihrem MSK-Cluster den Zugriff auf Folgendes ermöglichen:
+ Den Lambda-Service
+ Den [AWS -Security-Token-Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)
+ Optional den [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)-Service. Dies ist erforderlich, wenn das für die Cluster-Authentifizierung erforderliche Secret im Secrets Manager gespeichert ist.
Die Konfiguration von PrivateLink Endpunkten ist nur erforderlich, wenn Ihre Ereignisquellenzuordnung den On-Demand-Modus verwendet. Wenn Ihre Zuordnung von Ereignisquellen den Bereitstellungsmodus verwendet, richtet Lambda die erforderlichen Verbindungen für Sie ein.
PrivateLink Endpunkte ermöglichen einen sicheren, privaten Zugriff auf AWS Dienste über. AWS PrivateLink Alternativ können Sie ein NAT-Gateway konfigurieren, um Ihrem MSK-Cluster Zugriff auf das öffentliche Internet zu ermöglichen (siehe [Konfiguration eines NAT-Gateways für eine MSK-Ereignisquelle](#msk-nat-gateway)).
Nachdem Sie Ihre VPC-Endpunkte konfiguriert haben, sollte Ihr MSK-Cluster direkten und privaten Zugriff auf Lambda, STS und optional Secrets Manager haben.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/MSK-PrivateLink-Endpoints.png)
Die folgenden Schritte führen Sie durch die Konfiguration eines PrivateLink Endpunkts mithilfe der Konsole. Wiederholen Sie diese Schritte nach Bedarf für jeden Endpunkt (Lambda, STS, Secrets Manager).
**So konfigurieren Sie PrivateLink VPC-Endpunkte (Konsole)**
1. Öffnen Sie die [Amazon VPC-Konsole](https://console.aws.amazon.com/vpc/) und wählen Sie im linken Menü **Endpunkte** aus.
1. Wählen Sie **Endpunkt erstellen** aus.
1. Geben Sie optional einen Namen für Ihren Endpunkt ein.
1. Wählen Sie für **Typ** die Option **AWS -Services** aus.
1. Beginnen Sie unter **Services** mit der Eingabe des Namens des Service. Um beispielsweise einen Endpunkt für die Verbindung mit Lambda zu erstellen, geben Sie `lambda` in das Suchfeld ein.
1. In den Ergebnissen sollte der Service-Endpunkt in der aktuellen Region angezeigt werden. In der Region USA Ost (Nord-Virginia) sollte beispielsweise `com.amazonaws.us-east-2.lambda` angezeigt werden. Wählen Sie diesen Service aus.
1. Wählen Sie unter **Netzwerkeinstellungen** die VPC aus, die Ihren MSK-Cluster enthält.
1. Wählen Sie unter **Subnetze** das aus, in dem AZs sich Ihr MSK-Cluster befindet.
+ Wählen Sie für jede AZ unter **Subnetz-ID** das private Subnetz aus, das Ihren MSK-Cluster enthält.
1. Wählen Sie unter **Sicherheitsgruppen** die Ihrem MSK-Cluster zugeordneten Sicherheitsgruppen aus.
1. Wählen Sie **Endpunkt erstellen** aus.
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. Für Ihren Secrets-Manager-Endpunkt können Sie beispielsweise dessen Richtlinie so ändern, dass nur die Ausführungsrolle Ihrer Funktion auf das Secret zugreifen kann.
**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"
}
]
}
```
Für die AWS STS und Lambda-Endpunkte können Sie den aufrufenden Principal auf den Lambda-Serviceprinzipal beschränken. Stellen Sie jedoch sicher, dass Sie in diesen Richtlinien `"Resource": "*"` verwenden.
**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": "*"
}
]
}
```
# Konfiguration von Lambda-Berechtigungen für Amazon MSK-Ereignisquellenzuordnungen
Um auf den Amazon-MSK-Cluster zugreifen zu können, benötigen Ihre Funktion und Zuordnung von Ereignisquellen Berechtigungen zum Ausführen verschiedener Amazon-MSK-API-Aktionen. Fügen Sie diese Berechtigungen zur [Ausführungsrolle](lambda-intro-execution-role.md) der Funktion hinzu. Wenn Ihre Benutzer Zugriff benötigen, fügen Sie die erforderlichen Berechtigungen zur Identitätsrichtlinie für Benutzer oder Rolle hinzu.
Die Richtlinie „[AWSLambdaMSKExecutionRollenverwaltung](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)“ enthält die erforderlichen Mindestberechtigungen für Amazon MSK Lambda-Ereignisquellenzuordnungen. Um den Genehmigungsprozess zu vereinfachen, können Sie:
+ Fügen Sie Ihrer [AWSLambdaMSKExecutionAusführungsrolle die Richtlinie „Rollenverwaltete](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) Verwaltung“ hinzu.
+ Lassen Sie die Lambda-Konsole die Berechtigungen für Sie generieren. Wenn Sie [eine Amazon MSK-Ereignisquellenzuordnung in der Konsole erstellen](msk-esm-create.md#msk-console), bewertet Lambda Ihre Ausführungsrolle und warnt Sie, wenn Berechtigungen fehlen. Wählen Sie **Berechtigungen generieren**, um Ihre Ausführungsrolle automatisch zu aktualisieren. Dies funktioniert nicht, wenn Sie Ihre Richtlinien für Ausführungsrollen manuell erstellt oder geändert haben oder wenn die Richtlinien mehreren Rollen zugeordnet sind. Beachten Sie, dass für Ihre Ausführungsrolle möglicherweise weiterhin zusätzliche Berechtigungen erforderlich sind, wenn Sie erweiterte Funktionen wie [On-Failure Destination](kafka-on-failure.md) oder [AWS Glue Schema Registry](services-consume-kafka-events.md) verwenden.
**Topics**
+ [Erforderliche Berechtigungen](#msk-required-permissions)
+ [Optionale Berechtigungen](#msk-optional-permissions)
## Erforderliche Berechtigungen
Ihre Lambda-Funktionsausführungsrolle muss über die folgenden erforderlichen Berechtigungen für Amazon MSK-Ereignisquellenzuordnungen verfügen. [Diese Berechtigungen sind in der Richtlinie „Rollenverwaltung“ enthalten. AWSLambda MSKExecution](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)
### CloudWatch Protokolliert Berechtigungen
Die folgenden Berechtigungen ermöglichen es Lambda, Protokolle in Amazon CloudWatch Logs zu erstellen und zu speichern.
+ [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)
### MSK-Cluster-Berechtigungen
Die folgenden Berechtigungen ermöglichen Lambda, in Ihrem Namen auf Ihren Amazon MSK-Cluster zuzugreifen:
+ [Kafka: DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html)
+ [Kafka: V2 DescribeCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html)
+ [Kafka: GetBootstrapBrokers](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html)
Wir empfehlen die Verwendung von [kafka: DescribeCluster V2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html) anstelle von [kafka](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html):. DescribeCluster Die v2-Berechtigung funktioniert sowohl mit bereitgestellten als auch mit serverlosen Amazon MSK-Clustern. In Ihrer Richtlinie benötigen Sie nur eine dieser Berechtigungen.
### VPC-Berechtigungen
Die folgenden Berechtigungen ermöglichen es Lambda, Netzwerkschnittstellen zu erstellen und zu verwalten, wenn eine Verbindung zu Ihrem Amazon MSK-Cluster hergestellt wird:
+ [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)
## Optionale Berechtigungen
Ihre Lambda-Funktion benötigt möglicherweise auch Berechtigungen für Folgendes:
+ Greifen Sie auf kontenübergreifende Amazon MSK-Cluster zu. Für kontenübergreifende Zuordnungen von Ereignisquellen benötigen Sie [kafka](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connection-arn.html): in der Ausführungsrolle. DescribeVpcConnection [Ein IAM-Prinzipal, der eine kontenübergreifende Zuordnung von Ereignisquellen erstellt, benötigt kafka:. ListVpcConnections](https://docs.aws.amazon.com/msk/1.0/apireference/vpc-connections.html)
+ Greifen Sie auf Ihr SCRAM-Secret zu, wenn Sie die [SASL/SCRAM-Authentifizierung](msk-cluster-auth.md#msk-sasl-scram) verwenden. Dadurch kann Ihre Funktion einen Benutzernamen und ein Passwort verwenden, um eine Verbindung zu Kafka herzustellen.
+ Beschreiben Sie Ihr Secrets Manager-Geheimnis, falls Sie die SASL/SCRAM [mTLS-Authentifizierung](msk-cluster-auth.md#msk-mtls) verwenden. Dadurch kann Ihre Funktion die für sichere Verbindungen erforderlichen Anmeldeinformationen oder Zertifikate abrufen.
+ Greifen Sie auf Ihren vom AWS KMS Kunden verwalteten Schlüssel zu, wenn Ihr AWS Secrets Manager Geheimnis mit einem vom AWS KMS Kunden verwalteten Schlüssel verschlüsselt ist.
+ Greifen Sie auf Ihre Schemaregistrierungs-Secrets zu, wenn Sie eine Schemaregistrierung mit Authentifizierung verwenden:
+ Für AWS Glue Schema Registry: Ihre Funktionsanforderungen `glue:GetRegistry` und `glue:GetSchemaVersion` Berechtigungen. Dadurch kann Ihre Funktion die in AWS Glue gespeicherten Nachrichtenformatregeln nachschlagen und verwenden.
+ Für [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/security/index.html) mit `BASIC_AUTH` oder`CLIENT_CERTIFICATE_TLS_AUTH`: Ihre Funktion benötigt die Berechtigung `secretsmanager:GetSecretValue` für das Secret, das die Authentifizierungsdaten enthält. Auf diese Weise kann Ihre Funktion die Oder-Zertifikate abrufen, die username/password für den Zugriff auf die Confluent Schema Registry erforderlich sind.
+ Für private CA-Zertifikate: Ihre Funktion benötigt die GetSecretValue Berechtigung secretsmanager: für das Secret, das das Zertifikat enthält. Dadurch kann Ihre Funktion die Identität von Schemaregistrierungen überprüfen, die benutzerdefinierte Zertifikate verwenden.
+ Greifen Sie auf Kafka-Cluster-Nutzergruppen und Abfragemeldungen aus dem Thema zu, wenn Sie die IAM-Authentifizierung für die Zuordnung der Ereignisquellen verwenden.
Diese entsprechen den folgenden erforderlichen Berechtigungen:
+ [kafka: ListScramSecrets](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html) — Ermöglicht die Auflistung von SCRAM-Geheimnissen für die Kafka-Authentifizierung
+ [secretsmanager: GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) - Ermöglicht das Abrufen von Geheimnissen aus Secrets Manager
+ [kms:Decrypt — Ermöglicht die Entschlüsselung verschlüsselter Daten mit](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) AWS KMS
+ [glue: GetRegistry](https://docs.aws.amazon.com/glue/latest/webapi/API_GetRegistry.html) - Ermöglicht den Zugriff auf die Schemaregistrierung AWS Glue
+ [glue: GetSchemaVersion](https://docs.aws.amazon.com/glue/latest/webapi/API_GetSchemaVersion.html) - Ermöglicht das Abrufen bestimmter Schemaversionen aus der AWS Glue Schemaregistry
+ [kafka-cluster:Connect — Erteilt die Erlaubnis, eine Verbindung](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) zum Cluster herzustellen und sich dort zu authentifizieren
+ [kafka-cluster: AlterGroup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Erteilt die Erlaubnis, Gruppen in einem Cluster beizutreten, was der READ GROUP-ACL von Apache Kafka entspricht
+ [kafka-cluster: DescribeGroup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Erteilt die Erlaubnis, Gruppen in einem Cluster zu beschreiben, was der DESCRIBE GROUP-ACL von Apache Kafka entspricht
+ [kafka-cluster: DescribeTopic](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Erteilt die Erlaubnis, Themen in einem Cluster zu beschreiben, was der DESCRIBE TOPIC-ACL von Apache Kafka entspricht
+ [kafka-cluster: ReadData](https://docs.aws.amazon.com/service-authorization/latest/reference/list_apachekafkaapisforamazonmskclusters.html) - Erteilt die Berechtigung, Daten aus Themen in einem Cluster zu lesen, was der READ TOPIC-ACL von Apache Kafka entspricht
Wenn Sie außerdem Aufzeichnungen fehlgeschlagener Aufrufe an ein Ziel für Fehlerfälle senden möchten, benötigen Sie je nach Zieltyp die folgenden Berechtigungen:
+ Für Amazon SQS SQS-Ziele: [sqs: SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) — Ermöglicht das Senden von Nachrichten an eine Amazon SQS SQS-Warteschlange
+ Für Amazon-SNS-Ziele: [sns:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html) – erlaubt die Veröffentlichung von Nachrichten zu einem Amazon-SNS-Thema
+ Für Amazon S3 S3-Bucket-Ziele: [s3: PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) und [s3: ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListBucket.html) — Ermöglicht das Schreiben und Auflisten von Objekten in einem Amazon S3 S3-Bucket
Informationen zur Behebung von Authentifizierungs- und Autorisierungsfehlern finden Sie unter [Fehlerbehebung bei der Kafka-Zuordnung von Ereignisquellen](with-kafka-troubleshoot.md).
# Konfigurieren von Amazon MSK-Ereignisquellen für Lambda
Um einen selbstverwalteten Amazon-MSK-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 Amazon MSK erstellen.
Auf dieser Seite wird davon ausgegangen, dass Sie Ihren MSK-Cluster und die [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html), in der er sich befindet, bereits ordnungsgemäß konfiguriert haben. Wenn Sie Ihren Cluster oder Ihre VPC einrichten müssen, finden Sie entsprechende Informationen unter [Konfiguration Ihres Amazon-MSK-Clusters und Ihres Amazon-VPC-Netzwerks für Lambda](with-msk-cluster-network.md). Informationen zum Konfigurieren des Wiederholungsverhaltens für die Fehlerbehandlung finden Sie unter[Konfiguration der Fehlerbehandlungssteuerungen für Kafka-Ereignisquellen](kafka-retry-configurations.md).
**Topics**
+ [Verwenden eines Amazon MSK-Clusters als Ereignisquelle](#msk-esm-overview)
+ [Konfiguration von Amazon MSK-Cluster-Authentifizierungsmethoden in Lambda](msk-cluster-auth.md)
+ [Erstellen einer Lambda-Zuordnung von Ereignisquellen für eine Amazon-MSK-Ereignisquelle](msk-esm-create.md)
+ [Erstellen von kontenübergreifenden Zuordnungen von Ereignisquellen in Lambda](msk-cross-account.md)
+ [Alle Amazon-MSK-Konfigurationsparameter von Ereignisquellen in Lambda](msk-esm-parameters.md)
## Verwenden eines Amazon MSK-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 von Amazon MSK-Cluster-Authentifizierungsmethoden in Lambda
Lambda benötigt eine Berechtigung, um auf Ihren Amazon-MSK-Cluster zuzugreifen, Datensätze abzurufen und andere Aufgaben auszuführen. Amazon MSK unterstützt mehrere Methoden zur Authentifizierung bei Ihrem MSK-Cluster.
**Topics**
+ [Nicht authentifizierter Zugriff](#msk-unauthenticated)
+ [SASL/SCRAM-Authentifizierung](#msk-sasl-scram)
+ [Gegenseitige TLS-Authentifizierung](#msk-mtls)
+ [IAM-Authentifizierung](#msk-iam-auth)
+ [So wählt Lambda einen Bootstrap-Broker](#msk-bootstrap-brokers)
## Nicht authentifizierter Zugriff
Wenn keine Clients über das Internet auf den Cluster zugreifen, können Sie einen nicht authentifizierten Zugriff verwenden.
## SASL/SCRAM-Authentifizierung
Lambda unterstützt die [Authentifizierung Simple Authentication und Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM)](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html) mit der SHA-512-Hash-Funktion und der Transport Layer Security (TLS) -Verschlüsselung. Damit Lambda eine Verbindung zum Cluster herstellen kann, speichern Sie die Authentifizierungsanmeldeinformationen (Benutzername und Passwort) in einem Secrets-Manager-Geheimnis und verweisen Sie bei der Konfiguration Ihrer Zuordnung von Ereignisquellen auf dieses Geheimnis.
Weitere Informationen zur Verwendung von Secrets Manager finden Sie unter [Authentifizierung der Anmeldeinformationen mit Secrets Manager](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html) im *Entwicklerhandbuch für Amazon Managed Streaming for Kafka*.
**Anmerkung**
Amazon MSK unterstützt keine SASL/PLAIN Authentifizierung.
## Gegenseitige TLS-Authentifizierung
Gegenseitige TLS (mTLS) bietet eine bidirektionale Authentifizierung zwischen Client und Server. Der Client sendet ein Zertifikat an den Server, damit dieser den Client überprüfen kann. Der Server sendet ebenfalls ein Zertifikat an den Client, damit dieser den Server überprüfen kann.
Bei Amazon-MSK-Integrationen mit Lambda fungiert Ihr MSK-Cluster als Server und Lambda als Client.
+ Damit Lambda Ihren MSK-Cluster überprüfen kann, konfigurieren Sie ein Client-Zertifikat als Geheimnis in Secrets Manager und verweisen Sie in Ihrer Konfiguration der Zuordnung von Ereignisquellen auf dieses Zertifikat. Das Clientzertifikat muss von einer Zertifizierungsstelle (CA) im Trust Store des Servers signiert sein.
+ Der MSK-Cluster sendet auch ein Serverzertifikat an Lambda. Das Serverzertifikat muss von einer Zertifizierungsstelle (CA) im AWS Trust Store signiert werden.
Amazon MSK unterstützt keine selbstsignierten Serverzertifikate. Alle Broker in Amazon MSK verwenden [öffentliche Zertifikate](https://docs.aws.amazon.com/msk/latest/developerguide/msk-encryption.html), die von [Amazon Trust Services](https://www.amazontrust.com/repository/) signiert wurden CAs, denen Lambda standardmäßig vertraut.
### Konfigurieren des mTLS-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-----"
}
```
Weitere Informationen zu mTLS für Amazon MSK und Anweisungen zum Generieren eines Clientzertifikats finden Sie unter [Gegenseitige TLS-Authentifizierung für Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/msk-authentication.html) im *Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka*.
## IAM-Authentifizierung
Sie können AWS Identity and Access Management (IAM) verwenden, um die Identität von Clients zu authentifizieren, die eine Verbindung zum MSK-Cluster herstellen. Bei der IAM-Authentifizierung nutzt Lambda die Berechtigungen in der [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion, um eine Verbindung zum Cluster herzustellen, Datensätze abzurufen und andere erforderliche Aktionen auszuführen. Ein Beispiel für eine Richtlinie, welche die erforderlichen Berechtigungen enthält, finden Sie unter [Erstellen von Autorisierungsrichtlinien für die IAM-Rolle](https://docs.aws.amazon.com/msk/latest/developerguide/create-iam-access-control-policies.html) im *Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka*.
Wenn die IAM-Authentifizierung für Ihren MSK-Cluster aktiv ist und Sie kein Geheimnis angeben, verwendet Lambda automatisch standardmäßig die IAM-Authentifizierung.
Weitere Informationen zur IAM-Authentifizierung in Amazon MSK finden Sie unter [IAM-Zugriffskontrolle](https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html).
## So wählt Lambda einen Bootstrap-Broker
Lambda wählt einen [Bootstrap-Broker](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html) basierend auf den auf Ihrem Cluster verfügbaren Authentifizierungsmethoden aus und ob Sie ein Geheimnis für die Authentifizierung angeben.. Wenn Sie ein Geheimnis für MTLs oder SASL/SCRAM angeben, wählt Lambda automatisch diese Authentifizierungsmethode. Wenn Sie kein Geheimnis angeben, wählt Lambda die stärkste Authentifizierungsmethode aus, die in Ihrem Cluster aktiv ist. Im Folgenden ist die Reihenfolge der Priorität aufgeführt, in der Lambda einen Broker auswählt, von der stärksten zur schwächsten Authentifizierung:
+ mTLS (Geheimnis für mTLS bereitgestellt)
+ SASL/SCRAM (secret provided for SASL/SCRAM)
+ SASL IAM (kein Geheimnis angegeben und IAM-Authentifizierung aktiv)
+ Nicht authentifiziertes TLS (kein Geheimnis bereitgestellt und IAM-Authentifizierung nicht aktiv)
+ Klartext (kein Geheimnis angegeben und sowohl IAM-Authentifizierung als auch nicht authentifiziertes TLS sind nicht aktiv)
**Anmerkung**
Wenn Lambda keine Verbindung zum sichersten Brokertyp herstellen kann, versucht Lambda nicht, eine Verbindung zu einem anderen (schwächeren) Brokertyp herzustellen. Wenn Sie möchten, dass Lambda einen schwächeren Brokertyp wählt, deaktivieren Sie alle stärkeren Authentifizierungsmethoden in Ihrem Cluster.
# Erstellen einer Lambda-Zuordnung von Ereignisquellen für eine Amazon-MSK-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.
**Anmerkung**
Wenn Sie die Zuordnung von Ereignisquellen erstellen, erstellt Lambda eine [Hyperplane-ENI](configuration-vpc.md#configuration-vpc-enis) im privaten Subnetz, das Ihren MSK-Cluster enthält, sodass Lambda eine sichere Verbindung herstellen kann. Diese Hyperplane-ENI ermöglicht die Verwendung der Subnetz- und Sicherheitsgruppenkonfiguration Ihres MSK-Clusters, nicht Ihrer Lambda-Funktion.
Mit den folgenden Schritten in der Konsole fügen Sie einen Amazon-MSK-Cluster als Auslöser für Ihre Lambda-Funktion hinzu. Im Hintergrund wird dadurch eine Zuordnung von Ereignisquellen erstellt.
**So fügen Sie Ihrer Lambda-Funktion (Konsole) einen Amazon MSK-Trigger hinzu**
1. Öffnen Sie die Seite [Funktion](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie den Namen der Lambda-Funktion aus, der Sie einen Amazon-MSK-Auslöser hinzufügen möchten.
1. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add trigger (Trigger hinzufügen)**.
1. Wählen Sie unter **Auslöser-Konfiguration** die Option **MSK** aus.
1. Führen Sie die folgenden Schritte aus, um Ihre Kafka-Cluster-Details anzugeben:
1. Wählen Sie für **MSK-Cluster** Ihren Cluster aus.
1. Geben Sie für **Themenname** den Namen des Kafka-Themas ein, von dem Nachrichten verbraucht werden sollen.
1. Geben Sie für **Verbrauchergruppen-ID** ggf. die ID einer Kafka-Verbrauchergruppe ein, der Sie beitreten möchten. Weitere Informationen finden Sie unter [Anpassbare Verbrauchergruppen-ID in Lambda](kafka-consumer-group-id.md).
1. Nehmen Sie für die **Cluster-Authentifizierung** die erforderlichen Konfigurationen vor. Weitere Informationen über Cluster-Authentifizierung finden Sie unter [Konfiguration von Amazon MSK-Cluster-Authentifizierungsmethoden in Lambda](msk-cluster-auth.md).
+ Aktivieren Sie **Authentifizierung verwenden**, wenn Lambda beim Verbindungsaufbau die Authentifizierung bei Ihrem MSK-Cluster durchführen soll. Die Authentifizierung wird empfohlen.
+ Wenn Sie Authentifizierung verwenden, wählen Sie für **Authentifizierungsmethode** die zu verwendende Authentifizierungsmethode aus.
+ Wenn Sie Authentifizierung verwenden, wählen Sie für **Secrets-Manager-Schlüssel** den Secrets-Manager-Schlüssel aus, der die für den Zugriff auf Ihren Cluster erforderlichen Authentifizierungsanmeldeinformationen enthält.
1. Nehmen Sie unter **Konfiguration des Ereignis-Pollers** die erforderlichen Konfigurationen vor.
+ Wählen Sie **Auslöser aktivieren**, um den Auslöser unmittelbar nach der Erstellung zu aktivieren.
+ Wählen Sie aus, ob Sie den **Bereitstellungsmodus** für Ihre Zuordnung von Ereignisquellen konfigurieren möchten. Weitere Informationen finden Sie unter [Skalierungsmodi des Ereignis-Pollers von Apache Kafka in Lambda](kafka-scaling-modes.md).
+ Wenn Sie den Bereitstellungsmodus konfigurieren, geben Sie einen Wert für **Minimale Anzahl von Ereignisabfragen**, einen Wert für **Maximale Anzahl von Ereignisabfragen** und einen optionalen Wert ein, PollerGroupName um die Gruppierung mehrerer ESMs innerhalb derselben Ereignisquellen-VPC anzugeben.
+ Wählen Sie unter **Startposition** aus, wie Lambda mit dem Lesen aus Ihrem Stream beginnen soll. Weitere Informationen finden Sie unter [Apache-Kafka-Abfrage und Stream-Startpositionen in Lambda](kafka-starting-positions.md).
1. Nehmen Sie unter **Batching** die erforderlichen Konfigurationen vor. Weitere Informationen zu Batching finden Sie unter [Batching-Verhalten](invocation-eventsourcemapping.md#invocation-eventsourcemapping-batching).
1. Geben Sie für **Batchgröße** die maximale Anzahl von Nachrichten ein, die in einem einzelnen Batch empfangen werden sollen.
1. Geben Sie für **Batch-Fenster** die maximale Zeit in Sekunden ein, die Lambda mit dem Sammeln von Datensätzen verbringt, bevor die Funktion aufgerufen wird.
1. Nehmen Sie unter **Filterung** die erforderlichen Konfigurationen vor. Weitere Informationen zur Filterung erhalten Sie unter [Filtern von Ereignissen aus Amazon MSK und selbstverwalteten Apache-Kafka-Ereignisquellen](kafka-filtering.md).
+ Fügen Sie unter **Filterkriterien** Definitionen für Filterkriterien hinzu, um zu bestimmen, ob ein Ereignis verarbeitet werden soll oder nicht.
1. Nehmen Sie unter **Fehlerbehandlung** die erforderlichen Konfigurationen vor. Weitere Informationen zur Fehlerbehandlung finden Sie unter [Erfassen verworfener Batches für Amazon MSK und selbstverwaltete Apache-Kafka-Ereignisquellen](kafka-on-failure.md).
+ Geben Sie für **Fehlerziel** den ARN Ihres Fehlerziels an.
1. Geben Sie unter **Tags** die Tags ein, die dieser Zuordnung von Ereignisquellen zugeordnet werden sollen.
1. Wählen Sie **hinzufügen** aus, um den Auslöser zu erstellen.
Sie können die Ereignisquellenzuordnung auch mithilfe der AWS CLI mit dem [ create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)Befehl erstellen. Im folgenden Beispiel wird eine Zuordnung von Ereignisquellen erstellt, um die Lambda-Funktion `my-msk-function` ab der `LATEST`-Nachricht dem `AWSKafkaTopic`-Thema zuzuordnen. Dieser Befehl verwendet das [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)Objekt auch, um Lambda anzuweisen, bei der Verbindung mit dem Cluster die [SASL/SCRAM-Authentifizierung](msk-cluster-auth.md#msk-sasl-scram) zu verwenden.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
--source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'
```
Wenn der Cluster [mTLS-Authentifizierung verwendet](msk-cluster-auth.md#msk-mtls), fügen Sie ein [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)Objekt hinzu, das einen Secrets Manager Manager-Schlüssel-ARN spezifiziert`CLIENT_CERTIFICATE_TLS_AUTH`. Das wird im folgenden Befehl veranschaulicht:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
--source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'
```
Wenn der Cluster die [IAM-Authentifizierung](msk-cluster-auth.md#msk-iam-auth) verwendet, benötigen Sie kein [ SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)Objekt. Das wird im folgenden Befehl veranschaulicht:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
```
# Erstellen von kontenübergreifenden Zuordnungen von Ereignisquellen in Lambda
Sie können [private Multi-VPC-Konnektivität](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html) verwenden, um eine Lambda-Funktion mit einem bereitgestellten MSK-Cluster in einem anderen AWS-Konto zu verbinden. Multi-VPC-Konnektivität verwendet AWS PrivateLink, wodurch der gesamte Datenverkehr im AWS Netzwerk bleibt.
**Anmerkung**
Sie können keine kontenübergreifenden Zuordnungen von Ereignisquellen für Serverless-MSK-Cluster erstellen.
Um eine kontenübergreifende Zuordnung von Ereignisquellen zu erstellen, müssen Sie zunächst die [Multi-VPC-Konnektivität für den MSK-Cluster konfigurieren](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-cluster-owner-action-turn-on). Verwenden Sie beim Erstellen der Zuordnung von Ereignisquellen den ARN der verwalteten VPC-Verbindung anstelle des Cluster-ARNs, wie in den folgenden Beispielen gezeigt. Der [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)Vorgang unterscheidet sich auch je nachdem, welchen Authentifizierungstyp der MSK-Cluster verwendet.
**Example – Erstellen Sie eine kontoübergreifende Zuordnung von Ereignisquellen für einen Cluster, der die IAM-Authentifizierung verwendet**
Wenn der Cluster die [rollenbasierte IAM-Authentifizierung verwendet, benötigen](msk-cluster-auth.md#msk-iam-auth) Sie kein Objekt. [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html) Beispiel:
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function
```
**Example — Erstellen Sie eine kontenübergreifende Zuordnung von Ereignisquellen für einen Cluster, der Authentifizierung verwendet SASL/SCRAM**
Wenn der Cluster die [SASL/SCRAM-Authentifizierung](msk-cluster-auth.md#msk-sasl-scram) verwendet, müssen Sie ein [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)Objekt angeben, das einen geheimen Secrets Manager Manager-ARN spezifiziert, `SASL_SCRAM_512_AUTH` und einen geheimen ARN hinzufügen.
Es gibt zwei Möglichkeiten, Geheimnisse für kontoübergreifende Amazon MSK-Ereignisquellenzuordnungen mit Authentifizierung zu verwenden: SASL/SCRAM
+ Erstellen Sie ein Secret im Lambda-Funktionskonto und synchronisieren Sie es mit dem Cluster-Secret. [Erstellen Sie eine Rotation](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html), um die beiden Secrets synchron zu halten. Mit dieser Option können Sie das Secret vom Funktionskonto aus kontrollieren.
+ Verwenden Sie das Secret, das dem MSK-Cluster zugeordnet ist. Dieses Secret muss kontoübergreifenden Zugriff auf das Lambda-Funktionskonto ermöglichen. Weitere Informationen finden Sie unter [Berechtigungen für AWS Secrets Manager -Secrets für Benutzer in einem anderen Konto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html).
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function \
--source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'
```
**Example – Erstellen Sie eine kontoübergreifende Zuordnung von Ereignisquellen für einen Cluster, der die mTLS-Authentifizierung verwendet**
Wenn der Cluster [mTLS-Authentifizierung](msk-cluster-auth.md#msk-mtls) verwendet, müssen Sie ein [SourceAccessConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_SourceAccessConfiguration.html)Objekt angeben, das einen geheimen ARN von Secrets Manager spezifiziert`CLIENT_CERTIFICATE_TLS_AUTH`. Das Secret kann im Clusterkonto oder im Lambda-Funktionskonto gespeichert werden.
```
aws lambda create-event-source-mapping \
--event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
--topics AWSKafkaTopic \
--starting-position LATEST \
--function-name my-kafka-function \
--source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'
```
# Alle Amazon-MSK-Konfigurationsparameter von 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 Amazon MSK, wie in der folgenden Tabelle dargestellt.
| Parameter | Erforderlich | Standard | Hinweise |
| --- | --- | --- | --- |
| AmazonManagedKafkaEventSourceConfig | N | Enthält das ConsumerGroupId Feld, das standardmäßig einen eindeutigen Wert hat. | Kann nur auf „Erstellen“ festgelegt werden |
| 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 | |
| BisectBatchOnFunctionError | N | Falsch | [Konfiguration der Fehlerbehandlungssteuerungen für Kafka-Ereignisquellen](kafka-retry-configurations.md) |
| FunctionResponseTypes | N | – | [Konfiguration der Fehlerbehandlungssteuerungen für Kafka-Ereignisquellen](kafka-retry-configurations.md) |
| MaximumRecordAgeInSeconds | N | -1 (unendlich) | [Konfiguration der Fehlerbehandlungssteuerungen für Kafka-Ereignisquellen](kafka-retry-configurations.md) |
| MaximumRetryAttempts | N | -1 (unendlich) | [Konfiguration der Fehlerbehandlungssteuerungen für Kafka-Ereignisquellen](kafka-retry-configurations.md) |
| EventSourceArn | Y | – | Kann nur auf „Erstellen“ festgelegt werden |
| 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) |
| SourceAccessConfigurations | N | Keine Anmeldedaten | Anmeldeinformationen zur SASL/SCRAM- oder CLIENT\$1CERTIFICATE\$1TLS\$1AUTH (MutualTLS)-Authentifizierung für Ihre Ereignisquelle |
| StartingPosition | Y | – | AT\$1TIMESTAMP, TRIM\$1HORIZON, oder LATEST Kann nur auf „Erstellen“ festgelegt werden |
| StartingPositionTimestamp | N | – | Erforderlich, wenn es auf StartingPosition AT\$1TIMESTAMP gesetzt ist |
| Tags (Markierungen) | N | – | [Verwendung von Tags für Zuordnungen von Ereignisquellen](tags-esm.md) |
| Topics | Y | – | Kafka-Thema-Name 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.
# Tutorial: Verwenden einer Amazon-MSK-Zuordnung von Ereignisquellen zum Aufrufen einer Lambda-Funktion
In diesem Tutorial führen Sie Folgendes durch:
+ Erstellen Sie eine Lambda-Funktion in demselben AWS Konto wie ein vorhandener Amazon MSK-Cluster.
+ Konfigurieren Sie Netzwerk und Authentifizierung für Lambda für die Kommunikation mit Amazon MSK.
+ Richten Sie eine Lambda Amazon MSK-Zuordnung von Ereignisquellen ein, die Ihre Lambda-Funktion ausführt, wenn Ereignisse im Thema auftauchen.
Nachdem Sie diese Schritte durchgeführt haben, können Sie, wenn Ereignisse an Amazon MSK gesendet werden, eine Lambda-Funktion einrichten, um diese Ereignisse automatisch mit Ihrem eigenen benutzerdefinierten Lambda-Code zu verarbeiten.
**Was können Sie mit diesem Feature machen?**
**Beispiellösung: Verwenden Sie eine MSK-Zuordnung von Ereignisquellen, um Ihren Kunden Live-Ergebnisse zu liefern.**
Stellen Sie sich das folgende Szenario vor: Ihr Unternehmen hostet eine Webanwendung, mit der Ihre Kunden Informationen über Live-Ereignisse, z. B. Sportspiele, abrufen können. Aktuelle Informationen aus dem Spiel werden Ihrem Team über ein Kafka-Thema auf Amazon MSK zur Verfügung gestellt. Sie möchten eine Lösung entwerfen, die Aktualisierungen aus dem MSK-Thema abruft, um den Kunden in einer von Ihnen entwickelten Anwendung eine aktualisierte Ansicht des Live-Ereignisses zu bieten. Sie haben sich für den folgenden Designansatz entschieden: Ihre Client-Anwendungen werden mit einem Serverless-Backend kommunizieren, das in AWS gehostet wird. Clients stellen mithilfe der Amazon WebSocket API Gateway eine Verbindung über Websocket-Sitzungen her.
Bei dieser Lösung benötigen Sie eine Komponente, die MSK-Ereignisse liest, eine benutzerdefinierte Logik ausführt, um diese Ereignisse für die Anwendungsschicht vorzubereiten und diese Informationen dann an die API-Gateway-API weiterleitet. Sie können diese Komponente implementieren AWS Lambda, indem Sie Ihre benutzerdefinierte Logik in einer Lambda-Funktion bereitstellen und sie dann mit einer AWS Lambda Amazon MSK-Ereignisquellenzuordnung aufrufen.
Weitere Informationen zur Implementierung von Lösungen mit der Amazon API Gateway WebSocket API finden Sie WebSocket in den [API-Tutorials](https://docs.aws.amazon.com/apigateway/latest/developerguide/websocket-api-chat-app.html) in der API Gateway-Dokumentation.
## Voraussetzungen
Ein AWS Konto mit den folgenden vorkonfigurierten Ressourcen:
**Um diese Voraussetzungen zu erfüllen, empfehlen wir den Abschnitt [Erste Schritte mit Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/getting-started.html) in der Amazon MSK-Dokumentation.**
+ Ein Amazon-MSK-Cluster. Siehe [Erstellen eines Amazon MSK-Clusters](https://docs.aws.amazon.com//msk/latest/developerguide/create-cluster.html) in *Erste Schritte mit Amazon MSK*.
+ Die folgende Konfiguration:
+ Vergewissern Sie sich, dass die **rollenbasierte IAM-Authentifizierung** in den Sicherheitseinstellungen Ihres Clusters **aktiviert** ist. Dies verbessert Ihre Sicherheit, da Ihre Lambda-Funktion nur auf die benötigten Amazon MSK-Ressourcen zugreifen kann. Dies ist bei neuen Amazon MSK-Clustern standardmäßig aktiviert.
+ Vergewissern Sie sich, dass der **öffentliche Zugang** in den Netzwerkeinstellungen Ihres Clusters deaktiviert ist. Wenn Sie den Zugang Ihres Amazon MSK Clusters zum Internet einschränken, erhöht sich Ihre Sicherheit, da die Anzahl der Vermittler, die Ihre Daten verarbeiten, begrenzt wird. Dies ist bei neuen Amazon MSK-Clustern standardmäßig aktiviert.
+ Ein Kafka-Thema in Ihrem Amazon MSK-Cluster, das Sie für diese Lösung verwenden können. Weitere Informationen finden Sie unter [Erstellen eines Themas](https://docs.aws.amazon.com//msk/latest/developerguide/create-topic.html) unter *Erste Schritte mit Amazon MSK*.
+ Ein Kafka-Admin-Host, der so eingerichtet ist, dass er Informationen von Ihrem Kafka-Cluster abruft und Kafka-Ereignisse zu Testzwecken an Ihr Thema sendet, z. B. eine Amazon EC2-Instance mit der Kafka-Admin-CLI und der installierten Amazon-MSK-IAM-Bibliothek. Siehe [Erstellen eines Client-Rechners](https://docs.aws.amazon.com//msk/latest/developerguide/create-client-machine.html) in *Erste Schritte mit Amazon MSK*.
Nachdem Sie diese Ressourcen eingerichtet haben, erfassen Sie die folgenden Informationen aus Ihrem AWS Konto, um zu bestätigen, dass Sie bereit sind, fortzufahren.
+ Der Name Ihres Amazon MSK-Clusters. Sie finden diese Informationen in der Amazon-MSK-Konsole.
+ Die Cluster-UUID, Teil des ARN für Ihren Amazon MSK-Cluster, den Sie in der Amazon MSK-Konsole finden können. Folgen Sie den Verfahren unter [Cluster auflisten](https://docs.aws.amazon.com/msk/latest/developerguide/msk-list-clusters.html) in der Amazon MSK-Dokumentation, um diese Informationen zu finden.
+ Die mit Ihrem Amazon MSK-Cluster verbundenen Sicherheitsgruppen. Sie finden diese Informationen in der Amazon-MSK-Konsole. Bezeichnen Sie diese in den folgenden Schritten als Ihre*clusterSecurityGroups*.
+ Die ID der Amazon VPC, die Ihren Amazon MSK-Cluster enthält. Sie können diese Informationen finden, indem Sie in der Amazon MSK-Konsole die mit Ihrem Amazon MSK-Cluster verbundenen Subnetze identifizieren und dann in der Amazon VPC-Konsole die mit dem Subnetz verbundene Amazon VPC identifizieren.
+ Der Name des in Ihrer Lösung verwendeten Kafka-Themas. Sie können diese Informationen finden, indem Sie Ihren Amazon MSK-Cluster mit der Kafka `topics` CLI von Ihrem Kafka-Administrationshost aus aufrufen. Weitere Informationen zur Themen-CLI finden Sie in der Kafka-Dokumentation unter [Themen hinzufügen und entfernen](https://kafka.apache.org/documentation/#basic_ops_add_topic).
+ Der Name einer Verbrauchergruppe für Ihr Kafka-Thema, geeignet für die Verwendung durch Ihre Lambda-Funktion. Diese Gruppe kann automatisch von Lambda erstellt werden, Sie müssen sie also nicht mit der Kafka-CLI erstellen. Wenn Sie Ihre Verbrauchergruppen verwalten müssen, finden Sie weitere Informationen über die Verbrauchergruppen-CLI unter [Verwalten von Verbrauchergruppen](https://kafka.apache.org/documentation/#basic_ops_consumer_group) in der Kafka-Dokumentation.
Die folgenden Berechtigungen in Ihrem AWS Konto:
+ Berechtigung zur Erstellung und Verwaltung einer Lambda-Funktion.
+ Erlaubnis, IAM-Richtlinien zu erstellen und sie mit Ihrer Lambda-Funktion zu verknüpfen.
+ Berechtigung zum Erstellen von Amazon VPC-Endpunkten und zum Ändern der Netzwerkkonfiguration in der Amazon VPC, die Ihren Amazon MSK-Cluster hostet.
### Installiere das AWS Command Line Interface
Wenn Sie das noch nicht installiert haben AWS Command Line Interface, folgen Sie den Schritten unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), um es zu installieren.
Das Tutorial erfordert zum Ausführen von Befehlen ein Befehlszeilenterminal oder eine Shell. Verwenden Sie unter Linux und macOS Ihre bevorzugte Shell und Ihren bevorzugten Paketmanager.
**Anmerkung**
In Windows werden einige Bash-CLI-Befehle, die Sie häufig mit Lambda verwenden (z. B. `zip`), von den integrierten Terminals des Betriebssystems nicht unterstützt. Um eine in Windows integrierte Version von Ubuntu und Bash zu erhalten, [installieren Sie das Windows-Subsystem für Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10).
## Konfigurieren Sie die Netzwerkkonnektivität für Lambda zur Kommunikation mit Amazon MSK
Wird verwendet AWS PrivateLink , um Lambda und Amazon MSK zu verbinden. Sie können dies tun, indem Sie Amazon VPC-Endpunkte in der Amazon VPC-Konsole erstellen. Weitere Informationen zur Netzwerkkonfiguration finden Sie unter [Konfiguration Ihres Amazon-MSK-Clusters und Ihres Amazon-VPC-Netzwerks für Lambda](with-msk-cluster-network.md).
Wenn eine Amazon MSK-Zuordnung von Ereignisquellen im Namen einer Lambda-Funktion ausgeführt wird, übernimmt es die Ausführungsrolle der Lambda-Funktion. Diese IAM-Rolle autorisiert die Zuordnung für den Zugriff auf durch IAM gesicherte Ressourcen, wie z. B. Ihren Amazon MSK-Cluster. Obwohl die Komponenten eine gemeinsame Ausführungsrolle haben, haben das Amazon MSK-Mapping und Ihre Lambda-Funktion separate Konnektivitätsanforderungen für ihre jeweiligen Aufgaben, wie im folgenden Diagramm dargestellt.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/msk_tut_network.png)
Ihre Zuordnung von Ereignisquellen gehört zu Ihrer Amazon MSK-Cluster-Sicherheitsgruppe. In diesem Vernetzungsschritt erstellen Sie Amazon VPC-Endpunkte von Ihrer Amazon MSK-Cluster-VPC, um die Zuordnung von Ereignisquellen mit den Lambda- und STS-Services zu verbinden. Sichern Sie diese Endpunkte, damit sie Datenverkehr von Ihrer Amazon MSK-Cluster-Sicherheitsgruppe akzeptieren. Passen Sie dann die Sicherheitsgruppen des Amazon MSK-Clusters an, damit die Zuordnung von Ereignisquellen mit dem Amazon MSK-Cluster kommunizieren kann.
Sie können die folgenden Schritte mit dem AWS-Managementkonsole.
**So konfigurieren Sie Schnittstellen-Amazon-VPC-Endpunkte, um Lambda und Amazon MSK zu verbinden**
1. Erstellen Sie eine Sicherheitsgruppe für Ihre Schnittstelle Amazon VPC-Endpunkte,*endpointSecurityGroup*, die eingehenden TCP-Verkehr auf 443 von ermöglicht. *clusterSecurityGroups* Befolgen Sie das Verfahren unter [Erstellen einer Sicherheitsgruppe](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group) in der Amazon EC2-Dokumentation, um eine Sicherheitsgruppe zu erstellen. Folgen Sie dann dem Verfahren unter [Hinzufügen von Regeln zu einer Sicherheitsgruppe](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) in der Amazon EC2-Dokumentation, um entsprechende Regeln hinzuzufügen.
**Erstellen Sie eine Sicherheitsgruppe mit den folgenden Informationen:**
Wenn Sie Ihre Regeln für eingehenden Datenverkehr hinzufügen, erstellen Sie eine Regel für jede Sicherheitsgruppe in. *clusterSecurityGroups* Für jede Regel:
+ Wählen Sie für **Type (Typ)** **HTTPS** aus.
+ Wählen Sie für **Quelle** eine von. *clusterSecurityGroups*
1. Erstellen Sie einen Endpunkt, der den Lambda-Service mit der Amazon VPC verbindet, die Ihren Amazon MSK-Cluster enthält. Folgen Sie dem Verfahren unter [Schnittstellenendpunkt erstellen](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html).
**Erstellen Sie einen Schnittstellenendpunkt mit den folgenden Informationen:**
+ Wählen Sie als **Dienstname** aus`com.amazonaws.regionName.lambda`, wo Ihre Lambda-Funktion *regionName* gehostet wird.
+ Wählen Sie für **VPC** die Amazon VPC aus, die Ihren Amazon MSK-Cluster enthält.
+ Wählen Sie für **Sicherheitsgruppen** die Gruppen aus*endpointSecurityGroup*, die Sie zuvor erstellt haben.
+ Wählen Sie für **Subnetze** die Subnetze aus, die Ihren Amazon MSK-Cluster hosten.
+ Geben Sie für die **Richtlinie** das folgende Richtliniendokument an, das den Endpunkt für die Verwendung durch den Lambda-Serviceprinzipal für die `lambda:InvokeFunction`-Aktion sichert.
```
{
"Statement": [
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
+ Stellen Sie sicher, dass **DNS-Name aktivieren** weiterhin aktiviert ist.
1. Erstellen Sie einen Endpunkt, der den AWS STS Service mit der Amazon VPC verbindet, die Ihren Amazon MSK-Cluster enthält. Folgen Sie dem Verfahren unter [Schnittstellenendpunkt erstellen](https://docs.aws.amazon.com//vpc/latest/privatelink/create-interface-endpoint.html).
**Erstellen Sie einen Schnittstellenendpunkt mit den folgenden Informationen:**
+ Wählen Sie als **Dienstname** die Option aus. AWS STS
+ Wählen Sie für **VPC** die Amazon VPC aus, die Ihren Amazon MSK-Cluster enthält.
+ Wählen Sie für **Sicherheitsgruppen** die Option aus*endpointSecurityGroup*.
+ Wählen Sie für **Subnetze** die Subnetze aus, die Ihren Amazon MSK-Cluster hosten.
+ Geben Sie für die **Richtlinie** das folgende Richtliniendokument an, das den Endpunkt für die Verwendung durch den Lambda-Serviceprinzipal für die `sts:AssumeRole`-Aktion sichert.
```
{
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": [
"lambda.amazonaws.com"
]
},
"Resource": "*"
}
]
}
```
+ Stellen Sie sicher, dass **DNS-Name aktivieren** weiterhin aktiviert ist.
1. Lassen Sie für jede Sicherheitsgruppe, die Ihrem Amazon MSK-Cluster zugeordnet ist, d. h. in*clusterSecurityGroups*, Folgendes zu:
+ Erlauben Sie allen eingehenden und ausgehenden TCP-Verkehr auf 9098 für alle*clusterSecurityGroups*, auch für sich selbst.
+ Den gesamten ausgehenden TCP-Verkehr auf 443 zulassen.
Ein Teil dieses Datenverkehrs wird durch die Standardregeln der Sicherheitsgruppe zugelassen. Wenn Ihr Cluster also nur einer einzigen Sicherheitsgruppe angehört und diese Gruppe über Standardregeln verfügt, sind zusätzliche Regeln nicht erforderlich. Um die Regeln für Sicherheitsgruppen anzupassen, befolgen Sie die Verfahren unter [Hinzufügen von Regeln zu einer Sicherheitsgruppe](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) in der Amazon EC2-Dokumentation.
**Fügen Sie Ihren Sicherheitsgruppen Regeln mit den folgenden Informationen hinzu:**
+ Geben Sie für jede eingehende oder ausgehende Regel für Port 9098 Folgendes an
+ Wählen Sie für **Type** (Typ) **Custom TCP** (Benutzerdefiniertes TCP).
+ Geben Sie als **Portbereich** 9098 an.
+ Geben Sie als **Quelle** einen von an. *clusterSecurityGroups*
+ Wählen Sie für jede eingehende Regel für Port 443 als **Typ** die Option **HTTPS** aus.
## Erstellen Sie eine IAM-Rolle, die Lambda aus Ihrem Amazon-MSK-Thema lesen kann
Identifizieren Sie die Authentifizierungsanforderungen für Lambda, um aus Ihrem Amazon MSK-Thema zu lesen und definieren Sie sie dann in einer Richtlinie. Erstellen Sie eine Rolle*lambdaAuthRole*, die Lambda autorisiert, diese Berechtigungen zu verwenden. Autorisieren Sie Aktionen in Ihrem Amazon MSK-Cluster mithilfe von `kafka-cluster` IAM-Aktionen. Autorisieren Sie Lambda anschließend, Amazon MSK `kafka` - und Amazon EC2 EC2-Aktionen durchzuführen, die für die Erkennung Ihres Amazon MSK-Clusters und die Verbindung zu ihm erforderlich sind, sowie CloudWatch Aktionen, damit Lambda protokollieren kann, was es getan hat.
**So beschreiben Sie die Authentifizierungsanforderungen für Lambda, um von Amazon MSK zu lesen**
1. Schreiben Sie ein IAM-Richtliniendokument (ein JSON-Dokument), das es Lambda ermöglicht*clusterAuthPolicy*, mithilfe Ihrer Kafka-Verbrauchergruppe aus Ihrem Kafka-Thema in Ihrem Amazon MSK-Cluster zu lesen. Für Lambda muss beim Lesen eine Kafka-Verbrauchergruppe festgelegt werden.
Ändern Sie die folgende Vorlage, um sie an Ihre Voraussetzungen anzupassen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeGroup",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeTopic",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeClusterDynamicConfiguration"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/mskClusterName/cluster-uuid",
"arn:aws:kafka:us-east-1:111122223333:topic/mskClusterName/cluster-uuid/mskTopicName",
"arn:aws:kafka:us-east-1:111122223333:group/mskClusterName/cluster-uuid/mskGroupName"
]
}
]
}
```
------
Weitere Informationen erhalten Sie von [Konfiguration von Lambda-Berechtigungen für Amazon MSK-Ereignisquellenzuordnungen](with-msk-permissions.md). Wenn Sie Ihre Richtlinie schreiben:
+ Ersetzen Sie *us-east-1* und *111122223333* durch das AWS-Region und AWS-Konto Ihres Amazon MSK-Clusters.
+ Geben Sie für *mskClusterName* den Namen Ihres Amazon MSK-Clusters an.
+ Geben Sie für *cluster-uuid* die UUID im ARN für Ihren Amazon MSK-Cluster an.
+ Geben Sie für *mskTopicName* den Namen Ihres Kafka-Themas an.
+ Geben Sie für *mskGroupName* den Namen Ihrer Kafka-Verbrauchergruppe an.
1. Identifizieren Sie Amazon MSK, Amazon EC2 und die CloudWatch Berechtigungen, die Lambda benötigt, um Ihren Amazon MSK-Cluster zu erkennen und zu verbinden, und protokollieren Sie diese Ereignisse.
Die `AWSLambdaMSKExecutionRole`-verwaltete Richtlinie definiert die erforderlichen Berechtigungen auf unzulässige Weise. Verwenden Sie es in den folgenden Schritten.
Beurteilen Sie in einer Produktionsumgebung `AWSLambdaMSKExecutionRole`, um Ihre Ausführungsrollenrichtlinie auf der Grundlage des Prinzips der geringsten Berechtigung einzuschränken und schreiben Sie dann eine Richtlinie für Ihre Rolle, die diese verwaltete Richtlinie ersetzt.
Weitere Informationen zur IAM-Richtliniensprache finden Sie unter [IAM-Dokumentation](https://docs.aws.amazon.com//iam/).
Nachdem Sie nun Ihr Richtliniendokument verfasst haben, erstellen Sie eine IAM-Richtlinie, die Sie mit Ihrer Rolle verknüpfen können. Sie können dies über die Konsole mit dem folgenden Verfahren tun.
**So erstellen Sie eine IAM-Richtlinie aus Ihrem Richtliniendokument**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich auf der linken Seite **Policies (Richtlinien)**.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Wählen Sie im Bereich **Policy editor** (Richtlinien-Editor) die Option **JSON** aus.
1. Einfügen*clusterAuthPolicy*.
1. Wenn Sie mit dem Hinzufügen von Berechtigungen zur Richtlinie fertig sind, wählen Sie **Next** (Weiter) aus.
1. Geben Sie auf der Seite **Review and create** (Überprüfen und erstellen) unter **Name** einen Namen und unter **Description** (Beschreibung) (optional) eine Beschreibung für die Richtlinie ein, die Sie erstellen. Überprüfen Sie **Permissions defined in this policy** (In dieser Richtlinie definierte Berechtigungen), um die Berechtigungen einzusehen, die von Ihrer Richtlinie gewährt werden.
1. Wählen Sie **Create policy** (Richtlinie erstellen) aus, um Ihre neue Richtlinie zu speichern.
Weitere Informationen finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) in der IAM-Dokumentation.
Nachdem Sie nun über die entsprechenden IAM-Richtlinien verfügen, erstellen Sie eine Rolle und ordnen Sie sie dieser zu. Sie können dies über die Konsole mit dem folgenden Verfahren tun.
**So erstellen Sie eine Ausführungsrolle in der IAM-Konsole**
1. Öffnen Sie die Seite [Roles (Rollen)](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole.
1. Wählen Sie **Rolle erstellen** aus.
1. Wählen Sie unter **Typ der vertrauenswürdigen Entität** die Option **AWS -Service** aus.
1. Wählen Sie unter **Anwendungsfall** **Lambda** aus.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie die folgenden Richtlinien:
+ *clusterAuthPolicy*
+ `AWSLambdaMSKExecutionRole`
1. Wählen Sie **Weiter** aus.
1. Geben Sie **als Rollenname den Text Rolle** **erstellen ein *lambdaAuthRole* und wählen Sie dann Create role** aus.
Weitere Informationen finden Sie unter [Definieren von Lambda-Funktionsberechtigungen mit einer Ausführungsrolle](lambda-intro-execution-role.md).
## Erstellen Sie eine Lambda-Funktion zum Lesen aus Ihrem Amazon MSK-Thema
Erstellen Sie eine Lambda-Funktion, die für die Verwendung Ihrer IAM-Rolle konfiguriert ist. Sie können Ihre Lambda-Funktion über die Konsole erstellen.
**So erstellen Sie eine Lambda-Funktion mit Ihrer Authentifizierungskonfiguration**
1. Öffnen Sie die Lambda-Konsole und wählen Sie im Header die Option **Funktion erstellen** aus.
1. Wählen Sie **Verfassen von Grund auf** aus.
1. Geben Sie als **Funktionsnamen** einen geeigneten Namen Ihrer Wahl an.
1. Wählen Sie für **Laufzeit** die **neueste unterstützte** Version von `Node.js`, um den in diesem Tutorial bereitgestellten Code zu verwenden.
1. Wählen Sie **Standardeausführungsrolle ändern** aus.
1. Wählen Sie **Eine vorhandene Rolle verwenden** aus.
1. Wählen Sie für **Existierende Rolle** die Option aus*lambdaAuthRole*.
In einer Produktionsumgebung müssen Sie der Ausführungsrolle für Ihre Lambda-Funktion normalerweise weitere Richtlinien hinzufügen, um Ihre Amazon MSK-Ereignisse sinnvoll verarbeiten zu können. Weitere Informationen zum Hinzufügen von Richtlinien zu Ihrer Rolle finden Sie unter [Hinzufügen oder Entfernen von Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) in der IAM-Dokumentation.
## Erstellen einer Zuordnung der Ereignisquelle zu Ihrer Lambda-Funktion
Ihre Amazon MSK-Zuordnung von Ereignisquellen liefert dem Lambda-Service die notwendigen Informationen, um Ihr Lambda aufzurufen, wenn entsprechende Amazon MSK-Ereignisse auftreten. Sie können über die Konsole eine Amazon MSK-Zuordnung erstellen. Erstellen Sie einen Lambda-Trigger, dann wird die Zuordnung von Ereignisquellen automatisch eingerichtet.
**So erstellen Sie einen Lambda-Trigger (und eine Zuordnung von Ereignisquellen)**
1. Navigieren Sie zur Übersichtsseite Ihrer Lambda-Funktion.
1. Wählen Sie im Abschnitt Funktionsübersicht unten links **Auslöser hinzufügen**.
1. Wählen Sie in der Dropdownliste **Quelle auswählen** die Option **Amazon MSK** aus.
1. Legen Sie keine **Authentifizierung** fest.
1. Wählen Sie für **MSK-Cluster** den Namen Ihres Clusters aus.
1. Geben Sie für **Batch size (Stapelgröße)** 1 ein. Dieser Schritt erleichtert das Testen dieses Features, ist aber für die Produktion nicht ideal.
1. Geben Sie für **Themenname** den Namen Ihres Kafka-Themas ein.
1. Geben Sie unter **Verbrauchergruppen-ID** die ID Ihrer Kafka-Verbrauchergruppe an.
## Aktualisieren Sie Ihre Lambda-Funktion, um Ihre Streaming-Daten zu lesen
Lambda liefert Informationen über Kafka-Ereignisse über den Parameter der Ereignismethode. Ein Beispiel für die Struktur eines Amazon MSK-Ereignisses finden Sie unter [Beispielereignis](with-msk.md#msk-sample-event). Nachdem Sie verstanden haben, wie die von Lambda weitergeleiteten Amazon MSK-Ereignisse zu interpretieren sind, können Sie Ihren Lambda-Funktionscode so ändern, dass er die von ihnen bereitgestellten Informationen nutzt.
Fügen Sie den folgenden Code in Ihre Lambda-Funktion ein, um den Inhalt eines Lambda Amazon MSK-Ereignisses zu Testzwecken zu protokollieren:
------
#### [ .NET ]
**SDK für .NET**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon MSK-Ereignisses mit Lambda unter Verwendung von .NET.
```
using System.Text;
using Amazon.Lambda.Core;
using Amazon.Lambda.KafkaEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace MSKLambda;
public class Function
{
/// The event for the Lambda function handler to process.
/// The ILambdaContext that provides methods for logging and describing the Lambda environment.
///
public void FunctionHandler(KafkaEvent evnt, ILambdaContext context)
{
foreach (var record in evnt.Records)
{
Console.WriteLine("Key:" + record.Key);
foreach (var eventRecord in record.Value)
{
var valueBytes = eventRecord.Value.ToArray();
var valueText = Encoding.UTF8.GetString(valueBytes);
Console.WriteLine("Message:" + valueText);
}
}
}
}
```
------
#### [ Go ]
**SDK für Go V2**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon MSK-Ereignisses mit Lambda unter Verwendung von Go.
```
package main
import (
"encoding/base64"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.KafkaEvent) {
for key, records := range event.Records {
fmt.Println("Key:", key)
for _, record := range records {
fmt.Println("Record:", record)
decodedValue, _ := base64.StdEncoding.DecodeString(record.Value)
message := string(decodedValue)
fmt.Println("Message:", message)
}
}
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK für Java 2.x**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon MSK-Ereignisses mit Lambda unter Verwendung von Java.
```
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.KafkaEvent;
import com.amazonaws.services.lambda.runtime.events.KafkaEvent.KafkaEventRecord;
import java.util.Base64;
import java.util.Map;
public class Example implements RequestHandler {
@Override
public Void handleRequest(KafkaEvent event, Context context) {
for (Map.Entry> entry : event.getRecords().entrySet()) {
String key = entry.getKey();
System.out.println("Key: " + key);
for (KafkaEventRecord record : entry.getValue()) {
System.out.println("Record: " + record);
byte[] value = Base64.getDecoder().decode(record.getValue());
String message = new String(value);
System.out.println("Message: " + message);
}
}
return null;
}
}
```
------
#### [ JavaScript ]
**SDK für JavaScript (v3)**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Ein Amazon MSK-Ereignis mit Lambda verwenden. JavaScript
```
exports.handler = async (event) => {
// Iterate through keys
for (let key in event.records) {
console.log('Key: ', key)
// Iterate through records
event.records[key].map((record) => {
console.log('Record: ', record)
// Decode base64
const msg = Buffer.from(record.value, 'base64').toString()
console.log('Message:', msg)
})
}
}
```
Ein Amazon MSK-Ereignis mit Lambda verwenden. TypeScript
```
import { MSKEvent, Context } from "aws-lambda";
import { Buffer } from "buffer";
import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger({
logLevel: "INFO",
serviceName: "msk-handler-sample",
});
export const handler = async (
event: MSKEvent,
context: Context
): Promise => {
for (const [topic, topicRecords] of Object.entries(event.records)) {
logger.info(`Processing key: ${topic}`);
// Process each record in the partition
for (const record of topicRecords) {
try {
// Decode the message value from base64
const decodedMessage = Buffer.from(record.value, 'base64').toString();
logger.info({
message: decodedMessage
});
}
catch (error) {
logger.error('Error processing event', { error });
throw error;
}
};
}
}
```
------
#### [ PHP ]
**SDK für PHP**
Es gibt noch mehr dazu. GitHub Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon MSK-Ereignisses mit Lambda unter Verwendung von PHP.
```
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handle(mixed $event, Context $context): void
{
$kafkaEvent = new KafkaEvent($event);
$this->logger->info("Processing records");
$records = $kafkaEvent->getRecords();
foreach ($records as $record) {
try {
$key = $record->getKey();
$this->logger->info("Key: $key");
$values = $record->getValue();
$this->logger->info(json_encode($values));
foreach ($values as $value) {
$this->logger->info("Value: $value");
}
} catch (Exception $e) {
$this->logger->error($e->getMessage());
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**SDK für Python (Boto3)**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon MSK-Ereignisses mit Lambda unter Verwendung von Python.
```
import base64
def lambda_handler(event, context):
# Iterate through keys
for key in event['records']:
print('Key:', key)
# Iterate through records
for record in event['records'][key]:
print('Record:', record)
# Decode base64
msg = base64.b64decode(record['value']).decode('utf-8')
print('Message:', msg)
```
------
#### [ Ruby ]
**SDK für Ruby**
Es gibt noch mehr GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon MSK-Ereignisses mit Lambda unter Verwendung von Ruby.
```
require 'base64'
def lambda_handler(event:, context:)
# Iterate through keys
event['records'].each do |key, records|
puts "Key: #{key}"
# Iterate through records
records.each do |record|
puts "Record: #{record}"
# Decode base64
msg = Base64.decode64(record['value'])
puts "Message: #{msg}"
end
end
end
```
------
#### [ Rust ]
**SDK für Rust**
Es gibt noch mehr dazu GitHub. Das vollständige Beispiel sowie eine Anleitung zum Einrichten und Ausführen finden Sie im Repository mit [Serverless-Beispielen](https://github.com/aws-samples/serverless-snippets/tree/main/integration-msk-to-lambda).
Nutzen eines Amazon-MSK-Ereignisses mit Lambda unter Verwendung von Rust.
```
use aws_lambda_events::event::kafka::KafkaEvent;
use lambda_runtime::{run, service_fn, tracing, Error, LambdaEvent};
use base64::prelude::*;
use serde_json::{Value};
use tracing::{info};
/// Pre-Requisites:
/// 1. Install Cargo Lambda - see https://www.cargo-lambda.info/guide/getting-started.html
/// 2. Add packages tracing, tracing-subscriber, serde_json, base64
///
/// This is the main body for the function.
/// Write your code inside it.
/// There are some code example in the following URLs:
/// - https://github.com/awslabs/aws-lambda-rust-runtime/tree/main/examples
/// - https://github.com/aws-samples/serverless-rust-demo/
async fn function_handler(event: LambdaEvent) -> Result {
let payload = event.payload.records;
for (_name, records) in payload.iter() {
for record in records {
let record_text = record.value.as_ref().ok_or("Value is None")?;
info!("Record: {}", &record_text);
// perform Base64 decoding
let record_bytes = BASE64_STANDARD.decode(record_text)?;
let message = std::str::from_utf8(&record_bytes)?;
info!("Message: {}", message);
}
}
Ok(().into())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
// required to enable CloudWatch error logging by the runtime
tracing::init_default_subscriber();
info!("Setup CW subscriber!");
run(service_fn(function_handler)).await
}
```
------
Sie können Ihrem Lambda Funktionscode über die Konsole zur Verfügung stellen.
**So aktualiseren Sie Ihren Funktionscode mit dem Code-Editor**
1. Öffnen Sie die [Funktionsseite](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole und wählen Sie Ihre Funktion aus.
1. Wählen Sie die Registerkarte **Code** aus.
1. Wählen Sie im Bereich **Codequelle** Ihre Quellcodedatei aus und bearbeiten Sie sie im integrierten Code-Editor.
1. Wählen Sie im Abschnitt **BEREITSTELLEN** die Option **Bereitstellen** aus, um den Code Ihrer Funktion zu aktualisieren:
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
## Testen Sie Ihre Lambda-Funktion, um zu überprüfen, ob sie mit Ihrem Amazon MSK-Thema verbunden ist
Sie können jetzt überprüfen, ob Ihr Lambda von der Ereignisquelle aufgerufen wird, indem Sie die Ereignisprotokolle überprüfen CloudWatch .
**So überprüfen Sie, ob Ihre Lambda-Funktion aufgerufen wird**
1. Verwenden Sie Ihren Kafka-Admin-Host, um Kafka-Ereignisse mithilfe der `kafka-console-producer`-CLI zu generieren. Weitere Informationen finden Sie in der Kafka-Dokumentation unter [Einige Ereignisse in das Thema schreiben](https://kafka.apache.org/documentation/#quickstart_send). Senden Sie so viele Ereignisse, dass der durch die Stapelgröße definierte Stapel für die im vorherigen Schritt definierte Zuordnung von Ereignisquellen gefüllt wird, oder Lambda wartet auf weitere Informationen, um den Aufruf zu starten.
1. Wenn Ihre Funktion ausgeführt wird, schreibt Lambda, was passiert ist. CloudWatch Navigieren Sie in der Konsole zur Detailseite Ihrer Lambda-Funktion.
1. Wählen Sie die Registerkarte **Configuration** aus.
1. Wählen Sie in der Seitenleiste die Option **Überwachungs- und Betriebstools**.
1. Identifizieren Sie die **CloudWatch Protokollgruppe** unter **Logging-Konfiguration**. Die Protokollgruppe sollte mit `/aws/lambda` beginnen. Wählen Sie den Link zur Protokollgruppe.
1. Suchen Sie in der CloudWatch Konsole in den **Protokollereignissen** nach den Protokollereignissen, die Lambda an den Protokollstream gesendet hat. Stellen Sie fest, ob es Protokollereignisse gibt, die die Nachricht aus Ihrem Kafka-Ereignis enthalten, wie in der folgenden Abbildung dargestellt. Falls ja, haben Sie erfolgreich eine Lambda-Funktion mit einer Lambda-Zuordnung von Ereignisquellen mit Amazon MSK verbunden.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/msk_tut_log.png)