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. # Grundlegendes zu Methoden zum Aufrufen von Lambda-Funktionen Nach dem Bereitstellen Ihrer Lambda-Funktion können Sie sie auf verschiedene Arten aufrufen: + Die [Lambda-Konsole](testing-functions.md) – Verwenden Sie die Lambda-Konsole, um schnell ein Testereignis zu erstellen, mit dem Sie Ihre Funktion aufrufen. + Das [AWS SDK](https://aws.amazon.com/developer/tools/) — Verwenden Sie das AWS SDK, um Ihre Funktion programmgesteuert aufzurufen. + Die [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)-API – Verwenden Sie die Lambda-Invoke-API, um Ihre Funktion direkt aufzurufen. + Das [AWS Command Line Interface (AWS CLI)](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) — Verwenden Sie den `aws lambda invoke` AWS CLI Befehl, um Ihre Funktion direkt von der Befehlszeile aus aufzurufen. + Ein [URL-HTTP (S) -Endpunkt für eine Funktion](urls-configuration.md) — Verwenden Sie URLs die Funktion, um einen dedizierten HTTP (S) -Endpunkt zu erstellen, mit dem Sie Ihre Funktion aufrufen können. All diese Methoden sind *direkte* Möglichkeiten, Ihre Funktion aufzurufen. In Lambda besteht ein häufiger Anwendungsfall darin, Ihre Funktion auf der Grundlage eines Ereignisses aufzurufen, das an anderer Stelle in Ihrer Anwendung auftritt. Einige Dienste können bei jedem neuen Ereignis eine Lambda-Funktion aufrufen. Dies wird als [Trigger](lambda-services.md) bezeichnet. Für stream- und warteschlangenbasierte Dienste ruft Lambda die Funktion mit Batches von Datensätzen auf. Dies wird als [Zuordnung von Ereignisquellen](invocation-eventsourcemapping.md) bezeichnet. Wenn Sie eine Funktion aufrufen, können Sie bestimmen, ob sie synchron oder asynchron aufgerufen wird. Bei einem [synchronen Aufruf](invocation-sync.md) warten Sie, bis die Funktion das Ereignis verarbeitet und eine Antwort zurückgegeben hat. Bei einem [asynchronen](invocation-async.md) Aufruf stellt Lambda das Ereignis für die Verarbeitung in eine Warteschlangen und gibt umgehend eine Antwort zurück. Der [`InvocationType`-Anforderungsparameter in der Invoke-API](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#API_Invoke_RequestParameters) bestimmt, wie Lambda Ihre Funktion aufruft. Der Wert von `RequestResponse` steht für einen synchronen Aufruf und der Wert von `Event` steht für einen asynchronen Aufruf. [Verwenden Sie die öffentlichen Dual-Stack-Endpunkte von Lambda IPv6, um Ihre Funktion erneut aufzurufen.](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints) Dual-Stack-Endpunkte unterstützen sowohl als auch. IPv4 IPv6 Lambda-Dual-Stack-Endpunkte verwenden die folgende Syntax: ``` protocol://lambda.us-east-1.api.aws ``` Sie können die [Lambda-Funktion](urls-configuration.md) auch verwenden URLs, um Funktionen aufzurufen. IPv6 Funktions-URL-Endpunkte haben das folgende Format: ``` https://url-id.lambda-url.us-east-1.on.aws ``` Wenn der Funktionsaufruf zu einem Fehler führt, sehen Sie sich bei synchronen Aufrufen die Fehlermeldung in der Antwort an und wiederholen Sie den Aufruf manuell. Bei asynchronen Aufrufen werden Wiederholungsversuche automatisch von Lambda verarbeitet und Aufrufdatensätze an ein [Ziel](invocation-async-retain-records.md#invocation-async-destinations) gesendet. # Eine Lambda-Funktion synchron aufrufen Wenn Sie eine Funktion synchron aufrufen, führt Lambda die Funktion aus und wartet auf eine Antwort. Wenn der Funktionsaufruf beendet ist, gibt Lambda die Antwort aus dem Funktionscode mit zusätzlichen Daten, wie z. B. der Version der aufgerufenen Funktion, zurück. Wenn Sie eine Funktion mithilfe der AWS CLI synchron ausführen möchten, verwenden Sie den Befehl `invoke`. ``` aws lambda invoke --function-name my-function \ --cli-binary-format raw-in-base64-out \ --payload '{ "key": "value" }' response.json ``` Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*. Die Ausgabe sollte folgendermaßen aussehen: ``` { "ExecutedVersion": "$LATEST", "StatusCode": 200 } ``` Das folgende Diagramm zeigt Clients, die eine Lambda-Funktion synchron aufrufen. Lambda sendet die Ereignisse direkt an die Funktion und sendet die Antwort der Funktion zurück an den Aufrufer. ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/invocation-sync.png) `payload` ist eine Zeichenfolge, die ein Ereignis im JSON-Format enthält. Der Name der Datei, in die die AWS CLI die Antwort von der Funktion schreibt, lautet `response.json`. Wenn die Funktion ein Objekt oder einen Fehler zurückgibt, ist der Antworttext das Objekt oder der Fehler im JSON-Format. Wenn die Funktion fehlerfrei beendet wird, lautet der Antworttext `null`. **Anmerkung** Lambda wartet nicht, bis externe Erweiterungen abgeschlossen sind, bevor die Antwort gesendet wird. Externe Erweiterungen werden als unabhängige Prozesse in der Ausführungsumgebung ausgeführt und laufen auch nach Abschluss des Funktionsaufrufs weiter. Weitere Informationen finden Sie unter [Lambda-Funktionen mit Lambda-Erweiterungen erweitern](lambda-extensions.md). Die Ausgabe des Befehls, die im Terminal angezeigt wird, enthält Informationen aus Headern in der Antwort von Lambda. Dies umfasst die Version, von der das Ereignis verarbeitet wurde (nützlich bei der Verwendung von [Aliassen](configuration-aliases.md)) und den von Lambda zurückgegebenen Statuscode. Wenn Lambda die Funktion ausführen konnte, lautet der Statuscode 200, auch wenn die Funktion einen Fehler zurückgegeben hat. **Anmerkung** Bei Funktionen mit einem langen Timeout wird Ihr Client während eines synchronen Aufrufs möglicherweise getrennt, während er auf eine Antwort wartet. Konfigurieren Sie HTTP-Client, SDK, Firewall, Proxy oder Betriebssystem so, dass lange Verbindungen mit Timeout- oder Keepalive-Einstellungen möglich sind. Wenn Lambda die Funktion nicht ausführen kann, wird der Fehler in der Ausgabe angezeigt. ``` aws lambda invoke --function-name my-function \ --cli-binary-format raw-in-base64-out \ --payload value response.json ``` Die Ausgabe sollte folgendermaßen aussehen: ``` An error occurred (InvalidRequestContentException) when calling the Invoke operation: Could not parse request body into json: Unrecognized token 'value': was expecting ('true', 'false' or 'null') at [Source: (byte[])"value"; line: 1, column: 11] ``` Die AWS CLI ist ein Open-Source-Tool, mit dem Sie über Befehle in Ihrer Befehlszeilen-Shell mit den AWS-Services interagieren können. Zur Durchführung der Schritte in diesem Abschnitt benötigen Sie [AWS CLI Version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Sie können die [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) verwenden, um Protokolle für einen Aufruf mit der `--log-type`-Befehlsoption abzurufen. Die Antwort enthält das Feld `LogResult`, das bis zu 4 KB base64-verschlüsselte Protokolle aus dem Aufruf enthält. **Example eine Log-ID abrufen** Das folgende Beispiel zeigt, wie eine *Protokoll-ID* aus dem `LogResult`-Feld für eine Funktion namens `my-function` abgerufen wird. ``` aws lambda invoke --function-name my-function out --log-type Tail ``` Die Ausgabe sollte folgendermaßen aussehen: ``` { "StatusCode": 200, "LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...", "ExecutedVersion": "$LATEST" } ``` **Example entschlüsseln der Protokolle** Verwenden Sie in derselben Eingabeaufforderung das `base64`-Dienstprogramm, um die Protokolle zu entschlüsseln. Das folgende Beispiel zeigt, wie Base64-codierte Logs für abgerufen werde `my-function`. ``` aws lambda invoke --function-name my-function out --log-type Tail \ --query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode ``` Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*. Die Ausgabe sollte folgendermaßen aussehen: ``` START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST "AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib", END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB ``` Das `base64`-Dienstprogramm ist unter Linux, macOS und [Ubuntu auf Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10)verfügbar. macOS-Benutzer müssen möglicherweise `base64 -D` verwenden. Weitere Informationen über die `Invoke`-API, einschließlich einer vollständigen Liste von Parametern, Kopfzeilen und Fehlern, finden Sie unter [Aufrufen](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). Wenn Sie eine Funktion direkt aufrufen, können Sie die Antwort auf Fehler überprüfen und es erneut versuchen. Die AWS CLI- und das AWS SDK unternehmen zudem automatisch einen Wiederholversuch bei Client-Zeitbeschränkungen, Drosselung und Service-Fehlern. Weitere Informationen finden Sie unter [Grundlegendes zum Wiederholungsverhalten in Lambda](invocation-retries.md). # Asynchrones Aufrufen einer Lambda-Funktion Mehrere AWS-Services wie Amazon Simple Storage Service (Amazon S3) und Amazon Simple Notification Service (Amazon SNS) rufen Funktionen asynchron auf, um Ereignisse zu verarbeiten. Sie können eine Lambda-Funktion auch asynchron mit dem AWS Command Line Interface (AWS CLI) oder einem der AWS-SDKs aufrufen. Wenn Sie eine Funktion asynchron aufrufen, warten Sie nicht auf eine Antwort aus dem Funktionscode. Sie übergeben das Ereignis an Lambda und Lambda erledigt den Rest. Sie können konfigurieren, wie Lambda Fehler behandelt, und Sie können Aufruf-Datensätze an eine nachgelagerte Ressource wie Amazon Simple Queue Service (Amazon SQS) oder Amazon EventBridge (EventBridge) senden, um Komponenten Ihrer Anwendung miteinander zu verketten. Das folgende Diagramm zeigt Clients, die eine Lambda-Funktion asynchron aufrufen. Lambda stellt die Ereignisse in eine Warteschlange, bevor sie an die Funktion gesendet werden. ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/features-async.png) Lambda platziert das Ereignis bei asynchronem Aufruf in eine Warteschlange und gibt eine Erfolgsantwort ohne zusätzliche Informationen zurück. Ein separater Prozess liest Ereignisse aus der Warteschlange und senden sie zu Ihrer Funktion. Um eine Lambda-Funktion asynchron mit dem AWS Command Line Interface (AWS CLI) oder einem der AWS-SDKs aufzurufen, setzen Sie den [InvocationType](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-InvocationType)-Parameter auf `Event`. Das folgende Beispiel zeigt einen AWS CLI-Befehl zum Aufrufen einer Funktion. ``` aws lambda invoke \ --function-name my-function \ --invocation-type Event \ --cli-binary-format raw-in-base64-out \ --payload '{ "key": "value" }' response.json ``` Die Ausgabe sollte folgendermaßen aussehen: ``` { "StatusCode": 202 } ``` Die **cli-binary-format**-Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface-Benutzerhandbuch für Version 2*. Die Ausgabedatei (`response.json`) enthält keine Informationen, wird bei der Ausführung dieses Befehls aber dennoch erstellt. Wenn Lambda das Ereignis nicht zur Warteschlange hinzufügen kann, erscheint in der Befehlsausgabe eine Fehlermeldung. # Wie Lambda mit Fehlern und Wiederholungsversuchen mit asynchronem Aufruf umgeht Lambda verwaltet Ihre asynchrone Ereigniswarteschlange der Funktion und unternimmt bei Fehlern Wiederholungsversuche. Wenn die Funktion einen Fehler zurückgibt, versucht Lambda standardmäßig zwei weitere Male, sie auszuführen. Dabei wird eine Minute lang zwischen den ersten zwei Versuchen und zwei Minuten lang zwischen dem zweiten und dem dritten Versuch gewartet. Zu Funktionsfehlern gehören Fehler, die vom Code der Funktion zurückgegeben werden, sowie Fehler, die von der Laufzeit des Fehlers zurückgegeben werden, wie z. B. Timeouts. Wenn für die Funktion nicht genügend Gleichzeitigkeit für die Verarbeitung aller Ereignisse verfügbar ist, werden weitere Anforderungen gedrosselt. Bei Drosselungsfehlern (429) und Systemfehlern (500-Serie) sendet Lambda das Ereignis zur Warteschlange zurück und versucht standardmäßig bis zu 6 Stunden lang, die Funktion erneut auszuführen. Das Wiederholungsintervall erhöht sich exponentiell von 1 Sekunde nach dem ersten Versuch auf maximal 5 Minuten. Lambda stellt viele Einträge in die Warteschlange, erhöht das Wiederholungsintervall und reduziert die Rate, mit der es Ereignisse aus der Warteschlange liest. Selbst wenn Ihre Funktion keinen Fehler zurückgibt, ist es möglich, dass sie dasselbe Ereignis mehrmals von Lambda erhält, da die Warteschlange selbst „letztendliche Konsistenz“ ist. Wenn die Funktion mit eingehenden Ereignissen nicht Schritt halten kann, kann es auch vorkommen, dass Ereignisse aus der Warteschlange gelöscht werden, ohne zur Funktion gesendet zu werden. Stellen Sie sicher, dass Ihr Funktionscode doppelte Ereignisse ordnungsgemäß verarbeitet und dass Sie über genügend Gleichzeitigkeit zur Verarbeitung aller Aufrufe verfügen. Wenn die Warteschlange sehr lang ist, können neue Ereignisse veraltet sein, bevor Lambda sie an Ihre Funktion senden kann. Wenn ein Ereignis abläuft oder bei ihm alle Verarbeitungsversuche fehlschlagen, wird es von Lambda verworfen. Sie können die [Fehlerbehandlung für eine Funktion konfigurieren](invocation-async-configuring.md), um die Anzahl der Wiederholungsversuche zu reduzieren, die Lambda durchführt, oder um unverarbeitete Ereignisse schneller zu verwerfen. [Konfigurieren Sie eine Warteschlange für unzustellbare Nachrichten](invocation-async-retain-records.md#invocation-dlq), um verworfene Ereignisse zu erfassen. Zur Erfassung von Aufzeichnungen fehlgeschlagener Aufrufe (z. B. Zeitüberschreitungen oder Laufzeitfehler) zu erfassen, [erstellen Sie Fehlerziel](invocation-async-retain-records.md#invocation-async-destinations). # Konfigurieren von Fehlerbehandlungseinstellungen für asynchrone Lambda-Aufrufe Verwenden Sie die folgenden Einstellungen, um zu konfigurieren, wie Lambda Fehler und Wiederholungen bei asynchronen Funktionsaufrufen behandelt: + [MaximumEventAgeInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html#lambda-PutFunctionEventInvokeConfig-request-MaximumEventAgeInSeconds): Die maximale Zeitspanne in Sekunden, die Lambda ein Ereignis in der Warteschlange für asynchrone Ereignisse behält, bevor es verworfen wird. + [MaximumRetryAttempts](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html#lambda-PutFunctionEventInvokeConfig-request-MaximumRetryAttempts): Die maximale Anzahl der Wiederholungen von Lambda-Ereignissen, wenn die Funktion einen Fehler zurückgibt. Verwenden Sie die Lambda-Konsole oder AWS CLI, um Einstellungen für die Fehlerbehandlung für eine Funktion, eine Version oder einen Alias zu konfigurieren. ------ #### [ Console ] **So konfigurieren Sie die Fehlerbehandlung** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie eine Funktion aus. 1. Wählen Sie „**Konfiguration**“ und dann „**Asynchroner Aufruf**“ aus. 1. Wählen Sie unter **Asynchronous invocation (Asynchroner Aufruf)** die Option **Edit (Bearbeiten)**. 1. Konfigurieren Sie die folgenden Einstellungen. + **Maximales Alter des Ereignisses** – Die maximale Zeitspanne, die Lambda ein Ereignis in der Warteschlange für asynchrone Ereignisse behält (bis zu 6 Stunden). + **Wiederholversuche** – Die Anzahl der Wiederholungen, die Lambda es erneut versucht, wenn die Funktion einen Fehler zurückgibt (zwischen 0 und 2). 1. Wählen Sie **Speichern**. ------ #### [ AWS CLI ] Um den asynchronen Aufruf mit dem AWS CLI zu konfigurieren, verwenden Sie den Befehl [put-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-function-event-invoke-config.html). Im folgenden Beispiel wird eine Funktion mit einem maximalen Ereignisalter von 1 Stunde und ohne Wiederholversuche konfiguriert. ``` aws lambda put-function-event-invoke-config \ --function-name error \ --maximum-event-age-in-seconds 3600 \ --maximum-retry-attempts 0 ``` Der Befehl `put-function-event-invoke-config` überschreibt alle vorhandenen Konfigurationen für die Funktion, die Version oder den Alias. Um eine Option zu konfigurieren, ohne andere zurückzusetzen, verwenden Sie [update-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-event-invoke-config.html). Im folgenden Beispiel wird Lambda so konfiguriert, dass ein Datensatz an eine SQS-Standardwarteschlange namens `destination` gesendet wird, wenn ein Ereignis nicht verarbeitet werden kann. ``` aws lambda update-function-event-invoke-config \ --function-name my-function \ --destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-1:123456789012:destination"}}' ``` ------ Die Ausgabe sollte folgendermaßen aussehen: ``` { "LastModified": 1573686021.479, "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST", "MaximumRetryAttempts": 0, "MaximumEventAgeInSeconds": 3600, "DestinationConfig": { "OnSuccess": {}, "OnFailure": {} } } ``` Wenn ein Aufrufereignis das maximale Alter überschreitet oder alle Wiederholversuche fehlschlagen, wird es von Lambda verworfen. Um eine Kopie der verworfenen Ereignisse beizubehalten, konfigurieren Sie ein [Ziel](invocation-async-retain-records.md#invocation-async-destinations) für fehlgeschlagene Ereignisse. # Erfassung von Datensätzen asynchroner Lambda-Aufrufe Lambda kann Aufzeichnungen von asynchronen Aufrufen an einen der folgenden Server senden. AWS-Services + **Amazon SQS** – Eine standardmäßige SQS-Warteschlange + **Amazon SNS** – Ein SNS-Standardthema + **Amazon S3** – Ein Amazon S3-Bucket (nur bei einem Fehler) + **AWS Lambda** – Eine Lambda-Funktion + **Amazon EventBridge** — Ein EventBridge Eventbus Der Aufrufdatensatz enthält Details zur Anforderung und Antwort im JSON-Format. Sie können separate Ziele für Ereignisse konfigurieren, die erfolgreich verarbeitet werden, und für Ereignisse, bei denen alle Verarbeitungsversuche fehlschlagen. Alternativ können Sie eine Amazon-SQS-Standardwarteschlange oder ein Amazon-SNS-Standardthema als Warteschlange für unzustellbare Nachrichten für verworfene Ereignisse konfigurieren. Für Warteschlangen für unzustellbare Nachrichten sendet Lambda nur den Inhalt des Ereignisses ohne Details zur Antwort. Wenn Lambda einen Datensatz nicht an ein von Ihnen konfiguriertes Ziel senden kann, sendet es eine `DestinationDeliveryFailures` Metrik an Amazon CloudWatch. Dies kann passieren, wenn Ihre Konfiguration einen nicht unterstützten Zieltyp enthält, z. B. eine Amazon-SQS-FIFO-Warteschlange oder ein Amazon-SNS-FIFO-Thema. Zustellungsfehler können auch aufgrund von Berechtigungsfehlern und Größenbeschränkungen auftreten. Weitere Informationen zu Lambda-Aufrufmetriken finden Sie unter [Aufrufmetriken](monitoring-metrics-types.md#invocation-metrics). **Anmerkung** Um zu verhindern, dass eine Funktion ausgelöst wird, können Sie die reservierte Parallelität der Funktion auf Null setzen. Wenn Sie die reservierte Parallelität für eine asynchron aufgerufene Funktion auf Null setzen, sendet Lambda sofort und ohne Wiederholungsversuche alle Ereignisse ohne erneute Versuche an die konfigurierte [Warteschlange für unzustellbare Nachrichten](#invocation-dlq) oder an das [Ereignisziel](#invocation-async-destinations) bei Fehlern. Um Ereignisse zu verarbeiten, die gesendet wurden, während die reservierte Parallelität auf Null gesetzt war, müssen Sie die Ereignisse aus der Warteschlange für unzustellbare Nachrichten oder dem Ereignisziel bei Fehlern verarbeiten. ## Hinzufügen eines Ziels Um Datensätze der asynchronen Aufrufe beizubehalten, fügen Sie Ihrer Funktion ein Ziel hinzu. Sie können wählen, ob erfolgreiche Aufrufe oder fehlgeschlagene Aufrufe an ein Ziel gesendet werden sollen. Jede Funktion kann mehrere Ziele haben, sodass Sie separate Ziele für erfolgreiche und fehlgeschlagene Ereignisse konfigurieren können. Jeder Datensatz, der an das Ziel gesendet wird, ist ein JSON-Dokument mit Details zum Aufruf. Wie Einstellungen zur Fehlerbehandlung können Sie Ziele für eine Funktion, eine Funktionsversion oder einen Alias konfigurieren. **Tipp** Sie können auch Aufzeichnungen über fehlgeschlagene Aufrufe für die folgenden Typen von Ereignisquellenzuordnungen speichern: [Amazon Kinesis, Amazon](kinesis-on-failure-destination.md#kinesis-on-failure-destination-console) [DynamoDB und Apache Kafka (Amazon](services-dynamodb-errors.md) [MSK und selbstverwalteter Apache Kafka)](kafka-on-failure.md#kafka-onfailure-destination). In der folgenden Tabelle werden die unterstützten Ziele für Datensätze der asynchronen Aufrufen aufgelistet. Damit Lambda erfolgreich Datensätze an das von Ihnen ausgewählte Ziel senden kann, stellen Sie sicher, dass die [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion auch die entsprechenden Berechtigungen enthält. In der Tabelle wird auch beschrieben, wie jeder Zieltyp den JSON-Aufrufdatensatz empfängt. | Zieltyp | Erforderliche Berechtigung | Zielspezifisches JSON-Format | | --- | --- | --- | | Amazon-SQS-Warteschlange | [sqs: SendMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) | Lambda übergibt den Aufrufdatensatz als `Message` an das Ziel. | | Amazon-SNS-Thema | [sns:Publish](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html) | Lambda übergibt den Aufrufdatensatz als `Message` an das Ziel. | | Ein Amazon S3-Bucket (nur bei einem Fehler) | [s3: PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) [s3: ListBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/invocation-async-retain-records.html) | | Lambda-Funktion | [Lambda: InvokeFunction](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) | Lambda übergibt den Aufrufdatensatz als Nutzlast in der Funktion. | | EventBridge | [Ereignisse: PutEvents](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/invocation-async-retain-records.html) | **Anmerkung** Wenn Sie für Amazon S3 S3-Ziele die Verschlüsselung für den Bucket mithilfe eines KMS-Schlüssels aktiviert haben, benötigt Ihre Funktion auch die [kms: GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) -Berechtigung. **Wichtig** Wenn Sie Amazon SNS als Ziel verwenden, beachten Sie, dass Amazon SNS eine maximale Nachrichtengröße von 256 KB hat. Wenn sich Ihre Nutzdaten für asynchrone Aufrufe 1 MB nähern, kann der Aufrufdatensatz (der die ursprünglichen Nutzdaten plus zusätzliche Metadaten enthält) das Amazon-SNS-Limit überschreiten und zu Übermittlungsfehlern führen. Erwägen Sie die Verwendung von Amazon-SQS- oder Amazon-S3-Zielen für größere Nutzdaten. In den folgenden Schritten wird beschrieben, wie Sie mit der Lambda-Konsole und der AWS CLI ein Ziel für eine Funktion konfigurieren. ------ #### [ Console ] 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie eine Funktion aus. 1. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add destination (Ziel hinzufügen)**. 1. Wählen Sie unter **Source (Quelle)** die Option **Asynchronous invocation (Asynchroner Aufruf)**. 1. Wählen Sie unter **Condition (Bedingung)** eine der folgenden Optionen aus: + **Bei Fehler** – Es wird ein Datensatz gesendet, wenn das Ereignis alle Verarbeitungsversuche ausschöpft oder das maximale Alter überschreitet. + **Bei Erfolg** – Es wird ein Datensatz gesendet, wenn die Funktion einen asynchronen Aufruf erfolgreich verarbeitet. 1. Wählen Sie unter **Destination type (Zieltyp)** den Ressourcentyp aus, der den Aufrufdatensatz empfängt. 1. Wählen Sie unter **Destination (Ziel)** eine Ressource aus. 1. Wählen Sie **Speichern**. ------ #### [ AWS CLI ] Um ein Ziel mit dem zu konfigurieren AWS CLI, führen Sie den Befehl [update-function-event-invoke-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-event-invoke-config.html) aus. Im folgenden Beispiel wird Lambda so konfiguriert, dass ein Datensatz an eine SQS-Standardwarteschlange namens `destination` gesendet wird, wenn ein Ereignis nicht verarbeitet werden kann. ``` aws lambda update-function-event-invoke-config \ --function-name my-function \ --destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-1:123456789012:destination"}}' ``` ------ ### Bewährte Methoden für die Sicherheit in Amazon-S3-Zielen Das Löschen eines S3-Buckets, der als Ziel konfiguriert ist, ohne das Ziel aus der Konfiguration Ihrer Funktion zu entfernen, kann ein Sicherheitsrisiko darstellen. Wenn ein anderer Benutzer den Namen Ihres Ziel-Buckets kennt, kann er den Bucket in seinem AWS-Konto neu erstellen. Aufzeichnungen über fehlgeschlagene Aufrufe werden an den entsprechenden Bucket gesendet, wodurch möglicherweise Daten aus Ihrer Funktion verfügbar gemacht werden. **Warnung** Um sicherzustellen, dass Aufrufdatensätze Ihrer Funktion nicht an einen S3-Bucket in einem anderen gesendet werden können AWS-Konto, fügen Sie der Ausführungsrolle Ihrer Funktion eine Bedingung hinzu, die die `s3:PutObject` Berechtigungen auf Buckets in Ihrem Konto beschränkt. -Das folgende Beispiel zeigt eine IAM-Richtlinie, die die `s3:PutObject`-Berechtigungen Ihrer Funktion auf Buckets in Ihrem Konto beschränkt. Diese Richtlinie gibt Lambda auch die `s3:ListBucket`-Erlaubnis, einen S3-Bucket als Ziel zu verwenden. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "S3BucketResourceAccountWrite", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::*/*", "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "s3:ResourceAccount": "111122223333" } } } ] } ``` Um der Ausführungsrolle Ihrer Funktion mithilfe von AWS-Managementkonsole oder eine Berechtigungsrichtlinie hinzuzufügen AWS CLI, lesen Sie die Anweisungen in den folgenden Verfahren: ------ #### [ Console ] **So fügen Sie der Ausführungsrolle einer Funktion (Konsole) eine Berechtigungsrichtlinie hinzu** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie die Lambda-Funktion aus, deren Ausführungsrolle Sie ändern möchten. 1. Klicken Sie in der Registerkarte **Konfiguration** auf die Option **Berechtigungen**. 1. Wählen Sie auf der Registerkarte **Ausführungsrolle** den **Rollennamen** Ihrer Funktion aus, um die IAM-Konsolenseite der Rolle zu öffnen. 1. Fügen Sie der Rolle wie folgt eine Richtlinie mit Berechtigungen hinzu: 1. Wählen Sie im Bereich **Berechtigungsrichtlinien** die Optionen **Berechtigungen hinzufügen** und dann **Inline-Richtlinie erstellen** aus. 1. Wählen Sie im **Richtlinien-Editor** **JSON** aus. 1. Fügen Sie die Richtlinie, die Sie hinzufügen möchten, in den Editor ein (indem Sie die vorhandene JSON-Datei ersetzt) und wählen Sie dann **Weiter** aus. 1. Geben Sie unter **Richtliniendetails** für den **Richtliniennamen** ein. 1. Wählen Sie **Richtlinie erstellen** aus. ------ #### [ AWS CLI ] **So fügen Sie der Ausführungsrolle einer Funktion (CLI) eine Berechtigungsrichtlinie hinzu** 1. Erstellen Sie ein JSON-Richtliniendokument mit den erforderlichen Berechtigungen und speichern Sie es in einem lokalen Verzeichnis. 1. Verwenden Sie den `put-role-policy` IAM-CLI-Befehl, um die Berechtigungen zur Ausführungsrolle Ihrer Funktion hinzuzufügen. Führen Sie den folgenden Befehl in dem Verzeichnis aus, in dem Sie Ihr JSON-Richtliniendokument gespeichert haben und ersetzen Sie den Rollennamen, den Richtliniennamen und das Richtliniendokument durch Ihre eigenen Werte. ``` aws iam put-role-policy \ --role-name my_lambda_role \ --policy-name LambdaS3DestinationPolicy \ --policy-document file://my_policy.json ``` ------ ### Beispiel für Aufrufdatensatz Wenn ein Aufruf mit der Bedingung übereinstimmt, sendet Lambda [ein JSON-Dokument](#destinations-permissions) mit Details zum Aufruf an das Ziel. Das folgende Beispiel zeigt einen Aufrufdatensatz für ein Ereignis, bei dem drei Verarbeitungsversuche aufgrund eines Funktionsfehlers fehlgeschlagen sind. **Example** ``` { "version": "1.0", "timestamp": "2019-11-14T18:16:05.568Z", "requestContext": { "requestId": "e4b46cbf-b738-xmpl-8880-a18cdf61200e", "functionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function:$LATEST", "condition": "RetriesExhausted", "approximateInvokeCount": 3 }, "requestPayload": { "ORDER_IDS": [ "9e07af03-ce31-4ff3-xmpl-36dce652cb4f", "637de236-e7b2-464e-xmpl-baf57f86bb53", "a81ddca6-2c35-45c7-xmpl-c3a03a31ed15" ] }, "responseContext": { "statusCode": 200, "executedVersion": "$LATEST", "functionError": "Unhandled" }, "responsePayload": { "errorMessage": "RequestId: e4b46cbf-b738-xmpl-8880-a18cdf61200e Process exited before completing request" } } ``` Der Aufrufdatensatz enthält Details zum Ereignis, zur Antwort und zu dem Grund, warum der Datensatz gesendet wurde. ### Zurückverfolgen von Anforderungen zu Zielen Sie können AWS X-Ray verwenden, um eine verbundene Ansicht jeder Anforderung zu sehen, während sie in die Warteschlange gestellt, von einer Lambda-Funktion verarbeitet und an den Zielservice übergeben wird. Wenn Sie X-Ray-Tracing für eine Funktion oder einen Service aktivieren, der eine Funktion aufruft, fügt Lambda der Anforderung einen X-Ray-Header hinzu und übergibt den Header an den Zielservice. Traces von Upstream-Services werden automatisch mit Traces von Downstream-Lambda-Funktionen und Zieldiensten verknüpft, sodass eine end-to-end Ansicht der gesamten Anwendung entsteht. Weitere Informationen zum Tracing finden Sie unter [Visualisieren Sie Lambda-Funktionsaufrufe mit AWS X-Ray](services-xray.md). ## Hinzufügen einer Warteschlange für unzustellbare Nachrichten Als eine Alternativ zu einem [Zielort bei Ausfall](#invocation-async-destinations) können Sie Ihre Funktion mit einer Warteschlangen für unzustellbare Nachrichten konfigurieren, um verworfene Ereignisse zur weiteren Verarbeitung zu speichern. Eine Warteschlange für unzustellbare Nachrichten fungiert genauso wie ein Ziel bei Ausfall, da sie verwendet wird, wenn alle Verarbeitungsversuche eines Ereignisses fehlschlagen oder ein Ereignis abläuft, ohne verarbeitet zu werden. Sie können jedoch nur auf Funktionsebene eine Warteschlange für unzustellbare Nachrichten hinzufügen oder entfernen. Funktionsversionen verwenden dieselben Einstellungen für Warteschlangen für unzustellbare Nachrichten wie die unveröffentlichte Version (\$1LATEST). Ausfallziele unterstützen auch zusätzliche Ziele und enthalten Details zur Reaktion der Funktion im Aufrufdatensatz. Um Ereignisse in einer Warteschlange für unzustellbare Nachrichten erneut zu verarbeiten, können Sie sie als [Ereignisquelle](invocation-eventsourcemapping.md) für Ihre Lambda-Funktion festlegen. Alternativ können Sie die Ereignisse manuell abrufen. Sie können eine Amazon-SQS-Standardwarteschlange oder ein Amazon-SNS-Standardthema für Ihre Warteschlange für unzustellbare Nachrichten auswählen. FIFO-Warteschlangen und Amazon-SNS-FIFO-Themen werden nicht unterstützt. + [Amazon-SQS-Warteschlange](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-create-queue.html) – Eine Warteschlange nimmt fehlgeschlagene Ereignisse auf, bis sie abgerufen werden. Wählen Sie eine Amazon SQS SQS-Standardwarteschlange, wenn Sie erwarten, dass eine einzelne Entität, z. B. eine Lambda-Funktion oder ein CloudWatch Alarm, das fehlgeschlagene Ereignis verarbeitet. Weitere Informationen finden Sie unter [Verwenden von Lambda mit Amazon SQS](with-sqs.md). + [Amazon-SNS-Thema](https://docs.aws.amazon.com/sns/latest/gsg/CreateTopic.html) – Ein Thema leitet fehlgeschlagene Ereignisse an eine oder mehrere Ziele. Wählen Sie ein Amazon-SNS-Standardthema aus, wenn Sie erwarten, dass mehrere Entitäten auf ein fehlgeschlagenes Ereignis reagieren. Sie können beispielsweise ein Thema so konfigurieren, dass Ereignisse an eine E-Mail-Adresse, eine Lambda-Funktion oder and/or einen HTTP-Endpunkt gesendet werden. Weitere Informationen finden Sie unter [Aufrufen von Lambda-Funktionen mit Amazon-SNS-Benachrichtigungen](with-sns.md). Um Ereginisse an eine Warteschlange oder an ein Thema zu senden, benötigt Ihre Funktion zusätzliche Berechtigungen. Fügen Sie eine Richtlinie mit den [ erforderlichen Berechtigungen](#destinations-permissions) zur [Ausführungsrolle](lambda-intro-execution-role.md) Ihrer Funktion hinzu. Wenn die Zielwarteschlange oder das Zielthema mit einem vom Kunden verwalteten AWS KMS Schlüssel verschlüsselt ist, stellen Sie sicher, dass sowohl die Ausführungsrolle Ihrer Funktion als auch die [ressourcenbasierte Richtlinie des Schlüssels die entsprechenden](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) Berechtigungen enthalten. Nachdem das Ziel erstellt und die Ausführungsrolle Ihrer Funktion aktualisiert wurde, fügen Sie die Warteschlange für unzustellbare Nachrichten zu Ihrer Funktion hinzu. Sie können mehrere Funktionen zum Senden von Ereignissen an dasselbe Ziel konfigurieren. ------ #### [ Console ] 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie eine Funktion aus. 1. Wählen Sie „**Konfiguration**“ und dann „**Asynchroner Aufruf**“ aus. 1. Wählen Sie unter **Asynchronous invocation (Asynchroner Aufruf)** die Option **Edit (Bearbeiten)**. 1. Stellen Sie den **Warteschlangenservice für unzustellbare Nachrichten** auf **Amazon SQS** oder **Amazon SNS** ein. 1. Wählen Sie die Ziel-Warteschlange oder das Ziel-Thema aus. 1. Wählen Sie **Speichern**. ------ #### [ AWS CLI ] Verwenden Sie den Befehl, um eine Warteschlange mit unerlaubten Briefen zu AWS CLI konfigurieren. [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) ``` aws lambda update-function-configuration \ --function-name my-function \ --dead-letter-config TargetArn=arn:aws:sns:us-east-1:123456789012:my-topic ``` ------ Lambda sendet das Ereignis mit zusätzlichen Informationen in den Attributen an die Warteschlange für unzustellbare Nachrichten. Sie können anhand dieser Informationen den von der Funktion zurückgegebenen Fehler erkennen oder das Ereignis mit Protokollen oder einer AWS X-Ray -Ablaufverfolgung korrelieren. **Nachrichtenattribute der Warteschlange für unzustellbare Nachrichten** + **RequestID** (Zeichenfolge) – Die ID der Aufrufanforderung. Die Anfrage IDs wird in den Funktionsprotokollen angezeigt. Sie können das X-Ray-SDK auch verwenden, um die Anforderungs-ID für ein Attribut in der Ablaufverfolgung aufzuzeichnen. Anschließend können Sie anhand der Anforderungs-ID in der X-Ray-Konsole nach Spuren suchen. + **ErrorCode**(Nummer) — Der HTTP-Statuscode. + **ErrorMessage**(String) — Die ersten 1 KB der Fehlermeldung. Wenn Lambda keine Nachricht an die Warteschlange für unzustellbare Briefe senden kann, löscht es das Ereignis und gibt die Metrik aus. [DeadLetterErrors](monitoring-metrics-types.md) Dies kann bei mangelnden Berechtigungen passieren oder wenn die Gesamtgröße der Nachricht den Grenzwert der Zielwarteschlange oder des Ziel-Themas überschreitet. Nehmen wir zum Beispiel an, dass eine Amazon-SNS-Benachrichtigung mit einem Text von fast 1 MB eine Funktion auslöst, die zu einem Fehler führt. In diesem Fall können die Ereignisdaten, die Amazon SNS hinzufügt, in Kombination mit den Attributen, die Lambda hinzufügt, dazu führen, dass die Nachricht die maximale Größe überschreitet, die in der Warteschlange für unzustellbare Nachrichten zulässig ist. Wenn Sie Amazon SQS als Ereignisquelle verwenden, konfigurieren Sie eine Warteschlange für unzustellbare Nachrichten für die Amazon-SQS-Warteschlange selbst und nicht für die Lambda-Funktion. Weitere Informationen finden Sie unter [Verwenden von Lambda mit Amazon SQS](with-sqs.md). # Dauerhafte Lambda-Funktionen aufrufen Dauerhafte Lambda-Funktionen können mit den gleichen Methoden wie standardmäßige Lambda-Funktionen aufgerufen werden, allerdings mit wichtigen Überlegungen für lang andauernde Ausführungen. In diesem Abschnitt werden Aufrufmuster, Ausführungsmanagement und bewährte Methoden für langlebige Funktionen behandelt. ## Grenzwerte für synchrone Aufrufe Synchrone Aufrufe dauerhafter Lambda-Funktionen sind auf 15 Minuten begrenzt, genau wie bei Standard-Lambda-Funktionen. Wenn Ihre dauerhafte Funktion länger als 15 Minuten ausgeführt werden muss, muss sie asynchron aufgerufen werden. **Wann sollte der synchrone Aufruf verwendet** werden? Verwenden Sie diesen Befehl für dauerhafte Funktionen, die innerhalb von 15 Minuten abgeschlossen werden, und wenn Sie sofortige Ergebnisse benötigen, z. B. schnelle Genehmigungsworkflows oder kurze Datenverarbeitungsaufgaben. ## Asynchroner Aufruf für Workflows mit langer Laufzeit Verwenden Sie für dauerhafte Funktionen, die länger als 15 Minuten ausgeführt werden können, den asynchronen Aufruf. Dadurch kann die Funktion weiter ausgeführt werden, während Ihr Client sofort eine Bestätigung erhält. ------ #### [ TypeScript ] ``` import { LambdaClient, InvokeCommand } from "@aws-sdk/client-lambda"; const client = new LambdaClient({}); // Asynchronous invocation const command = new InvokeCommand({ FunctionName: "my-durable-function", InvocationType: "Event", // Asynchronous Payload: JSON.stringify({ orderId: "12345" }) }); await client.send(command); ``` ------ #### [ Python ] ``` import boto3 import json client = boto3.client('lambda') # Asynchronous invocation response = client.invoke( FunctionName='my-durable-function', InvocationType='Event', # Asynchronous Payload=json.dumps({'order_id': '12345'}) ) ``` ------ ## Verwaltung der Ausführung APIs Lambda ermöglicht APIs die Verwaltung und Überwachung dauerhafter Funktionsausführungen, einschließlich der Auflistung von Ausführungen, dem Abrufen des Ausführungsstatus und dem Stoppen laufender Ausführungen. ------ #### [ TypeScript ] ``` // Get execution status const statusCommand = new InvokeCommand({ FunctionName: "my-durable-function", InvocationType: "RequestResponse", Payload: JSON.stringify({ action: "getStatus", executionId: "exec-123" }) }); const result = await client.send(statusCommand); ``` ------ #### [ Python ] ``` # Get execution status response = client.invoke( FunctionName='my-durable-function', InvocationType='RequestResponse', Payload=json.dumps({ 'action': 'get_status', 'execution_id': 'exec-123' }) ) ``` ------ # Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet Ein *Zuordnung von Ereignisquellen* ist eine Lambda-Ressource, die Elemente aus Stream- und Warteschlangen-basierten Diensten liest und eine Funktion mit Stapeln von Datensätzen aufruft. Innerhalb einer Zuordnung von Ereignisquellen fragen Ressourcen, sogenannte *Event-Poller*, aktiv nach neuen Nachrichten ab und rufen Funktionen auf. Standardmäßig skaliert Lambda Ereignisabfragen automatisch, aber für bestimmte Ereignisquellentypen können Sie den [Bereitstellungsmodus](#invocation-eventsourcemapping-provisioned-mode) verwenden, um die Mindest- und Höchstanzahl von Event-Pollern zu steuern, die für Ihre Zuordnung von Ereignisquellen vorgesehen sind. Die folgenden Dienste verwenden Zuordnungen von Ereignisquellen, um Lambda-Funktionen aufzurufen: + [Amazon DocumentDB (mit MongoDB-Kompatibilität) (Amazon DocumentDB)](with-documentdb.md) + [Amazon-DynamoDB](with-ddb.md) + [Amazon Kinesis](with-kinesis.md) + [Amazon MQ](with-mq.md) + [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](with-msk.md) + [Selbstverwaltetes Apache Kafka](with-kafka.md) + [Amazon-Simple-Queue-Service (Amazon SQS)](with-sqs.md) **Warnung** Zuordnung von Lambda-Ereignisquellen verarbeiten jedes Ereignis mindestens einmal und es kann zu einer doppelten Verarbeitung von Datensätzen kommen. Um mögliche Probleme im Zusammenhang mit doppelten Ereignissen zu vermeiden, empfehlen wir Ihnen dringend, Ihren Funktionscode idempotent zu machen. Weitere Informationen finden Sie im Knowledge Center unter [Wie mache ich meine Lambda-Funktion idempotent](https://repost.aws/knowledge-center/lambda-function-idempotent)?. AWS ## Wie unterscheiden sich Zuordnungen von Ereignisquellen von direkten Auslösern *Einige AWS-Services können Lambda-Funktionen mithilfe von Triggern direkt aufrufen.* Diese Dienste leiten Ereignisse an Lambda weiter und die Funktion wird sofort aufgerufen, wenn das angegebene Ereignis eintritt. Trigger eignen sich für diskrete Ereignisse und die Verarbeitung in Echtzeit. Wenn Sie [mit der Lambda-Konsole einen Trigger erstellen](lambda-services.md#lambda-invocation-trigger), interagiert die Konsole mit dem entsprechenden AWS Dienst, um die Ereignisbenachrichtigung für diesen Dienst zu konfigurieren. Der Auslöser wird tatsächlich von dem Dienst gespeichert und verwaltet, der die Ereignisse generiert, nicht von Lambda. Hier sind einige Beispiele für Dienste, die Auslöser zum Aufrufen von Lambda-Funktionen verwenden: + **Amazon Simple Storage Service (Amazon S3):** Ruft eine Funktion auf, wenn ein Objekt in einem Bucket erstellt, gelöscht oder geändert wird. Weitere Informationen finden Sie unter [Tutorial: Verwenden eines Amazon-S3-Auslösers zum Aufrufen einer Lambda-Funktion](with-s3-example.md). + **Amazon Simple Notification Service (Amazon SNS):** Ruft eine Funktion auf, wenn eine Nachricht in einem SNS-Thema veröffentlicht wird. Weitere Informationen finden Sie unter [Tutorial: Verwendung AWS Lambda mit Amazon Simple Notification Service](with-sns-example.md). + **Amazon API Gateway:** Ruft eine Funktion auf, wenn eine API-Anfrage an einen bestimmten Endpunkt gestellt wird. Weitere Informationen finden Sie unter [Aufrufen einer Lambda-Funktion über einen Amazon API Gateway-Endpunkt](services-apigateway.md). Zuordnungen von Ereignisquellen sind Lambda-Ressourcen, die innerhalb des Lambda-Service erstellt und verwaltet werden. Zuordnungen von Ereignisquellen sind für die Verarbeitung umfangreicher Streaming-Daten oder Nachrichten aus Warteschlangen konzipiert. Die stapelweise Verarbeitung von Datensätzen aus einem Stream oder einer Warteschlange ist effizienter als die Verarbeitung einzelner Datensätze. ## Batching-Verhalten Standardmäßig batcht eine Ereignisquellenzuordnung Datensätze in einer einzigen Nutzlast, die Lambda an Ihre Funktion sendet. Um das Batching-Verhalten zu optimieren, können Sie ein Batching-Fenster ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) und eine Batch-Größe ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize)) konfigurieren. Ein Batch-Fenster ist die maximale Zeitspanne zur Erfassung von Datensätzen in einer einzigen Nutzlast. Eine Batch-Größe ist die maximale Anzahl von Datensätzen in einem einzigen Batch. Lambda ruft Ihre Funktion auf, wenn eines der folgenden drei Kriterien erfüllt ist: + **Das Batching-Fenster erreicht seinen Maximalwert.** Das standardmäßige Batch-Fensterverhalten unterscheidet sich je nach Ereignisquelle. + **Für Kinesis-, DynamoDB- und Amazon SQS SQS-Ereignisquellen:** Das Standard-Batch-Fenster beträgt 0 Sekunden. Das bedeutet, dass Lambda Ihre Funktion aufruft, sobald Datensätze verfügbar sind. Um ein Batching-Fenster festzulegen, konfigurieren Sie `MaximumBatchingWindowInSeconds`. Sie können diesen Parameter auf einen beliebigen Wert zwischen 0 und 300 Sekunden in Schritten von 1 Sekunde einstellen. Wenn Sie ein Stapelverarbeitungsfenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Funktionsaufruf abgeschlossen ist. + **Für Amazon-MSK-, selbstverwaltete Apache-Kafka-, Amazon-MQ- und Amazon-DocumentDB-Ereignisquellen:** Das standardmäßige Batching-Fenster beträgt 500 ms. Sie können `MaximumBatchingWindowInSeconds` auf einen beliebigen Wert von 0 Sekunden bis 300 Sekunden in Sekundenschritten einstellen. Wenn Sie im Bereitstellungsmodus für Kafka-Zuordnungen von Ereignisquellen ein Batching-Fenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Batch abgeschlossen ist. Wenn Sie ein Batching-Fenster konfigurieren, beginnt das nächste Fenster, sobald der vorherige Funktionsaufruf abgeschlossen ist. Um die Latenz bei der Verwendung von Kafka-Zuordnungen von Ereignisquellen im Bereitstellungsmodus zu minimieren, setzen Sie `MaximumBatchingWindowInSeconds` auf 0. Diese Einstellung stellt sicher, dass Lambda unmittelbar nach Abschluss des aktuellen Funktionsaufrufs mit der Verarbeitung des nächsten Batches beginnt. Weitere Informationen zur Verarbeitung mit niedriger Latenz finden Sie unter [Niedrige Latenz für Apache-Kafka](with-kafka-low-latency.md). + **Für die Ereignisquellen Amazon MQ und Amazon DocumentDB:** Das standardmäßige Batching-Fenster beträgt 500 ms. Sie können `MaximumBatchingWindowInSeconds` auf einen beliebigen Wert von 0 Sekunden bis 300 Sekunden in Sekundenschritten einstellen. Ein Batch-Fenster beginnt, sobald der erste Datensatz eintrifft. **Anmerkung** Da Sie `MaximumBatchingWindowInSeconds` nur in Sekundenschritten ändern können, können Sie nicht zu dem Standard-Batch-Fenster von 500 ms zurückkehren, nachdem Sie es geändert haben. Um das Standard-Batch-Fenster wiederherzustellen, müssen Sie eine neue Ereignisquellenzuordnung erstellen. + **Die Batch-Größe wird erreicht.** Die minimale Batch-Größe beträgt 1. Die Standard- und die maximale Batch-Größe hängen von der Ereignisquelle ab. Weitere Informationen zu diesen Werten finden Sie unter [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize)-Spezifikation für die `CreateEventSourceMapping`-API-Operation. + **Die Nutzlastgröße erreicht [6 MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).** Sie können dieses Limit nicht ändern. Das folgende Diagramm verdeutlicht diese Bedingungen. Angenommen, ein Batch-Fenster beginnt bei `t = 7` Sekunden. Im ersten Szenario erreicht das Batch-Fenster sein Maximum von 40 Sekunden bei `t = 47` Sekunden nach dem Erfassen von 5 Datensätzen. Im zweiten Szenario erreicht die Batch-Größe 10, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster früh endet. Im dritten Szenario wird die maximale Nutzlastgröße erreicht, bevor das Batch-Fenster abläuft, sodass das Batch-Fenster frühzeitig endet. ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/batching-window.png) Wir empfehlen Ihnen, mit verschiedenen Stapel- und Datensatzgrößen zu testen, damit die Abfragefrequenz jeder Ereignisquelle darauf abgestimmt ist, wie schnell Ihre Funktion ihre Aufgabe erledigen kann. Der [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)`BatchSize`Parameter steuert die maximale Anzahl von Datensätzen, die bei jedem Aufruf an Ihre Funktion gesendet werden können. Eine höhere Stapelgröße kann den mit dem Aufruf-Overhead über eine größere Datensatzgruppe hinweg oft effizienter verarbeiten und Ihren Durchsatz erhöhen. Lambda wartet mit dem Senden des nächsten zu verarbeitenden Stapels nicht, bis ggf. konfigurierte [Erweiterungen](lambda-extensions.md) abgeschlossen sind. Anders ausgedrückt: Ihre Erweiterungen werden möglicherweise weiter ausgeführt, während Lambda den nächsten Stapel von Datensätzen verarbeitet. Dies kann zu Drosselungsproblemen führen, wenn Sie gegen eine Einstellung oder gegen einen Grenzwert im Zusammenhang mit der [Parallelität](lambda-concurrency.md) Ihres Kontos verstoßen. Um zu erkennen, ob möglicherweise ein Problem vorliegt, müssen Sie Ihre Funktionen überwachen sowie überprüfen, ob für Ihre Zuordnung von Ereignisquellen unerwartet hohe [Parallelitätsmetriken](monitoring-concurrency.md#general-concurrency-metrics) vorliegen. Aufgrund der kurzen Zeit zwischen den Aufrufen kann Lambda kurzzeitig eine höhere Gleichzeitigkeitsnutzung als die Anzahl der Shards melden. Dies kann sogar für Lambda-Funktionen ohne Erweiterungen gelten. Wenn Ihre Funktion einen Fehler zurückgibt, verarbeitet die Ereignisquellenzuordnung standardmäßig das gesamte Batch erneut, bis die Funktion erfolgreich ist oder die Elemente im Batch ablaufen. Um eine ordnungsgemäße Verarbeitung zu gewährleisten, unterbricht die Ereignisquellenzuordnung die Verarbeitung für den betroffenen Shard, bis der Fehler behoben ist. Für Stream-Quellen (DynamoDB und Kinesis) können Sie die maximale Anzahl von Wiederholungsversuchen von Lambda konfigurieren, wenn Ihre Funktion einen Fehler zurückgibt. Service-Fehler oder Drosselungen, bei denen der Stapel Ihre Funktion nicht erreicht, zählen nicht zu den Wiederholungsversuchen. Sie können die Zuordnung von Ereignisquellen auch so konfigurieren, dass ein Aufrufdatensatz an ein [Ziel](invocation-async-retain-records.md#invocation-async-destinations) gesendet wird, wenn ein Ereignisbatch verworfen wird. ## Modus bereitgestellter Kapazität Lambda-Ereignisquellenzuordnungen verwenden Ereignisabfragen, um Ihre Ereignisquelle nach neuen Nachrichten abzufragen. Standardmäßig verwaltet Lambda die automatische Skalierung dieser Poller auf der Grundlage des Nachrichtenvolumens. Wenn der Nachrichtenverkehr zunimmt, erhöht Lambda automatisch die Anzahl der Event-Poller, um die Last zu bewältigen und reduziert sie, wenn der Verkehr abnimmt. Im Bereitstellungsmodus können Sie den Durchsatz Ihrer Ereignisquellenzuordnung feinabstimmen, indem Sie Mindest- und Höchstgrenzen für dedizierte Abfrageressourcen definieren, die bereit sind, die erwarteten Datenverkehrsmuster zu verarbeiten. Diese Ressourcen werden dreimal schneller automatisch skaliert, um plötzliche Spitzen im Ereignisverkehr zu bewältigen, und bieten eine 16-mal höhere Kapazität zur Verarbeitung von Millionen von Ereignissen. Auf diese Weise können Sie reaktionsschnelle ereignisgesteuerte Workloads mit strengen Leistungsanforderungen erstellen. In Lambda ist ein Event Poller eine Recheneinheit mit Durchsatzmöglichkeiten, die je nach Art der Ereignisquelle variieren. Bei Amazon MSK und selbstverwaltetem Apache Kafka kann jeder Event Poller bis zu 5% MB/sec des Durchsatzes oder bis zu 5 gleichzeitige Aufrufe verarbeiten. Wenn Ihre Ereignisquelle beispielsweise eine durchschnittliche Nutzlast von 1 MB erzeugt und die durchschnittliche Dauer Ihrer Funktion 1 Sekunde beträgt, kann ein einziger Kafka-Event-Poller 5 MB/sec Durchsatz- und 5 gleichzeitige Lambda-Aufrufe unterstützen (vorausgesetzt, es gibt keine Payload-Transformation). Für Amazon SQS kann jeder Event Poller bis zu 1 MB/sec Durchsatz oder bis zu 10 gleichzeitige Aufrufe verarbeiten. Bei der Verwendung des Bereitstellungsmodus fallen zusätzliche Kosten an, die von Ihrer Nutzung des Event-Pollers abhängen. Details zu den Preisen finden Sie unter [AWS Lambda -Preise](https://aws.amazon.com/lambda/pricing/). Der Bereitstellungsmodus ist für Amazon MSK, selbstverwaltete Apache Kafka- und Amazon SQS SQS-Ereignisquellen verfügbar. Während Sie mit den Gleichzeitigkeitseinstellungen die Skalierung Ihrer Funktion steuern können, haben Sie im Bereitstellungsmodus die Kontrolle über den Durchsatz Ihrer Zuordnung von Ereignisquellen. Um eine maximale Leistung zu gewährleisten, müssen Sie möglicherweise beide Einstellungen unabhängig voneinander anpassen. Der Bereitstellungsmodus ist ideal für Echtzeitanwendungen, die eine konstante Latenz bei der Ereignisverarbeitung erfordern, z. B. Finanzdienstleister, die Marktdatenfeeds verarbeiten, E-Commerce-Plattformen, die personalisierte Empfehlungen in Echtzeit bereitstellen, und Spieleunternehmen, die Live-Spielerinteraktionen verwalten. Jeder Event Poller unterstützt unterschiedliche Durchsatzkapazitäten: + Für Amazon MSK und selbstverwalteten Apache Kafka: bis zu 5% Durchsatz oder bis zu 5 MB/sec gleichzeitige Aufrufe + Für Amazon SQS: bis zu 1 MB/sec Durchsatz oder bis zu 10 gleichzeitige Aufrufe oder bis zu 10 SQS-Polling-API-Aufrufe pro Sekunde. Für Amazon SQS SQS-Ereignisquellenzuordnungen können Sie die Mindestanzahl von Pollern zwischen 2 und 200 mit einer Standardeinstellung von 2 und die maximale Anzahl zwischen 2 und 2.000 mit einer Standardeinstellung von 200 festlegen. Lambda skaliert die Anzahl der Event-Poller zwischen Ihrem konfigurierten Minimum und Maximum und fügt schnell bis zu 1.000 Parallelität pro Minute hinzu, um eine konsistente Verarbeitung Ihrer Ereignisse mit niedriger Latenz zu gewährleisten. Für Kafka-Ereignisquellenzuordnungen können Sie die Mindestanzahl von Pollern zwischen 1 und 200 mit dem Standardwert 1 und die Höchstanzahl zwischen 1 und 2.000 mit einem Standardwert von 200 festlegen. Lambda skaliert die Anzahl der Event-Poller auf der Grundlage Ihres Event-Backlogs in Ihrem Thema zwischen Ihrem konfigurierten Minimum und Maximum, um eine Verarbeitung Ihrer Ereignisse mit geringer Latenz zu ermöglichen. Beachten Sie, dass für Amazon SQS SQS-Ereignisquellen die Einstellung für maximale Parallelität nicht im Bereitstellungsmodus verwendet werden kann. Wenn Sie den Bereitstellungsmodus verwenden, steuern Sie die Parallelität über die Einstellung „Maximale Anzahl von Event-Pollers“. Weitere Informationen zur Konfiguration des Bereitstellungsmodus finden Sie in folgenden Abschnitten: + [Konfiguration des Bereitstellungsmodus für Amazon MSK-Ereignisquellenzuordnungen](kafka-scaling-modes.md) + [Konfiguration des Bereitstellungsmodus für selbstverwaltete Apache-Kafka-Ereignisquellen-Zuordnungen](kafka-scaling-modes.md#kafka-provisioned-mode) + [Verwenden des Bereitstellungsmodus mit Amazon SQS SQS-Ereignisquellenzuordnungen](with-sqs.md#sqs-provisioned-mode) Um die Latenz im Bereitstellungsmodus zu minimieren, setzen Sie den Wert auf 0. `MaximumBatchingWindowInSeconds` Diese Einstellung stellt sicher, dass Lambda unmittelbar nach Abschluss des aktuellen Funktionsaufrufs mit der Verarbeitung des nächsten Batches beginnt. Weitere Informationen zur Verarbeitung mit niedriger Latenz finden Sie unter [Niedrige Latenz für Apache-Kafka](with-kafka-low-latency.md). Nachdem Sie den Bereitstellungsmodus konfiguriert haben, können Sie die Verwendung von Event-Pollern für Ihren Workload beobachten, indem Sie die `ProvisionedPollers`-Metrik überwachen. Weitere Informationen finden Sie unter [Metriken zur Zuordnung von Ereignisquellen](monitoring-metrics-types.md#event-source-mapping-metrics). ## API für die Ereignisquellenzuordnung Um eine Ereignisquelle mit der [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) oder einem [AWS -SDK](https://aws.amazon.com/getting-started/tools-sdks/) zu verwalten, können Sie die folgenden API-Operationen verwenden: + [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) + [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html) + [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html) + [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) + [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html) # Verwendung von Tags für Zuordnungen von Ereignisquellen Sie können Zuordnungen von Ereignisquellen taggen, um Ihre Ressourcen zu organisieren und zu verwalten. Tags sind frei formulierte Schlüssel-Wert-Paare, die mit Ihren Ressourcen verknüpft sind und von AWS-Services unterstützt werden. Weitere Informationen zu Anwendungsfällen für Tags finden Sie unter [Allgemeine Tagging-Strategien](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) im *Tagging AWS Resources and Tag Editor Guide*. Zuordnungen von Ereignisquellen sind mit Funktionen verknüpft, die ihre eigenen Tags haben können. Zuordnungen von Ereignisquellen erben nicht automatisch Tags von Funktionen. Sie können die AWS Lambda API verwenden, um Tags anzuzeigen und zu aktualisieren. Sie können auch Tags anzeigen und aktualisieren, während Sie eine bestimmte Ereignisquellenzuordnung in der Lambda-Konsole verwalten, einschließlich solcher, die den Bereitstellungsmodus für Amazon SQS verwenden. ## Erforderliche Berechtigungen zum Arbeiten mit Tags Um einer AWS Identity and Access Management -(IAM)-Identität (Benutzer, Gruppe oder Rolle) das Lesen oder Setzen von Tags auf einer Ressource zu ermöglichen, gewähren Sie ihr die entsprechenden Berechtigungen: + **lambda: ListTags** —Wenn eine Ressource Tags enthält, gewähren Sie diese Berechtigung jedem, der sie aufrufen muss. `ListTags` Für Funktionen mit Tags ist diese Berechtigung auch für `GetFunction` erforderlich. + **lambda: TagResource** —Erteilen Sie diese Berechtigung jedem, der bei create ein Tag aufrufen `TagResource` oder ausführen muss. Optional können Sie erwägen, auch die **lambda: UntagResource** -Berechtigung zu erteilen, um `UntagResource` Aufrufe der Ressource zuzulassen. Weitere Informationen finden Sie unter [Identitätsbasierte IAM-Richtlinien für Lambda](access-control-identity-based.md). ## Verwendung von Tags mit der Lambda-Konsole Sie können die Lambda-Konsole verwenden, um Ereignisquellenzuordnungen mit Tags zu erstellen, Tags zu vorhandenen Ereignisquellenzuordnungen hinzuzufügen und Ereignisquellenzuordnungen nach Tag zu filtern, einschließlich der im Bereitstellungsmodus für Amazon SQS konfigurierten. Wenn Sie einen Auslöser für unterstützte Stream- und Warteschlangen-basierte Dienste über die Lambda-Konsole hinzufügen, erstellt Lambda automatisch eine Zuordnung von Ereignisquellen. Weitere Informationen zu diesen Ereignisquellen finden Sie unter [Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet](invocation-eventsourcemapping.md). Sie benötigen die folgenden Voraussetzungen, um eine Zuordnung von Ereignisquellen in der Konsole zu erstellen: + Eine -Funktion + Eine Ereignisquelle von einem betroffenen Dienst. Sie können die Tags als Teil derselben Benutzeroberfläche hinzufügen, die Sie zum Erstellen oder Aktualisieren von Triggern verwenden. **So fügen Sie ein Tag hinzu, wenn Sie eine Zuordnung von Ereignisquellen erstellen** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen Ihrer Funktion aus. 1. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add trigger (Trigger hinzufügen)**. 1. Wählen Sie unter **Auslöserkonfiguration** in der Dropdownliste den Namen des Dienstes aus, aus dem Ihre Ereignisquelle stammt. 1. Geben Sie die Kernkonfiguration für Ihre Ereignisquelle an. Weitere Informationen zur Konfiguration Ihrer Ereignisquelle finden Sie im Abschnitt für den entsprechenden Dienst unter [Lambda mit Ereignissen aus anderen Diensten aufrufen AWS](lambda-services.md). 1. Wählen Sie unter **Konfiguration der Zuordnung von Ereignisquellen** die Option **Zusätzliche Einstellungen** aus. 1. Wählen Sie unter **Tags** die Option **Neuen Tag hinzufügen** aus 1. Geben Sie im Feld **Schlüssel** Ihren Tag-Schlüssel ein. *Informationen zu Tagging-Einschränkungen finden Sie unter Beschränkungen und Anforderungen für die [Benennung von Tags im Tagging Resources and Tag Editor](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) Guide. AWS * 1. Wählen Sie **Hinzufügen** aus. **So fügen Sie Tags zu einer bestehenden Zuordnung von Ereignisquellen hinzu** 1. Öffnen Sie die [Zuordnungen von Ereignisquellen](https://console.aws.amazon.com/lambda/home#/event-source-mappings) in der Lambda-Konsole. 1. Wählen Sie aus der Ressourcenliste die **UUID** für die Zuordnung von Ereignisquellen aus, die Ihrem **Funktions**- und **Ereignisquellen-ARN** entspricht. 1. Wählen Sie in der Registerkartenliste unter dem **Konfigurationsbereich Allgemein** die Option **Tags**. 1. Wählen Sie **Tags verwalten** aus. 1. Wählen Sie **Neues Tag hinzufügen** aus. 1. Geben Sie im Feld **Schlüssel** Ihren Tag-Schlüssel ein. Informationen zu Einschränkungen beim Taggen finden Sie unter [Beschränkungen und Anforderungen für die Benennung von Tags im Leitfaden für AWS Tag-Ressourcen](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) *und Tag-Editor*. 1. Wählen Sie **Speichern**. **So filtern Sie Zuordnungen von Ereignisquellen nach Tag** 1. Öffnen Sie die [Zuordnungen von Ereignisquellen](https://console.aws.amazon.com/lambda/home#/event-source-mappings) in der Lambda-Konsole. 1. Wählen Sie das Suchfeld. 1. Wählen Sie in der Dropdown-Liste Ihren Tagschlüssel unter der **Tag**-Unterüberschrift aus. 1. Wählen Sie **Verwenden: „Tag-Name“**, um alle Zuordnungen von Ereignisquellen zu sehen, die mit dieser Taste gekennzeichnet sind oder wählen Sie einen **Operator**, um weiter nach Werten zu filtern. 1. Wählen Sie Ihren Tag-Wert aus, um nach einer Kombination aus Tag-Schlüssel und -Wert zu filtern. Das Suchfeld unterstützt auch die Suche nach Tag-Schlüsseln. Geben Sie den Namen eines Schlüssels ein, um ihn in der Liste zu finden. ## Verwenden von Tags mit dem AWS CLI Mit der Lambda-API können Sie Tags zu vorhandenen Lambda-Ressourcen, einschließlich Zuordnungen von Ereignisquellen, hinzufügen und entfernen. Sie können beim Erstellen einer Zuordnung von Ereignisquellen auch Tags hinzufügen, sodass Sie eine Ressource während ihres gesamten Lebenszyklus mit Tags versehen können. ### Aktualisieren von Tags mit dem Lambda-Tag APIs Sie können Tags für unterstützte Lambda-Ressourcen über die [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)und [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API-Operationen hinzufügen und entfernen. Sie können diese Operationen mit der Taste AWS CLI aufrufen. Um Tags einer vorhandenen Ressource hinzuzufügen, verwenden Sie den folgenden `tag-resource`-Befehl. In diesem Beispiel werden zwei Tags hinzugefügt, eines mit dem Schlüssel *Department* und eines mit dem Schlüssel*CostCenter*. ``` aws lambda tag-resource \ --resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \ --tags Department=Marketing,CostCenter=1234ABCD ``` Mit dem Befehl `untag-resource` können Sie Tags entfernen. In diesem Beispiel wird das Tag mit dem Schlüssel entfernt*Department*. ``` aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \ --tag-keys Department ``` ### Hinzufügen von Tags beim Erstellen einer Zuordnung von Ereignisquellen Verwenden Sie die [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)API-Operation, um eine neue Lambda-Ereignisquellenzuordnung mit Tags zu erstellen. Geben Sie den Parameter `Tags` an. Sie können diesen Vorgang mit dem `create-event-source-mapping` AWS CLI Befehl und der `--tags` Option aufrufen. Weitere Informationen zum CLI-Befehl finden Sie [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)in der *AWS CLI Befehlsreferenz*. Vergewissern Sie sich vor der Verwendung des `Tags`-Parameters mit `CreateEventSourceMapping`, dass Ihre Rolle neben den üblichen Berechtigungen, die für diesen Vorgang erforderlich sind, auch die Berechtigung hat, Ressourcen zu taggen. Weitere Informationen zu den Berechtigungen für das Tagging finden Sie unter [Erforderliche Berechtigungen zum Arbeiten mit Tags](#esm-tags-required-permissions). ### Tags mit dem Lambda-Tag anzeigen APIs Um die Tags anzuzeigen, die auf eine bestimmte Lambda-Ressource angewendet werden, verwenden Sie die `ListTags`-API-Operation. Weitere Informationen finden Sie unter [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html). Sie können diesen Vorgang mit dem `list-tags` AWS CLI Befehl aufrufen, indem Sie einen ARN (Amazon Resource Name) angeben. ``` aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier ``` ### Filtern von Ressourcen nach Tag Sie können den AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API-Vorgang verwenden, um Ihre Ressourcen nach Tags zu filtern. Die `GetResources`-Operation empfängt bis zu 10 Filter, wobei jeder Filter einen Tag-Schlüssel und bis zu 10 Tag-Werte enthält. Sie stellen `GetResources` mit einem `ResourceType` zur Verfügung, um nach bestimmten Ressourcentypen zu filtern. Sie können diesen Vorgang mit dem `get-resources` AWS CLI Befehl aufrufen. Beispiele für die Verwendung von `get-resources` finden Sie unter [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) in der *AWS -CLI-Befehlsreferenz*. # Steuern Sie, welche Ereignisse Lambda an Ihre Funktion sendet Sie können die Ereignisfilterung verwenden, um zu steuern, welche Datensätze aus einem Stream oder einer Warteschlange Lambda an Ihre Funktion sendet. Sie können zum Beispiel einen Filter hinzufügen, damit Ihre Funktion nur Amazon-SQS-Nachrichten verarbeitet, die bestimmte Datenparameter enthalten. Die Ereignisfilterung funktioniert nur mit der bestimmten Zuordnung von Ereignisquellen. Sie können den Zuordnungen von Ereignisquellen Filter für Folgendes hinzufügen: AWS-Services + Amazon DynamoDB + Amazon Kinesis Data Streams + Amazon MQ + Amazon Managed Streaming for Apache Kafka (Amazon MSK) + Selbstverwaltetes Apache Kafka + Amazon-Simple-Queue-Service (Amazon SQS) Spezifische Informationen zum Filtern mit bestimmten Ereignisquellen finden Sie unter [Verwenden von Filtern mit unterschiedlichen AWS-Services](#filtering-by-service). Lambda unterstützt keine Ereignisfilterung für Amazon DocumentDB. Standardmäßig können Sie bis zu fünf verschiedene Filter für eine einzelne Zuordnung von Ereignisquellen definieren. Ihre Filter gehören logisch ORed zusammen. Wenn ein Datensatz aus Ihrer Ereignisquelle einen oder mehrere Ihrer Filter erfüllt, nimmt Lambda den Datensatz in das nächste Ereignis auf, das es an Ihre Funktion sendet. Wenn keiner Ihrer Filter erfüllt ist, verwirft Lambda den Datensatz. **Anmerkung** Wenn Sie mehr als fünf Filter für eine Ereignisquelle definieren müssen, können Sie eine Kontingenterhöhung auf bis zu 10 Filter für jede Ereignisquelle beantragen. Wenn Sie versuchen, mehr Filter hinzuzufügen, als Ihr aktuelles Kontingent erlaubt, wird Lambda einen Fehler zurückgeben, wenn Sie versuchen, die Ereignisquelle zu erstellen. **Topics** + [ ## Grundlagen der Ereignisfilterung verstehen ](#filtering-basics) + [ ## Umgang mit Datensätzen, die die Filterkriterien nicht erfüllen ](#filtering-criteria-not-met) + [ ## Filterregelsyntax ](#filtering-syntax) + [ ## Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (Konsole) ](#filtering-console) + [ ## Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (AWS CLI) ](#filtering-cli) + [ ## Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (AWS SAM) ](#filtering-sam) + [ ## Verschlüsselung der Filterkriterien ](#filter-criteria-encryption) + [ ## Verwenden von Filtern mit unterschiedlichen AWS-Services ](#filtering-by-service) ## Grundlagen der Ereignisfilterung verstehen Ein Filterkriterienobjekt (`FilterCriteria`) ist eine Struktur, die aus einer Liste von Filtern (`Filters`) besteht. Jeder Filter ist eine Struktur, die ein Ereignisfiltermuster (`Pattern`) definiert. Ein Muster ist eine Zeichenkette, die eine JSON-Filterregel darstellt. Die Struktur eines `FilterCriteria`-Objekts ist wie folgt. ``` { "Filters": [ { "Pattern": "{ \"Metadata1\": [ rule1 ], \"data\": { \"Data1\": [ rule2 ] }}" } ] } ``` Zur Verdeutlichung sehen Sie hier den Wert des Filter-`Pattern` in reinem JSON. ``` { "Metadata1": [ rule1 ], "data": { "Data1": [ rule2 ] } } ``` Ihr Filtermuster kann Metadateneigenschaften, Dateneigenschaften oder beides enthalten. Die verfügbaren Metadaten-Parameter und das Format der Daten-Parameter variieren je nach dem AWS-Service , der als Ereignisquelle fungiert. Nehmen wir zum Beispiel an, dass Ihre Zuordnung von Ereignisquellen den folgenden Datensatz von einer Amazon-SQS-Warteschlange empfängt: ``` { "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d", "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...", "body": "{\\n \"City\": \"Seattle\",\\n \"State\": \"WA\",\\n \"Temperature\": \"46\"\\n}", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082649183", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082649185" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" } ``` + **Metadateneigenschaften** sind die Felder, die Informationen über das Ereignis enthalten, das den Datensatz erstellt hat. Im Beispiel für den Amazon-SQS-Datensatz umfassen die Metadateneigenschaften Felder wie `messageID`, `eventSourceArn` und `awsRegion`. + **Dateneigenschaften** sind die Felder des Datensatzes, die die Daten aus Ihrem Stream oder Ihrer Warteschlange enthalten. Im Amazon-SQS-Ereignisbeispiel ist der Schlüssel für das Datenfeld `body`, und die Dateneigenschaften sind die Felder `City`, `State` und `Temperature`. Verschiedene Arten von Ereignisquellen verwenden unterschiedliche Schlüsselwerte für ihre Datenfelder. Um nach Dateneigenschaften zu filtern, müssen sie den richtigen Schlüssel in Ihrem Filtermuster verwenden. Eine Liste der Datenfilterschlüssel und Beispiele für Filtermuster für die einzelnen unterstützten AWS-Service Schlüssel finden Sie [Verwenden von Filtern mit unterschiedlichen AWS-Services](#filtering-by-service) unter. Die Ereignisfilterung kann mehrstufige JSON-Filterung verarbeiten. Betrachten Sie zum Beispiel das folgende Fragment eines Datensatzes aus einem DynamoDB-Stream: ``` "dynamodb": { "Keys": { "ID": { "S": "ABCD" } "Number": { "N": "1234" }, ... } ``` Angenommen, Sie möchten nur die Datensätze verarbeiten, bei denen die `Number` des Sortierschlüssels 4567 ist. In diesem Fall würde Ihr `FilterCriteria`-Objekt wie folgt aussehen: ``` { "Filters": [ { "Pattern": "{ \"dynamodb\": { \"Keys\": { \"Number\": { \"N\": [ "4567" ] } } } }" } ] } ``` Zur Verdeutlichung sehen Sie hier den Wert des Filter-`Pattern` in reinem JSON. ``` { "dynamodb": { "Keys": { "Number": { "N": [ "4567" ] } } } } ``` ## Umgang mit Datensätzen, die die Filterkriterien nicht erfüllen Die Art und Weise, wie Lambda mit Datensätzen umgeht, die Ihren Filterkriterien nicht entsprechen, hängt von der Ereignisquelle ab. + Bei **Amazon SQS** entfernt Lambda die Nachricht automatisch aus der Warteschlange, wenn die Nachricht Ihren Filterkriterien nicht entspricht. Sie müssen diese Nachrichten in Amazon SQS nicht manuell löschen. + Bei **Kinesis** und **DynamoDB** schreitet der Stream-Iterator nach der Auswertung eines Datensatzes durch Ihre Filterkriterien über diesen Datensatz hinaus. Wenn der Datensatz Ihre Filterkriterien nicht erfüllt, müssen Sie den Datensatz nicht manuell aus Ihrer Ereignisquelle löschen. Nach Ablauf der Aufbewahrungsfrist löschen Kinesis und DynamoDB diese alten Datensätze automatisch. Wenn Sie möchten, dass Datensätze früher gelöscht werden, lesen Sie [Ändern des Zeitraums der Datenaufbewahrung](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html). + Bei **Amazon MSK-**, **selbstverwalteten Apache-Kafka-** und **Amazon MQ**-Nachrichten verwirft Lambda Nachrichten, die nicht allen im Filter enthaltenen Feldern entsprechen. Bei Amazon MSK und selbstverwaltetem Apache Kafka schreibt Lambda Offsets für übereinstimmende und nicht übereinstimmende Nachrichten fest, nachdem die Funktion erfolgreich aufgerufen wurde. Bei Amazon MQ bestätigt Lambda übereinstimmende Nachrichten nach erfolgreichem Aufruf der Funktion und bestätigt nicht übereinstimmende Nachrichten beim Filtern. ## Filterregelsyntax Für Filterregeln unterstützt Lambda die EventBridge Amazon-Regeln und verwendet dieselbe Syntax wie EventBridge. Weitere Informationen finden Sie unter [Amazon EventBridge Event Patterns](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) im * EventBridge Amazon-Benutzerhandbuch*. Im Folgenden finden Sie eine Zusammenfassung aller Vergleichsoperatoren, die für die Lambda-Ereignisfilterung verfügbar sind. | Vergleichsoperator | Beispiel | Regelsyntax | | --- | --- | --- | | Null | UserID is null | "UserID": [ null ] | | Leer | LastName ist leer | "LastName": [""] | | Gleich | Name is "Alice" | "Name": [ "Alice" ] | | Gleich (Groß-/Kleinschreibung ignorieren) | Name is "Alice" | „Name“: [\$1"equals-ignore-case„: „Alice“\$1] | | Bedingung 2 | Location is "New York" and Day is "Monday" | "Location": [ "New York" ], "Day": ["Monday"] | | Oder | PaymentType ist „Kredit“ oder „Lastschrift“ | "PaymentType„: [„Kredit“, „Lastschrift"] | | Oder (mehrere Felder) | Location is "New York", or Day is "Monday". | "\$1or": [ \$1 "Location": [ "New York" ] \$1, \$1 "Day": [ "Monday" ] \$1 ] | | Nicht | Weather is anything but "Raining" | "Weather": [ \$1 "anything-but": [ "Raining" ] \$1 ] | | Numeric (equals) | Price is 100 | "Price": [ \$1 "numeric": [ "=", 100 ] \$1 ] | | Numeric (range) | Price is more than 10, and less than or equal to 20 | "Price": [ \$1 "numeric": [ ">", 10, "<=", 20 ] \$1 ] | | Vorhanden | ProductName existiert | "ProductName„: [\$1„existiert“: wahr\$1] | | Nicht vorhanden | ProductName existiert nicht | "ProductName„: [\$1„existiert“: falsch\$1] | | Beginnt mit | Region is in the US | "Region": [ \$1"prefix": "us-" \$1 ] | | Endet mit | FileName endet mit der Erweiterung.png. | "FileName„: [\$1„Suffix“: „.png“\$1] | **Anmerkung** Wie bei EventBridge Zeichenketten verwendet Lambda den exakten character-by-character Abgleich ohne Umschaltung der Groß- und Kleinschreibung oder eine andere Normalisierung von Zeichenketten. Bei Zahlen verwendet Lambda auch eine Zeichenfolgendarstellung. 300, 300,0 und 3,0e2 werden z. B. nicht gleich behandelt. Beachten Sie, dass der Exists-Operator nur für Blattknoten in Ihrer JSON-Ereignisquelle funktioniert. Es passt nicht zu Zwischenknoten. Bei der folgenden JSON-Datei `{ "person": { "address": [ { "exists": true } ] } }"` würde das Filtermuster beispielsweise keine Übereinstimmung finden, da es sich um einen Zwischenknoten `"address"` handelt. ``` { "person": { "name": "John Doe", "age": 30, "address": { "street": "123 Main St", "city": "Anytown", "country": "USA" } } } ``` ## Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (Konsole) Führen Sie diese Schritte aus, um eine neue Ereignisquellenzuordnung mit Filterkriterien über die Lambda-Konsole zu erstellen. **Eine neue Ereignisquellenzuordnung mit Filterkriterien erstellen (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen einer Funktion aus, für die eine Ereignisquellenzuordnung erstellt werden soll. 1. Wählen Sie unter **Function overview (Funktionsübersicht)** die Option **Add trigger (Trigger hinzufügen)**. 1. Wählen Sie bei **Trigger configuration** (Auslöserkonfiguration) einen Auslösertyp aus, der Ereignisfilterung unterstützt. Eine Liste der unterstützten Services finden Sie in der Liste am Anfang dieser Seite. 1. Erweitern Sie **Additional settings** (Zusätzliche Einstellungen). 1. Wählen Sie unter **Filter criteria** (Filterkriterien) die Option **Add** (Hinzufügen) aus und definieren Sie anschließend Ihre Filter. Sie können z. B. Folgendes eingeben. ``` { "Metadata" : [ 1, 2 ] } ``` Damit wird Lambda angewiesen, nur Datensätze zu verarbeiten, in denen das Feld `Metadata` gleich 1 oder 2 ist. Sie können weiterhin **Hinzufügen** auswählen, um weitere Filter bis zur maximal zulässigen Anzahl hinzuzufügen. 1. Wenn Sie fertig mit dem Hinzufügen Ihrer Filter sind, klicken Sie auf **Speichern**. Wenn Sie Filterkriterien über die Konsole eingeben, geben Sie nur das Filtermuster ein und müssen weder den `Pattern`-Schlüssel noch Escape-Anführungszeichen angeben. In Schritt 6 der Anweisungen oben entspricht `{ "Metadata" : [ 1, 2 ] }` den folgenden `FilterCriteria`. ``` { "Filters": [ { "Pattern": "{ \"Metadata\" : [ 1, 2 ] }" } ] } ``` Nachdem Sie Ihre Ereignisquellenzuordnung in der Konsole erstellt haben, sehen Sie die formatierten `FilterCriteria` in den Auslöserdetails. Weitere Beispiele zum Erstellen von Ereignisfiltern mithilfe der -Konsole finden Sie unter [Verwenden von Filtern mit unterschiedlichen AWS-Services](#filtering-by-service). ## Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (AWS CLI) Angenommen, Sie möchten, dass eine Ereignisquellenzuordnung folgende hat `FilterCriteria`: ``` { "Filters": [ { "Pattern": "{ \"Metadata\" : [ 1, 2 ] }" } ] } ``` Führen Sie den folgenden Befehl aus, um mithilfe der AWS Command Line Interface (AWS CLI) eine neue Zuordnung der Ereignisquelle mit diesen Filterkriterien zu erstellen. ``` aws lambda create-event-source-mapping \ --function-name my-function \ --event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \ --filter-criteria '{"Filters": [{"Pattern": "{ \"Metadata\" : [ 1, 2 ]}"}]}' ``` Dieser [ create-event-source-mapping](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-event-source-mapping.html)Befehl erstellt eine neue Amazon SQS SQS-Ereignisquellenzuordnung für eine Funktion `my-function` mit dem angegebenen `FilterCriteria` Wert. Führen Sie den folgenden Befehl aus, um diese Filterkriterien zu einer vorhandenen Zuordnung von Ereignisquellen hinzuzufügen. ``` aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --filter-criteria '{"Filters": [{"Pattern": "{ \"Metadata\" : [ 1, 2 ]}"}]}' ``` Beachten Sie, dass Sie zum Aktualisieren einer Ereignisquellenzuordnung ihre UUID benötigen. Sie können die UUID aus einem Anruf abrufen. [ list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) Lambda gibt auch die UUID in der CLI-Antwort zurück. [ create-event-source-mapping](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-event-source-mapping.html) Um Filterkriterien aus einer Ereignisquelle zu entfernen, können Sie den folgenden [ update-event-source-mapping](https://docs.aws.amazon.com/cli/latest/reference/lambda/update-event-source-mapping.html)Befehl mit einem leeren Objekt ausführen. `FilterCriteria` ``` aws lambda update-event-source-mapping \ --uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \ --filter-criteria "{}" ``` Weitere Beispiele für das Erstellen von Ereignisfiltern mithilfe von finden Sie unter[Verwenden von Filtern mit unterschiedlichen AWS-Services](#filtering-by-service). AWS CLI ## Anhängen von Filterkriterien an eine Ereignisquellenzuordnung (AWS SAM) Angenommen, Sie möchten eine Ereignisquelle so konfigurieren AWS SAM , dass sie die folgenden Filterkriterien verwendet: ``` { "Filters": [ { "Pattern": "{ \"Metadata\" : [ 1, 2 ] }" } ] } ``` Um diese Filterkriterien zu Ihrer Zuordnung von Ereignisquellen hinzuzufügen, fügen Sie das folgende Snippet in die YAML-Vorlage für Ihre Ereignisquelle ein. ``` FilterCriteria: Filters: - Pattern: '{"Metadata": [1, 2]}' ``` Weitere Informationen zum Erstellen und Konfigurieren einer AWS SAM Vorlage für eine Ereignisquellenzuordnung finden Sie im [ EventSource](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-eventsource.html)Abschnitt des AWS SAM Entwicklerhandbuchs. Weitere Beispiele für die Erstellung von Ereignisfiltern mithilfe von AWS SAM Vorlagen finden Sie unter[Verwenden von Filtern mit unterschiedlichen AWS-Services](#filtering-by-service). ## Verschlüsselung der Filterkriterien Standardmäßig verschlüsselt Lambda Ihr Filterkriterienobjekt nicht. In Anwendungsfällen, in denen Sie vertrauliche Informationen in Ihr Filterkriterienobjekt aufnehmen können, können Sie diese mit Ihrem eigenen [KMS-Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) verschlüsseln. Nachdem Sie Ihr Filterkriterienobjekt verschlüsselt haben, können Sie seine Klartextversion mithilfe eines [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)API-Aufrufs anzeigen. Sie müssen über `kms:Decrypt`-Berechtigungen verfügen, um die Filterkriterien im Klartext anzeigen zu können. **Anmerkung** Wenn Ihr Filterkriterienobjekt verschlüsselt ist, redigiert Lambda den Wert des `FilterCriteria` Felds in der [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)Antwort auf Aufrufe. Stattdessen wird dieses Feld als `null` angezeigt. Verwenden Sie die API`FilterCriteria`, um den wahren Wert von zu ermitteln. [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html) Um den entschlüsselten Wert von `FilterCriteria` in der Konsole anzuzeigen, stellen Sie sicher, dass Ihre IAM-Rolle Berechtigungen für enthält. [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html) Sie können Ihren eigenen KMS-Schlüssel über die Konsole, API/CLI oder CloudFormation angeben. **Um Filterkriterien mit einem kundeneigenen KMS-Schlüssel zu verschlüsseln (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie **Add trigger**. Wenn Sie bereits über einen vorhandenen Trigger verfügen, wählen Sie die Registerkarte **Konfiguration** und dann **Trigger** aus. Wählen Sie den vorhandenen Auslöser aus und klicken Sie auf **Edit** (Bearbeiten). 1. Aktivieren Sie das Kontrollkästchen neben **Mit dem vom Kunden verwalteten KMS-Schlüssel verschlüsseln**. 1. Wählen Sie für **Wählen Sie einen vom Kunden verwalteten KMS-Verschlüsselungsschlüssel** einen vorhandenen aktivierten Schlüssel aus oder erstellen Sie einen neuen Schlüssel. Je nach Vorgang benötigen Sie einige oder alle der folgenden Berechtigungen: `kms:DescribeKey`, `kms:GenerateDataKey` und `kms:Decrypt`. Verwenden Sie die KMS-Schlüsselrichtlinie, um diese Berechtigungen zu gewähren. Wenn Sie Ihren eigenen KMS-Schlüssel verwenden, müssen die folgenden API-Vorgänge in der [Schlüsselrichtlinie](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) zugelassen sein: + `kms:Decrypt` – Muss dem regionalen Lambda-Serviceprinzipal gewährt werden (`lambda.AWS_region.amazonaws.com`). Dies ermöglicht Lambda die Entschlüsselung von Daten mit diesem KMS-Schlüssel. + Um ein [dienstübergreifendes Problem mit verwirrten Stellvertretern](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) zu vermeiden, verwendet die Schlüsselrichtlinie den [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) globalen Bedingungsschlüssel. Der richtige Wert des `aws:SourceArn`-Schlüssels ist der ARN Ihrer Ressource für die Zuordnung von Ereignisquellen. Sie können ihn also erst dann zu Ihrer Richtlinie hinzufügen, wenn Sie den ARN kennen. Lambda leitet auch die `aws:lambda:FunctionArn`- und `aws:lambda:EventSourceArn`-Schlüssel und ihre jeweiligen Werte im [Verschlüsselungskontext](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) weiter, wenn eine Entschlüsselungsanforderung an KMS gestellt wird. Diese Werte müssen den in der Schlüsselrichtlinie angegebenen Bedingungen entsprechen, damit die Entschlüsselungsanforderung erfolgreich ist. EventSourceArn Für selbstverwaltete Kafka-Ereignisse müssen Sie keine Quellen angeben, da sie keine haben. EventSourceArn + `kms:Decrypt`— Muss auch dem Prinzipal gewährt werden, der beabsichtigt, den Schlüssel zur Anzeige der Klartext-Filterkriterien in [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)unseren API-Aufrufen zu verwenden. [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html) + `kms:DescribeKey` – Stellt die vom Kunden verwalteten Schlüsseldetails bereit, um dem angegebenen Prinzipal die Verwendung des Schlüssels zu ermöglichen. + `kms:GenerateDataKey` – Ermöglicht Lambda die Generierung eines Datenschlüssels zur Verschlüsselung der Filterkriterien im Namen des angegebenen Prinzipals ([Umschlagverschlüsselung](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). Sie können AWS CloudTrail damit AWS KMS Anfragen verfolgen, die Lambda in Ihrem Namen stellt. CloudTrail Beispielereignisse finden Sie unter[Überwachen Ihrer Verschlüsselungsschlüssel für Lambda](security-encryption-at-rest.md#encryption-key-monitoring). Wir empfehlen außerdem, den [https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-via-service](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-via-service)-Bedingungsschlüssel zu verwenden, um die Verwendung des KMS-Schlüssels nur auf Anfragen von Lambda zu beschränken. Der Wert dieses Schlüssels ist der regionale Lambda-Serviceprinzipal (`lambda.AWS_region.amazonaws.com`). Im Folgenden finden Sie ein Beispiel für eine Schlüsselrichtlinie, die alle relevanten Berechtigungen gewährt: **Example AWS KMS wichtige Richtlinie** **** ``` { "Version":"2012-10-17", "Id": "example-key-policy-1", "Statement": [ { "Sid": "Allow Lambda to decrypt using the key", "Effect": "Allow", "Principal": { "Service": "lambda.us-east-1.amazonaws.com" }, "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "ArnEquals" : { "aws:SourceArn": [ "arn:aws:lambda:us-east-1:123456789012:event-source-mapping:" ] }, "StringEquals": { "kms:EncryptionContext:aws:lambda:FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:test-function", "kms:EncryptionContext:aws:lambda:EventSourceArn": "arn:aws:sqs:us-east-1:123456789012:test-queue" } } }, { "Sid": "Allow actions by an AWS account on the key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow use of the key to specific roles", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/ExampleRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "*", "Condition": { "StringEquals" : { "kms:ViaService": "lambda.us-east-1.amazonaws.com" } } } ] } ``` Um Ihren eigenen KMS-Schlüssel zum Verschlüsseln von Filterkriterien zu verwenden, können Sie auch den folgenden [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) AWS CLI Befehl verwenden. Geben Sie den KMS-Schlüssel ARN mit dem `--kms-key-arn`-Flag an. ``` aws lambda create-event-source-mapping --function-name my-function \ --maximum-batching-window-in-seconds 60 \ --event-source-arn arn:aws:sqs:us-east-1:123456789012:my-queue \ --filter-criteria "{\"filters\": [{\"pattern\": \"{\"a\": [\"1\", \"2\"]}\" }]}" \ --kms-key-arn arn:aws:kms:us-east-1:123456789012:key/055efbb4-xmpl-4336-ba9c-538c7d31f599 ``` Wenn Sie bereits über eine Ereignisquellenzuordnung verfügen, verwenden Sie stattdessen den [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) AWS CLI Befehl. Geben Sie den KMS-Schlüssel ARN mit dem `--kms-key-arn`-Flag an. ``` aws lambda update-event-source-mapping --function-name my-function \ --maximum-batching-window-in-seconds 60 \ --event-source-arn arn:aws:sqs:us-east-1:123456789012:my-queue \ --filter-criteria "{\"filters\": [{\"pattern\": \"{\"a\": [\"1\", \"2\"]}\" }]}" \ --kms-key-arn arn:aws:kms:us-east-1:123456789012:key/055efbb4-xmpl-4336-ba9c-538c7d31f599 ``` Dieser Vorgang überschreibt alle zuvor angegebenen KMS-Schlüssel. Wenn Sie das `--kms-key-arn`-Flag zusammen mit einem leeren Argument angeben, verwendet Lambda Ihren KMS-Schlüssel nicht mehr zum Verschlüsseln von Filterkriterien. Stattdessen verwendet Lambda standardmäßig wieder einen Amazon-eigenen Schlüssel. Um Ihren eigenen KMS-Schlüssel in einer CloudFormation Vorlage anzugeben, verwenden Sie die `KMSKeyArn` Eigenschaft des `AWS::Lambda::EventSourceMapping` Ressourcentyps. Sie können beispielsweise das folgende Snippet in die YAML-Vorlage für Ihre Ereignisquelle einfügen. ``` MyEventSourceMapping: Type: AWS::Lambda::EventSourceMapping Properties: ... FilterCriteria: Filters: - Pattern: '{"a": [1, 2]}' KMSKeyArn: "arn:aws:kms:us-east-1:123456789012:key/055efbb4-xmpl-4336-ba9c-538c7d31f599" ... ``` Um Ihre verschlüsselten Filterkriterien in einem [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)oder [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)API-Aufruf im Klartext anzeigen zu können, benötigen Sie entsprechende `kms:Decrypt` Berechtigungen. Ab dem 6. August 2024 wird das `FilterCriteria` Feld nicht mehr in AWS CloudTrail Protokollen von [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html), und [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)API-Aufrufen angezeigt [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html), wenn Ihre Funktion keine Ereignisfilterung verwendet. Wenn Ihre Funktion die Ereignisfilterung verwendet, wird das `FilterCriteria`-Feld als leer (`{}`) angezeigt. Sie können Ihre Filterkriterien in der Antwort auf [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)API-Aufrufe weiterhin im Klartext anzeigen, wenn Sie über `kms:Decrypt` Berechtigungen für den richtigen KMS-Schlüssel verfügen. ### Beispiel für einen CloudTrail Protokolleintrag für Anrufe Create/Update/DeleteEventSourceMapping Im folgenden AWS CloudTrail Beispiel wird ein Protokolleintrag für einen CreateEventSourceMapping Anruf als leer (`{}`) `FilterCriteria` angezeigt, da die Funktion eine Ereignisfilterung verwendet. Dies ist auch dann der Fall, wenn `FilterCriteria`-Objekt gültige Filterkriterien enthält, die Ihre Funktion aktiv verwendet. Wenn die Funktion keine Ereignisfilterung verwendet, CloudTrail wird das `FilterCriteria` Feld in Protokolleinträgen überhaupt nicht angezeigt. ``` { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:userid1", "arn": "arn:aws:sts::123456789012:assumed-role/Example/example-role", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA987654321EXAMPLE", "arn": "arn:aws:iam::123456789012:role/User1", "accountId": "123456789012", "userName": "User1" }, "webIdFederationData": {}, "attributes": { "creationDate": "2024-05-09T20:35:01Z", "mfaAuthenticated": "false" } }, "invokedBy": "AWS Internal" }, "eventTime": "2024-05-09T21:05:41Z", "eventSource": "lambda.amazonaws.com", "eventName": "CreateEventSourceMapping20150331", "awsRegion": "us-east-2", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "eventSourceArn": "arn:aws:sqs:us-east-2:123456789012:example-queue", "functionName": "example-function", "enabled": true, "batchSize": 10, "filterCriteria": {}, "kMSKeyArn": "arn:aws:kms:us-east-2:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "scalingConfig": {}, "maximumBatchingWindowInSeconds": 0, "sourceAccessConfigurations": [] }, "responseElements": { "uUID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "batchSize": 10, "maximumBatchingWindowInSeconds": 0, "eventSourceArn": "arn:aws:sqs:us-east-2:123456789012:example-queue", "filterCriteria": {}, "kMSKeyArn": "arn:aws:kms:us-east-2:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:example-function", "lastModified": "May 9, 2024, 9:05:41 PM", "state": "Creating", "stateTransitionReason": "USER_INITIATED", "functionResponseTypes": [], "eventSourceMappingArn": "arn:aws:lambda:us-east-2:123456789012:event-source-mapping:a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb" }, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ``` ## Verwenden von Filtern mit unterschiedlichen AWS-Services Verschiedene Arten von Ereignisquellen verwenden unterschiedliche Schlüsselwerte für ihre Datenfelder. Um nach Dateneigenschaften zu filtern, müssen sie den richtigen Schlüssel in Ihrem Filtermuster verwenden. In der folgenden Tabelle sind die Filterschlüssel für jeden unterstützten Schlüssel aufgeführt AWS-Service. | AWS-Service | Filterschlüssel | | --- | --- | | DynamoDB | dynamodb | | Kinesis | data | | Amazon MQ | data | | Amazon MSK | value | | Selbstverwaltetes Apache Kafka | value | | Amazon SQS | body | In den folgenden Abschnitten finden Sie Beispiele für Filtermuster für verschiedene Arten von Ereignisquellen. Sie enthalten auch Definitionen der unterstützten Formate für eingehende Daten und Filtermuster für jeden unterstützten Service. + [Verwendung der Ereignisfilterung mit einer DynamoDB-Ereignisquelle](with-ddb-filtering.md) + [Verwendung der Ereignisfilterung mit einer Kinesis-Ereignisquelle](with-kinesis-filtering.md) + [Ereignisse aus einer Amazon MQ-Ereignisquelle filtern](with-mq-filtering.md) + [Filtern von Ereignissen aus Amazon MSK und selbstverwalteten Apache-Kafka-Ereignisquellen](kafka-filtering.md) + [Verwendung der Ereignisfilterung mit einer Amazon-SQS-Ereignisquelle](with-sqs-filtering.md) # Testen von Lambda-Funktionen mit Hilfe der Konsole Sie können Ihre Lambda-Funktion in der Konsole testen, indem Sie Ihre Funktion mit einem Testereignis aufrufen. Ein *Testereignis* ist eine JSON-Eingabe für Ihre Funktion. Wenn Ihre Funktion keine Eingabe erfordert, kann das Ereignis ein leeres Dokument `({})` sein. Wenn Sie einen Test in der Konsole ausführen, ruft Lambda Ihre Funktion synchron mit dem Testereignis auf. Die Funktionslaufzeit konvertiert das Ereignis-JSON in ein Objekt und übergibt es zur Verarbeitung an die Handler-Methode Ihres Codes. **Erstellen Sie ein Testereignis** Bevor Sie in der Konsole testen können, müssen Sie ein privates oder gemeinsam nutzbares Testereignis erstellen. ## Aufrufen von Funktionen mit Testereignissen **So testen Sie eine Funktion** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Klicken Sie auf den Namen der Funktion, die Sie testen möchten. 1. Wählen Sie die Registerkarte **Test**. 1. Wählen Sie unter **Test event** (Testereignis) die Option **Create new event** (Neues Ereignis erstellen) oder **Edit saved event** (Gespeichertes Ereignis bearbeiten) und dann das gespeicherte Ereignis aus, das Sie verwenden möchten. 1. Optional — wählen Sie ein **Template** (Vorlage) für den Event-JSON. 1. Wählen Sie **Test** aus. 1. Erweitern Sie unter **Execution result (Ausführungsergebnis)** die Option **Details**, um die Testergebnisse anzuzeigen. Um Ihre Funktion aufzurufen, ohne Ihr Testereignis zu speichern, wählen Sie **Test (Testen)** vor dem Speichern aus. Dadurch wird ein nicht gespeichertes Testereignis erstellt, das Lambda nur für die Dauer der Sitzung beibehält. Für die Laufzeiten Node.js, Python und Ruby können Sie auf der Registerkarte **Code** auch auf Ihre gespeicherten und nicht gespeicherten Testereignisse zugreifen. Verwenden Sie den Abschnitt **TESTEREIGNISSE**, um Tests zu erstellen, zu bearbeiten und auszuführen. ## Private Testereignisse erstellen Private Testereignisse stehen nur dem Ereignisersteller zur Verfügung und benötigen keine zusätzlichen Berechtigungen zur Verwendung. Sie können bis zu 10 Testereignisse pro Funktion erstellen und speichern. **So erstellen Sie ein privates Testereignis** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Klicken Sie auf den Namen der Funktion, die Sie testen möchten. 1. Wählen Sie die Registerkarte **Test**. 1. Erledigen Sie unter **Testereignis** Folgendes: 1. Wählen Sie eine **Vorlage**. 1. Geben Sie einen **Namen** für den Test an. 1. Geben Sie im Texteingabefeld das JSON-Testereignis ein. 1. Unter **Ereignisfreigabeeinstellungen** wählen Sie **Privat** aus. 1. Wählen Sie **Änderungen speichern ** aus. Für die Laufzeiten von Node.js, Python und Ruby können Sie auf der Registerkarte **Code** auch Testereignisse erstellen. Verwenden Sie den Abschnitt **TESTEREIGNISSE**, um Tests zu erstellen, zu bearbeiten und auszuführen. ## Freigabefähige Testereignisse erstellen Gemeinsam nutzbare Testereignisse sind Testereignisse, die Sie mit anderen Benutzern desselben AWS Kontos teilen können. Sie können die freigabefähigen Testereignisse anderer Benutzer bearbeiten und Ihre Funktion damit aufrufen. Lambda speichert gemeinsam nutzbare Testereignisse als Schemas in einer [Amazon EventBridge (CloudWatch Events) -Schemaregistry](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-registry.html) mit dem Namen. `lambda-testevent-schemas` Da Lambda diese Registry verwendet, um gemeinsam genutzte Testereignisse zu speichern und aufzurufen, empfehlen wir Ihnen nicht, diese Registry zu bearbeiten oder eine Registry mit dem Namen `lambda-testevent-schemas` zu erstellen. Um gemeinsam nutzbare Testereignisse zu sehen, zu teilen und zu bearbeiten, benötigen Sie Berechtigungen für alle der folgenden API-Operationen für die [EventBridge Schemaregistrierung (CloudWatch Ereignisse)](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/operations.html): + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname.html#CreateRegistry](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname.html#CreateRegistry) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#CreateSchema](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#CreateSchema) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#DeleteSchema](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#DeleteSchema) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname-version-schemaversion.html#DeleteSchemaVersion](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname-version-schemaversion.html#DeleteSchemaVersion) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname.html#DescribeRegistry](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname.html#DescribeRegistry) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#DescribeSchema](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#DescribeSchema) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-discover.html#GetDiscoveredSchema](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-discover.html#GetDiscoveredSchema) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname-versions.html#ListSchemaVersions](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname-versions.html#ListSchemaVersions) + [https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#UpdateSchema](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-registries-name-registryname-schemas-name-schemaname.html#UpdateSchema) Beachten Sie, dass das Speichern von Änderungen an einem freigabefähigen Testereignis dieses Ereignis überschreibt. Wenn Sie keine freigabefähigen Testereignisse erstellen, bearbeiten oder anzeigen können, überprüfen Sie, ob Ihr Konto über die erforderlichen Berechtigungen für diese Operationen verfügt. Wenn Sie über die erforderlichen Berechtigungen verfügen, aber immer noch nicht auf gemeinsam nutzbare Testereignisse zugreifen können, suchen Sie nach [ressourcenbasierten Richtlinien](access-control-resource-based.md), die den Zugriff auf die Registrierung EventBridge (CloudWatch Ereignisse) einschränken könnten. **So erstellen Sie ein freigabefähiges Testereignis** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Klicken Sie auf den Namen der Funktion, die Sie testen möchten. 1. Wählen Sie die Registerkarte **Test**. 1. Erledigen Sie unter **Testereignis** Folgendes: 1. Wählen Sie eine **Vorlage**. 1. Geben Sie einen **Namen** für den Test an. 1. Geben Sie im Texteingabefeld das JSON-Testereignis ein. 1. Wählen Sie unter **Event sharing settings (Ereignisfreigabeeinstellungen)** **Shareable (Freigabefähig)** aus. 1. Wählen Sie **Änderungen speichern ** aus. **Verwenden Sie gemeinsam nutzbare Testereignisse mit. AWS Serverless Application Model** Sie können es verwenden AWS SAM , um gemeinsam nutzbare Testereignisse aufzurufen. Siehe [https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/using-sam-cli-remote-test-event.html](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/using-sam-cli-remote-test-event.html) im [Entwicklerhandbuch für AWS Serverless Application Model](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/using-sam-cli-remote-test-event.html) ## Löschen von freigabefähigen Test-Ereignisschemas Wenn Sie freigabefähige Testereignisse löschen, entfernt Lambda sie aus der `lambda-testevent-schemas`-Registry. Wenn Sie das letzte freigabefähige Testereignis aus der Registry entfernen, löscht Lambda die Registry. Wenn Sie die Funktion löschen, löscht Lambda keine verknüpften freigabefähigen Testereignisschemas. Sie müssen diese Ressourcen manuell über die Konsole [EventBridge (CloudWatch Ereignisse)](https://console.aws.amazon.com/events) bereinigen. # Lambda-Funktionszustände Lambda enthält in der Funktionskonfiguration für alle Funktionen ein [Statusfeld](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State), das anzeigt, wann Ihre Funktion zum Aufruf bereit ist. `State` gibt Auskunft über den aktuellen Status der Funktion, einschließlich der Frage, ob Sie die Funktion erfolgreich aufrufen können. Funktionszustände ändern nicht das Verhalten von Funktionsaufrufen oder wie Ihre Funktion den Code ausführt. **Anmerkung** Die Funktionszustandsdefinitionen unterscheiden sich geringfügig für [SnapStart](snapstart.md)Funktionen. Weitere Informationen finden Sie unter [Lambda SnapStart und Funktionszustände](snapstart-activate.md#snapstart-function-states). In vielen Fällen ist eine DynamoDB-Tabelle eine ideale Methode zum Bewahren des Status zwischen Aufrufen, da sie Datenzugriff mit geringer Latenz ermöglicht und mit dem Lambda-Service skaliert werden kann. Sie können Daten auch in [ Amazon EFS for Lambda](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/) speichern, wenn Sie diesen Service verwenden. Dadurch wird ein Zugriff mit geringer Latenz auf den Dateisystemspeicher ermöglicht. Zu den Funktionszustände gehören: + `Pending` – Nachdem Lambda die Funktion erstellt hat, setzt es den Status auf „Ausstehend“. Im Status „Ausstehend“ versucht Lambda, Ressourcen für die Funktion zu erstellen oder zu konfigurieren, beispielsweise VPC- oder EFS-Ressourcen. Lambda ruft während des ausstehenden Status keine Funktion auf. Alle Aufrufe oder andere API-Aktionen, die mit der Funktion arbeiten, schlagen fehl. + `Active` – Ihre Funktion wechselt in den aktiven Status, nachdem Lambda die Ressourcenkonfiguration und -Bereitstellung abgeschlossen hat. Funktionen können nur erfolgreich aufgerufen werden, wenn sie aktiv sind. + `Failed` – Gibt an, dass bei der Ressourcenkonfiguration oder bei der Bereitstellung ein Fehler aufgetreten ist. Wenn die Funktionserstellung fehlschlägt, setzt Lambda den Funktionsstatus auf Fehlgeschlagen, und Sie müssen die Funktion löschen und neu erstellen. + `Inactive` – Eine Funktion wird inaktiv, wenn sie lange genug im Leerlauf war, damit Lambda die externen Ressourcen zurückfordern kann, die für sie konfiguriert wurden. Wenn Sie versuchen, eine Funktion aufzurufen, die inaktiv ist, schlägt der Aufruf fehl und Lambda setzt die Funktion auf den Status „Ausstehend“, bis die Funktionsressourcen neu erstellt werden. Wenn Lambda die Ressourcen nicht neu erstellen kann, kehrt die Funktion in den inaktiven Zustand zurück. Möglicherweise müssen Sie alle Fehler beheben und Ihre Funktion erneut bereitstellen, um sie wieder in den aktiven Zustand zu versetzen. Wenn Sie SDK-basierte Automatisierungsworkflows verwenden oder den Lambda-Service APIs direkt aufrufen, stellen Sie sicher, dass Sie vor dem Aufruf den Status einer Funktion überprüfen, um sicherzustellen, dass sie aktiv ist. Sie können dies mit der Lambda-API-Aktion [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)oder durch die Konfiguration eines Kellners mithilfe des [AWS SDK for Java](https://github.com/aws/aws-sdk-java-v2) 2.0 tun. ``` aws lambda get-function --function-name my-function --query 'Configuration.[State, LastUpdateStatus]' ``` Die Ausgabe sollte folgendermaßen aussehen: ``` [ "Active", "Successful" ] ``` Die folgenden Operationen schlagen fehl, während die Funktionserstellung aussteht: + [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) ## Funktionsstatus während der Aktualisierung Lambda hat zwei Vorgänge zum Aktualisieren von Funktionen: + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html): Aktualisiert das Bereitstellungspaket der Funktion + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html): Aktualisiert die Konfiguration der Funktion Lambda verwendet das [LastUpdateStatus](https://docs.aws.amazon.com/lambda/latest/api/API_FunctionConfiguration.html#lambda-Type-FunctionConfiguration-LastUpdateStatus)Attribut, um den Fortschritt dieser Aktualisierungsvorgänge zu verfolgen. Während ein Update läuft (wenn `"LastUpdateStatus": "InProgress"`): + Der [Status](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) der Funktion bleibt `Active`. + Bei Aufrufen werden weiterhin der vorherige Code und die vorherige Konfiguration der Funktion verwendet, bis die Aktualisierung abgeschlossen ist. + Der folgende Vorgang schlägt fehl: + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) + [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) Wenn ein Update fehlschlägt (wann`"LastUpdateStatus": "Failed"`): + Der [Status](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) der Funktion bleibt `Active`. + Aufrufe verwenden weiterhin den vorherigen Code und die vorherige Konfiguration der Funktion. **Example GetFunctionConfiguration Antwort** Das folgende Beispiel ist das Ergebnis einer [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)Anfrage für eine Funktion, die gerade aktualisiert wird. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function", "Runtime": "nodejs24.x", "VpcConfig": { "SubnetIds": [ "subnet-071f712345678e7c8", "subnet-07fd123456788a036", "subnet-0804f77612345cacf" ], "SecurityGroupIds": [ "sg-085912345678492fb" ], "VpcId": "vpc-08e1234569e011e83" }, "State": "Active", "LastUpdateStatus": "InProgress", ... } ``` # Grundlegendes zum Wiederholungsverhalten in Lambda Wenn Sie eine Funktion direkt aufrufen, bestimmen Sie die Strategie für den Umgang mit Fehlern im Zusammenhang mit dem Funktionscode. Lambda wiederholt diese Art von Fehlern nicht automatisch in Ihrem Namen. Um den Vorgang zu wiederholen, können Sie die Funktion manuell erneut aufrufen, das fehlgeschlagene Ereignis zum Debuggen an eine Warteschlange senden oder den Fehler ignorieren. Der Code Ihrer Funktion wurde möglicherweise vollständig, teilweise oder überhaupt nicht ausgeführt. Wenn Sie es erneut versuchen, stellen Sie sicher, dass der Code Ihrer Funktion das gleiche Ereignis mehrmals verarbeiten kann, ohne doppelte Transaktionen oder andere unerwünschte Nebenwirkungen zu verursachen. Wenn Sie eine Funktion indirekt aufrufen, müssen Sie sich über das Wiederholungsverhalten des Aufrufers und alle Services im Klaren sein, mit denen die Anforderung während des Vorgangs konfrontiert wird. Dies umfasst die folgenden Szenarien. + **Asynchroner Aufruf** – Lambda startet bei Funktionsfehlern zwei Wiederholungsversuche. Wenn die Kapazität der Funktion nicht für die Verarbeitung aller eingehenden Anforderungen ausreicht, verbleiben die an die Funktion zu sendenden Ereignisse möglicherweise stundenlang in der Warteschlange. Sie können für die Funktion eine Warteschlange für unzustellbare Nachrichten konfigurieren, um nicht erfolgreich verarbeitete Ereignisse aufzufangen. Weitere Informationen finden Sie unter [Hinzufügen einer Warteschlange für unzustellbare Nachrichten](invocation-async-retain-records.md#invocation-dlq). + **Ereignisquellen-Mappings** – Ereignisquellen-Mappings, die aus Streams lesen, führen für den gesamten Batch von Elementen einen Wiederholungsversuch durch. Wiederholte Fehlermeldungen blockieren die Verarbeitung des betroffenen Shards, bis der Fehler behoben ist oder die Elemente ablaufen. Zum Erkennen blockierter Shards können Sie die Metrik [Iterator Age](monitoring-metrics.md) überwachen. Für Ereignisquellen-Zuweisungen, die aus einer Warteschlange lesen, bestimmen Sie die Zeitdauer zwischen Wiederholversuchen und dem Ziel für fehlgeschlagene Ereignisse, indem Sie für die Quellwarteschlange die Zeitbeschränkung für die Sichtbarkeit und die Redrive-Richtlinie konfigurieren. Weitere Informationen finden Sie unter [Wie Lambda Datensätze aus Stream- und warteschlangenbasierten Ereignisquellen verarbeitet](invocation-eventsourcemapping.md) und in der servicespezifischen Dokumentation unter [Lambda mit Ereignissen aus anderen Diensten aufrufen AWS](lambda-services.md). + **AWS-Services** – AWS-Services können Ihre Funktion [synchron](invocation-sync.md) oder asynchron aufrufen. Beim synchronen Aufruf entscheidet der Dienst, ob er es erneut versucht. Zum Beispiel wiederholen Amazon-S3-Batch-Operationen den Vorgang, wenn die Lambda-Funktion einen `TemporaryFailure`-Antwortcode zurückgibt. Dienste, die ein Proxy von einem Upstream-Benutzer oder -Kunden anfordert, haben möglicherweise eine Wiederholungsstrategie oder leiten die Fehlerantwort möglicherweise an den Anforderer weiter. Zum Beispiel gibt API Gateway die Fehlerantwort immer an den Anforderer zurück. Bei asynchronen Aufrufen ist die Wiederholungslogik identisch mit der Wiederholungslogik, unabhängig von der Aufrufquelle. Standardmäßig wiederholt Lambda einen fehlgeschlagenen asynchronen Aufruf bis zu zweimal. Weitere Informationen finden Sie unter [Wie Lambda mit Fehlern und Wiederholungsversuchen mit asynchronem Aufruf umgeht](invocation-async-error-handling.md). + **Andere Konten und Clients** – Wenn Sie Zugriff auf andere Konten gewähren, können Sie mithilfe von [ressourcenbasierten Richtlinien](access-control-resource-based.md) einschränken, welche Services und Ressourcen von ihnen zum Aufruf Ihrer Funktion konfiguriert werden können. Zum Schutz Ihrer Funktion vor einer Überlastung sollten Sie Ihrer Funktion mit [Amazon API Gateway](services-apigateway.md) eine API-Ebene vorlagern. Um Sie bei der Handhabung von Fehlern in Lambda-Anwendungen zu unterstützen, ist Lambda in Services wie Amazon CloudWatch und integriert AWS X-Ray. Sie können mithilfe einer Kombination aus Protokollen, Metriken, Alarmen und Ablaufverfolgung Probleme in Funktionscode, API und anderen Ressourcen, die für Ihre Anwendung erforderlich sind, schnell erkennen und aufdecken. Weitere Informationen finden Sie unter [Überwachung, Debbugging und Fehlerbehebung bei Lambda-Funktionen](lambda-monitoring.md). # Verwenden Sie die rekursive Lambda-Schleifenerkennung, um Endlosschleifen zu verhindern Wenn Sie als Ziel für die Ausgabe einer Lambda-Funktion den gleichen Service oder die gleiche Ressource konfigurieren, durch den bzw. durch die die Funktion aufgerufen wird, kann eine unendliche rekursive Schleife entstehen. Ein Beispiel wäre etwa eine Lambda-Funktion, die eine Nachricht in eine Amazon Simple Queue Service (Amazon SQS)-Warteschlange schreibt, die wiederum die gleiche Funktion aufruft. Dieser Aufruf veranlasst die Funktion, eine weitere Nachricht in die Warteschlange zu schreiben, die wiederum erneut die Funktion aufruft. Unbeabsichtigte rekursive Schleifen können dazu führen, dass Ihnen unerwartete Gebühren in Rechnung gestellt werden. AWS-Konto Außerdem können Schleifen dazu führen, dass Lambda [skaliert](lambda-concurrency.md) wird und die gesamte verfügbare Parallelität Ihres Kontos nutzt. Um die Auswirkungen unbeabsichtigter Schleifen zu verringern, erkennt Lambda bestimmte Arten von rekursiven Schleifen kurz nach ihrem Auftreten. Wenn Lambda eine rekursive Schleife erkennt, wird der Aufruf Ihrer Funktion standardmäßig gestoppt und Sie werden benachrichtigt. Wenn Ihr Entwurf bewusst rekursive Muster verwendet, können Sie die Standardkonfiguration einer Funktion so ändern, dass sie rekursiv aufgerufen werden kann. Weitere Informationen finden Sie unter [Zulassen, dass eine Lambda-Funktion in einer rekursiven Schleife ausgeführt wird](#invocation-recursion-disable). **Topics** + [ ## Grundlegendes zur Erkennung rekursiver Schleifen ](#invocation-recursion-concepts) + [ ## Unterstützt AWS-Services und SDKs ](#invocation-recursion-supported) + [ ## Benachrichtigungen zu rekursiven Schleifen ](#invocation-recursion-monitoring) + [ ## Reagieren auf Benachrichtigungen im Zusammenhang mit der Erkennung rekursiver Schleifen ](#invocation-recursion-responding) + [ ## Zulassen, dass eine Lambda-Funktion in einer rekursiven Schleife ausgeführt wird ](#invocation-recursion-disable) + [ ## Unterstützte Regionen für die Erkennung rekursiver Lambda-Schleifen ](#invocation-recursion-regions) ## Grundlegendes zur Erkennung rekursiver Schleifen Zur Erkennung rekursiver Schleifen in Lambda werden Ereignisse nachverfolgt. Lambda ist ein ereignisgesteuerter Compute-Service, der Ihren Funktionscode ausführt, wenn bestimmte Ereignisse auftreten. Ein Beispiel wäre etwa das Hinzufügen eines Elements zu einer Amazon-SQS-Warteschlange oder zu einem Amazon Simple Notification Service (Amazon SNS)-Thema. Ereignisse werden von Lambda als JSON-Objekte mit Informationen zur Änderung des Systemstatus an Ihre Funktion übergeben. Die Ausführung Ihrer Funktion infolge eines Ereignisses wird als *Aufruf* bezeichnet. Zur Erkennung rekursiver Schleifen verwendet Lambda [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)-Ablaufverfolgungs-Header. Wenn [AWS-Services , die die Erkennung rekursiver Schleifen unterstützen](#invocation-recursion-supportedservices), Ereignisse an Lambda senden, werden diese Ereignisse automatisch mit Metadaten versehen. Wenn Ihre Lambda-Funktion eines dieser Ereignisse AWS-Service mithilfe einer [unterstützten Version eines AWS SDK](#invocation-recursion-supportedsdks) in ein anderes Ereignis schreibt, aktualisiert sie diese Metadaten. In den aktualisierten Metadaten ist angegeben, wie oft das Ereignis die Funktion aufgerufen hat. **Anmerkung** Dieses Feature funktioniert ohne Aktivierung der aktiven X-Ray-Ablaufverfolgung. Die Erkennung rekursiver Schleifen ist standardmäßig für alle AWS -Kunden aktiviert. Die Nutzung des Features ist kostenlos. Bei einer *Kette von Anforderungen* handelt es sich um eine Sequenz von Lambda-Aufrufen, die durch das gleiche auslösende Ereignis verursacht werden. Ein Beispiel: Angenommen, eine Amazon-SQS-Warteschlange ruft Ihre Lambda-Funktion auf. Anschließend sendet Ihre Lambda-Funktion das verarbeitete Ereignis an die gleiche Amazon-SQS-Warteschlange zurück und diese ruft wiederum erneut Ihre Funktion auf. In diesem Beispiel gehört jeder Aufruf Ihrer Funktion zur gleichen Kette von Anforderungen. Wenn Ihre Funktion ungefähr 16-mal in der gleichen Kette von Anforderungen aufgerufen wird, beendet Lambda automatisch den nächsten Funktionsaufruf in dieser Anforderungskette und benachrichtigt Sie. Wenn Ihre Funktion mit mehreren Auslösern konfiguriert ist, sind Aufrufe von anderen Auslösern nicht betroffen. **Anmerkung** Selbst wenn die `maxReceiveCount`-Einstellung in der Redrive-Richtlinie der Quellwarteschlange höher als 16 ist, verhindert der Lambda-Rekursionsschutz nicht, dass Amazon SQS die Nachricht erneut versucht, nachdem eine rekursive Schleife erkannt und beendet wurde. Wenn Lambda eine rekursive Schleife erkennt und nachfolgende Aufrufe abbricht, gibt es ein `RecursiveInvocationException` an die Zuordnung von Ereignisquellen zurück. Dadurch wird der `receiveCount`-Wert in der Nachricht erhöht. Lambda versucht weiterhin, die Nachricht zu wiederholen, und blockiert weiterhin Funktionsaufrufe, bis Amazon SQS feststellt, dass das `maxReceiveCount` überschritten wurde, und die Nachricht an die konfigurierte Warteschlange für unzustellbare Nachrichten sendet. Wenn Sie für Ihre Funktion ein [Ziel bei Ausfall](invocation-async-retain-records.md#invocation-async-destinations) oder eine [Warteschlange für unzustellbare Nachrichten](invocation-async-retain-records.md#invocation-dlq) konfiguriert haben, sendet Lambda das Ereignis aus dem beendeten Aufruf auch an Ihr Ziel oder an die Warteschlange für unzustellbare Nachrichten. Wenn Sie für Ihre Funktion ein Ziel oder eine Warteschlange für unzustellbare Nachrichten konfigurieren, achten Sie darauf, keinen Ereignisauslöser und keine Zuordnung von Ereignisquellen zu verwenden, die Ihre Funktion auch verwendet. Wenn Sie Ereignisse an die Ressource senden, die auch Ihre Funktion aufruft, können Sie eine weitere rekursive Schleife erstellen und diese Schleife wird auch beendet. Wenn Sie die Rekursionsschleifenerkennung deaktivieren, wird diese Schleife nicht beendet. ## Unterstützt AWS-Services und SDKs Lambda kann nur rekursive Schleifen erkennen, die bestimmte unterstützte enthalten. AWS-Services Damit rekursive Schleifen erkannt werden können, muss Ihre Funktion auch eine der unterstützten Schleifen verwenden. AWS SDKs ### Unterstützt AWS-Services Lambda erkennt derzeit rekursive Schleifen zwischen Funktionen, Amazon SQS, Amazon S3 und Amazon SNS. Außerdem erkennt Lambda Schleifen, die nur aus Lambda-Funktionen bestehen, die sich synchron oder asynchron gegenseitig aufrufen. Die folgenden Diagramme zeigen einige Beispiele für Schleifen, die von Lambda erkannt werden: ![\[Diagramme rekursiver Schleifen zwischen einer Lambda-Funktion, Amazon SNS, Amazon S3 und einer Amazon-SQS-Warteschlange.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/RunawayWorkloadDetected_v3.png) Wenn ein anderes AWS-Service System wie Amazon DynamoDB Teil der Schleife ist, kann Lambda es derzeit nicht erkennen und stoppen. Da Lambda derzeit nur rekursive Schleifen erkennt, an denen Amazon SQS, Amazon S3 und Amazon SNS beteiligt sind, ist es immer noch möglich, dass Schleifen, an denen andere beteiligt sind, zu einer unbeabsichtigten Nutzung Ihrer Lambda-Funktionen führen AWS-Services können. Um zu verhindern, dass Ihnen unerwartete Gebühren in Rechnung gestellt werden AWS-Konto, empfehlen wir Ihnen, [ CloudWatchAmazon-Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) so zu konfigurieren, dass Sie auf ungewöhnliche Nutzungsmuster aufmerksam gemacht werden. Sie können beispielsweise so konfigurieren, dass Sie über CloudWatch Spitzenwerte bei der Parallelität oder bei Aufrufen von Lambda-Funktionen benachrichtigt werden. Des Weiteren können Sie einen [Abrechnungsalarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html) konfigurieren, um benachrichtigt zu werden, wenn die Ausgaben für Ihr Konto einen von Ihnen angegebenen Schwellenwert übersteigen. Eine weitere Möglichkeit ist die Verwendung der [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/cost-management/latest/userguide/manage-ad.html), um über ungewöhnliche Abrechnungsmuster informiert zu werden. ### Unterstützt AWS SDKs Damit Lambda rekursive Schleifen erkennt, muss Ihre Funktion eine der folgenden SDK-Mindestversionen verwenden: | Laufzeit | Minimale erforderliche AWS SDK-Version | | --- | --- | | Node.js | 2.1147.0 (SDK-Version 2) 3.105.0 (SDK-Version 3) | | Python | 1.24.46 (boto3) 1.27.46 (botocore) | | Java 8 und Java 11 | 2.17.135 | | Java 17 | 2,20,81 | | Java 21 | 2,21,24 | | .NET | 3,7,293,0 | | Ruby | 3,134,0 | | PHP | 3,232,0 | | Go | V2 SDK 1.57.0 | Einige Lambda-Laufzeiten wie Python und Node.js enthalten eine Version des AWS SDK. Wenn die in der Laufzeit Ihrer Funktion enthaltene SDK-Version kleiner ist als die erforderliche Mindestversion, können Sie dem Bereitstellungspaket Ihrer Funktion eine unterstützte Version des SDK hinzufügen. Sie können auch eine [Lambda-Ebene](chapter-layers.md) verwenden, um Ihrer Funktion eine unterstützte SDK-Version hinzuzufügen. Eine Liste der in jeder Lambda-Laufzeit SDKs enthaltenen Funktionen finden Sie unter[Lambda-Laufzeiten](lambda-runtimes.md). ## Benachrichtigungen zu rekursiven Schleifen Wenn Lambda eine rekursive Schleife beendet, erhalten Sie Benachrichtigungen über das [Health Dashboard](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/) und per E-Mail. Sie können auch CloudWatch Metriken verwenden, um die Anzahl der rekursiven Aufrufe zu überwachen, die Lambda gestoppt hat. ### Health Dashboard Benachrichtigungen Wenn Lambda einen rekursiven Aufruf stoppt, wird auf der Seite „**Ihr Kontostatus**“ unter „[Offene Probleme“ und](https://health.aws.amazon.com/health/home#/account/dashboard/open-issues) „Aktuelle Probleme“ eine Benachrichtigung Health Dashboard angezeigt. Beachten Sie, dass es nach der Beendigung eines rekursiven Aufrufs durch Lambda bis zu 3,5 Stunden dauern kann, bis diese Benachrichtigung angezeigt wird. Weitere Informationen zum Anzeigen von Kontoereignissen in der Health Dashboard finden Sie unter [Erste Schritte mit Ihrem AWS Health Dashboard — Ihr Kontostatus](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) im *AWS Health-Benutzerhandbuch*. ### E-Mail-Benachrichtigungen Wenn Lambda zum ersten Mal einen rekursiven Aufruf Ihrer Funktion beendet, erhalten Sie eine E-Mail-Benachrichtigung. Für jede Funktion in Ihrem AWS-Konto wird alle 24 Stunden maximal eine E-Mail gesendet. Nachdem Lambda eine E-Mail-Benachrichtigung gesendet hat, erhalten Sie für einen Zeitraum von 24 Stunden keine E-Mails mehr zu dieser Funktion. Das gilt auch, wenn Lambda weitere rekursive Aufrufe der Funktion beendet. Beachten Sie, dass es nach der Beendigung eines rekursiven Aufrufs durch Lambda bis zu 3,5 Stunden dauern kann, bis Sie diese E-Mail-Benachrichtigung erhalten. Lambda sendet rekursive Loop-E-Mail-Benachrichtigungen an Ihren primären AWS-Konto Kundenkontakt und an den alternativen Betriebskontakt. Informationen zum Anzeigen oder Aktualisieren der E-Mail-Adressen in Ihrem Konto finden Sie in der *allgemeinen AWS -Referenz* unter [Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html). ### CloudWatch Amazon-Metriken Die [CloudWatch Metrik](monitoring-metrics-types.md) `RecursiveInvocationsDropped` zeichnet die Anzahl der Funktionsaufrufen auf, die Lambda gestoppt hat, weil Ihre Funktion in einer einzigen Anforderungskette mehr als etwa 16 Mal aufgerufen wurde. Lambda gibt diese Metrik aus, sobald ein rekursiver Aufruf beendet wurde. Um diese Metrik anzuzeigen, folgen Sie den Anweisungen unter [Metriken anzeigen auf der CloudWatch Konsole und wählen Sie die](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html#monitoring-metrics-console) Metrik aus. `RecursiveInvocationsDropped` ## Reagieren auf Benachrichtigungen im Zusammenhang mit der Erkennung rekursiver Schleifen Wenn Ihre Funktion etwa mehr als 16-mal durch das gleiche auslösende Ereignis aufgerufen wird, beendet Lambda den nächsten Funktionsaufruf für dieses Ereignis, um die rekursive Schleife zu unterbrechen. Gehen Sie wie folgt vor, um zu verhindern, dass eine rekursive Schleife, die von Lambda unterbrochen wurde, erneut auftritt: + Reduzieren Sie die verfügbare [Parallelität](lambda-concurrency.md) Ihrer Funktion auf Null. Dadurch werden alle zukünftigen Aufrufe gedrosselt. + Entfernen oder deaktivieren Sie den Auslöser oder die Zuordnung von Ereignisquellen, der bzw. die Ihre Funktion aufruft. + Identifizieren und beheben Sie Codefehler, die Ereignisse in die AWS Ressource zurückschreiben, die Ihre Funktion aufruft. Eine Fehlerquelle entsteht häufig, wenn die Ereignisquelle und das Ziel einer Funktion mithilfe von Variablen definiert werden. Achten Sie darauf, nicht für beide Variablen den gleichen Wert zu verwenden. Wenn die Ereignisquelle für Ihre Lambda-Funktion eine Amazon-SQS-Warteschlange ist, empfiehlt es sich außerdem gegebenenfalls, für die Quellwarteschlange [eine Warteschlange für unzustellbare Nachrichten zu konfigurieren](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue.html). **Anmerkung** Achten Sie darauf, die Warteschlange für unzustellbare Nachrichten für die Quellwarteschlange und nicht für die Lambda-Funktion zu konfigurieren. Die Warteschlange für unzustellbare Nachrichten, die Sie für eine Funktion konfigurieren, wird für die [Warteschlange asynchroner Aufrufe](invocation-async.md) der Funktion und nicht für Ereignisquellen-Warteschlangen verwendet. Wenn es sich bei der Ereignisquelle um ein Amazon-SNS-Thema handelt, empfiehlt es sich gegebenenfalls, für Ihre Funktion ein [Ziel bei Ausfall](invocation-async-retain-records.md#invocation-async-destinations) hinzuzufügen. **So reduzieren Sie die verfügbare Parallelität Ihrer Funktion auf Null (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen Ihrer Funktion aus. 1. Wählen Sie **Drosseln** aus. 1. Wählen Sie im Dialogfeld **Funktion drosseln** die Option **Bestätigen** aus. **So entfernen Sie einen Auslöser oder eine Zuordnung von Ereignisquellen für Ihre Funktion (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen Ihrer Funktion aus. 1. Wählen Sie die Registerkarte **Konfiguration** und anschließend **Auslöser** aus. 1. Wählen Sie unter **Auslöser** den Auslöser oder die Zuordnung von Ereignisquellen aus, den bzw. die Sie löschen möchten, und wählen Sie anschließend **Löschen** aus. 1. Wählen Sie im Dialogfeld **Auslöser löschen** die Option **Löschen** aus. **So deaktivieren Sie eine Zuordnung von Ereignisquellen für Ihre Funktion (AWS CLI)** 1. Führen Sie den Befehl AWS Command Line Interface (AWS CLI) aus, um die UUID für die Ereignisquellenzuordnung zu finden, die Sie deaktivieren möchten. [list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/list-event-source-mappings.html) ``` aws lambda list-event-source-mappings ``` 1. Führen Sie den folgenden AWS CLI [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html)Befehl aus, um die Zuordnung der Ereignisquellen zu deaktivieren. ``` aws lambda update-event-source-mapping --function-name MyFunction \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 --no-enabled ``` ## Zulassen, dass eine Lambda-Funktion in einer rekursiven Schleife ausgeführt wird Wenn Ihr Entwurf absichtlich eine rekursive Schleife verwendet, können Sie eine Lambda-Funktion so konfigurieren, dass sie rekursiv aufgerufen werden kann. Wir empfehlen, dass Sie rekursive Schleifen in Ihrem Entwurf vermeiden. Implementierungsfehler können dazu führen, dass rekursive Aufrufe Ihre gesamte verfügbare Parallelität nutzen und dass Ihrem AWS-Konto Konto unerwartete Gebühren in Rechnung gestellt werden. **Wichtig** Wenn Sie rekursive Schleifen verwenden, sollten Sie diese mit Vorsicht behandeln. Implementieren Sie bewährte Leitplanken, um das Risiko von Implementierungsfehlern zu minimieren. Weitere Informationen zu bewährten Methoden für die Verwendung rekursiver Muster finden Sie bei Serverless Land unter [Recursive patterns that cause run-away Lambda functions](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/recursive-runaway). Mithilfe der Lambda-Konsole, der AWS Command Line Interface (AWS CLI) und der API können Sie Funktionen so konfigurieren, dass sie rekursive Schleifen zulassen. [PutFunctionRecursionConfig](https://docs.aws.amazon.com//lambda/latest/api/API_PutFunctionRecursionConfig.html) Sie können auch die Einstellung für die Erkennung rekursiver Schleifen einer Funktion in und konfigurieren. AWS SAM CloudFormation Standardmäßig erkennt und beendet Lambda rekursive Schleifen. Sofern Ihr Entwurf nicht bewusst eine rekursive Schleife verwendet, empfehlen wir Ihnen, die Standardkonfiguration Ihrer Funktionen nicht zu ändern. Beachten Sie, dass die [CloudWatch Metrik](monitoring-metrics-types.md#invocation-metrics) `RecursiveInvocationsDropped` nicht ausgegeben wird, wenn Sie eine Funktion so konfigurieren, dass sie rekursive Schleifen zulässt. ------ #### [ Console ] **So können Sie eine Funktion in einer rekursiven Schleife ausführen (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen Ihrer Funktion, um die Funktionsdetailseite zu öffnen. 1. Wählen Sie die Registerkarte **Konfiguration** und anschließend **Gleichzeitigkeit und Rekursionserkennung**. 1. Wählen Sie neben **Rekursive Schleifenerkennung** die Option **Bearbeiten** aus. 1. Wählen Sie **Rekursive Schleifen zulassen** aus. 1. Wählen Sie **Speichern**. ------ #### [ AWS CLI ] Sie können die [PutFunctionRecursionConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionRecursionConfig.html)API verwenden, um zu ermöglichen, dass Ihre Funktion in einer rekursiven Schleife aufgerufen wird. Geben Sie `Allow` als Parameter für die rekursive Schleife an. Sie können diese API beispielsweise mit dem folgenden Befehl aufrufen: `put-function-recursion-config` AWS CLI ``` aws lambda put-function-recursion-config --function-name yourFunctionName --recursive-loop Allow ``` ------ Sie können die Konfiguration Ihrer Funktion auf die Standardeinstellung zurücksetzen, sodass Lambda rekursive Schleifen beendet, wenn es sie erkennt. Bearbeiten Sie die Konfiguration Ihrer Funktion mit der Lambda-Konsole oder dem AWS CLI. ------ #### [ Console ] **So konfigurieren Sie eine Funktion so, dass rekursive Schleifen abgebrochen werden (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen Ihrer Funktion, um die Funktionsdetailseite zu öffnen. 1. Wählen Sie die Registerkarte **Konfiguration** und anschließend **Gleichzeitigkeit und Rekursionserkennung**. 1. Wählen Sie neben **Rekursive Schleifenerkennung** die Option **Bearbeiten** aus. 1. Wählen Sie **Rekursive Schleifen beenden** aus. 1. Wählen Sie **Speichern**. ------ #### [ AWS CLI ] Sie können die [PutFunctionRecursionConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionRecursionConfig.html)API verwenden, um Ihre Funktion so zu konfigurieren, dass Lambda rekursive Schleifen beendet, wenn es sie erkennt. Geben Sie `Terminate` als Parameter für die rekursive Schleife an. Sie können diese API beispielsweise mit dem folgenden Befehl aufrufen: `put-function-recursion-config` AWS CLI ``` aws lambda put-function-recursion-config --function-name yourFunctionName --recursive-loop Terminate ``` ------ ## Unterstützte Regionen für die Erkennung rekursiver Lambda-Schleifen Die Lambda-Rekursivschleifenerkennung wird in allen [Handelsregionen](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region) außer Mexiko (Zentral) und Asien-Pazifik (Neuseeland) unterstützt. # Lambda-Funktion erstellen und verwalten URLs Eine Funktions-URL ist ein dedizierter HTTPS-Endpunkt für Ihre Lambda-Funktion. Sie können eine Funktions-URL über die Lambda-Konsole oder die Lambda-API erstellen und konfigurieren. **Tipp** Lambda bietet zwei Möglichkeiten, Ihre Funktion über einen HTTP-Endpunkt aufzurufen: function URLs und Amazon API Gateway. Wenn Sie sich nicht sicher sind, welche Methode für Ihren Anwendungsfall am besten geeignet ist, siehe [Wählen Sie eine Methode, um Ihre Lambda-Funktion über eine HTTP-Anfrage aufzurufen](furls-http-invoke-decision.md). Wenn Sie eine Funktions-URL erstellen, generiert Lambda automatisch einen eindeutigen URL-Endpunkt für Sie. Sobald Sie eine Funktions-URL erstellt haben, ändert sich ihr URL-Endpunkt nie mehr. Funktions-URL-Endpunkte haben das folgende Format: ``` https://.lambda-url..on.aws ``` **Anmerkung** Funktionen URLs werden in den folgenden Ländern nicht unterstützt AWS-Regionen: Asien-Pazifik (Hyderabad) (`ap-south-2`), Asien-Pazifik (Melbourne) (`ap-southeast-4`), Asien-Pazifik (Malaysia`ap-southeast-5`) (), Asien-Pazifik (Neuseeland) (`ap-southeast-6`), Asien-Pazifik (Thailand) (`ap-southeast-7`), Asien-Pazifik (Taipeh`ap-east-2`) (), Kanada West (Calgary`ca-west-1`) (), Europa (Spanien) (`eu-south-2`), Europa (Zürich) (`eu-central-2`), Israel (Tel Aviv) (`il-central-1`) und Naher Osten (VAE) (`me-central-1`). URLs Die Funktionen sind Dual-Stack-fähig, unterstützen IPv4 und IPv6. Nachdem Sie eine Funktions-URL für Ihre Funktion konfiguriert haben, können Sie Ihre Funktion über ihren HTTP(S)-Endpunkt über einen Webbrowser, curl, Postman oder einen beliebigen HTTP-Client aufrufen. **Anmerkung** Auf Ihre Funktions-URL können Sie nur über das öffentliche Internet zugreifen. Lambda-Funktionen unterstützen zwar AWS PrivateLink, Funktionen jedoch URLs nicht. Die Lambda-Funktion URLs verwendet [ressourcenbasierte Richtlinien](access-control-resource-based.md) für Sicherheit und Zugriffskontrolle. Die Funktion unterstützt URLs auch CORS-Konfigurationsoptionen (Cross-Origin Resource Sharing). Sie können die Funktion URLs auf einen beliebigen Funktionsalias oder auf die `$LATEST` unveröffentlichte Funktionsversion anwenden. Sie können keiner anderen Funktionsversion eine Funktions-URL hinzufügen. Der folgende Abschnitt zeigt, wie Sie eine Funktions-URL mithilfe der Lambda-Konsole AWS CLI, und -Vorlage erstellen und CloudFormation verwalten **Topics** + [ ## Erstellen einer Funktions-URL (Konsole) ](#create-url-console) + [ ## Erstellen einer Funktions-URL (AWS CLI) ](#create-url-cli) + [ ## Hinzufügen einer Funktions-URL zu einer CloudFormation Vorlage ](#urls-cfn) + [ ## Cross-Origin Resource Sharing (CORS) ](#urls-cors) + [ ## Drosselungsfunktion URLs ](#urls-throttling) + [ ## Funktion wird deaktiviert URLs ](#urls-deactivating) + [ ## Funktion löschen URLs ](#w2aac39c81c53) + [ # Steuern Sie den Zugriff auf die Lambda-Funktion URLs ](urls-auth.md) + [ # Aufrufen von Lambda-Funktions-URLs ](urls-invocation.md) + [ # Überwachen der Lambda-Funktions-URLs ](urls-monitoring.md) + [ # Wählen Sie eine Methode, um Ihre Lambda-Funktion über eine HTTP-Anfrage aufzurufen ](furls-http-invoke-decision.md) + [ # Tutorial: Erstellen eines Webhook-Endpunkts mithilfe einer Lambda-Funktions-URL ](urls-webhook-tutorial.md) ## Erstellen einer Funktions-URL (Konsole) Gehen Sie wie folgt vor, um eine Funktions-URL mit der Konsole zu erstellen. ### So erstellen Sie eine Funktions-URL für eine vorhandene Funktion 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen der Funktion, für die Sie die Funktions-URL erstellen möchten. 1. Wählen Sie die Registerkarte **Konfiguration** und dann **Funktions-URL**. 1. Wählen Sie **Funktions-URL erstellen**. 1. **Wählen Sie **als Authentifizierungstyp **AWS\$1IAM****oder NONE.** Weitere Informationen zur Authentifizierung der Funktions-URL finden Sie unter [Zugriffskontrolle](urls-auth.md). 1. (Optional) Wählen Sie **Configure cross-origin resource sharing (CORS)** (Cross-Origin Resource Sharing (CORS) konfigurieren) aus und konfigurieren Sie dann die CORS-Einstellungen für Ihre Funktions-URL. Weitere Informationen über CORS finden Sie unter [Cross-Origin Resource Sharing (CORS)](#urls-cors). 1. Wählen Sie **Speichern**. Dies erstellt eine Funktions-URL für die `$LATEST` unveröffentlichte Version Ihrer Funktion. Die Funktions-URL wird im Abschnitt **Function overview** (Funktionsübersicht) der Konsole angezeigt. ### So erstellen Sie eine Funktions-URL für einen vorhandenen Alias 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen der Funktion mit dem Alias, für die Sie die Funktions-URL erstellen möchten. 1. Wählen Sie die Registerkarte **Aliase** und wählen Sie dann den Namen der Funktion mit dem Alias, für die Sie die Funktions-URL erstellen möchten. 1. Wählen Sie die Registerkarte **Konfiguration** und dann **Funktions-URL**. 1. Wählen Sie **Funktions-URL erstellen**. 1. **Wählen Sie **als Authentifizierungstyp **AWS\$1IAM****oder NONE.** Weitere Informationen zur Authentifizierung der Funktions-URL finden Sie unter [Zugriffskontrolle](urls-auth.md). 1. (Optional) Wählen Sie **Configure cross-origin resource sharing (CORS)** (Cross-Origin Resource Sharing (CORS) konfigurieren) aus und konfigurieren Sie dann die CORS-Einstellungen für Ihre Funktions-URL. Weitere Informationen über CORS finden Sie unter [Cross-Origin Resource Sharing (CORS)](#urls-cors). 1. Wählen Sie **Speichern**. Dies erstellt eine Funktions-URL für Ihren Funktionsalias. Die Funktions-URL wird im Abschnitt **Funktionsübersicht** der Konsole für Ihren Alias angezeigt. ### So erstellen Sie eine neue Funktion mit einem Funktions-URL **So erstellen Sie eine neue Funktion mit einer Funktions-URL (Konsole)** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie **Funktion erstellen**. 1. Führen Sie unter **Basic information** (Grundlegende Informationen) die folgenden Schritte aus: 1. Geben Sie unter **Funktionsname** einen Namen für Ihre Funktion ein, z. B. **my-function**. 1. Wählen Sie für **Runtime** die Laufzeitsprache aus, die Sie bevorzugen, z. B. **Node.js 24.** 1. Wählen Sie für **Architecture** (Architektur) entweder **x86\$164** oder **arm64** aus. 1. Erweitern Sie **Permissions** (Berechtigungen) und wählen Sie dann aus, ob eine neue Ausführungsrolle erstellt oder eine vorhandene Rolle verwendet werden soll. 1. Erweitern Sie **Advanced settings** (Erweiterte Einstellungen) und wählen Sie dann **Funktions-URL** aus. 1. Wählen Sie für **Auth type **AWS\$1IAM****oder **NONE**. Weitere Informationen zur Authentifizierung der Funktions-URL finden Sie unter [Zugriffskontrolle](urls-auth.md). 1. (Optional) Wählen Sie **Cross-Origin Resource Sharing (CORS) konfigurieren** aus. Wenn Sie diese Option während der Funktionserstellung auswählen, lässt Ihre Funktions-URL standardmäßig sämtliche Anfragen zu. Sie können die CORS-Einstellungen für Ihre Funktions-URL bearbeiten, nachdem Sie die Funktion erstellt haben. Weitere Informationen über CORS finden Sie unter [Cross-Origin Resource Sharing (CORS)](#urls-cors). 1. Wählen Sie **Funktion erstellen**. Dies erstellt eine neue Funktions mit einer Funktions-URL für die `$LATEST` unveröffentlichte Version Ihrer Funktion. Die Funktions-URL wird im Abschnitt **Function overview** (Funktionsübersicht) der Konsole angezeigt. ## Erstellen einer Funktions-URL (AWS CLI) Führen Sie den folgenden Befehl aus, um eine Funktions-URL für eine bestehende Lambda-Funktion mithilfe von AWS Command Line Interface (AWS CLI) zu erstellen: ``` aws lambda create-function-url-config \ --function-name my-function \ --qualifier prod \ // optional --auth-type AWS_IAM --cors-config {AllowOrigins="https://example.com"} // optional ``` Dies fügt eine Funktions-URL zum **prod**-Qualifizierer für die Funktion**my-function** hinzu. Weitere Informationen zu diesen Konfigurationsparametern finden Sie unter [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) in der API-Referenz. **Anmerkung** Um eine Funktions-URL über die zu erstellen AWS CLI, muss die Funktion bereits existieren. ## Hinzufügen einer Funktions-URL zu einer CloudFormation Vorlage Verwenden Sie die folgende Syntax, um Ihrer CloudFormation Vorlage eine `AWS::Lambda::Url` Ressource hinzuzufügen: ### JSON ``` { "Type" : "AWS::Lambda::Url", "Properties" : { "AuthType" : String, "Cors" : Cors, "Qualifier" : String, "TargetFunctionArn" : String } } ``` ### YAML ``` Type: AWS::Lambda::Url Properties: AuthType: String Cors: Cors Qualifier: String TargetFunctionArn: String ``` ### Parameters + (Erforderlich) `AuthType` – Definiert den Typ der Authentifizierung für Ihre Funktions-URL. Die möglichen Werte sind `AWS_IAM` oder `NONE`. Um den Zugriff nur auf authentifizierte Benutzer zu beschränken, setzen Sie den Wert auf `AWS_IAM`. Um die IAM-Authentifizierung zu umgehen und jedem Benutzer zu erlauben, Anfragen an Ihre Funktion zu stellen, setzten Sie dies auf `NONE`. + (Optional)`Cors` – Definiert die [CORS-Einstellungen](#urls-cors) für Ihre Funktions-URL. Verwenden Sie `Cors` die folgende Syntax CloudFormation, um Ihrer `AWS::Lambda::Url` Ressource in etwas hinzuzufügen. **Example AWS::Lambda::Url.Cors (JSON)** ``` { "AllowCredentials" : Boolean, "AllowHeaders" : [ String, ... ], "AllowMethods" : [ String, ... ], "AllowOrigins" : [ String, ... ], "ExposeHeaders" : [ String, ... ], "MaxAge" : Integer } ``` **Example AWS::Lambda::Url.Cors (YAML)** ``` AllowCredentials: Boolean AllowHeaders: - String AllowMethods: - String AllowOrigins: - String ExposeHeaders: - String MaxAge: Integer ``` + (Optional) `Qualifier` – Der Aliasname. + (Erforderlich) `TargetFunctionArn` – Der Name oder der Amazon-Ressourcenname (ARN) der Lambda-Funktion. Gültige Namensformate sind unter anderem: + **Funktionsname** – `my-function`. + **Funktions-ARN** – `arn:aws:lambda:us-west-2:123456789012:function:my-function`. + **Partiellet ARN** – `123456789012:function:my-function`. ## Cross-Origin Resource Sharing (CORS) Um zu definieren, wie verschiedene Ursprünge auf Ihre Funktions-URL zugreifen können, verwenden Sie [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Wir empfehlen, CORS zu konfigurieren, wenn Sie beabsichtigen, Ihre Funktions-URL von einer anderen Domain aus aufzurufen. Lambda unterstützt die folgenden CORS-Header für Funktionen. URLs | CORS-Header | CORS-Konfigurationseigenschaft | Beispielwerte | | --- | --- | --- | | [ Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) | `AllowOrigins` | `*` (alle Ursprünge zulassen) `https://www.example.com` `http://localhost:60905` | | [ Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods) | `AllowMethods` | `GET`, `POST`, `DELETE`, `*` | | [ Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) | `AllowHeaders` | `Date`, `Keep-Alive`, `X-Custom-Header` | | [ Access-Control-Expose-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers) | `ExposeHeaders` | `Date`, `Keep-Alive`, `X-Custom-Header` | | [ Access-Control-Allow-Credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials) | `AllowCredentials` | `TRUE` | | [ Access-Control-Max-Age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age) | `MaxAge` | `5` (Standard), `300` | Wenn Sie CORS für eine Funktions-URL mithilfe der Lambda-Konsole oder der konfigurieren AWS CLI, fügt Lambda über die Funktions-URL automatisch die CORS-Header zu allen Antworten hinzu. Alternativ können Sie Ihrer Funktionsantwort manuell CORS-Header hinzufügen. Wenn es widersprüchliche Header gibt, ist das erwartete Verhalten abhängig vom Typ der Anfrage: + Bei Preflight-Anfragen wie OPTIONS-Anfragen haben die konfigurierten CORS-Header auf der Funktions-URL Vorrang. Lambda gibt nur diese CORS-Header in der Antwort zurück. + Bei Nicht-Preflight-Anforderungen wie GET- oder POST-Anforderungen gibt Lambda sowohl die konfigurierten CORS-Header der Funktions-URL als auch die von der Funktion zurückgegebenen CORS-Header zurück. Dies kann zu doppelten CORS-Header in der Antwort führen. Möglicherweise wird ein Fehler ähnlich dem folgenden angezeigt: `The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed`. Im Allgemeinen empfehlen wir, alle CORS-Einstellungen auf der Funktions-URL zu konfigurieren, anstatt CORS-Header manuell in der Funktionsantwort zu senden. ## Drosselungsfunktion URLs Die Drosselungsrate begrenzt die Geschwindigkeit, mit der Ihre Funktion Anfragen verarbeitet. Dies ist in vielen Situationen nützlich, z. B. um zu verhindern, dass Ihre Funktion nachgelagerte Ressourcen überlastet, oder beim Verarbeiten eines plötzlichen Anstiegs der Anfragen. Sie können die Rate der Anfragen, die Ihre Lambda-Funktion über eine Funktions-URL verarbeitet, drosseln, indem Sie die reservierte Gleichzeitigkeit konfigurieren. Reservierte Gleichzeitigkeit begrenzt die Anzahl der maximalen gleichzeitigen Aufrufe für Ihre Funktion. Die maximale Anforderungsrate Ihrer Funktion pro Sekunde (RPS) entspricht dem Zehnfachen der konfigurierten reservierten Gleichzeitigkeit. Wenn Sie Ihre Funktion beispielsweise mit einer reservierten Gleichzeitigkeit von 100 konfigurieren, beträgt der maximale RPS 1 000. Immer wenn Ihre Funktionsparallelität die reservierte Gleichzeitigkeit überschreitet, gibt Ihre Funktions-URL einen HTTP-`429`-Statuscode zurück. Wenn Ihre Funktion eine Anforderung erhält, die das 10-fache RPS-Maximum basierend auf Ihrer konfigurierten reservierten Gleichzeitigkeit überschreitet, erhalten Sie auch einen HTTP-`429`-Fehler. Weitere Hinweise zur reservierten Gleichzeitigkeit finden Sie unter [Konfigurieren reservierter Gleichzeitigkeit für eine Funktion](configuration-concurrency.md). ## Funktion wird deaktiviert URLs Im Notfall sollten Sie den gesamten Datenverkehr zu Ihrer Funktions-URL ablehnen. Um eine Funktion zu deaktivieren, setzen Sie die reservierte Gleichzeitigkeit auf Null. Dies drosselt alle Anfragen an Ihre Funktions-URL, was zu HTTP-`429`-Statusantworten führt. Um Ihre Funktions-URL zu reaktivieren, löschen Sie die Konfiguration für die reservierte Gleichzeitigkeit oder legen Sie die Konfiguration auf einen Betrag größer als null fest. ## Funktion löschen URLs Wenn Sie eine Funktions-URL löschen, können Sie sie nicht wiederherstellen. Das Erstellen einer neuen Funktions-URL führt zu einer anderen URL-Adresse. **Anmerkung** Wenn Sie Ihre Funktions-URL mit Authentifizierungstyp `NONE` löschen, löscht Lambda nicht automatisch die zugehörige ressourcenbasierte Richtlinie. Wenn Sie diese Richtlinie löschen möchten, müssen Sie dies manuell tun. 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen einer Funktion aus. 1. Wählen Sie die Registerkarte **Konfiguration** und dann **Funktions-URL**. 1. Wählen Sie **Löschen** aus. 1. Geben Sie den Ausdruck *delete* (löschen) in das Feld ein, um den Löschvorgang zu bestätigen. 1. Wählen Sie **Löschen** aus. **Anmerkung** Wenn Sie eine Funktion löschen, die eine Funktions-URL hat, löscht Lambda asynchron die Funktions-URL. Wenn Sie sofort eine neue Funktion mit demselben Namen im selben Konto erstellen, ist es möglich, dass die ursprüngliche Funktions-URL auf die neue Funktion abgebildet wird, anstatt gelöscht zu werden. # Steuern Sie den Zugriff auf die Lambda-Funktion URLs **Anmerkung** Ab Oktober 2025 sind für neue Funktionen URLs sowohl Genehmigungen als auch `lambda:InvokeFunctionUrl` `lambda:InvokeFunction` Genehmigungen erforderlich. Sie können den Zugriff auf Ihre Lambda-Funktion URLs mithilfe des [AuthType](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html#lambda-CreateFunctionUrlConfig-request-AuthType)Parameters in Kombination mit [ressourcenbasierten Richtlinien steuern, die an Ihre spezifische Funktion angehängt sind](access-control-resource-based.md). Die Konfiguration dieser beiden Komponenten bestimmt, wer andere administrative Aktionen für Ihre Funktions-URL aufrufen oder ausführen kann. Der `AuthType`-Parameter bestimmt, wie Lambda Anfragen an Ihre Funktions-URL authentifiziert oder autorisiert. Wenn Sie Ihre Funktions-URL konfigurieren, müssen Sie eine der folgenden `AuthType`-Optionen angeben: + `AWS_IAM`— Lambda verwendet AWS Identity and Access Management (IAM), um Anfragen auf der Grundlage der Identitätsrichtlinie des IAM-Prinzipals und der ressourcenbasierten Richtlinie der Funktion zu authentifizieren und zu autorisieren. Wählen Sie diese Option, wenn Sie möchten, dass nur authentifizierte -Benutzer und -Rollen Ihre Funktion über die Funktions-URL aufrufen können. + `NONE` – Lambda führt keine Authentifizierung durch, bevor Sie Ihre Funktion aufrufen. Die ressourcenbasierte Richtlinie Ihrer Funktion ist jedoch immer in Kraft und muss öffentlichen Zugriff gewähren, bevor Ihre Funktions-URL Anfragen erhalten kann. Wählen Sie diese Option, um öffentlichen, nicht authentifizierten Zugriff auf Ihre Funktions-URL zu ermöglichen. Für zusätzliche Einblicke in die Sicherheit können Sie eine umfassende Analyse des externen AWS Identity and Access Management Access Analyzer Zugriffs auf Ihre Funktions-URL nutzen. IAM Access Analyzer überwacht auch auf neue oder aktualisierte Berechtigungen für Ihre Lambda-Funktionen, um Berechtigungen zu identifizieren, die öffentlichen und kontoübergreifenden Zugriff gewähren. Sie können IAM Access Analyzer kostenlos nutzen. Weitere Informationen zu den ersten Schritten mit IAM Access Analyzer finden Sie unter [Verwenden des AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Diese Seite enthält Beispiele für ressourcenbasierte Richtlinien für beide Authentifizierungstypen und wie diese Richtlinien mithilfe des [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)API-Vorgangs oder der Lambda-Konsole erstellt werden. Informationen darüber, wie Sie Ihre Funktions-URL aufrufen können, nachdem Sie Berechtigungen eingerichtet haben, finden Sie unter [Aufrufen von Lambda-Funktions-URLs](urls-invocation.md). **Topics** + [ ## Verwenden des Auth-Typs `AWS_IAM` ](#urls-auth-iam) + [ ## Verwenden des Authentifizierungstyps `NONE` ](#urls-auth-none) + [ ## Governance und Zugriffskontrolle ](#urls-governance) ## Verwenden des Auth-Typs `AWS_IAM` Wenn Sie den Authentifizierungstyp `AWS_IAM` auswählen, müssen Benutzer, die Ihre Lambda-Funktions-URL aufrufen, die Berechtigungen `lambda:InvokeFunctionUrl` und `lambda:InvokeFunction` haben. Je nachdem, wer die Aufrufanforderung stellt, müssen Sie diese Berechtigung möglicherweise mithilfe einer [ressourcenbasierten Richtlinie](access-control-resource-based.md) erteilen. Wenn sich der Principal, der die Anfrage stellt, in derselben URL befindet AWS-Konto wie die Funktions-URL, muss der Principal **entweder** über `lambda:InvokeFunctionUrl` `lambda:InvokeFunction` Berechtigungen in seiner [identitätsbasierten Richtlinie verfügen **oder** ihm in der ressourcenbasierten Richtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) der Funktion Berechtigungen erteilt worden sein. Mit anderen Worten, eine ressourcenbasierte Richtlinie ist optional, wenn der Benutzer bereits die Berechtigungen `lambda:InvokeFunctionUrl` und `lambda:InvokeFunction` in seiner identitätsbasierten Richtlinie hat. Die Richtlinienbewertung folgt den Regeln, die in der [Auswertungslogik für Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) beschrieben sind. Wenn der Prinzipal, der die Anfrage stellt, in einem anderen Konto ist, muss der Prinzipal **sowohl** eine identitätsbasierte Richtlinie haben, die ihm die Berechtigungen `lambda:InvokeFunctionUrl` und `lambda:InvokeFunction` gewährt, **als auch** Berechtigungen, die ihm in einer ressourcenbasierten Richtlinie für die Funktion gewährt werden, die er aufrufen möchte. Die Richtlinienbewertung folgt den im Abschnitt [Festlegen, ob eine kontoübergreifende Anforderung zulässig ist](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html#policy-eval-cross-account) erläuterten Regeln. Die folgende ressourcenbasierte Richtlinie ermöglicht es der `example` Rolle in, die der Funktion AWS-Konto `444455556666` zugeordnete Funktions-URL aufzurufen. `my-function` Der Schlüssel [lambda: InvokedViaFunctionUrl](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html#lambda-AddPermission-request-InvokedViaFunctionUrl) context beschränkt die `lambda:InvokeFunction` Aktion auf URL-Aufrufe von Funktionen. Das bedeutet, dass der Prinzipal die Funktions-URL verwenden muss, um die Funktion aufzurufen. Wenn Sie `lambda:InvokedViaFunctionUrl` nicht einfügen, kann der Prinzipal Ihre Funktion zusätzlich zur Funktions-URL auch über andere Aufrufmethoden aufrufen. **Example – Kontoübergreifende ressourcenbasierte Richtlinie** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action": "lambda:InvokeFunctionUrl", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function", "Condition": { "Bool": { "lambda:InvokedViaFunctionUrl": "true" } } } ] } ``` Sie können diese ressourcenbasierte Richtlinie über die Konsole erstellen, indem Sie die folgenden Schritte ausführen: **So erteilen Sie einem anderen Konto (Konsole) URL-Aufrufberechtigungen** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie den Namen der Funktion aus, für die Sie URL-Aufrufberechtigungen gewähren möchten. 1. Wählen Sie die Registerkarte **Konfiguration** und dann **Berechtigungen** aus. 1. Wählen Sie unter **Resource-based policy** (Ressourcenbasierte Richtlinie) die Option **Add permissions** (Berechtigungen hinzufügen) aus. 1. Wählen Sie **Funktions-URL** aus. 1. Wählen Sie für **Auth type die Option. **AWS\$1IAM**** 1. Geben Sie eine **Anweisungs-ID** für Ihre Richtlinienanweisung ein. 1. Geben Sie unter **Prinzipal** den Amazon-Ressourcennamen (ARN) des Benutzers oder der Rolle ein, dem bzw. der Sie Berechtigungen gewähren möchten. Beispiel: **444455556666**. 1. Wählen Sie **Speichern**. Alternativ können Sie diese Richtlinie mit den folgenden [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) AWS Command Line Interface (AWS CLI) -Befehlen erstellen. Wenn Sie die verwenden AWS CLI, müssen Sie die `lambda:InvokeFunction` Anweisungen `lambda:InvokeFunctionUrl` und separat hinzufügen. Beispiel: ``` aws lambda add-permission --function-name my-function \ --statement-id UrlPolicyInvokeURL \ --action lambda:InvokeFunctionUrl \ --principal 444455556666 \ --function-url-auth-type AWS_IAM ``` ``` aws lambda add-permission --function-name my-function \ --statement-id UrlPolicyInvokeFunction \ --action lambda:InvokeFunction \ --principal 444455556666 \ --invoked-via-function-url ``` ## Verwenden des Authentifizierungstyps `NONE` **Wichtig** Wenn Ihre Funktions-URL-Auth-Typ `NONE` ist und Sie eine [ressourcenbasierte Richtlinie](access-control-resource-based.md) haben, die öffentlichen Zugriff gewährt, kann jeder nicht authentifizierte Benutzer mit Ihrer Funktions-URL Ihre Funktion aufrufen. In einigen Fällen möchten Sie möglicherweise, dass Ihre Funktions-URL öffentlich ist. So können Sie beispielsweise Anfragen direkt von einem Webbrowser aus bereitstellen. Um den öffentlichen Zugriff auf Ihre Funktions-URL zu ermöglichen, wählen Sie den Auth-Typ `NONE` aus. Wenn Sie den Auth-Typ `NONE` auswählen, verwendet Lambda IAM nicht, um Anfragen an Ihre Funktions-URL zu authentifizieren. Ihre Funktion muss jedoch über eine ressourcenbasierte Richtlinie verfügen, die `lambda:InvokeFunctionUrl` und `lambda:InvokeFunction` erlaubt. Wenn Sie `NONE` mithilfe der Konsole oder AWS Serverless Application Model (AWS SAM) eine Funktions-URL mit dem Authentifizierungstyp erstellen, erstellt Lambda automatisch die ressourcenbasierte Richtlinie für Sie. Wenn Sie die AWS CLI AWS CloudFormation, oder die Lambda-API direkt verwenden, müssen Sie [die Richtlinie selbst hinzufügen](#policy-cli). Wir empfehlen, dass Sie den InvokedViaFunctionUrl Kontextschlüssel [lambda:](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html#lambda-AddPermission-request-InvokedViaFunctionUrl) in Ihre ressourcenbasierten Richtlinien aufnehmen, wenn Sie den Authentifizierungstyp verwenden. `NONE` Dieser Kontextschlüssel stellt sicher, dass die Funktion nur über die Funktions-URL und nicht über andere Aufrufmethoden aufgerufen werden kann. Beachten Sie die folgenden Informationen über diese Richtlinie: + Alle Entitäten können `lambda:InvokeFunctionUrl` und `lambda:InvokeFunction` aufrufen. Das bedeutet, dass jeder, der Ihre Funktions-URL hat, Ihre Funktion aufrufen kann. + Der Wert des `lambda:FunctionUrlAuthType`-Bedingungsschlüssels ist `NONE`. Das bedeutet, dass diese Richtlinienanweisung den Zugriff nur erlaubt, wenn der Authentifizierungstyp Ihrer Funktions-URL ebenfalls `NONE` ist. + Die Bedingung `lambda:InvokedViaFunctionUrl` stellt sicher, dass die Funktion nur über die Funktions-URL und nicht über andere Aufrufmethoden aufgerufen werden kann. **Example – Ressourcenbasierte Standardrichtlinie für den Authentifizierungstyp NONE** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "FunctionURLAllowPublicAccess", "Effect": "Allow", "Principal": "*", "Action": "lambda:InvokeFunctionUrl", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } }, { "Sid": "FunctionURLInvokeAllowPublicAccess", "Effect": "Allow", "Principal": "*", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Condition": { "Bool": { "lambda:InvokedViaFunctionUrl": "true" } } } ] } ``` **Erstellen Sie die ressourcenbasierte Richtlinie mithilfe des AWS CLI** Sofern Sie nicht die Konsole verwenden oder AWS SAM eine Funktions-URL mit Authentifizierungstyp erstellen`NONE`, müssen Sie die ressourcenbasierte Richtlinie selbst hinzufügen. Verwenden Sie die folgenden Befehle zur Erstellung von Anweisungen für die Berechtigungen `lambda:InvokeFunctionUrl` und `lambda:InvokeFunction`. Jede Anweisung muss in einem separaten Befehl hinzugefügt werden. ``` aws lambda add-permission \ --function-name UrlTestFunction \ --statement-id UrlPolicyInvokeURL \ --action lambda:InvokeFunctionUrl \ --principal * \ --function-url-auth-type NONE ``` ``` aws lambda add-permission \ --function-name UrlTestFunction \ --statement-id UrlPolicyInvokeFunction \ --action lambda:InvokeFunction \ --principal * \ --invoked-via-function-url ``` **Anmerkung** Wenn Sie Ihre Funktions-URL mit Authentifizierungstyp `NONE` löschen, löscht Lambda nicht automatisch die zugehörige ressourcenbasierte Richtlinie. Wenn Sie diese Richtlinie löschen möchten, müssen Sie dies manuell tun. Wenn die ressourcenbasierte Richtlinie einer Funktion die Berechtigungen `lambda:invokeFunctionUrl` und `lambda:InvokeFunction` nicht gewährt, dann erhalten Benutzer einen 403-Forbidden-Fehlercode beim Versuch, Ihre Funktions-URL aufzurufen. Das geschieht auch dann, wenn die Funktions-URL den Authentifizierungstyp `NONE` verwendet. ## Governance und Zugriffskontrolle Neben den Zugriffsberechtigungen für den Aufruf von Funktions-URLs können Sie auch den Zugriff auf Aktionen steuern, die zur Konfiguration der Funktion URLs verwendet werden. Lambda unterstützt die folgenden IAM-Richtlinienaktionen für die Funktion: URLs + `lambda:InvokeFunctionUrl` – Ruft eine Lambda-Funktion mit der Funktions-URL auf. + `lambda:CreateFunctionUrlConfig` – Erstellt eine Funktions-URL und legt ihren `AuthType` fest. + `lambda:UpdateFunctionUrlConfig` – Aktualisiert eine Funktions-URL-Konfiguration und ihren `AuthType`. + `lambda:GetFunctionUrlConfig` – Zeigt die Details einer Funktions-URL an. + `lambda:ListFunctionUrlConfigs` – Listet die Funktions-URL-Konfigurationen auf. + `lambda:DeleteFunctionUrlConfig` – Löscht eine Funktions-URL. Um anderen AWS Entitäten den Zugriff auf Funktions-URLs zu gewähren oder zu verweigern, nehmen Sie diese Aktionen in die IAM-Richtlinien auf. Die folgende Richtlinie gewährt der `example` Rolle in beispielsweise AWS-Konto `444455556666` Berechtigungen zur Aktualisierung der Funktions-URL für die Funktion **my-function** im Konto`123456789012`. **Example Kontoübergreifende Funktions-URL-Richtlinie** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action": "lambda:UpdateFunctionUrlConfig", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function" } ] } ``` ### Bedingungsschlüssel Für eine detaillierte Zugriffskontrolle auf Ihre Funktion verwenden Sie URLs Bedingungskontexttasten. Lambda unterstützt die folgenden Kontexttasten für Funktionen URLs: + `lambda:FunctionUrlAuthType` – Definiert einen Aufzählungswert, der den Authentifizierungstyp beschreibt, den Ihre Funktions-URL verwendet. Der Wert kann entweder `AWS_IAM` oder `NONE` sein. + `lambda:InvokedViaFunctionUrl` – Beschränkt die Aktion `lambda:InvokeFunction` auf Aufrufe, die über die Funktions-URL getätigt werden. Das stellt sicher, dass die Funktion nur über die Funktions-URL und nicht über andere Aufrufmethoden aufgerufen werden kann. Beispiele für ressourcenbasierte Richtlinien, die den Kontextschlüssel `lambda:InvokedViaFunctionUrl` verwenden, finden Sie in den Beispielen unter [Verwenden des Auth-Typs `AWS_IAM`](#urls-auth-iam) und [Verwenden des Authentifizierungstyps `NONE`](#urls-auth-none). Sie können diese Kontextschlüssel in Richtlinien verwenden, die mit Ihrer Funktion verknüpft sind. Beispielsweise möchten Sie möglicherweise einschränken, wer Konfigurationsänderungen an Ihrer Funktion URLs vornehmen kann. Um alle `UpdateFunctionUrlConfig`-Anfragen an jede Funktion mit dem URL-Auth-Typ `NONE` zu verweigern, können Sie die folgende Richtlinie definieren: **Example Funktions-URL-Richtlinie mit expliziter Zugriffsverweigerung** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action":[ "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:us-east-1:123456789012:function:*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } } ] } ``` Um der `example` Rolle AWS-Konto `444455556666` Berechtigungen zum Erstellen `CreateFunctionUrlConfig` und `UpdateFunctionUrlConfig` Anfordern von Funktionen mit URL-Authentifizierungstyp zu gewähren`AWS_IAM`, können Sie die folgende Richtlinie definieren: **Example Funktions-URL-Richtlinie mit expliziter Zulassung** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action":[ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:us-east-1:123456789012:function:*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } } ] } ``` Sie können diesen Bedingungsschlüssel auch in einer [Service-Kontrollrichtlinie](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) verwenden. Wird verwendet SCPs , um Berechtigungen für eine gesamte Organisation in AWS Organizations zu verwalten. Verwenden Sie beispielsweise die folgende Dienststeuerungsrichtlinie, um Benutzern URLs das Erstellen oder Aktualisieren von Funktionen zu verbieten, die `AWS_IAM` etwas anderes als den Authentifizierungstyp verwenden: **Example Funktions-URL-SCP mit expliziter Zugriffsverweigerung** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action":[ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:*:123456789012:function:*", "Condition": { "StringNotEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } } ] } ``` # Aufrufen von Lambda-Funktions-URLs Eine Funktions-URL ist ein dedizierter HTTPS-Endpunkt für Ihre Lambda-Funktion. Sie können eine Funktions-URL über die Lambda-Konsole oder die Lambda-API erstellen und konfigurieren. **Tipp** Lambda bietet zwei Möglichkeiten, Ihre Funktion über einen HTTP-Endpunkt aufzurufen: Funktions-URLs und Amazon API Gateway. Wenn Sie sich nicht sicher sind, welche Methode für Ihren Anwendungsfall am besten geeignet ist, siehe [Wählen Sie eine Methode, um Ihre Lambda-Funktion über eine HTTP-Anfrage aufzurufen](furls-http-invoke-decision.md). Wenn Sie eine Funktions-URL erstellen, generiert Lambda automatisch einen eindeutigen URL-Endpunkt für Sie. Sobald Sie eine Funktions-URL erstellt haben, ändert sich ihr URL-Endpunkt nie mehr. Funktions-URL-Endpunkte haben das folgende Format: ``` https://.lambda-url..on.aws ``` **Anmerkung** Funktions-URLs werden in den folgenden AWS-Regionen nicht unterstützt: Asien-Pazifik (Hyderabad) (`ap-south-2`), Asien-Pazifik (Melbourne) (`ap-southeast-4`), Asien-Pazifik (Malaysia) (`ap-southeast-5`), Asien-Pazifik (Neuseeland) (`ap-southeast-6`), Asien-Pazifik (Thailand) (`ap-southeast-7`), Asien-Pazifik (Taipeh) (`ap-east-2`), Kanada West (Calgary) (`ca-west-1`), Europa (Spanien) (`eu-south-2`), Europa (Zürich) (`eu-central-2`), Israel (Tel Aviv) (`il-central-1`) und Naher Osten (VAE) (`me-central-1`). Funktions-URLs sind Dual-Stack-fähig und unterstützen IPv4 und IPv6. Nachdem Sie Ihre Funktions-URL konfiguriert haben, können Sie Ihre Funktion über ihren HTTP(S)-Endpunkt über einen Webbrowser, cURL, Postman oder einen beliebigen HTTP-Client aufrufen. Um eine Funktions-URL aufzurufen, müssen Sie `lambda:InvokeFunctionUrl`- und `lambda:InvokeFunction`-Berechtigungen haben. Weitere Informationen finden Sie unter [Zugriffskontrolle](urls-auth.md). **Topics** + [ ## Grundlagen des Aufrufs von Funktions-URLs ](#urls-invocation-basics) + [ ## Anfordern und Beantworten von Nutzlasten ](#urls-payloads) ## Grundlagen des Aufrufs von Funktions-URLs Wenn Ihre Funktions-URL den Auth-Typ `AWS_IAM` hat, müssen Sie jede HTTP-Anfrage mit der [AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) signieren. Tools wie [Postman](https://quickstarts.postman.com/guide/aws/index.html?index=..%2F..index#2) bieten integrierte Möglichkeiten, Ihre Anforderungen mit SigV4 zu signieren. Wenn Sie kein Tool verwenden, um HTTP-Anfragen an Ihre Funktions-URL zu signieren, müssen Sie jede Anfrage manuell mit SigV4 signieren. Wenn Ihre Funktions-URL eine Anfrage erhält, berechnet Lambda auch die SigV4-Signatur. Nur wenn die Signaturen übereinstimmen, verarbeitet Lambda die Anfrage. Anweisungen zum manuellen Signieren Ihrer Anforderungen mit SigV4 finden Sie unter [Signieren von AWS-Anforderungen mit Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) im *Allgemeine Amazon Web Services-Referenz*. Wenn Ihre Funktions-URL den Authentifizierungstyp `NONE` verwendet, müssen Sie Ihre Anfragen nicht mit SigV4 signieren. Sie können Ihre Funktion per Webbrowser, cURL, Postman oder einem beliebigen HTTP-Client aufrufen. Um einfache `GET`-Anfragen an Ihre Funktion zu testen, verwenden Sie einen Webbrowser. Wenn Ihre Funktions-URL zum Beispiel `https://abcdefg.lambda-url.us-east-1.on.aws` ist und sie einen Zeichenfolgeparameter `message` aufnimmt, könnte Ihre Anforderungs-URL folgendermaßen aussehen: ``` https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld ``` Um andere HTTP-Anfragen zu testen, z. B. eine `POST`-Anfrage, können Sie ein Tool wie cURL verwenden. Wenn Sie z. B. einige JSON-Daten in eine `POST`-Anfrage an Ihre Funktions-URL aufnehmen möchten, können Sie den folgenden cURL-Befehl verwenden: ``` curl -v 'https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld' \ -H 'content-type: application/json' \ -d '{ "example": "test" }' ``` ## Anfordern und Beantworten von Nutzlasten Wenn ein Client Ihre Funktions-URL aufruft, ordnet Lambda die Anforderung einem Ereignisobjekt zu, bevor es sie an Ihre Funktion übergibt. Die Antwort Ihrer Funktion wird dann einer HTTP-Antwort zugeordnet, die Lambda über die Funktions-URL an den Client zurücksendet. Die Formate für Anforderungs- und Antwortereignisse folgen dem gleichen Schema wie die [Amazon-API-Gateway-Nutzlastformatversion 2.0](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html#http-api-develop-integrations-lambda.proxy-format). ### Anforderungsnutzlastformat Eine Anforderungsnutzlast hat die folgende Struktur: ``` { "version": "2.0", "routeKey": "$default", "rawPath": "/my/path", "rawQueryString": "parameter1=value1¶meter1=value2¶meter2=value", "cookies": [ "cookie1", "cookie2" ], "headers": { "header1": "value1", "header2": "value1,value2" }, "queryStringParameters": { "parameter1": "value1,value2", "parameter2": "value" }, "requestContext": { "accountId": "123456789012", "apiId": "", "authentication": null, "authorizer": { "iam": { "accessKey": "AKIA...", "accountId": "111122223333", "callerId": "AIDA...", "cognitoIdentity": null, "principalOrgId": null, "userArn": "arn:aws:iam::111122223333:user/example-user", "userId": "AIDA..." } }, "domainName": ".lambda-url.us-west-2.on.aws", "domainPrefix": "", "http": { "method": "POST", "path": "/my/path", "protocol": "HTTP/1.1", "sourceIp": "123.123.123.123", "userAgent": "agent" }, "requestId": "id", "routeKey": "$default", "stage": "$default", "time": "12/Mar/2020:19:03:58 +0000", "timeEpoch": 1583348638390 }, "body": "Hello from client!", "pathParameters": null, "isBase64Encoded": false, "stageVariables": null } ``` | Parameter | Beschreibung | Beispiel | | --- | --- | --- | | `version` | Die Nutzlastformatversion für dieses Ereignis. Lambda-Funktions-URLs unterstützen derzeit die [Nutzlastformatversion 2.0](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html#http-api-develop-integrations-lambda.proxy-format). | `2.0` | | `routeKey` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `$default` als Platzhalter. | `$default` | | `rawPath` | Der Anforderungspfad. Wenn die Anforderungs-URL beispielsweise `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo` ist, dann ist der Rohpfadwert `/example/test/demo`. | `/example/test/demo` | | `rawQueryString` | Die Rohzeichenfolge, die die Abfragezeichenfolge-Parameter der Anforderung enthält. Zu den unterstützten Zeichen gehören `a-z`, `A-Z`, `0-9`, `.`, `_`, `-`, `%`, `&`, `=`, und `+`. | `"?parameter1=value1¶meter2=value2"` | | `cookies` | Ein Array, das alle Cookies enthält, die im Rahmen der Anforderung gesendet wurden. | `["Cookie_1=Value_1", "Cookie_2=Value_2"]` | | `headers` | Die Liste der Anforderungs-Header, die als Schlüssel-Wert-Paare dargestellt werden. | `{"header1": "value1", "header2": "value2"}` | | `queryStringParameters` | Die Abfrageparameter für die Anforderung. Wenn die Anforderungs-URL beispielsweise `https://{url-id}.lambda-url.{region}.on.aws/example?name=Jane` ist, dann ist der `queryStringParameters`-Wert ein JSON-Objekt mit einem Schlüssel von `name` und einem Wert von `Jane`. | `{"name": "Jane"}` | | `requestContext` | Ein Objekt, das zusätzliche Informationen über die Anforderung enthält, z. B. `requestId`, den Zeitpunkt der Anfrage und die Identität des Anrufers, falls über AWS Identity and Access Management (IAM) autorisiert. | | | `requestContext.accountId` | Die AWS-Konto-ID des Funktionsbesitzers. | `"123456789012"` | | `requestContext.apiId` | Die ID der Funktions-URL. | `"33anwqw8fj"` | | `requestContext.authentication` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `null`. | `null` | | `requestContext.authorizer` | Ein Objekt, das Informationen über die Aufruferidentität enthält, wenn die Funktions-URL den Authentifizierungstyp `AWS_IAM` verwendet. Ansonsten setzt Lambda dies auf `null`. | | | `requestContext.authorizer.iam.accessKey` | Der Zugriffsschlüssel der Anruferidentität. | `"AKIAIOSFODNN7EXAMPLE"` | | `requestContext.authorizer.iam.accountId` | Die AWS-Konto-Identitäts-ID des Anrufers. | `"111122223333"` | | `requestContext.authorizer.iam.callerId` | Die ID (Benutzer-ID) des Aufrufers. | `"AIDACKCEVSQ6C2EXAMPLE"` | | `requestContext.authorizer.iam.cognitoIdentity` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `null` oder schließt dies aus der JSON aus. | `null` | | `requestContext.authorizer.iam.principalOrgId` | Die Prinzipal-Organisations-ID, die mit der Anruferidentität verknüpft ist. | `"AIDACKCEVSQORGEXAMPLE"` | | `requestContext.authorizer.iam.userArn` | Der Benutzer-ARN (Amazon-Ressourcenname) der Anruferidentität. | `"arn:aws:iam::111122223333:user/example-user"` | | `requestContext.authorizer.iam.userId` | Die Benutzer-ID des Anrufers. | `"AIDACOSFODNN7EXAMPLE2"` | | `requestContext.domainName` | Der Domain-Name der Funktions-URL. | `".lambda-url.us-west-2.on.aws"` | | `requestContext.domainPrefix` | Das Domain-Präfix der Funktions-URL. | `""` | | `requestContext.http` | Ein Objekt, das Details zur HTTP-Anforderung enthält. | | | `requestContext.http.method` | Die in der Anforderung verwendete HTTP-Methode. Gültige Werte sind unter anderem `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PATCH` und `DELETE`. | `GET` | | `requestContext.http.path` | Der Anforderungspfad. Zum Beispiel, wenn die Anforderungs-URL `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo` ist, dann ist der Pfadwert `/example/test/demo`. | `/example/test/demo` | | `requestContext.http.protocol` | Das Protokoll der Anforderung. | `HTTP/1.1` | | `requestContext.http.sourceIp` | Die Quell-IP-Adresse der TCP-Verbindung, von der die Anforderung stammt. | `123.123.123.123` | | `requestContext.http.userAgent` | Der Headerwert der Benutzer-Agent-Anforderung. | `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Gecko/20100101 Firefox/42.0` | | `requestContext.requestId` | Die ID der aktuellen Aufrufanforderung. Sie können diese ID verwenden, um Aufrufprotokolle zu verfolgen, die sich auf Ihre Funktion beziehen. | `e1506fd5-9e7b-434f-bd42-4f8fa224b599` | | `requestContext.routeKey` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `$default` als Platzhalter. | `$default` | | `requestContext.stage` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `$default` als Platzhalter. | `$default` | | `requestContext.time` | Der Zeitstempel der Anfrage. | `"07/Sep/2021:22:50:22 +0000"` | | `requestContext.timeEpoch` | Die Uhrzeit der Anfrage in Unix-Epochen-Zeit. | `"1631055022677"` | | `body` | Der Text der Anforderung. Wenn der Inhaltstyp der Anforderung binär ist, ist der Text base64-kodiert. | `{"key1": "value1", "key2": "value2"}` | | `pathParameters` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `null` oder schließt dies aus der JSON aus. | `null` | | `isBase64Encoded` | `TRUE`, wenn der Text eine binäre Nutzlast hat und base64-kodiert ist. Ansonsten `FALSE`. | `FALSE` | | `stageVariables` | Funktions-URLs verwenden diesen Parameter nicht. Lambda setzt dies auf `null` oder schließt dies aus der JSON aus. | `null` | ### Antwortnutzlastformat Wenn Ihre Funktion eine Antwort zurückgibt, analysiert Lambda die Antwort und konvertiert sie in eine HTTP-Antwort. Funktionsantwortnutzlasten haben das folgende Format: ``` { "statusCode": 201, "headers": { "Content-Type": "application/json", "My-Custom-Header": "Custom Value" }, "body": "{ \"message\": \"Hello, world!\" }", "cookies": [ "Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT", "Cookie_2=Value2; Max-Age=78000" ], "isBase64Encoded": false } ``` Lambda leitet das Antwortformat für Sie ab. Wenn Ihre Funktion gültiges JSON zurückgibt und keinen `statusCode` zurückgibt, geht Lambda von Folgendem aus: + `statusCode` is `200`. **Anmerkung** Die gültigen `statusCode` liegen im Bereich von 100 bis 599. + `content-type` is `application/json`. + `body` ist die Antwort der Funktion. + `isBase64Encoded` is `false`. Die folgenden Beispiele zeigen, wie die Ausgabe Ihrer Lambda-Funktion der Antwortnutzlast und die Antwortnutzlast der endgültigen HTTP-Antwort zugeordnet wird. Wenn der Client Ihre Funktions-URL aufruft, wird die HTTP-Antwort angezeigt. **Beispielausgabe für eine Zeichenfolgeantwort** | Lambda-Funktionsausgabe | Interpretierte Antwortausgabe | HTTP-Antwort (was der Client sieht) | | --- | --- | --- | | 
"Hello, world!"
| 
{
  "statusCode": 200,
  "body": "Hello, world!",
  "headers": {
    "content-type": "application/json"
  },
  "isBase64Encoded": false
}
| 
HTTP/2 200
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 15

"Hello, world!"
| **Beispielausgabe für eine JSON-Antwort** | Lambda-Funktionsausgabe | Interpretierte Antwortausgabe | HTTP-Antwort (was der Client sieht) | | --- | --- | --- | | 
{
  "message": "Hello, world!"
}
| 
{
  "statusCode": 200,
  "body": {
    "message": "Hello, world!"
  },
  "headers": {
    "content-type": "application/json"
  },
  "isBase64Encoded": false
}
| 
HTTP/2 200
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 34

{
  "message": "Hello, world!"
}
| **Beispielausgabe für eine benutzerdefinierte Antwort** | Lambda-Funktionsausgabe | Interpretierte Antwortausgabe | HTTP-Antwort (was der Client sieht) | | --- | --- | --- | | 
{
   "statusCode": 201,
    "headers": {
        "Content-Type": "application/json",
        "My-Custom-Header": "Custom Value"
    },
    "body": JSON.stringify({
        "message": "Hello, world!"
    }),
    "isBase64Encoded": false
}
| 
{
   "statusCode": 201,
    "headers": {
        "Content-Type": "application/json",
        "My-Custom-Header": "Custom Value"
    },
    "body": JSON.stringify({
        "message": "Hello, world!"
    }),
    "isBase64Encoded": false
}
| 
HTTP/2 201
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 27
my-custom-header: Custom Value

{
  "message": "Hello, world!"
}
| ### Cookies Um Cookies von Ihrer Funktion zurückzugeben, fügen Sie `set-cookie`-Header nicht manuell hinzu. Fügen Sie stattdessen die Cookies in Ihr Antwortnutzlastobjekt ein. Lambda interpretiert dies automatisch und fügt sie als `set-cookie`-Header in Ihre HTTP-Antwort ein, wie im folgenden Beispiel gezeigt. | Lambda-Funktionsausgabe | HTTP-Antwort (was der Client sieht) | | --- | --- | | 
{
   "statusCode": 201,
    "headers": {
        "Content-Type": "application/json",
        "My-Custom-Header": "Custom Value"
    },
    "body": JSON.stringify({
        "message": "Hello, world!"
    }),
    "cookies": [
        "Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT",
        "Cookie_2=Value2; Max-Age=78000"
    ],
    "isBase64Encoded": false
}
| 
HTTP/2 201
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 27
my-custom-header: Custom Value
set-cookie: Cookie_1=Value2; Expires=21 Oct 2021 07:48 GMT
set-cookie: Cookie_2=Value2; Max-Age=78000

{
  "message": "Hello, world!"
}
| # Überwachen der Lambda-Funktions-URLs Sie können AWS CloudTrail und Amazon CloudWatch zur Überwachung Ihrer Funktions-URLs verwenden. **Topics** + [ ## Überwachen von Funktions-URLs mit CloudTrail ](#urls-cloudtrail) + [ ## CloudWatch-Metriken für Funktions-URLs ](#urls-cloudwatch) ## Überwachen von Funktions-URLs mit CloudTrail Bei Funktions-URLs unterstützt Lambda automatisch die Protokollierung der folgenden API-Operationen als Ereignisse in CloudTrail-Protokolldateien: + [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) + [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html) + [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html) + [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html) + [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html) Jeder Protokolleintrag enthält Informationen über die Anruferidentität, wann die Anfrage gestellt wurde, und andere Details. Sie können alle Ereignisse innerhalb der letzten 90 Tage sehen, indem Sie Ihren CloudTrail-**Ereignisverlauf** ansehen. Um Datensätze nach 90 Tagen beizubehalten, können Sie einen Trail erstellen. Standardmäßig protokolliert CloudTrail `InvokeFunctionUrl`-Anfragen, die für Datenereignisse gehalten werden, nicht. Sie können die Datenereignisprotokollierung jedoch in CloudTrail aktivieren. Weitere Informationen finden Sie unter [Protokollieren von Datenereignissen für Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) im *AWS CloudTrail-Benutzerhandbuch.* ## CloudWatch-Metriken für Funktions-URLs Lambda sendet aggregierte Metriken über Funktions-URL-Anfragen an CloudWatch. Mit diesen Metriken können Sie Ihre Funktions-URLs überwachen, Dashboards erstellen und Alarme in der CloudWatch-Konsole konfigurieren. Funktions-URLs unterstützen die folgenden Aufrufmetriken. Wir empfehlen, diese Metriken mit der `Sum`-Statistik anzuzeigen. + `UrlRequestCount` – Die Anzahl der Anforderungen an diese Funktions-URL. + `Url4xxCount` – Die Anzahl der Anforderungen, bei denen ein 4XX-HTTP-Statuscode zurückgegeben wurde. Codes der 4XX-Serie weisen auf clientseitige Fehler hin, z. B. schlechte Anforderungen. + `Url5xxCount` – Die Anzahl der Anforderungen, bei denen ein 5XX-HTTP-Statuscode zurückgegeben wurde. Codes der 5XX-Serie weisen auf serverseitige Fehler wie Funktionsfehler und Timeouts hin. Funktions-URLs unterstützen auch die folgende Leistungsmetrik. Wir empfehlen, diese Metriken mit der `Average`- oder `Max`-Statistik anzuzeigen. + `UrlRequestLatency` – Die Zeit zwischen dem Erhalt der Funktions-URL eine Anforderung und wann die Funktions-URL eine Antwort zurückgibt. Jede dieser Aufrufs- und Leistungsmetriken unterstützt die folgenden Dimensionen: + `FunctionName` – Zeigt Aggregatmetriken für Funktions-URLs an, die der `$LATEST` unveröffentlichten Version oder einem der Aliase der Funktion zugeordnet sind. Beispiel, `hello-world-function`. + `Resource` – Zeigt Metriken für eine bestimmte Funktions-URL an. Dies wird durch einen Funktionsnamen zusammen mit der `$LATEST` unveröffentlichten Version oder einem der Aliase der Funktion definiert. Beispiel, `hello-world-function:$LATEST`. + `ExecutedVersion` – Zeigt Metriken für eine bestimmte Funktions-URL basierend auf der ausgeführten Version an. Sie können diese Dimension hauptsächlich verwenden, um die Funktions-URL zu verfolgen, die der `$LATEST`unveröffentlichten Version zugeordnet ist. # Wählen Sie eine Methode, um Ihre Lambda-Funktion über eine HTTP-Anfrage aufzurufen Viele häufige Anwendungsfälle für Lambda beinhalten den Aufruf Ihrer Funktion über eine HTTP-Anfrage. Beispielsweise möchten Sie möglicherweise, dass eine Webanwendung Ihre Funktion über eine Browseranforderung aufruft. Lambda-Funktionen können auch verwendet werden, um vollständige REST zu erstellen APIs, Benutzerinteraktionen von mobilen Apps aus abzuwickeln, Daten von externen Diensten über HTTP-Aufrufe zu verarbeiten oder benutzerdefinierte Webhooks zu erstellen. In den folgenden Abschnitten wird erläutert, welche Möglichkeiten Sie haben, Lambda über HTTP aufzurufen und es werden Informationen bereitgestellt, die Ihnen helfen, die richtige Entscheidung für Ihren speziellen Anwendungsfall zu treffen. ## Welche Optionen stehen Ihnen bei der Auswahl einer HTTP-Aufrufmethode zur Verfügung? Lambda bietet zwei Hauptmethoden zum Aufrufen einer Funktion mithilfe einer HTTP-Anfrage: [Funktion URLs](urls-configuration.md) und [API](services-apigateway.md) Gateway. Die wichtigsten Unterschiede zwischen diesen beiden Optionen sind die folgenden: + Die **Lambda-Funktion URLs** bietet einen einfachen, direkten HTTP-Endpunkt für eine Lambda-Funktion. Sie sind auf Einfachheit und Kosteneffizienz optimiert und bieten den schnellsten Weg, um eine Lambda-Funktion über HTTP bereitzustellen. + **API Gateway** ist ein fortschrittlicherer Dienst zum Erstellen von Funktionen mit vollem Funktionsumfang APIs. API Gateway ist für den Aufbau und die Verwaltung von Produktionen APIs in großem Maßstab optimiert und bietet umfassende Tools für Sicherheit, Überwachung und Verkehrsmanagement. ## Empfehlungen, falls Sie Ihre Anforderungen bereits kennen Wenn Sie sich über Ihre Anforderungen bereits im Klaren sind, finden Sie hier unsere grundlegenden Empfehlungen: Wir empfehlen **[Funktionen URLs](urls-configuration.md)** für einfache Anwendungen oder für die Prototypenentwicklung, bei denen Sie nur grundlegende Authentifizierungsmethoden und request/response deren Handhabung benötigen und bei denen Sie Kosten und Komplexität auf ein Minimum reduzieren möchten. **[API Gateway](services-apigateway.md)** ist eine bessere Wahl für Produktionsanwendungen in großem Maßstab oder für Fälle, in denen Sie erweiterte Funktionen wie [OpenAPI-Description](https://www.openapis.org/), eine Auswahl an Authentifizierungsoptionen, benutzerdefinierte Domainnamen oder umfangreiche request/response Funktionen wie Drosselung, Caching und Transformation benötigen. request/response ## Was ist bei der Auswahl einer Methode zum Aufrufen Ihrer Lambda-Funktion zu beachten? Bei der Auswahl zwischen Funktion URLs und API Gateway müssen Sie die folgenden Faktoren berücksichtigen: + Ihre Authentifizierungsanforderungen, z. B. ob Sie Amazon Cognito für die Benutzerauthentifizierung benötigen OAuth + Ihre Skalierungsanforderungen und die Komplexität der API, die Sie implementieren möchten + Ob Sie erweiterte Funktionen wie die Validierung und Formatierung von Anfragen benötigen request/response + Ihre Überwachungsanforderungen + Was sind Ihre Ziele? Wenn Sie diese Faktoren verstehen, können Sie die Option auswählen, die Ihren Anforderungen an Sicherheit, Komplexität und Kosten am besten gerecht wird. Die folgenden Informationen fassen die wichtigsten Unterschiede zwischen den beiden Optionen zusammen. ### Authentifizierung + **Die Funktion URLs** bietet grundlegende Authentifizierungsoptionen über AWS Identity and Access Management (IAM). Sie können Ihre Endpunkte so konfigurieren, dass sie entweder öffentlich sind (keine Authentifizierung) oder dass sie eine IAM-Authentifizierung erfordern. Mit der IAM-Authentifizierung können Sie AWS Standardanmeldedaten oder IAM-Rollen verwenden, um den Zugriff zu steuern. Dieser Ansatz ist zwar einfach einzurichten, bietet aber im Vergleich zu anderen Authentifizierungsmethoden nur begrenzte Optionen. + **API Gateway** bietet Zugriff auf eine umfassendere Palette von Authentifizierungsoptionen. Neben der IAM-Authentifizierung können Sie [Lambda-Autorisierer](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (benutzerdefinierte Authentifizierungslogik), [Amazon Cognito Cognito-Benutzerpools](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) und .0-Flows verwenden. OAuth2 Diese Flexibilität ermöglicht es Ihnen, komplexe Authentifizierungsschemata zu implementieren, darunter Authentifizierungsanbieter von Drittanbietern, tokenbasierte Authentifizierung und Multi-Faktor-Authentifizierung. ### Anfrage-/Antwort-Anforderungen + **Die Funktion URLs bietet eine** grundlegende Behandlung von HTTP-Anfragen und -Antworten. Sie unterstützen Standard-HTTP-Methoden und bieten integrierte CORS-Unterstützung (Cross-Origin Resource Sharing). Sie können zwar JSON-Nutzdaten und Abfrageparameter auf natürliche Weise verarbeiten, bieten jedoch keine Funktionen zur Transformation oder Validierung von Anfragen. Die Bearbeitung von Antworten ist ähnlich einfach – der Client erhält die Antwort von Ihrer Lambda-Funktion genau so, wie Lambda sie zurückgibt. + **API Gateway** bietet ausgefeilte Funktionen zur Bearbeitung von Anfragen und Antworten. Sie können Anforderungsvalidatoren definieren, Anfragen und Antworten mithilfe von Zuordnungsvorlagen transformieren, request/response Header einrichten und das Zwischenspeichern von Antworten implementieren. API Gateway unterstützt auch binäre Nutzdaten und benutzerdefinierte Domainnamen und kann Antworten ändern, bevor sie den Client erreichen. Sie können Modelle für die request/response Validierung und Transformation mithilfe des JSON-Schemas einrichten. ### Skalierung + Die **Funktion URLs** skaliert direkt mit den Parallelitätsgrenzen Ihrer Lambda-Funktion und bewältigt Verkehrsspitzen, indem Sie Ihre Funktion bis zum konfigurierten Maximallimit skalieren. Sobald dieses Limit erreicht ist, reagiert Lambda auf weitere Anfragen mit HTTP 429-Antworten. Es gibt keinen integrierten Warteschlangenmechanismus, sodass der Umgang mit der Skalierung vollständig von der Konfiguration Ihrer Lambda-Funktion abhängt. Standardmäßig haben Lambda-Funktionen ein Limit von 1.000 gleichzeitigen Ausführungen pro. AWS-Region + **API Gateway** bietet zusätzlich zur Lambda-eigenen Skalierung zusätzliche Skalierungsfunktionen. Es umfasst integrierte Funktionen zur Warteschleife und Drosselung von Anfragen, sodass Sie Datenverkehrsspitzen besser bewältigen können. API Gateway kann standardmäßig bis zu 10.000 Anfragen pro Sekunde pro Region verarbeiten, mit einer Burst-Kapazität von 5.000 Anfragen pro Sekunde. Es bietet auch Tools zum Drosseln von Anfragen auf verschiedenen Ebenen (API, Phase oder Methode), um Ihr Backend zu schützen. ### Überwachen + **Function URLs** bietet eine grundlegende Überwachung anhand von CloudWatch Amazon-Metriken, einschließlich Anzahl der Anfragen, Latenz und Fehlerraten. Sie erhalten Zugriff auf standardmäßige Lambda-Metriken und -Protokolle, die die Rohanfragen anzeigen, die in Ihre Funktion eingehen. Dies bietet zwar wichtige betriebliche Transparenz, die Metriken konzentrieren sich jedoch hauptsächlich auf die Funktionsausführung. + **API Gateway** bietet umfassende Überwachungsfunktionen, einschließlich detaillierter Metriken, Protokollierungs- und Verfolgungsoptionen. Sie können API-Aufrufe, Latenz, Fehlerraten und hit/miss Cache-Raten über überwachen CloudWatch. API Gateway lässt sich auch AWS X-Ray für verteiltes Tracing integrieren und bietet anpassbare Protokollierungsformate. ### Cost (Kosten) + Die **Funktionen URLs** folgen dem Standard-Lambda-Preismodell — Sie zahlen nur für Funktionsaufrufe und Rechenzeit. Für den URL-Endpunkt selbst fallen keine zusätzlichen Gebühren an. Dies macht es zu einer kostengünstigen Wahl für einfache Anwendungen APIs oder Anwendungen mit geringem Datenverkehr, wenn Sie die zusätzlichen Funktionen von API Gateway nicht benötigen. + **API Gateway** bietet ein [kostenloses Kontingent](https://aws.amazon.com/api-gateway/pricing/#Free_Tier), das eine Million API-Aufrufe für REST APIs und eine Million API-Aufrufe für HTTP umfasst APIs. Danach berechnet API Gateway Gebühren für API-Aufrufe, Datenübertragung und Caching (falls aktiviert). Weitere Informationen zu den Kosten für Ihren eigenen Anwendungsfall finden Sie auf der [Seite mit den Preisen](https://aws.amazon.com/api-gateway/pricing/) für API Gateway. ### Weitere Funktionen + URLsDie **Funktionen** sind auf Einfachheit und direkte Lambda-Integration ausgelegt. Sie unterstützen sowohl HTTP- als auch HTTPS-Endpunkte, bieten integrierte CORS-Unterstützung und bieten Dual-Stack- (IPv4 und) Endpunkte. IPv6 Ihnen fehlen zwar erweiterte Features, sie zeichnen sich jedoch in Szenarien aus, in denen Sie Lambda-Funktionen schnell und unkompliziert über HTTP verfügbar machen müssen. + **API Gateway** umfasst zahlreiche zusätzliche Funktionen wie API-Versionierung, Stagemanagement, API-Schlüssel für Nutzungspläne, API-Dokumentation über Swagger/OpenAPI WebSocket APIs, private Funktionen APIs innerhalb einer VPC und WAF-Integration für zusätzliche Sicherheit. Es unterstützt auch kanarische Implementierungen, Scheinintegrationen zum Testen und die Integration mit anderen Systemen AWS-Services als Lambda. ## Wählen Sie eine Methode, um Ihre Lambda-Funktion aufzurufen Nachdem Sie sich mit den Kriterien für die Auswahl zwischen Lambda-Funktion URLs und API Gateway und den wichtigsten Unterschieden zwischen ihnen vertraut gemacht haben, können Sie die Option auswählen, die Ihren Anforderungen am besten entspricht, und die folgenden Ressourcen verwenden, um Ihnen den Einstieg in die Verwendung zu erleichtern. ------ #### [ Function URLs ] **Nutzen Sie die folgenden Ressourcen, um URLs mit Function zu beginnen** + Folgen Sie dem Tutorial [Erstellen einer Lambda-Funktion mit einer Funktions-URL](urls-webhook-tutorial.md) + Weitere Informationen zur Funktion finden Sie URLs im [Lambda-Funktion erstellen und verwalten URLs](urls-configuration.md) Kapitel dieses Handbuchs + Probieren Sie das in der Konsole enthaltene Tutorial **Erstellen Sie eine einfache Web-App** aus, indem Sie wie folgt vorgehen: 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Öffnen Sie das Hilfe-Panel, indem Sie das Symbol in der oberen rechten Ecke des Bildschirms wählen. ![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/console_help_screenshot.png) 1. Wählen Sie **Tutorials** aus. 1. Wählen Sie unter **Einfache Web-App erstellen** die Option **Tutorial starten** aus. ------ #### [ API Gateway ] **Beginnen Sie mit Lambda und API Gateway mit den folgenden Ressourcen** + Folgen Sie dem Tutorial [Verwenden von Lambda mit API Gateway](services-apigateway-tutorial.md), um eine REST-API zu erstellen, die in eine Backend-Lambda-Funktion integriert ist. + In den folgenden Abschnitten des *Amazon API Gateway Developer Guide* erfahren Sie mehr über die verschiedenen Arten von APIs, die von API Gateway angeboten werden: + [API-Gateway-REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) + [API Gateway HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) + [API Gateway WebSocket APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html) + Probieren Sie eines oder mehrere der Beispiele im Abschnitt [Tutorials und Workshops](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) im *Amazon API Gateway Developer Guide* aus. ------ # Tutorial: Erstellen eines Webhook-Endpunkts mithilfe einer Lambda-Funktions-URL In diesem Tutorial erstellen Sie eine Lambda-Funktions-URL, um einen Webhook-Endpunkt zu implementieren. Ein Webhook ist eine einfache, ereignisgesteuerte Kommunikation, die automatisch Daten zwischen Anwendungen über HTTP sendet. Sie können Webhooks verwenden, um sofortige Benachrichtigungen über Ereignisse in einem anderen System zu erhalten, z. B. wenn sich ein neuer Kunde auf einer Website registriert, eine Zahlung verarbeitet wird oder eine Datei hochgeladen wird. Mit Lambda können Webhooks entweder mithilfe der Lambda-Funktion URLs oder des API Gateway implementiert werden. Function ist eine gute Wahl für einfache Webhooks, für die keine Funktionen wie erweiterte Autorisierung oder Anforderungsvalidierung erforderlich URLs sind. **Tipp** Wenn Sie sich nicht sicher sind, welche Lösung für Ihren speziellen Anwendungsfall am besten geeignet ist, lesen Sie bitte [Wählen Sie eine Methode, um Ihre Lambda-Funktion über eine HTTP-Anfrage aufzurufen](furls-http-invoke-decision.md). ## Voraussetzungen Um dieses Tutorial durchzuführen, muss entweder Python (Version 3.8 oder höher) oder Node.js (Version 18 oder höher) auf Ihrem lokalen Rechner installiert sein. Um den Endpunkt mit einer HTTP-Anfrage zu testen, verwendet das Tutorial [curl](https://curl.se/), ein Befehlszeilentool, mit dem Sie Daten über verschiedene Netzwerkprotokolle übertragen können. In der [curl-Dokumentation](https://curl.se/docs/install.html) erfahren Sie, wie Sie das Tool installieren, falls Sie das noch nicht getan haben. ## So erstellen Sie die Lambda-Funktion: Erstellen Sie zunächst die Lambda-Funktion, die ausgeführt wird, wenn eine HTTP-Anfrage an Ihren Webhook-Endpunkt gesendet wird. In diesem Beispiel sendet die sendende Anwendung bei jeder Zahlung eine Aktualisierung und gibt im Hauptteil der HTTP-Anfrage an, ob die Zahlung erfolgreich war. Die Lambda-Funktion analysiert die Anfrage und ergreift entsprechend dem Status der Zahlung Maßnahmen. In diesem Beispiel gibt der Code lediglich die Bestellnummer für die Zahlung aus, aber in einer realen Anwendung würden Sie die Bestellung möglicherweise einer Datenbank hinzufügen oder eine Benachrichtigung senden. Die Funktion implementiert auch die gängigste Authentifizierungsmethode für Webhooks, die hashbasierte Nachrichtenauthentifizierung (HMAC). Bei dieser Methode teilen sich sowohl die sendende als auch die empfangende Anwendung einen geheimen Schlüssel. Die sendende Anwendung verwendet einen Hash-Algorithmus, um anhand dieses Schlüssels und des Nachrichteninhalts eine eindeutige Signatur zu generieren, und fügt die Signatur als HTTP-Header in die Webhook-Anfrage ein. Die empfangende Anwendung wiederholt diesen Schritt, generiert die Signatur unter Verwendung des geheimen Schlüssels und vergleicht den resultierenden Wert mit der im Anfrage-Header gesendeten Signatur. Stimmt das Ergebnis überein, wird die Anfrage als legitim angesehen. Erstellen Sie die Funktion mithilfe der Lambda-Konsole mit der Python- oder Node.js-Laufzeit. ------ #### [ Python ] **So erstellen Sie die Lambda-Funktion:** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Erstellen Sie eine einfache „Hello World“-Funktion: 1. Wählen Sie **Funktion erstellen**. 1. Wählen Sie **Verfassen von Grund auf** aus. 1. Geben Sie für **Function name** (Funktionsname) **myLambdaWebhook** ein. 1. Wählen Sie für **Runtime** **python3.14** aus. 1. Wählen Sie **Funktion erstellen**. 1. Ersetzen Sie im Bereich **Codequelle** den vorhandenen Code durch Folgendes: ``` import json import hmac import hashlib import os def lambda_handler(event, context): # Get the webhook secret from environment variables webhook_secret = os.environ['WEBHOOK_SECRET'] # Verify the webhook signature if not verify_signature(event, webhook_secret): return { 'statusCode': 401, 'body': json.dumps({'error': 'Invalid signature'}) } try: # Parse the webhook payload payload = json.loads(event['body']) # Handle different event types event_type = payload.get('type') if event_type == 'payment.success': # Handle successful payment order_id = payload.get('orderId') print(f"Processing successful payment for order {order_id}") # Add your business logic here # For example, update database, send notifications, etc. elif event_type == 'payment.failed': # Handle failed payment order_id = payload.get('orderId') print(f"Processing failed payment for order {order_id}") # Add your business logic here else: print(f"Received unhandled event type: {event_type}") # Return success response return { 'statusCode': 200, 'body': json.dumps({'received': True}) } except json.JSONDecodeError: return { 'statusCode': 400, 'body': json.dumps({'error': 'Invalid JSON payload'}) } except Exception as e: print(f"Error processing webhook: {e}") return { 'statusCode': 500, 'body': json.dumps({'error': 'Internal server error'}) } def verify_signature(event, webhook_secret): """ Verify the webhook signature using HMAC """ try: # Get the signature from headers signature = event['headers'].get('x-webhook-signature') if not signature: print("Error: Missing webhook signature in headers") return False # Get the raw body (return an empty string if the body key doesn't exist) body = event.get('body', '') # Create HMAC using the secret key expected_signature = hmac.new( webhook_secret.encode('utf-8'), body.encode('utf-8'), hashlib.sha256 ).hexdigest() # Compare the expected signature with the received signature to authenticate the message is_valid = hmac.compare_digest(signature, expected_signature) if not is_valid: print(f"Error: Invalid signature. Received: {signature}, Expected: {expected_signature}") return False return True except Exception as e: print(f"Error verifying signature: {e}") return False ``` 1. Wählen Sie im Abschnitt **BEREITSTELLEN** die Option **Bereitstellen** aus, um den Code Ihrer Funktion zu aktualisieren. ------ #### [ Node.js ] **So erstellen Sie die Lambda-Funktion:** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Erstellen Sie eine einfache „Hello World“-Funktion: 1. Wählen Sie **Funktion erstellen**. 1. Wählen Sie **Verfassen von Grund auf** aus. 1. Geben Sie für **Function name** (Funktionsname) **myLambdaWebhook** ein. 1. **Wählen Sie für **Runtime nodejs24.x** aus.** 1. Wählen Sie **Funktion erstellen**. 1. Ersetzen Sie im Bereich **Codequelle** den vorhandenen Code durch Folgendes: ``` import crypto from 'crypto'; export const handler = async (event, context) => { // Get the webhook secret from environment variables const webhookSecret = process.env.WEBHOOK_SECRET; // Verify the webhook signature if (!verifySignature(event, webhookSecret)) { return { statusCode: 401, body: JSON.stringify({ error: 'Invalid signature' }) }; } try { // Parse the webhook payload const payload = JSON.parse(event.body); // Handle different event types const eventType = payload.type; switch (eventType) { case 'payment.success': { // Handle successful payment const orderId = payload.orderId; console.log(`Processing successful payment for order ${orderId}`); // Add your business logic here // For example, update database, send notifications, etc. break; } case 'payment.failed': { // Handle failed payment const orderId = payload.orderId; console.log(`Processing failed payment for order ${orderId}`); // Add your business logic here break; } default: console.log(`Received unhandled event type: ${eventType}`); } // Return success response return { statusCode: 200, body: JSON.stringify({ received: true }) }; } catch (error) { if (error instanceof SyntaxError) { // Handle JSON parsing errors return { statusCode: 400, body: JSON.stringify({ error: 'Invalid JSON payload' }) }; } // Handle all other errors console.error('Error processing webhook:', error); return { statusCode: 500, body: JSON.stringify({ error: 'Internal server error' }) }; } }; // Verify the webhook signature using HMAC const verifySignature = (event, webhookSecret) => { try { // Get the signature from headers const signature = event.headers['x-webhook-signature']; if (!signature) { console.log('No signature found in headers:', event.headers); return false; } // Get the raw body (return an empty string if the body key doesn't exist) const body = event.body || ''; // Create HMAC using the secret key const hmac = crypto.createHmac('sha256', webhookSecret); const expectedSignature = hmac.update(body).digest('hex'); // Compare expected and received signatures const isValid = signature === expectedSignature; if (!isValid) { console.log(`Invalid signature. Received: ${signature}, Expected: ${expectedSignature}`); return false; } return true; } catch (error) { console.error('Error during signature verification:', error); return false; } }; ``` 1. Wählen Sie im Abschnitt **BEREITSTELLEN** die Option **Bereitstellen** aus, um den Code Ihrer Funktion zu aktualisieren. ------ ## Erstellen des geheimen Schlüssels Damit die Lambda-Funktion die Webhook-Anfrage authentifizieren kann, verwendet sie einen geheimen Schlüssel, den sie mit der aufrufenden Anwendung teilt. In diesem Beispiel wird der Schlüssel in einer Umgebungsvariablen gespeichert. Schließen Sie in einer Produktionsanwendung keine sensiblen Informationen wie Passwörter in Ihren Funktionscode ein. [Erstellen Sie stattdessen ein AWS Secrets Manager Geheimnis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) und [verwenden Sie dann die Lambda-Erweiterung AWS Parameters and Secrets](with-secrets-manager.md), um Ihre Anmeldeinformationen in Ihrer Lambda-Funktion abzurufen. **Erstellen und Speichern des geheimen Webhook-Schlüssels** 1. Generieren Sie eine lange, zufällige Zeichenfolge mit einem kryptografisch sicheren Zufallszahlengenerator. Sie können die folgenden Codeausschnitte in Python oder Node.js verwenden, um einen 32-stelligen geheimen Schlüssel zu generieren und auszudrucken, oder Ihre eigene bevorzugte Methode verwenden. ------ #### [ Python ] **Example Code zum Generieren eines geheimen Schlüssels** ``` import secrets webhook_secret = secrets.token_urlsafe(32) print(webhook_secret) ``` ------ #### [ Node.js ] **Example Code zum Generieren eines geheimen Schlüssels (ES-Modulformat)** ``` import crypto from 'crypto'; let webhookSecret = crypto.randomBytes(32).toString('base64'); console.log(webhookSecret) ``` ------ 1. Speichern Sie Ihre generierte Zeichenfolge als Umgebungsvariable für Ihre Funktion: 1. Wählen Sie auf der Registerkarte **Konfiguration** für Ihre Funktion die Option **Umgebungsvariablen** aus. 1. Wählen Sie **Bearbeiten** aus. 1. Wählen Sie **Umgebungsvariablen hinzufügen** aus. 1. Geben Sie für **Schlüssel** **WEBHOOK\$1SECRET** ein und dann für **Wert** den geheimen Schlüssel, den Sie im vorherigen Schritt generiert haben. 1. Wählen Sie **Speichern**. Sie werden diesen geheimen Schlüssel später im Tutorial erneut verwenden müssen, um Ihre Funktion zu testen. Notieren Sie ihn sich daher jetzt. ## Erstellen des Funktions-URL-Endpunkts Erstellen Sie einen Endpunkt für Ihren Webhook mithilfe einer Lambda-Funktions-URL. Da Sie den Authentifizierungstyp `NONE` verwenden, um einen Endpunkt mit öffentlichem Zugriff zu erstellen, kann jeder, der über die URL verfügt, Ihre Funktion aufrufen. Weitere Informationen zur Steuerung des Zugriffs auf Funktionen finden Sie URLs unter. [Steuern Sie den Zugriff auf die Lambda-Funktion URLs](urls-auth.md) Wenn Sie erweiterte Authentifizierungsoptionen für Ihren Webhook benötigen, sollten Sie die Verwendung von API Gateway in Betracht ziehen. **Erstellen des Funktions-URL-Endpunkts** 1. Wählen Sie auf der Registerkarte **Konfiguration** Ihrer Funktion die Option **Funktions-URL** aus. 1. Wählen Sie **Funktions-URL erstellen**. 1. Wählen Sie als **Authentifizierungstyp** die Option **KEINEN** aus. 1. Wählen Sie **Speichern**. Der Endpunkt für die Funktions-URL, die Sie gerade erstellt haben, wird im Bereich **Funktions-URL** angezeigt. Kopieren Sie den Endpunkt, um ihn später im Tutorial zu verwenden. ## Testen der Funktion in der Konsole Bevor Sie eine HTTP-Anfrage verwenden, um Ihre Funktion über den URL-Endpunkt aufzurufen, testen Sie sie in der Konsole, um sicherzustellen, dass Ihr Code wie erwartet funktioniert. Um die Funktion in der Konsole zu überprüfen, berechnen Sie zunächst eine Webhook-Signatur unter Verwendung des zuvor im Tutorial generierten geheimen Schlüssels mit den folgenden Test-JSON-Nutzdaten: ``` { "type": "payment.success", "orderId": "1234", "amount": "99.99" } ``` Verwenden Sie eines der folgenden Python- oder Node.js-Codebeispiele, um die Webhook-Signatur mit Ihrem eigenen geheimen Schlüssel zu berechnen. ------ #### [ Python ] **Berechnen der Webhook-Signatur** 1. Speichern Sie den folgenden Code als Datei mit dem Namen `calculate_signature.py`. Ersetzen Sie den geheimen Webhook-Schlüssel im Code durch Ihren eigenen Wert. ``` import secrets import hmac import json import hashlib webhook_secret = "arlbSDCP86n_1H90s0fL_Qb2NAHBIBQOyGI0X4Zay4M" body = json.dumps({"type": "payment.success", "orderId": "1234", "amount": "99.99"}) signature = hmac.new( webhook_secret.encode('utf-8'), body.encode('utf-8'), hashlib.sha256 ).hexdigest() print(signature) ``` 1. Berechnen Sie die Signatur, indem Sie den folgenden Befehl aus dem Verzeichnis ausführen, in dem Sie den Code gespeichert haben. Kopieren Sie die Signatur, die der Code ausgibt. ``` python calculate_signature.py ``` ------ #### [ Node.js ] **Berechnen der Webhook-Signatur** 1. Speichern Sie den folgenden Code als Datei mit dem Namen `calculate_signature.mjs`. Ersetzen Sie den geheimen Webhook-Schlüssel im Code durch Ihren eigenen Wert. ``` import crypto from 'crypto'; const webhookSecret = "arlbSDCP86n_1H90s0fL_Qb2NAHBIBQOyGI0X4Zay4M" const body = "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}"; let hmac = crypto.createHmac('sha256', webhookSecret); let signature = hmac.update(body).digest('hex'); console.log(signature); ``` 1. Berechnen Sie die Signatur, indem Sie den folgenden Befehl aus dem Verzeichnis ausführen, in dem Sie den Code gespeichert haben. Kopieren Sie die Signatur, die der Code ausgibt. ``` node calculate_signature.mjs ``` ------ Sie können Ihren Funktionscode jetzt mit einer Test-HTTP-Anfrage in der Konsole testen. **Testen der Funktion in der Konsole** 1. Wählen Sie die Registerkarte **Code** für Ihre Funktion aus. 1. Wählen Sie im Abschnitt **TESTEREIGNISSE** die Option **Neues Testereignis erstellen** aus. 1. Geben Sie als **Event name (Ereignisname)** die Zeichenfolge **myEvent** ein. 1. Ersetzen Sie das vorhandene JSON, indem Sie Folgendes kopieren und in den Bereich **Ereignis-JSON** einfügen. Ersetzen Sie die Webhook-Signatur durch den im vorherigen Schritt berechneten Wert. ``` { "headers": { "Content-Type": "application/json", "x-webhook-signature": "2d672e7a0423fab740fbc040e801d1241f2df32d2ffd8989617a599486553e2a" }, "body": "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}" } ``` 1. Wählen Sie **Speichern**. 1. Wählen Sie ** aufrufen** aus. Die Ausgabe sollte folgendermaßen oder ähnlich aussehen: ------ #### [ Python ] ``` Status: Succeeded Test Event Name: myEvent Response: { "statusCode": 200, "body": "{\"received\": true}" } Function Logs: START RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 Version: $LATEST Processing successful payment for order 1234 END RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 REPORT RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 Duration: 1.55 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 36 MB Init Duration: 136.32 ms ``` ------ #### [ Node.js ] ``` Status: Succeeded Test Event Name: myEvent Response: { "statusCode": 200, "body": "{\"received\":true}" } Function Logs: START RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 Version: $LATEST 2025-01-10T18:05:42.062Z e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 INFO Processing successful payment for order 1234 END RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 REPORT RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 Duration: 60.10 ms Billed Duration: 61 ms Memory Size: 128 MB Max Memory Used: 72 MB Init Duration: 174.46 ms Request ID: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 ``` ------ ## Testen der Funktion mit einer HTTP-Anfrage Testen Sie Ihren Webhook-Endpunkt mit dem Befehlszeilentool curl. **Testen der Funktion mit HTTP-Anfragen** 1. Führen Sie in einem Terminal- oder Shell-Programm den folgenden curl-Befehl aus. Ersetzen Sie die URL durch den Wert für Ihren eigenen Funktions-URL-Endpunkt und ersetzen Sie die Webhook-Signatur durch die Signatur, die Sie mit Ihrem eigenen geheimen Schlüssel berechnet haben. ``` curl -X POST https://ryqgmbx5xjzxahif6frvzikpre0bpvpf.lambda-url.us-west-2.on.aws/ \ -H "Content-Type: application/json" \ -H "x-webhook-signature: d5f52b76ffba65ff60ea73da67bdf1fc5825d4db56b5d3ffa0b64b7cb85ef48b" \ -d '{"type": "payment.success", "orderId": "1234", "amount": "99.99"}' ``` Die Ausgabe sollte folgendermaßen aussehen: ``` {"received": true} ``` 1. Prüfen Sie die CloudWatch Protokolle Ihrer Funktion, um sicherzustellen, dass sie die Nutzlast korrekt analysiert hat. Gehen Sie dazu wie folgt vor: 1. Öffnen Sie die [Gruppenseite Logs](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups) in der CloudWatch Amazon-Konsole. 1. Wählen Sie die Protokollgruppe Ihrer Funktion (`/aws/lambda/myLambdaWebhook`). 1. Wählen Sie den neuesten Protokoll-Stream. In den Protokollen Ihrer Funktion sollte eine Ausgabe ähnlich der folgenden zu sehen sein: ------ #### [ Python ] ``` Processing successful payment for order 1234 ``` ------ #### [ Node.js ] ``` 2025-01-10T18:05:42.062Z e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 INFO Processing successful payment for order 1234 ``` ------ 1. Überprüfen Sie, ob Ihr Code eine ungültige Signatur erkennt, indem Sie den folgenden curl-Befehl ausführen. Ersetzen Sie die URL durch Ihren eigenen Funktions-URL-Endpunkt. ``` curl -X POST https://ryqgmbx5xjzxahif6frvzikpre0bpvpf.lambda-url.us-west-2.on.aws/ \ -H "Content-Type: application/json" \ -H "x-webhook-signature: abcdefg" \ -d '{"type": "payment.success", "orderId": "1234", "amount": "99.99"}' ``` Die Ausgabe sollte folgendermaßen aussehen: ``` {"error": "Invalid signature"} ``` ## Bereinigen Ihrer Ressourcen Sie können jetzt die Ressourcen, die Sie für dieses Tutorial erstellt haben, löschen, es sei denn, Sie möchten sie behalten. Durch das Löschen von AWS Ressourcen, die Sie nicht mehr verwenden, vermeiden Sie unnötige Kosten für Ihre AWS-Konto. **So löschen Sie die Lambda-Funktion:** 1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole. 1. Wählen Sie die Funktion aus, die Sie erstellt haben. 1. Wählen Sie **Aktionen**, **Löschen** aus. 1. Geben Sie **confirm** in das Texteingabefeld ein und wählen Sie **Delete** (Löschen) aus. Als Sie die Lambda-Funktion in der Konsole erstellt haben, hat Lambda auch eine [Ausführungsrolle](lambda-intro-execution-role.md) für Ihre Funktion erstellt. **So löschen Sie die Ausführungsrolle** 1. Öffnen Sie die Seite [Roles (Rollen)](https://console.aws.amazon.com/iam/home#/roles) in der IAM-Konsole. 1. Wählen Sie die von Lambda erstellte Ausführungsrolle aus. Die Rolle weist das Benennungsformat `myLambdaWebhook-role-` auf. 1. Wählen Sie **Löschen** aus. 1. Geben Sie den Namen der Rolle in das Texteingabefeld ein und wählen Sie **Delete** (Löschen) aus.