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