Konfigurieren von Amazon MSK-Ereignisquellen für Lambda - AWS Lambda

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.

Konfigurieren von Amazon MSK-Ereignisquellen für Lambda

Bevor Sie eine Zuordnung von Ereignisquellen für Ihren Amazon MSK-Cluster erstellen, müssen Sie sicherstellen, dass Ihr Cluster und die VPC, in der er sich befindet, korrekt konfiguriert sind. Sie müssen auch sicherstellen, dass die Ausführungsrolle Ihrer Lambda-Funktion über die erforderlichen IAM-Berechtigungen verfügt.

Folgen Sie den Anweisungen in den folgenden Abschnitten, um Ihren Amazon MSK-Cluster, Ihre VPC und Ihre Lambda-Funktion zu konfigurieren. Wie Sie die Zuordnung von Ereignisquellen erstellen können, erfahren Sie unter Hinzufügen von Amazon MSK als Ereignisquelle.

MSK-Cluster-Authentifizierung

Lambda benötigt eine Berechtigung, um auf den Amazon-MSK-Cluster zuzugreifen, Datensätze abzurufen und andere Aufgaben auszuführen. Amazon MSK unterstützt mehrere Optionen zur Steuerung des Client-Zugriffs auf den MSK-Cluster.

Nicht authentifizierter Zugriff

Wenn keine Clients über das Internet auf den Cluster zugreifen, können Sie einen nicht authentifizierten Zugriff verwenden.

SASL/SCRAM-Authentifizierung

Amazon MSK unterstützt die Authentifizierung mit Transport Layer Security (TLS)-Verschlüsselung von Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM). Damit Lambda eine Verbindung zum Cluster herstellen kann, speichern Sie die Anmeldeinformationen für die Authentifizierung (Benutzername und Passwort) in einemAWS Secrets Manager-Secret.

Weitere Informationen zur Verwendung von Secrets Manager finden Sie unter Benutzername und Passwortauthentifizierung mit AWS Secrets Manager im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

Amazon MSK unterstützt die SASL/PLAIN-Authentifizierung nicht.

Auf IAM-Rolle basierende Authentifizierung

Sie können IAM verwenden, um die Identität von Clients zu authentifizieren, die sich mit dem MSK-Cluster verbinden. Wenn die IAM-Authentifizierung auf Ihrem MSK-Cluster aktiv ist und Sie kein Geheimnis für die Authentifizierung angeben, verwendet Lambda automatisch standardmäßig die IAM-Authentifizierung. Verwenden Sie die IAM-Konsole oder API, um Richtlinien zu erstellen und zu implementieren, die auf Benutzern oder Rollen basieren. Weitere Informationen finden Sie unter IAM-Zugriffskontrolle im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

Fügen Sie die folgenden Berechtigungen zur Ausführungsrolle Ihrer Funktion hinzu, um Lambda zu erlauben, sich mit dem MSK-Cluster zu verbinden, Datensätze zu lesen und andere erforderliche Aktionen auszuführen.

{ "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:region:account-id:cluster/cluster-name/cluster-uuid", "arn:aws:kafka:region:account-id:topic/cluster-name/cluster-uuid/topic-name", "arn:aws:kafka:region:account-id:group/cluster-name/cluster-uuid/consumer-group-id" ] } ] }

Sie können diese Berechtigungen für einen bestimmten Cluster, ein bestimmtes Thema und eine bestimmte Gruppe einteilen. Weitere Informationen finden Sie unter Amazon-MSK-Kafka-Aktionen im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

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.

Für Amazon MSK fungiert Lambda als der Client. Sie konfigurieren ein Client-Zertifikat (als Secret in Secrets Manager), um Lambda für die Broker in Ihrem MSK-Cluster zu authentifizieren. Das Client-Zertifikat muss von einer Zertifizierungsstelle im Trust Store des Servers signiert sein. Der MSK-Cluster sendet ein Serverzertifikat an Lambda, um die Broker für Lambda zu authentifizieren. Das Serverzertifikat muss von einer Zertifizierungsstelle (CA) signiert sein, die sich im Trust Store von AWS befindet.

Informationen dazu, wie Sie ein Client-Zertifikat generieren, finden Sie unter Vorstellung von gegenseitiger TLS-Authentifizierung für Amazon MSK als Ereignisquelle.

Amazon MSK unterstützt keine selbstsignierten Serverzertifikate, da alle Broker in Amazon MSK öffentliche Zertifikate verwenden, die von Amazon-TrustServices-Zertifizierungsstellen signiert sind, denen Lambda standardmäßig vertraut.

Weitere Informationen über mTLS für Amazon MSK finden Sie unter Gegenseitige TLS-Authentifizierung im Entwicklerhandbuch für Amazon Managed Streaming for Apache Kafka.

Konfigurieren des mTLS-Secrets

Das Secret CLIENT_CERTIFICATE_TLS_AUTH 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 PBES1-Algorithmen (aber nicht PBES2) zur Verschlüsselung von privaten Schlüsseln.

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----- <certificate contents> -----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 #8 mit folgender Struktur vorliegen:

-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----

Verwenden Sie für einen verschlüsselten privaten Schlüssel die folgende Struktur:

-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----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-----" }

So wählt Lambda einen Bootstrap-Broker

Lambda wählt einen Bootstrap-Broker 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 (Geheimnis für SASL/SCRAM bereitgestellt)

  • 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.

Verwalten von API-Zugriff und -Berechtigungen

Neben dem Zugriff auf den Amazon-MSK-Cluster benötigt Ihre Funktion auch Berechtigungen, um verschiedene Amazon-MSK-API-Aktionen auszuführen. Sie fügen diese Berechtigungen zur Ausführungsrolle der Funktion hinzu. Wenn Ihre Benutzer Zugriff auf Amazon-MSK-API-Aktionen benötigen, fügen Sie die erforderlichen Berechtigungen zur Identitätsrichtlinie für den Benutzer oder die Rolle hinzu.

Sie können Ihrer Ausführungsrolle jede der folgenden Berechtigungen manuell hinzufügen. Alternativ können Sie die von AWS verwaltete Richtlinie AWSLambdaMSKExecutionRole Ihrer Ausführungsrolle zuordnen. Die AWSLambdaMSKExecutionRole-Richtlinie enthält alle unten aufgeführten erforderlichen API-Aktionen und VPC-Berechtigungen.

Erforderliche Berechtigungen für Ausführungsrolle der Lambda-Funktion

Um Protokolle in einer Protokollgruppe in Amazon CloudWatch Logs zu erstellen und zu speichern, muss Ihre Lambda-Funktion die folgenden Berechtigungen in ihrer Ausführungsrolle haben:

Damit Lambda in Ihrem Namen auf Ihren Amazon-MSK-Cluster zugreifen kann, muss Ihre Lambda-Funktion über die folgenden Berechtigungen in ihrer Ausführungsrolle verfügen:

Sie müssen nur entweder kafka:DescribeCluster oder kafka:DescribeClusterV2 hinzufügen. Für bereitgestellte MSK-Cluster funktioniert jede der beiden Berechtigungen. Für Serverless-MSK-Cluster müssen Sie kafka:DescribeClusterV2 verwenden.

Anmerkung

Lambda plant, schließlich die kafka:DescribeCluster-Genehmigung aus dieser AWSLambdaMSKExecutionRole-Richtlinie zu entfernen. Wenn Sie diese Richtlinie verwenden, sollten Sie alle Anwendungen, die kafka:DescribeCluster verwendet, auf kafka:DescribeClusterV2 umstellen.

VPC-Berechtigungen

Wenn nur Benutzer innerhalb einer VPC auf Ihren Amazon-MSK-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. Diese Berechtigungen sind in der AWS-verwalteten Richtlinie AWSLambdaMSKExecutionRole enthalten.

Optionale Lambda-Funktionsberechtigungen

Ihre Lambda-Funktion benötigt möglicherweise auch Berechtigungen für Folgendes:

  • Greifen Sie auf Ihr SCRAM-Secret zu, wenn Sie die SASL/SCRAM-Authentifizierung verwenden.

  • Beschreiben Ihres Secrets-Manager-Secrets

  • Zugriff auf Ihre AWS Key Management Service (AWS KMS) vom Kunden verwalteten Schlüssel

  • 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 Amazon-MSK-Broker konfigurieren, benötigt Ihre Lambda-Funktion möglicherweise die Berechtigung, auf Ihr SCRAM-Secret (bei Verwendung von SASL/SCRAM-Authentifizierung) oder Secrets Manager-Secret zuzugreifen, um 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:

Hinzufügen von Berechtigungen zu Ihrer Ausführungsrolle

Befolgen Sie diese Schritte, um die AWS verwaltete Richtlinie AWSLambdaMSKExecutionRole mithilfe der IAM-Konsole zu Ihrer Ausführungsrolle hinzuzufügen.

So fügen Sie eine AWS verwaltete Richtlinie hinzu
  1. Öffnen Sie die Seite Richtlinien in der IAM-Konsole.

  2. Geben Sie im Suchfeld den Namen der Richtlinie ein (AWSLambdaMSKExecutionRole).

  3. Wählen Sie die Richtlinie aus der Liste aus und wählen Sie dann Richtlinienaktionen, Anhängen aus.

  4. Wählen Sie auf der Seite Richtlinie anfügen Ihre Ausführungsrolle aus der Liste aus, und wählen Sie dann Richtlinie anfügen aus.

Gewähren von Benutzerzugriff mit einer IAM-Richtlinie

Standardmäßig haben Benutzer und Rollen keine Berechtigung zum Ausführen von Amazon-MSK-API-Operationen. Um Benutzern in Ihrem Unternehmen oder Konto Zugriff zu gewähren, können Sie eine identitätsbasierte Richtlinie hinzufügen oder aktualisieren. Weitere Informationen finden Sie unter Beispiele für identitätsbasierte Amazon-MSK-Richtlinien im Entwicklerhanbuch für Amazon Managed Streaming for Apache Kafka.

Authentifizierungs- und Autorisierungsfehler

Wenn eine der Berechtigungen, die zur Nutzung von Daten aus dem Amazon-MSK-Cluster erforderlich sind, fehlt, zeigt Lambda eine der folgenden Fehlermeldungen in der Ereignisquellenzuordnung unter LastProcessingResult an.

Cluster konnte Lambda nicht autorisieren

Bei SASL/SCRAM oder mTLS weist dieser Fehler darauf hin, dass der angegebene Benutzer nicht über alle nachfolgenden erforderlichen Berechtigungen für die Kafka-Zugriffskontrollliste (ACL) verfügt:

  • DescribeConfigs-Cluster

  • Beschreiben von Gruppe

  • Gruppe lesen

  • Thema beschreiben

  • Thema lesen

Zur IAM-Zugriffskontrolle fehlen der Ausführungsrolle Ihrer Funktion eine oder mehrere der Berechtigungen, die für den Zugriff auf die Gruppe oder das Thema erforderlich sind. Prüfen Sie die Liste der erforderlichen Berechtigungen in Auf IAM-Rolle basierende Authentifizierung.

Wenn Sie Kafka-ACLs oder eine IAM-Richtlinie mit den erforderlichen Kafka-Cluster-Berechtigungen erstellen, geben Sie das Thema und die Gruppe als Ressourcen an. Der Themenname muss mit dem Thema in der Ereignisquellenzuordnung übereinstimmen. Der Gruppenname muss mit der UUID der Ereignisquellenzuordnung übereinstimmen.

Nachdem Sie der Ausführungsrolle die erforderlichen Berechtigungen hinzugefügt haben, kann es einige Minuten dauern, bis die Änderungen wirksam werden.

SASL-Authentifizierung fehlgeschlagen

Bei SASL/SCRAM weist dieser Fehler darauf hin, dass der angegebene Benutzername und das Passwort ungültig sind.

Zur IAM-Zugriffskontrolle fehlt der Ausführungsrolle die Berechtigung kafka-cluster:Connect für den MSK-Cluster. Fügen Sie der Rolle diese Berechtigung hinzu und geben Sie den Amazon-Ressourcenname (ARN) des Clusters als Ressource an.

Dieser Fehler wird Ihnen möglicherweise in zeitlichen Abständen angezeigt. Der Cluster lehnt Verbindungen ab, wenn die Anzahl der TCP-Verbindungen das Amazon-MSK-Servicekontingent überschreitet. Lambda zieht sich zurück und versucht es erneut, bis eine Verbindung erfolgreich ist. Nachdem Lambda eine Verbindung zum Cluster hergestellt hat und nach Datensätzen abfragt, ändert sich das letzte Verarbeitungsergebnis zu OK.

Server konnte Lambda nicht authentifizieren

Dieser Fehler weist darauf hin, dass die Amazon-MSK-Kafka-Broker sich bei Lambda nicht authentifizieren konnten. Dieser Fehler kann aus folgenden Gründen auftreten:

  • Sie haben kein Client-Zertifikat für die mTLS-Authentifizierung bereitgestellt.

  • Sie haben ein Client-Zertifikat bereitgestellt, aber die Broker sind nicht für die Verwendung von mTLS konfiguriert.

  • Die Broker vertrauen einem Client-Zertifikat nicht.

Bereitgestelltes Zertifikat oder bereitgestellter privater Schlüssel ist ungültig

Dieser Fehler weist darauf hin, dass der Amazon-MSK-Konsument das bereitgestellte Zertifikat oder den bereitgestellten privaten Schlüssel nicht verwenden konnte. Stellen Sie sicher, dass das Zertifikat und der Schlüssel das PEM-Format haben und die Verschlüsselung des privaten Schlüssels einen PBES1-Algorithmus nutzt.

Konfigurieren Sie die Netzwerksicherheit

Um Lambda vollen Zugriff auf Amazon MSK ü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 Amazon MSK mit Lambda verwenden, erstellen Sie AWS PrivateLink VPC-Endpunkte, 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 Bereitstellungsmodus 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 das AWS STS, damit ein Dienstprinzipal 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.

Wenn Sie eine Zuordnung von Ereignisquellen für Amazon MSK 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 der 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. Amazon MSK verwendet standardmäßig die folgenden Ports: 9092 für Klartext, 9094 für TLS, 9096 für SASL, 9098 für IAM.

  • Eingehende Regeln – Erlauben Sie den gesamten Datenverkehr auf dem Standard-Cluster-Port für die Sicherheitsgruppe, die mit Ihrer Ereignisquelle verbunden ist.

  • Ausgehende Regeln – Erlauben Sie allen Datenverkehr an Port 443 für alle Ziele. Erlauben Sie den gesamten Datenverkehr auf dem Standard-Cluster-Port für die Sicherheitsgruppe, die mit Ihrer Ereignisquelle verbunden ist.

  • Amazon VPC-Endpunkt-Eingangsregeln – Wenn Sie einen Amazon VPC-Endpunkt verwenden, muss die Sicherheitsgruppe, die mit Ihrem Amazon VPC-Endpunkt verbunden ist, eingehenden Verkehr auf Port 443 von der Cluster-Sicherheitsgruppe zulassen.

Wenn Ihr Cluster 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-Dienstprinzipal.

Beispiel 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-Dienstprinzipal 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-Dienstprinzipal für die AWS STS- und Lambda-Endpunkte gewährt wird.

Beispiel VPC-Endpunktrichtlinie – AWS STS-Endpunkt
{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Beispiel VPC-Endpunktrichtlinie – Lambda-Endpunkt
{ "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }