Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Création et gestion de la fonction Lambda URLs Une URL de fonction est un point de terminaison HTTP(S) dédié pour votre fonction Lambda. Vous pouvez créer et configurer une URL de fonction via la console Lambda ou l’API Lambda. **Astuce** Lambda propose deux méthodes pour appeler votre fonction via un point de terminaison HTTP : function URLs et Amazon API Gateway. Si vous ne savez pas quelle est la meilleure méthode pour votre cas d’utilisation, consultez [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](furls-http-invoke-decision.md). Lorsque vous créez une URL de fonction, Lambda génère automatiquement un point de terminaison URL unique pour vous. Une fois que vous avez créé une URL de fonction, son point de terminaison URL ne change jamais. Les points de terminaison URL de fonction ont le format suivant : ``` https://.lambda-url..on.aws ``` **Note** URLs Les fonctions ne sont pas prises en charge dans les pays suivants Régions AWS : Asie-Pacifique (Hyderabad`ap-south-2`) (), Asie-Pacifique (Malaisie`ap-southeast-4`) (), Asie-Pacifique (Nouvelle Zélande`ap-southeast-5`) (), Asie-Pacifique (Thaïlande) (`ap-southeast-6`), Asie-Pacifique (Thaïlande) (), Asie-Pacifique (Taipei`ap-southeast-7`) ()`ap-east-2`, Canada Ouest (Calgary) (), Europe (Espagne) ()`ca-west-1`, Europe (Zurich`eu-south-2`) (), Israël (Tel Aviv ()`eu-central-2`, et Moyen-Orient (Émirats arabes unis`il-central-1`) (). `me-central-1` URLs Les fonctions sont compatibles avec le double empilage, prenant en charge et. IPv4 IPv6 Après avoir configuré une URL de fonction pour votre fonction, vous pouvez invoquer cette fonction via son point de terminaison HTTP(S), via un navigateur web, curl, Postman ou n’importe quel client HTTP. **Note** Vous pouvez accéder à l’URL de votre fonction via l’Internet public uniquement. Bien que les fonctions Lambda soient compatibles AWS PrivateLink, les fonctions ne le sont URLs pas. La fonction Lambda URLs utilise des [politiques basées sur les ressources](access-control-resource-based.md) pour la sécurité et le contrôle d'accès. La fonction prend URLs également en charge les options de configuration de partage de ressources entre origines (CORS). Vous pouvez appliquer une fonction URLs à n'importe quel alias de fonction ou à la version de fonction `$LATEST` non publiée. Vous ne pouvez pas ajouter d’URL de fonction à une autre version de fonction. La section suivante explique comment créer et gérer une URL de fonction à l'aide de la console Lambda et du AWS CLI modèle CloudFormation **Topics** + [Création d’une URL de fonction (console)](#create-url-console) + [Création d’URL de fonction (AWS CLI)](#create-url-cli) + [Ajouter une URL de fonction à un CloudFormation modèle](#urls-cfn) + [Partage des ressources cross-origin (CORS)](#urls-cors) + [Fonction d'étranglement URLs](#urls-throttling) + [Fonction de désactivation URLs](#urls-deactivating) + [Fonction de suppression URLs](#w2aac39c81c53) + [Contrôler l'accès à la fonction Lambda URLs](urls-auth.md) + [Invocation d’URL de fonctions Lambda](urls-invocation.md) + [Surveillance des URL de fonctions Lambda](urls-monitoring.md) + [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](furls-http-invoke-decision.md) + [Didacticiel : création d’un point de terminaison webhook à l’aide d’une URL de fonction Lambda](urls-webhook-tutorial.md) ## Création d’une URL de fonction (console) Suivez ces étapes pour créer une URL de fonction à l’aide de la console. ### Créer une URL de fonction pour une fonction existante 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Choisissez le nom de la fonction pour laquelle vous souhaitez créer l’URL de fonction. 1. Choisissez l’onglet **Configuration**, puis **Function URL** (URL de fonction). 1. Choisissez **Create function URL** (Créer une URL de fonction). 1. Pour **le type d'authentification**, choisissez **AWS\$1IAM****NONE**. Pour plus d’informations sur l’authentification de l’URL de fonction, consultez [Contrôle d’accès](urls-auth.md). 1. (Facultatif) Sélectionnez **Configure cross-origin resource sharing (CORS)** (Configurer le partage des ressources cross-origin [CORS]), puis configurez les paramètres CORS pour l’URL de votre fonction. Pour plus d’informations sur le CORS, consultez [Partage des ressources cross-origin (CORS)](#urls-cors). 1. Choisissez **Save** (Enregistrer). Une URL de fonction est créée pour la version non publiée `$LATEST` de votre fonction. L’URL de la fonction s’affiche dans la section **Function overview** (Présentation de la fonction) de la console. ### Créer une URL de fonction pour un alias existant 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Choisissez le nom de la fonction avec l’alias pour lequel vous souhaitez créer l’URL de fonction. 1. Choisissez l’onglet **Aliases** (Alias), puis le nom de l’alias pour lequel vous souhaitez créer l’URL de fonction. 1. Choisissez l’onglet **Configuration**, puis **Function URL** (URL de fonction). 1. Choisissez **Create function URL** (Créer une URL de fonction). 1. Pour **le type d'authentification**, choisissez **AWS\$1IAM****NONE**. Pour plus d’informations sur l’authentification de l’URL de fonction, consultez [Contrôle d’accès](urls-auth.md). 1. (Facultatif) Sélectionnez **Configure cross-origin resource sharing (CORS)** (Configurer le partage des ressources cross-origin [CORS]), puis configurez les paramètres CORS pour l’URL de votre fonction. Pour plus d’informations sur le CORS, consultez [Partage des ressources cross-origin (CORS)](#urls-cors). 1. Choisissez **Enregistrer**. Cela crée une URL de fonction pour votre alias de fonction. L’URL de fonction s’affiche dans la section **Function overview** (Présentation des fonctions) de la console. ### Créer une nouvelle fonction avec une URL de fonction **Pour créer une nouvelle fonction avec une URL de fonction (console)** 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Choisissez **Créer une fonction**. 1. Sous **Basic information** (Informations de base), procédez comme suit : 1. Dans **Function name** (nom de la fonction), saisissez un nom pour votre fonction, par exemple **my-function**. 1. Pour **Runtime**, choisissez le langage d'exécution que vous préférez, tel que **Node.js 24**. 1. Pour **Architecture**, choisissez **x86\$164** ou **arm64**. 1. Développez **Permissions** (Autorisations), puis choisissez si vous souhaitez créer un nouveau rôle d’exécution ou utiliser un rôle existant. 1. Développez **Advanced settings** (Paramètres avancés), puis sélectionnez **Function URL** (URL de fonction). 1. Pour **le type d'authentification**, choisissez **AWS\$1IAM****NONE**. Pour plus d’informations sur l’authentification de l’URL de fonction, consultez [Contrôle d’accès](urls-auth.md). 1. (Facultatif) Sélectionnez **Configure cross-origin resource sharing (CORS)** (Configuration du partage des ressources cross-origin). En sélectionnant cette option lors de la création de la fonction, l’URL de votre fonction autorise par défaut les demandes de toutes les origines. Vous pouvez modifier les paramètres CORS de l’URL de votre fonction après avoir créé la fonction. Pour plus d’informations sur le CORS, consultez [Partage des ressources cross-origin (CORS)](#urls-cors). 1. Sélectionnez **Create function** (Créer une fonction). Ceci crée une nouvelle fonction avec une URL de fonction pour la `$LATEST` version non publiée de la fonction. L’URL de la fonction s’affiche dans la section **Function overview** (Présentation des fonctions) de la console. ## Création d’URL de fonction (AWS CLI) Pour créer une URL de fonction pour une fonction Lambda existante à l'aide de AWS Command Line Interface (AWS CLI), exécutez la commande suivante : ``` aws lambda create-function-url-config \ --function-name my-function \ --qualifier prod \ // optional --auth-type AWS_IAM --cors-config {AllowOrigins="https://example.com"} // optional ``` Une URL de fonction est ajoutée au qualificateur **prod** pour la fonction **my-function**. Pour plus d'informations sur ces paramètres de configuration, consultez [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) dans la référence d'API. **Note** Pour créer une URL de fonction via le AWS CLI, la fonction doit déjà exister. ## Ajouter une URL de fonction à un CloudFormation modèle Pour ajouter une `AWS::Lambda::Url` ressource à votre CloudFormation modèle, utilisez la syntaxe suivante : ### 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 + (Obligatoire) `AuthType` – Définit le type d’authentification pour l’URL de votre fonction. Les valeurs possibles sont soit `AWS_IAM`, soit `NONE`. Pour limiter l’accès aux utilisateurs authentifiés uniquement, définissez la valeur sur `AWS_IAM`. Pour contourner l’authentification IAM et autoriser n’importe quel utilisateur à envoyer des demandes à votre fonction, définissez la valeur `NONE`. + (Facultatif) `Cors` – Définit les [paramètres CORS](#urls-cors) de l’URL de votre fonction. Pour ajouter `Cors` des éléments à votre `AWS::Lambda::Url` ressource CloudFormation, utilisez la syntaxe suivante. **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 ``` + (Facultatif) `Qualifier` – Le nom de l’alias. + (Obligatoire) `TargetFunctionArn` – Le nom ou l’ARN (Amazon Resource Name) de la fonction Lambda. Les formats de nom valides sont notamment les suivants : + **Nom de fonction** – `my-function` + **ARN de fonction** – `arn:aws:lambda:us-west-2:123456789012:function:my-function` + **ARN partiel** – `123456789012:function:my-function` ## Partage des ressources cross-origin (CORS) Pour définir comment différentes origines peuvent accéder à l’URL de votre fonction, utilisez le [partage de ressources cross-origin (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Nous vous recommandons de configurer CORS si vous avez l’intention d’appeler l’URL de votre fonction à partir d’un autre domaine. Lambda prend en charge les en-têtes CORS suivants pour les fonctions. URLs | En-têtes CORS | Propriété de configuration CORS | Exemples de valeur | | --- | --- | --- | | [ Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) | `AllowOrigins` | `*` (autoriser toutes les origines) `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` (par défaut), `300` | Lorsque vous configurez CORS pour une URL de fonction à l'aide de la console Lambda ou du AWS CLI, Lambda ajoute automatiquement les en-têtes CORS à toutes les réponses via l'URL de la fonction. Vous pouvez également ajouter manuellement des en-têtes CORS à la réponse de votre fonction. En cas de conflit d’en-têtes, le comportement attendu dépend du type de la requête : + Pour les requêtes en amont, telles que les requêtes OPTIONS, les en-têtes CORS configurés sur l’URL de la fonction ont priorité. Lambda renvoie uniquement ces en-têtes CORS dans la réponse. + Pour les requêtes autres que celles effectuées en amont, telles que les requêtes GET ou POST, Lambda renvoie à la fois les en-têtes CORS configurés sur l’URL de la fonction, ainsi que les en-têtes CORS renvoyés par la fonction. Cela peut entraîner une duplication d’en-têtes CORS dans la réponse. Vous pouvez voir une erreur similaire à ce qui suit : `The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed`. En général, nous recommandons de configurer tous les paramètres CORS sur l’URL de la fonction, plutôt que d’envoyer les en-têtes CORS manuellement dans la réponse de la fonction. ## Fonction d'étranglement URLs La limitation limite le débit auquel la fonction traite les demandes. Cette fonction est utile dans de nombreuses situations, notamment pour empêcher votre fonction de surcharger les ressources en aval ou pour gérer une augmentation soudaine des demandes. Vous pouvez limiter le débit des demandes traitées par votre fonction Lambda via une URL de fonction en configurant la simultanéité réservée. La simultanéité réservée limite le nombre maximal d’invocations simultanées pour votre fonction. Le débit de demandes maximal par seconde (RPS) de votre fonction est équivalent à 10 fois la simultanéité réservée configurée. Par exemple, si vous configurez votre fonction avec une simultanéité réservée de 100, le RPS maximal est de 1 000. Lorsque la simultanéité de la fonction dépasse la simultanéité réservée, l’URL de votre fonction renvoie un code d’état HTTP `429`. Si votre fonction reçoit une demande qui dépasse le maximum de 10 fois le RPS par rapport à la simultanéité réservée configurée, vous recevez également une erreur HTTP `429`. Pour de plus amples informations sur la simultanéité réservée, consultez [Configuration de la simultanéité réservée pour une fonction](configuration-concurrency.md). ## Fonction de désactivation URLs En cas d’urgence, vous pouvez rejeter tout le trafic vers l’URL de fonction. Pour désactiver votre URL de fonction, définissez la simultanéité réservée sur zéro. Cela limite toutes les demandes envoyées à l’URL de votre fonction, ce qui entraîne des réponses d’état HTTP `429`. Pour réactiver l’URL de votre fonction, supprimez la configuration de simultanéité réservée ou définissez la configuration sur un montant supérieur à zéro. ## Fonction de suppression URLs Lorsque vous supprimez une URL de fonction, vous ne pouvez pas la récupérer. La création d’une nouvelle URL de fonction entraînera une adresse URL différente. **Note** Si vous supprimez une URL de fonction avec un type d’authentification `NONE`, Lambda ne supprime pas automatiquement la politique basée sur les ressources associée. Si vous souhaitez supprimer cette politique, vous devez le faire manuellement. 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Choisissez le nom de la fonction. 1. Choisissez l’onglet **Configuration**, puis **Function URL** (URL de fonction). 1. Sélectionnez **Delete** (Supprimer). 1. Entrez le mot *delete* dans le champ pour confirmer la suppression. 1. Sélectionnez **Delete (Supprimer)**. **Note** Lorsque vous supprimez une fonction qui possède une URL de fonction, Lambda supprime cette URL de manière asynchrone. Si vous créez immédiatement une nouvelle fonction portant le même nom dans le même compte, il est possible que l’URL de la fonction d’origine soit mappée à la nouvelle fonction au lieu d’être supprimée. # Contrôler l'accès à la fonction Lambda URLs **Note** À compter d'octobre 2025, la nouvelle fonction URLs nécessitera à la fois des `lambda:InvokeFunction` autorisations `lambda:InvokeFunctionUrl` et des autorisations. Vous pouvez contrôler l'accès à votre fonction Lambda à URLs l'aide du [AuthType](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html#lambda-CreateFunctionUrlConfig-request-AuthType)paramètre combiné aux [politiques basées sur les ressources](access-control-resource-based.md) associées à votre fonction spécifique. La configuration de ces deux composants détermine qui peut invoquer ou exécuter d’autres actions administratives sur l’URL de votre fonction. Le paramètre `AuthType` détermine comment Lambda authentifie ou autorise les demandes vers l’URL de votre fonction. Lorsque vous configurez l’URL de votre fonction, vous devez spécifier l’une des options `AuthType` suivantes : + `AWS_IAM`— Lambda utilise Gestion des identités et des accès AWS (IAM) pour authentifier et autoriser les demandes en fonction de la politique d'identité du principal IAM et de la politique basée sur les ressources de la fonction. Choisissez cette option si vous souhaitez que seuls les utilisateurs et les rôles authentifiés invoquent votre fonction via l’URL de la fonction. + `NONE` – Lambda n’effectue aucune authentification avant d’invoquer votre fonction. Toutefois, la stratégie basée sur les ressources de votre fonction est toujours en vigueur et doit accorder un accès public avant que l’URL de votre fonction puisse recevoir des demandes. Choisissez cette option pour autoriser un accès public et non authentifié à l’URL de votre fonction. Pour obtenir des informations supplémentaires sur la sécurité, vous pouvez AWS Identity and Access Management Access Analyzer obtenir une analyse complète de l'accès externe à l'URL de votre fonction. IAM Access Analyzer surveille également les autorisations nouvelles ou mises à jour sur vos fonctions Lambda afin de vous aider à identifier les autorisations accordant un accès public et entre comptes. Vous pouvez utiliser IAM Access Analyzer sans frais. Pour démarrer avec IAM Access Analyzer, consultez [Utilisation d’ AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Cette page contient des exemples de politiques basées sur les ressources pour les deux types d'authentification et explique comment créer ces politiques à l'aide de l'opération [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)API ou de la console Lambda. Pour plus d’informations sur la procédure d’invocation de l’URL de votre fonction après avoir configuré les autorisations, consultez [Invocation d’URL de fonctions Lambda](urls-invocation.md). **Topics** + [Utilisation du type d’authentification `AWS_IAM`](#urls-auth-iam) + [Utilisation du type d’authentification `NONE`](#urls-auth-none) + [Gouvernance et contrôle d’accès](#urls-governance) ## Utilisation du type d’authentification `AWS_IAM` Si vous choisissez le type d’authentification `AWS_IAM`, les utilisateurs qui ont besoin d’invoquer l’URL de votre fonction Lambda doivent avoir les autorisations `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`. Selon la personne qui effectue la demande d’invocation, vous devrez peut-être accorder cette autorisation à l’aide d’une [stratégie basée sur les ressources](access-control-resource-based.md). Si le principal qui fait la demande se trouve dans la même URL Compte AWS que l'URL de la fonction, il doit **soit** disposer `lambda:InvokeFunctionUrl` d'`lambda:InvokeFunction`autorisations dans sa [politique basée sur l'identité, **soit** avoir des autorisations qui lui sont accordées dans le cadre de la politique basée sur](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) les ressources de la fonction. En d’autres termes, une stratégie basée sur les ressources est facultative si l’utilisateur possède déjà des autorisations `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction` dans sa stratégie basée sur l’identité. L’évaluation des politiques suit les règles décrites dans la [Logique d’évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html). Si le principal qui fait la demande se trouve dans un autre compte, il doit avoir **à la fois** une stratégie basée sur l’identité qui lui donne des autorisations `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`, **et** des autorisations qui lui sont accordées dans une stratégie basée sur les ressources de la fonction qu’il essaie d’invoquer. L’évaluation des stratégies suit les règles décrites dans [Comment déterminer si une demande d’accès entre comptes est autorisée](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html#policy-eval-cross-account). La politique basée sur les ressources suivante permet au `example` rôle in d'invoquer l'URL Compte AWS `444455556666` de la fonction associée à la fonction. `my-function` La touche de InvokedViaFunctionUrl contexte [lambda :](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html#lambda-AddPermission-request-InvokedViaFunctionUrl) limite l'`lambda:InvokeFunction`action aux appels d'URL de fonction. Cela signifie que le principal doit utiliser l’URL de la fonction pour invoquer la fonction. Si vous n’incluez pas `lambda:InvokedViaFunctionUrl`, le principal peut invoquer votre fonction via d’autres méthodes d’invocation, en plus de l’URL de la fonction. **Example – Stratégie intercompte basée sur une ressource** **** ``` { "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" } } } ] } ``` Vous pouvez créer cette politique basée sur les ressources via la console en suivant les étapes suivantes : **Comment accorder des autorisations d’invocation d’URL à un autre compte (console)** 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Choisissez le nom de la fonction pour laquelle vous souhaitez accorder des autorisations d’invocation d’URL. 1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations). 1. Sous **Resource-based policy** (stratégie basée sur une ressource), choisissez **Add permissions** (Ajouter des autorisations). 1. Choisissez **Function URL** (URL de fonction). 1. Pour le **type d'authentification**, choisissez **AWS\$1IAM**. 1. Entrez un **ID de déclaration** pour votre déclaration de politique. 1. Pour **Principal**, saisissez l’ID de compte ou l’Amazon Resource Name (ARN) de l’utilisateur ou du rôle auquel vous souhaitez accorder des autorisations. Par exemple : **444455556666**. 1. Choisissez **Enregistrer**. Vous pouvez également créer cette politique à l'aide des commandes [add permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) AWS Command Line Interface (AWS CLI) suivantes. Lorsque vous utilisez le AWS CLI, vous devez ajouter les `lambda:InvokeFunction` instructions `lambda:InvokeFunctionUrl` et séparément. Par exemple : ``` 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 ``` ## Utilisation du type d’authentification `NONE` **Important** Lorsque le type d’authentification de votre URL de fonction est `NONE` et que vous disposez d’une [politique basée sur les ressources](access-control-resource-based.md) qui accorde un accès public, tout utilisateur non authentifié ayant de votre URL de fonction peut invoquer votre fonction. Dans certains cas, vous pouvez souhaiter que votre URL de fonction soit publique. Vus pourriez souhaiter répondre aux demandes envoyées directement à partir d’un navigateur Web. Pour autoriser l’accès public à votre URL de fonction, choisissez le type d’authentification `NONE`. Si vous choisissez le `NONE` type d’authentification, Lambda n’utilise pas IAM pour authentifier les demandes vers votre URL de fonction. Toutefois, votre fonction doit disposer d’une politique basée sur les ressources qui autorise `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`. Lorsque vous créez une URL de fonction avec un type d'authentification à `NONE` l'aide de la console ou AWS Serverless Application Model (AWS SAM), Lambda crée automatiquement la politique basée sur les ressources pour vous. Si vous utilisez directement l'API AWS CLI AWS CloudFormation, ou l'API Lambda, vous devez [ajouter la politique vous-même](#policy-cli). Nous vous recommandons d'inclure la clé de InvokedViaFunctionUrl contexte [lambda :](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html#lambda-AddPermission-request-InvokedViaFunctionUrl) dans vos politiques basées sur les ressources lorsque vous utilisez le `NONE` type d'authentification. Cette clé de contexte garantit que la fonction ne peut être invoquée que via l’URL de la fonction et non via d’autres méthodes d’invocation. Notez ce qui suit concernant cette politique : + Toutes les entités peuvent appeler `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`. Cela signifie que toute personne disposant de votre URL de fonction peut invoquer votre fonction. + La valeur de la clé de condition `lambda:FunctionUrlAuthType` est `NONE`. Cela signifie que la déclaration de stratégie n’autorise l’accès que lorsque le type d’authentification de votre URL de fonction est également `NONE`. + La condition `lambda:InvokedViaFunctionUrl` garantit que la fonction ne peut être invoquée que via l’URL de la fonction et non via d’autres méthodes d’invocation. **Example – Politique basée sur les ressources par défaut pour le type d’authentification 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" } } } ] } ``` **Créez la politique basée sur les ressources à l'aide du AWS CLI** À moins que vous n'utilisiez la console ou AWS SAM que vous ne créiez une URL de fonction avec un type d'authentification`NONE`, vous devez ajouter vous-même la politique basée sur les ressources. Utilisez les commandes suivantes pour créer des instructions pour les autorisations `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`. Chaque instruction doit être ajoutée dans une commande distincte. ``` 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 ``` **Note** Si vous supprimez une URL de fonction avec un type d’authentification `NONE`, Lambda ne supprime pas automatiquement la politique basée sur les ressources associée. Si vous souhaitez supprimer cette politique, vous devez le faire manuellement. Si la stratégie basée sur les ressources d’une fonction n’accorde pas les autorisations `lambda:invokeFunctionUrl` et `lambda:InvokeFunction`, les utilisateurs obtiendront alors un code d’erreur 403 Forbidden lorsqu’ils essaient d’invoquer l’URL de votre fonction. Cela se produira même si l’URL de la fonction utilise le type d’authentification `NONE`. ## Gouvernance et contrôle d’accès Outre les autorisations d'appel d'URL de fonction, vous pouvez également contrôler l'accès aux actions utilisées pour configurer la fonction URLs. Lambda prend en charge les actions de politique IAM suivantes pour les fonctions : URLs + `lambda:InvokeFunctionUrl` – Invoquer une fonction Lambda à l’aide de l’URL de fonction. + `lambda:CreateFunctionUrlConfig` – Créer une URL de fonction et définir son `AuthType`. + `lambda:UpdateFunctionUrlConfig` – Mettre à jour la configuration d’une URL de fonction et son `AuthType`. + `lambda:GetFunctionUrlConfig` – Affichez les détails d’une URL de fonction. + `lambda:ListFunctionUrlConfigs` – Répertorier les configurations d’URL de fonction. + `lambda:DeleteFunctionUrlConfig` – Supprimer une URL de fonction. Pour autoriser ou refuser l'accès à l'URL des fonctions à d'autres AWS entités, incluez ces actions dans les politiques IAM. Par exemple, la politique suivante accorde au `example` rôle dans les Compte AWS `444455556666` autorisations de mettre à jour l'URL de la fonction pour la fonction **my-function** dans le compte`123456789012`. **Example exemple de stratégie d’URL de fonction inter-comptes** **** ``` { "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" } ] } ``` ### Clés de condition Pour un contrôle d'accès précis à votre fonction URLs, utilisez les touches contextuelles de condition. Lambda prend en charge les clés de contexte suivantes pour la fonction : URLs + `lambda:FunctionUrlAuthType` : définit une valeur d’énumération décrivant le type d’authentification utilisé par l’URL de votre fonction. La valeur peut être `AWS_IAM` ou `NONE`. + `lambda:InvokedViaFunctionUrl` : limite l’action `lambda:InvokeFunction` aux appels effectués via l’URL de la fonction. Cela garantit que la fonction ne peut être invoquée que via l’URL de la fonction et non via d’autres méthodes d’invocation. Pour des exemples de politiques basées sur les ressources qui utilisent la clé de contexte `lambda:InvokedViaFunctionUrl`, consultez les exemples dans [Utilisation du type d’authentification `AWS_IAM`](#urls-auth-iam) et [Utilisation du type d’authentification `NONE`](#urls-auth-none). Vous pouvez utiliser ces clés de contexte dans les stratégies associées à votre fonction. Par exemple, vous souhaiterez peut-être limiter les personnes autorisées à modifier la configuration de votre fonction URLs. Pour rejeter toutes les demandes `UpdateFunctionUrlConfig` à n’importe quelle fonction avec un type d’authentification URL `NONE`, vous pouvez définir la stratégie suivante : **Example exemple de stratégie d’URL de fonction avec refus explicite** **** ``` { "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" } } } ] } ``` Pour accorder le `example` rôle dans Compte AWS `444455556666` les autorisations de création `CreateFunctionUrlConfig` et de `UpdateFunctionUrlConfig` requêtes sur les fonctions avec un type d'authentification URL`AWS_IAM`, vous pouvez définir la politique suivante : **Example exemple de stratégie d’URL de fonction avec autorisation explicite** **** ``` { "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" } } } ] } ``` Vous pouvez également utiliser cette clé de condition dans une [stratégie de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP). SCPs À utiliser pour gérer les autorisations dans l'ensemble d'une organisation dans AWS Organizations. Par exemple, pour empêcher les utilisateurs de créer ou de mettre à jour des fonctions URLs utilisant autre chose que le type d'`AWS_IAM`authentification, appliquez la politique de contrôle des services suivante : **Example exemple d’URL de fonction SCP avec refus explicite** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action":[ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:*:123456789012:function:*", "Condition": { "StringNotEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } } ] } ``` # Invocation d’URL de fonctions Lambda Une URL de fonction est un point de terminaison HTTP(S) dédié pour votre fonction Lambda. Vous pouvez créer et configurer une URL de fonction via la console Lambda ou l’API Lambda. **Astuce** Lambda propose deux méthodes pour invoquer votre fonction via un point de terminaison HTTP : les URL de fonction et Amazon API Gateway. Si vous ne savez pas quelle est la meilleure méthode pour votre cas d’utilisation, consultez [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](furls-http-invoke-decision.md). Lorsque vous créez une URL de fonction, Lambda génère automatiquement un point de terminaison URL unique pour vous. Une fois que vous avez créé une URL de fonction, son point de terminaison URL ne change jamais. Les points de terminaison URL de fonction ont le format suivant : ``` https://.lambda-url..on.aws ``` **Note** Les URL de fonction ne sont pas prises en charge dans les Régions AWS suivantes : Asie-Pacifique (Hyderabad) (`ap-south-2`), Asie-Pacifique (Melbourne) (`ap-southeast-4`), Asie-Pacifique (Malaisie) (`ap-southeast-5`), Asie-Pacifique (Nouvelle-Zélande) (`ap-southeast-6`), Asie-Pacifique (Thaïlande) (`ap-southeast-7`), Asie-Pacifique (Taipei) (`ap-east-2`), Canada Ouest (Calgary) (`ca-west-1`), Europe (Espagne) (`eu-south-2`), Europe (Zurich) (`eu-central-2`), Israël (Tel Aviv) (`il-central-1`) et Moyen-Orient (EAU) (`me-central-1`). Les URL de fonctions sont compatibles avec la pile double, prenant en charge les adresses IPv4 et IPv6. Après avoir configuré votre URL de fonction, vous pouvez invoquer votre fonction à travers son point de terminaison HTTP(S) via un navigateur Web, curl, Postman, ou n’importe quel client HTTP. Pour invoquer l’URL d’une fonction, vous devez avoir les autorisations `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`. Pour de plus amples informations, consultez [Contrôle d’accès](urls-auth.md). **Topics** + [Principes de base de l’invocation d’une URL de fonction](#urls-invocation-basics) + [Charges utiles de demandes et de réponses](#urls-payloads) ## Principes de base de l’invocation d’une URL de fonction Si votre URL de votre fonction utilise le type d’authentification `AWS_IAM`, vous devez signer chaque demande HTTP en utilisant [AWSSignature Version 4 (SigV4)](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html). Des outils comme [Postman](https://quickstarts.postman.com/guide/aws/index.html?index=..%2F..index#2) offrent des moyens intégrés de signer vos demandes avec SigV4. Si vous n’utilisez pas d’outil pour signer des demandes HTTP sur l’URL de votre fonction, vous devez signer manuellement chaque demande à l’aide de SigV4. Lorsque l’URL de votre fonction reçoit une demande, Lambda calcule également la signature SigV4. Lambda traite la demande uniquement si les signatures correspondent. Pour obtenir des instructions sur la signature manuelle de vos demandes avec SigV4, consultez [Signature de demandes AWS avec Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) dans le *Guide Référence générale d'Amazon Web Services*. Si l’URL de votre fonction utilise le type d’authentification `NONE`, vous n’avez pas besoin de signer vos demandes avec SigV4. Vous pouvez invoquer votre fonction via un navigateur Web, curl, Postman ou n’importe quel client HTTP. Pour tester des demandes `GET` simples vers votre fonction, utilisez un navigateur web. Par exemple, si l’URL de votre fonction est `https://abcdefg.lambda-url.us-east-1.on.aws`, et si elle prend en compte un paramètre de chaîne `message`, l’URL de votre demande peut se présenter comme suit : ``` https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld ``` Pour tester d’autres demandes HTTP, telles qu’une demande `POST`, vous pouvez utiliser un outil tel que curl. Par exemple, si vous souhaitez inclure certaines données JSON dans une demande `POST` pour l’URL de votre fonction, vous pouvez utiliser la commande curl suivante : ``` curl -v 'https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld' \ -H 'content-type: application/json' \ -d '{ "example": "test" }' ``` ## Charges utiles de demandes et de réponses Lorsqu’un client appelle l’URL de votre fonction, Lambda mappe la demande sur un objet événement avant de la transmettre à votre fonction. La réponse de votre fonction est ensuite mappée à une réponse HTTP que Lambda renvoie au client via l’URL de la fonction. Les formats d’événements de demande et de réponse suivent le même schéma que le [format de charge utile version 2.0 d’Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html#http-api-develop-integrations-lambda.proxy-format). ### Format de la charge utile de demande Une charge utile de demande a la structure suivante : ``` { "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 } ``` | Paramètre | Description | Exemple | | --- | --- | --- | | `version` | La version du format de la charge utile pour cet événement. Les URL de fonctions Lambda prennent actuellement en charge [le format de charge utile version 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` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `$default` comme espace réservé. | `$default` | | `rawPath` | Chemin d’accès de la demande. Par exemple, si l’URL de la demande est `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo`, alors la valeur du chemin brut est `/example/test/demo`. | `/example/test/demo` | | `rawQueryString` | La chaîne brute contenant les paramètres de la chaîne de la requête de la demande. Les caractères pris en charge sont les suivants : `a-z`, `A-Z`, `0-9`, `.`, `_`, `-`, `%`, `&`, `=`, et `+`. | `"?parameter1=value1¶meter2=value2"` | | `cookies` | Un tableau contenant tous les cookies envoyés dans le cadre de la demande. | `["Cookie_1=Value_1", "Cookie_2=Value_2"]` | | `headers` | La liste des en-têtes de demande, présentée sous forme de paires valeur-clé. | `{"header1": "value1", "header2": "value2"}` | | `queryStringParameters` | Paramètres de requête pour la demande. Par exemple, si l’URL de la demande est `https://{url-id}.lambda-url.{region}.on.aws/example?name=Jane`, alors la valeur `queryStringParameters` est un objet JSON avec une clé `name` et une valeur `Jane`. | `{"name": "Jane"}` | | `requestContext` | Un objet qui contient des informations supplémentaires sur la demande, comme `requestId`, l’heure de la demande, et l’identité de l’appelant s’il est autorisé via Gestion des identités et des accès AWS (IAM). | | | `requestContext.accountId` | L’identifiant Compte AWS du propriétaire de la fonction. | `"123456789012"` | | `requestContext.apiId` | L’identifiant de l’URL de la fonction. | `"33anwqw8fj"` | | `requestContext.authentication` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `null`. | `null` | | `requestContext.authorizer` | Un objet qui contient des informations sur l’identité de l’appelant si l’URL de la fonction utilise le type d’authentification `AWS_IAM`. Sinon, Lambda définit cette valeur sur `null`. | | | `requestContext.authorizer.iam.accessKey` | La clé d’accès de l’identité de l’appelant. | `"AKIAIOSFODNN7EXAMPLE"` | | `requestContext.authorizer.iam.accountId` | L’identifiant Compte AWS de l’identité de l’appelant. | `"111122223333"` | | `requestContext.authorizer.iam.callerId` | L’ID (ID d’utilisateur) de l’appelant. | `"AIDACKCEVSQ6C2EXAMPLE"` | | `requestContext.authorizer.iam.cognitoIdentity` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `null` ou l’exclut de JSON. | `null` | | `requestContext.authorizer.iam.principalOrgId` | L’ID de l’organisation du principal associé à l’ID de l’appelant. | `"AIDACKCEVSQORGEXAMPLE"` | | `requestContext.authorizer.iam.userArn` | L’Amazon Resource Name (ARN) utilisateur de l’identité de l’appelant. | `"arn:aws:iam::111122223333:user/example-user"` | | `requestContext.authorizer.iam.userId` | L’identifiant utilisateur de l’identité de l’appelant. | `"AIDACOSFODNN7EXAMPLE2"` | | `requestContext.domainName` | Le nom de domaine de l’URL de la fonction. | `".lambda-url.us-west-2.on.aws"` | | `requestContext.domainPrefix` | Le nom de domaine de l’URL de la fonction. | `""` | | `requestContext.http` | Un objet qui contient des informations sur la demande HTTP. | | | `requestContext.http.method` | La méthode HTTP utilisée dans cette demande. Les valeurs valides sont les suivantes : `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PATCH` et `DELETE`. | `GET` | | `requestContext.http.path` | Chemin d’accès de la demande. Par exemple, si l’URL de la demande est `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo`, alors la valeur du chemin est `/example/test/demo`. | `/example/test/demo` | | `requestContext.http.protocol` | Le protocole de la demande. | `HTTP/1.1` | | `requestContext.http.sourceIp` | L’adresse IP source de la connexion TCP immédiate qui fait la demande. | `123.123.123.123` | | `requestContext.http.userAgent` | La valeur de l’en-tête de la demande Utilisateur-Agent. | `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Gecko/20100101 Firefox/42.0` | | `requestContext.requestId` | L’identifiant de la demande d’invocation. Vous pouvez utiliser cet ID pour suivre les journaux d’invocation liés à votre fonction. | `e1506fd5-9e7b-434f-bd42-4f8fa224b599` | | `requestContext.routeKey` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `$default` comme espace réservé. | `$default` | | `requestContext.stage` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `$default` comme espace réservé. | `$default` | | `requestContext.time` | Horodatage de la demande. | `"07/Sep/2021:22:50:22 +0000"` | | `requestContext.timeEpoch` | L’horodatage de la demande, en heure d’époque Unix. | `"1631055022677"` | | `body` | Le corps de la demande. Si le type de contenu de la demande est binaire, le corps est codé en base64. | `{"key1": "value1", "key2": "value2"}` | | `pathParameters` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `null` ou l’exclut de JSON. | `null` | | `isBase64Encoded` | `TRUE` si le corps est une charge utile binaire et codé en base64. Sinon `FALSE`. | `FALSE` | | `stageVariables` | Les URL de fonctions n’utilisent pas ce paramètre. Lambda le définit sur `null` ou l’exclut du JSON. | `null` | ### Format de la charge utile de la réponse Lorsque votre fonction renvoie une réponse, Lambda analyse la réponse et la convertit en réponse HTTP. Les charges utiles de la réponse de fonction ont le format suivant : ``` { "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 déduit le format de réponse pour vous. Si votre fonction renvoie un JSON valide et ne renvoie pas un `statusCode`, Lambda assume ce qui suit : + `statusCode` is `200`. **Note** Les valeurs de `statusCode` valides sont comprises entre 100 et 599. + `content-type` is `application/json`. + `body` est la réponse de la fonction. + `isBase64Encoded` is `false`. Les exemples suivants montrent comment la sortie de votre fonction Lambda est mappée à la charge utile de réponse et comment la charge utile de réponse est mappée à la réponse HTTP finale. Lorsque le client invoque l’URL de votre fonction, il voit la réponse HTTP. **Exemple de sortie pour une réponse de chaîne** | Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) | | --- | --- | --- | | 
"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!"
| **Exemple de sortie pour une réponse JSON** | Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) | | --- | --- | --- | | 
{
  "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!"
}
| **Exemple de sortie pour une réponse personnalisée** | Sortie de la fonction Lambda | Sortie de réponse interprétée | Réponse HTTP (ce que voit le client) | | --- | --- | --- | | 
{
   "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 Pour renvoyer des cookies depuis votre fonction, n’ajoutez pas manuellement des en-têtes `set-cookie`. Incluez plutôt les cookies dans votre objet de charge utile de réponse. Lambda les interprète automatiquement et les ajoute comme en-têtes `set-cookie` de votre réponse HTTP, comme dans l’exemple suivant. | Sortie de la fonction Lambda | Réponse HTTP (ce que voit le client) | | --- | --- | | 
{
   "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!"
}
| # Surveillance des URL de fonctions Lambda Vous pouvez utiliser AWS CloudTrail et Amazon CloudWatch pour surveiller vos URL de fonctions. **Topics** + [URL de fonctions de surveillance avec CloudTrail](#urls-cloudtrail) + [Métriques CloudWatch pour les URL de fonctions](#urls-cloudwatch) ## URL de fonctions de surveillance avec CloudTrail Pour les URL de fonctions, Lambda prend automatiquement en charge la journalisation des opérations API suivantes en tant qu'événements dans des fichiers journaux CloudTrail : + [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) Chaque entrée de journal contient des informations sur l'identité de l'appelant, le moment où la demande a été faite, et d'autres détails. Vous pouvez voir tous les événements des 90 derniers jours en consultant votre **Event history** (Historique des événements) CloudTrail. Pour conserver les enregistrements de plus de 90 jours, vous pouvez créer un journal d'activité. Par défaut, CloudTrail ne journalise pas les demandes `InvokeFunctionUrl`, qui sont considérées comme des événements de données. Cependant, vous pouvez activer la journalisation des événements de données dans CloudTrail. Pour plus d’informations, consultez [Consignation d’événements de données pour les journaux d’activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) dans le *Guide de l’utilisateur AWS CloudTrail*. ## Métriques CloudWatch pour les URL de fonctions Lambda envoie des métriques agrégées concernant les demandes d'URL de fonction vers CloudWatch. Avec ces métriques, vous pouvez surveiller les URL de vos fonctions, créer des tableaux de bord et configurer des alarmes dans la console CloudWatch. Les URL de fonctions prennent en charge les métriques d'invocation suivantes. Nous vous recommandons de consulter ces métriques avec la statistique `Sum`. + `UrlRequestCount` – Nombre de demandes faites vers cette URL de fonction. + `Url4xxCount` – Nombre de demandes ayant retourné un code d'état HTTP 4XX. Les codes de la série 4XX indiquent des erreurs côté client, telles que des demandes erronées. + `Url5xxCount` – Nombre de demandes ayant retourné un code d'état HTTP 5XX. Les codes de la série 5XX indiquent des erreurs côté serveur, telles que des erreurs de fonction et des délais d'attente. Les URL de fonctions prennent également en charge la métrique de performance suivante. Nous vous recommandons de consulter ces métriques avec les statistiques `Average` ou `Max`. + `UrlRequestLatency` – Le temps écoulé entre le moment où l'URL de fonction reçoit une demande et celui où l'URL de fonction renvoie une réponse. Chacune de ces métriques d'invocation et de performance prend en charge les dimensions suivantes : + `FunctionName` – Affichez les métriques agrégées pour les URL de fonctions attribuées à la version non publiée `$LATEST` d'une fonction, ou à tout alias de la fonction. Par exemple, `hello-world-function`. + `Resource` – Affichez les métriques d'une URL de fonction spécifique. Cela est défini par un nom de fonction, accompagné de la version non publiée `$LATEST` de la fonction ou d'un alias de la fonction. Par exemple, `hello-world-function:$LATEST`. + `ExecutedVersion` – Affichez les métriques d'une URL de fonction spécifique en fonction de la version exécutée. Vous pouvez utiliser cette dimension principalement pour suivre l'URL de la fonction affectée à la version non publiée `$LATEST`. # Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP De nombreux cas d’utilisation courants de Lambda impliquent d’invoquer votre fonction à l’aide d’une requête HTTP. Vous pourriez souhaiter qu’une application Web invoque votre fonction par le biais d’une demande de navigateur. Les fonctions Lambda peuvent également être utilisées pour créer un REST complet APIs, gérer les interactions des utilisateurs à partir d'applications mobiles, traiter des données provenant de services externes via des appels HTTP ou créer des webhooks personnalisés. Les sections suivantes expliquent quels sont vos choix pour invoquer Lambda via HTTP et fournissent des informations qui vous aideront à prendre la bonne décision pour votre cas d’utilisation particulier. ## Options proposées lors de la sélection d’une méthode d’appel HTTP Lambda propose deux méthodes principales pour appeler une fonction à l'aide d'une requête HTTP : [function URLs](urls-configuration.md) et [API](services-apigateway.md) Gateway. Les principales différences entre ces deux options sont les suivantes : + **La fonction Lambda URLs** fournit un point de terminaison HTTP simple et direct pour une fonction Lambda. Elles sont optimisées pour la simplicité et la rentabilité et constituent le moyen le plus rapide d’exposer une fonction Lambda via HTTP. + **API Gateway** est un service plus avancé permettant de créer des fonctionnalités complètes APIs. API Gateway est optimisé pour créer et gérer des productions APIs à grande échelle et fournit des outils complets pour la sécurité, la surveillance et la gestion du trafic. ## Recommandations si vous connaissez déjà vos besoins Si vous connaissez déjà bien vos besoins, voici nos recommandations de base : Nous recommandons cette **[fonction URLs](urls-configuration.md)** pour les applications simples ou le prototypage où vous n'avez besoin que de méthodes d'authentification et de request/response manipulation de base et où vous souhaitez réduire les coûts et la complexité au minimum. **[API Gateway](services-apigateway.md)** est un meilleur choix pour les applications de production à grande échelle ou pour les cas où vous avez besoin de fonctionnalités plus avancées telles que la prise en charge d'[OpenAPI Description](https://www.openapis.org/), un choix d'options d'authentification, des noms de domaine personnalisés ou une request/response gestion riche, notamment la régulation, la mise en cache et la transformation. request/response ## Éléments à prendre en compte lors de la sélection d’une méthode pour invoquer votre fonction Lambda Lorsque vous choisissez entre function URLs et API Gateway, vous devez prendre en compte les facteurs suivants : + Vos besoins en matière d'authentification, par exemple si vous avez besoin OAuth d'Amazon Cognito pour authentifier les utilisateurs + Vos exigences en matière de mise à l’échelle et la complexité de l’API que vous souhaitez implémenter + Si vous avez besoin de fonctionnalités avancées telles que la validation et le request/response formatage des demandes + Vos besoins en matière de surveillance + Vos objectifs en matière de coûts La compréhension de ces facteurs vous permettra de choisir l’option qui répond le mieux à vos exigences en matière de sécurité, de complexité et de coût. Le tableau suivant résume les différences entre les deux options. ### Authentification + **La fonction URLs** fournit des options d'authentification de base via Gestion des identités et des accès AWS (IAM). Vous pouvez configurer vos points de terminaison pour qu’ils soient publics (aucune authentification) ou pour qu’ils nécessitent une authentification IAM. Avec l'authentification IAM, vous pouvez utiliser des AWS informations d'identification standard ou des rôles IAM pour contrôler l'accès. Bien que simple à configurer, cette approche offre des options limitées par rapport aux autres méthodes d’authentification. + **API Gateway** donne accès à une gamme plus complète d’options d’authentification. Outre l'authentification IAM, vous pouvez utiliser des autorisateurs [Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (logique d'authentification personnalisée), des groupes d'utilisateurs Amazon [Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) et des flux .0. OAuth2 Cette flexibilité vous permet de mettre en œuvre des schémas d’authentification complexes, notamment des fournisseurs d’authentification tiers, une authentification basée sur des jetons et une authentification multifactorielle. ### Traitement des requêtes et réponses + **La fonction URLs** fournit une gestion de base des requêtes et des réponses HTTP. Elles prennent en charge les méthodes HTTP standard et créent une prise en charge intégrée du partage des ressources entre origines (CORS, cross-origin resource sharing). Bien qu’elles puissent gérer naturellement les charges utiles JSON et les paramètres de requête, elles n’offrent pas de fonctionnalités de transformation ou de validation des requêtes. La gestion des réponses est tout aussi simple : le client reçoit la réponse de votre fonction Lambda exactement telle que Lambda la renvoie. + **API Gateway** fournit des fonctionnalités sophistiquées de gestion des requêtes et des réponses. Vous pouvez définir des validateurs de demandes, transformer les demandes et les réponses à l'aide de modèles de mappage, configurer request/response des en-têtes et implémenter la mise en cache des réponses. API Gateway prend également en charge les charges utiles binaires et les noms de domaine personnalisés et peut modifier les réponses avant qu’elles n’atteignent le client. Vous pouvez configurer des modèles pour la request/response validation et la transformation à l'aide du schéma JSON. ### Mise à l’échelle + Les **fonctions** s' URLsadaptent directement aux limites de simultanéité de votre fonction Lambda et gérez les pics de trafic en augmentant la taille de votre fonction jusqu'à sa limite de simultanéité maximale configurée. Une fois cette limite atteinte, Lambda répond aux requêtes supplémentaires avec des réponses HTTP 429. Il n’existe aucun mécanisme de mise en file d’attente intégré. La gestion de la mise à l’échelle dépend donc entièrement de la configuration de votre fonction Lambda. Par défaut, les fonctions Lambda sont limitées à 1 000 exécutions simultanées par fonction. Région AWS + **API Gateway** fournit des fonctionnalités de dimensionnement supplémentaires en plus de la propre mise à l’échelle de Lambda. Il inclut des commandes intégrées de mise en file d’attente et de limitation des requêtes, ce qui vous permet de gérer les pics de trafic de manière plus élégante. API Gateway peut traiter jusqu’à 10 000 requêtes par seconde et par région par défaut, avec une capacité de débordement de 5 000 requêtes par seconde. Il fournit également des outils pour limiter les requêtes à différents niveaux (API, étape ou méthode) afin de protéger votre dorsal. ### Contrôle + Les **fonctions URLs** offrent une surveillance de base via CloudWatch les métriques Amazon, notamment le nombre de demandes, la latence et les taux d'erreur. Vous avez accès aux métriques et aux journaux Lambda standard, qui indiquent les requêtes brutes entrant dans votre fonction. Bien que cela fournisse une visibilité opérationnelle essentielle, les métriques se concentrent principalement sur l’exécution des fonctions. + **API Gateway** fournit des fonctionnalités de surveillance complètes, notamment des métriques détaillées, des options de journalisation et de suivi. Vous pouvez surveiller les appels d'API, la latence, les taux d'erreur et hit/miss les taux de cache via CloudWatch. API Gateway s'intègre également au AWS X-Ray traçage distribué et fournit des formats de journalisation personnalisables. ### Cost + Les **fonctions URLs** suivent le modèle de tarification Lambda standard : vous ne payez que pour les appels de fonctions et le temps de calcul. Il n’y a pas de frais supplémentaires pour le point de terminaison de l’URL lui-même. Cela en fait un choix rentable pour les applications simples APIs ou à faible trafic si vous n'avez pas besoin des fonctionnalités supplémentaires d'API Gateway. + **API Gateway** propose un [niveau gratuit](https://aws.amazon.com/api-gateway/pricing/#Free_Tier) qui inclut un million d'appels d'API reçus pour REST APIs et un million d'appels d'API reçus pour HTTP APIs. Ensuite, API Gateway facture les appels d’API, le transfert de données et la mise en cache (si activée). Reportez-vous à la [page de tarification](https://aws.amazon.com/api-gateway/pricing/) d’API Gateway pour connaître les coûts associés à votre propre cas d’utilisation. ### Autres fonctions + URLsLes **fonctions** sont conçues pour la simplicité et l'intégration directe de Lambda. Ils prennent en charge les points de terminaison HTTP et HTTPS, offrent un support CORS intégré et fournissent des points de terminaison à double pile (IPv4 et IPv6). Bien qu’elles ne disposent d’aucune fonctionnalité avancée, elles excellent dans les scénarios où vous avez besoin d’un moyen rapide et simple d’exposer les fonctions Lambda via HTTP. + **API Gateway** inclut de nombreuses fonctionnalités supplémentaires telles que la gestion des versions des API, la gestion des étapes, les clés d'API pour les plans d'utilisation, la documentation des API via Swagger/OpenAPI, le mode WebSocket APIs privé au sein d' APIs un VPC et l'intégration WAF pour une sécurité accrue. Il prend également en charge les déploiements Canary, les intégrations fictives à des fins de test et l'intégration avec d'autres solutions que Services AWS Lambda. ## Sélection d’une méthode pour invoquer votre fonction Lambda Maintenant que vous avez pris connaissance des critères de sélection entre la fonction Lambda URLs et API Gateway et des principales différences entre les deux, vous pouvez sélectionner l'option qui répond le mieux à vos besoins et utiliser les ressources suivantes pour vous aider à commencer à l'utiliser. ------ #### [ Function URLs ] **Commencez à utiliser Function URLs grâce aux ressources suivantes** + Suivre le tutoriel [Création d’une fonction Lambda avec une URL de fonction](urls-webhook-tutorial.md) + Pour en savoir plus sur URLs les fonctions, consultez le [Création et gestion de la fonction Lambda URLs](urls-configuration.md) chapitre de ce guide + Essayez le tutoriel guidé intégré à la console **Créer une application Web simple** en procédant comme suit : 1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda. 1. Ouvrez le panneau d’aide en cliquant sur l’icône dans le coin supérieur droit de l’écran. ![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console_help_screenshot.png) 1. Sélectionnez **Tutoriels**. 1. Dans **Créer une application Web simple**, choisissez **Démarrer le tutoriel**. ------ #### [ API Gateway ] **Mise en route avec Lambda et API Gateway grâce aux ressources suivantes** + Suivez le tutoriel [Utilisation de Lambda avec API Gateway](services-apigateway-tutorial.md) pour créer une API REST intégrée à une fonction Lambda principale. + Pour en savoir plus sur les différents types d’API proposés par API Gateway, consultez les sections suivantes du *Guide du développeur Amazon API Gateway* : + [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) + Essayez un ou plusieurs des exemples de la section [Tutoriels et ateliers](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) du manuel *Guide du développeur Amazon API Gateway*. ------ # Didacticiel : création d’un point de terminaison webhook à l’aide d’une URL de fonction Lambda Dans ce didacticiel, vous créez une URL de fonction Lambda pour implémenter un point de terminaison webhook. Un webhook est une communication légère pilotée par les événements qui envoie automatiquement des données entre applications via HTTP. Vous pouvez utiliser un webhook pour recevoir des mises à jour immédiates sur les événements survenant dans un autre système, par exemple lorsqu’un nouveau client s’inscrit sur un site Web, qu’un paiement est traité ou qu’un fichier est chargé. Avec Lambda, les webhooks peuvent être implémentés à l'aide de la fonction Lambda ou d'API Gateway. URLs URLs Les fonctions sont un bon choix pour les webhooks simples qui ne nécessitent pas de fonctionnalités telles que l'autorisation avancée ou la validation des demandes. **Astuce** Si vous ne savez pas quelle est la solution la mieux adaptée à votre cas d’utilisation particulier, consultez [Sélection d’une méthode pour invoquer votre fonction Lambda à l’aide d’une requête HTTP](furls-http-invoke-decision.md). ## Conditions préalables Pour terminer ce didacticiel, Python (version 3.8 ou ultérieure) ou Node.js (version 18 ou ultérieure) doit être installé sur votre machine locale. Pour tester le point de terminaison à l’aide d’une requête HTTP, le didacticiel utilise [curl](https://curl.se/), un outil de ligne de commande que vous pouvez utiliser pour transférer des données à l’aide de différents protocoles réseau. Reportez-vous à la [documentation curl](https://curl.se/docs/install.html) pour savoir comment installer l’outil si vous ne l’avez pas déjà. ## Créer la fonction Lambda Créez d’abord la fonction Lambda qui s’exécute lorsqu’une requête HTTP est envoyée à votre point de terminaison webhook. Dans cet exemple, l’application d’envoi envoie une mise à jour chaque fois qu’un paiement est soumis, et indique dans le corps de la requête HTTP si le paiement a été effectué avec succès. La fonction Lambda analyse la demande et agit en fonction du statut du paiement. Dans cet exemple, le code imprime simplement l’ID de commande pour le paiement, mais dans une application réelle, vous pouvez ajouter la commande à une base de données ou envoyer une notification. La fonction implémente également la méthode d’authentification la plus couramment utilisée pour les webhooks, l’authentification des messages basée sur le hachage (HMAC). Avec cette méthode, les applications d’envoi et de réception partagent une clé secrète. L’application d’envoi utilise un algorithme de hachage pour générer une signature unique à l’aide de cette clé associée au contenu du message, et inclut la signature dans la demande de webhook sous forme d’en-tête HTTP. L’application réceptrice répète ensuite cette étape en générant la signature à l’aide de la clé secrète, et compare la valeur obtenue avec la signature envoyée dans l’en-tête de la demande. Si le résultat correspond, la demande est considérée comme légitime. Créez la fonction à l’aide de la console Lambda avec l’environnement d'exécution Python ou Node.js. ------ #### [ Python ] **Créer la fonction Lambda** 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Créez une fonction de type « Hello World » de base en procédant comme suit : 1. Choisissez **Créer une fonction**. 1. Sélectionnez **Créer à partir de zéro**. 1. Sous **Nom de la fonction**, saisissez **myLambdaWebhook**. 1. Pour **Runtime**, sélectionnez **python3.14**. 1. Choisissez **Créer une fonction**. 1. Dans le volet **Source du code**, remplacez le code existant en copiant et en collant ce qui suit : ``` 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. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction. ------ #### [ Node.js ] **Créer la fonction Lambda** 1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda. 1. Créez une fonction de type « Hello World » de base en procédant comme suit : 1. Choisissez **Créer une fonction**. 1. Sélectionnez **Créer à partir de zéro**. 1. Sous **Nom de la fonction**, saisissez **myLambdaWebhook**. 1. Pour **Runtime**, sélectionnez **nodejs24.x**. 1. Choisissez **Créer une fonction**. 1. Dans le volet **Source du code**, remplacez le code existant en copiant et en collant ce qui suit : ``` 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. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction. ------ ## Créer la clé de secret Pour que la fonction Lambda authentifie la demande de webhook, elle utilise une clé secrète qu’elle partage avec l’application appelante. Dans cet exemple, la clé est stockée dans une variable d’environnement. Dans une application de production, n’incluez pas d’informations sensibles telles que des mots de passe dans votre code de fonction. [Créez plutôt un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html), puis [utilisez l'extension Lambda AWS Parameters and Secrets](with-secrets-manager.md) pour récupérer vos informations d'identification dans votre fonction Lambda. **Créer et stocker la clé secrète du webhook** 1. Générez une longue chaîne aléatoire à l’aide d’un générateur de nombres aléatoires sécurisé par cryptographie. Vous pouvez utiliser les extraits de code suivants en Python ou Node.js pour générer et imprimer un secret de 32 caractères, ou utiliser votre propre méthode préférée. ------ #### [ Python ] **Example code pour générer un secret** ``` import secrets webhook_secret = secrets.token_urlsafe(32) print(webhook_secret) ``` ------ #### [ Node.js ] **Example code pour générer un secret (format du module ES)** ``` import crypto from 'crypto'; let webhookSecret = crypto.randomBytes(32).toString('base64'); console.log(webhookSecret) ``` ------ 1. Stockez la chaîne générée en tant que variable d’environnement pour votre fonction en procédant comme suit : 1. Dans l’onglet **Configuration** de votre fonction, sélectionnez **Variables d’environnement**. 1. Choisissez **Modifier**. 1. Choisissez **Ajouter une variable d’environnement**. 1. Pour **Clé**, saisissez **WEBHOOK\$1SECRET**, puis pour **Valeur**, saisissez le secret que vous avez généré à l’étape précédente. 1. Choisissez **Enregistrer**. Vous devrez réutiliser ce secret ultérieurement dans le didacticiel pour tester votre fonction. Veillez donc à le noter dès maintenant. ## Créer le point de terminaison d’URL de fonction Créez un point de terminaison pour votre webhook à l’aide d’une URL de fonction Lambda. Comme vous utilisez le type d’authentification `NONE` pour créer un point de terminaison avec accès public, toute personne disposant de l’URL peut invoquer votre fonction. Pour en savoir plus sur le contrôle de l'accès aux fonctions URLs, voir[Contrôler l'accès à la fonction Lambda URLs](urls-auth.md). Si vous avez besoin d’options d’authentification plus avancées pour votre webhook, pensez à utiliser API Gateway. **Créer le point de terminaison d’URL de fonction** 1. Dans l’onglet **Configuration** de votre fonction, sélectionnez **URL de la fonction**. 1. Choisissez **Create function URL** (Créer une URL de fonction). 1. Pour **Type d’authentification**, sélectionnez **NONE**. 1. Choisissez **Enregistrer**. Le point de terminaison de l’URL de fonction que vous venez de créer s’affiche dans le volet **URL de fonction**. Copiez le point de terminaison ; vous l’utiliserez ultérieurement dans le didacticiel. ## Tester la fonction dans console Avant d’utiliser une requête HTTP pour invoquer votre fonction à l’aide du point de terminaison d’URL, testez-la dans la console pour vérifier que votre code fonctionne comme prévu. Pour vérifier la fonction dans la console, vous devez d’abord calculer une signature de webhook à l’aide du secret que vous avez généré plus tôt dans le didacticiel avec les données utiles JSON de test suivantes : ``` { "type": "payment.success", "orderId": "1234", "amount": "99.99" } ``` Utilisez l’un des exemples de code Python ou Node.js suivants pour calculer la signature du webhook à l’aide de votre propre secret. ------ #### [ Python ] **Calculer la signature du webhook** 1. Enregistrez le code suivant dans un fichier nommé `calculate_signature.py`. Remplacez le secret de webhook dans le code par votre propre valeur. ``` 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. Calculez la signature en exécutant la commande suivante à partir du répertoire où vous avez enregistré le code. Copiez la signature émise par le code. ``` python calculate_signature.py ``` ------ #### [ Node.js ] **Calculer la signature du webhook** 1. Enregistrez le code suivant dans un fichier nommé `calculate_signature.mjs`. Remplacez le secret de webhook dans le code par votre propre valeur. ``` 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. Calculez la signature en exécutant la commande suivante à partir du répertoire où vous avez enregistré le code. Copiez la signature émise par le code. ``` node calculate_signature.mjs ``` ------ Vous pouvez désormais tester le code de votre fonction à l’aide d’une requête HTTP de test dans la console. **Tester la fonction dans console** 1. Sélectionnez l’onglet **Code** correspondant à votre fonction. 1. Dans la section **ÉVÉNEMENTS DE TEST**, choisissez **Créer un nouvel événement de test**. 1. Dans **Event Name (Nom de l'événement)**, saisissez **myEvent**. 1. Remplacez le JSON existant en copiant et en collant ce qui suit dans le volet **JSON d’événement**. Remplacez la signature de webhook par la valeur calculée à l’étape précédente. ``` { "headers": { "Content-Type": "application/json", "x-webhook-signature": "2d672e7a0423fab740fbc040e801d1241f2df32d2ffd8989617a599486553e2a" }, "body": "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}" } ``` 1. Choisissez **Enregistrer**. 1. Sélectionnez **Invoquer **. Vous devez voir des résultats similaires à ce qui suit : ------ #### [ 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 ``` ------ ## Tester la fonction avec une requête HTTP Utilisez l’outil de ligne de commande curl pour tester votre point de terminaison webhook. **Tester la fonction avec des requêtes HTTP** 1. Dans un terminal ou un programme shell, exécutez la commande curl suivante. Remplacez l’URL par la valeur du point de terminaison de votre URL de fonction et remplacez la signature du webhook par la signature que vous avez calculée à l’aide de votre propre clé secrète. ``` 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"}' ``` Vous devriez voir la sortie suivante : ``` {"received": true} ``` 1. Examinez les CloudWatch journaux de votre fonction pour confirmer qu'elle a correctement analysé la charge utile en procédant comme suit : 1. Ouvrez la page du [groupe Logs](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups) dans la CloudWatch console Amazon. 1. Sélectionnez le groupe de journaux de votre fonction (`/aws/lambda/myLambdaWebhook`). 1. Sélectionnez le flux de journaux le plus récent. Vous devez voir des résultats similaires à ce qui suit dans les journaux de votre fonction : ------ #### [ 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. Confirmez que votre code détecte une signature non valide en exécutant la commande curl suivante. Remplacez l’URL par le point de terminaison de l’URL de votre propre fonction. ``` 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"}' ``` Vous devriez voir la sortie suivante : ``` {"error": "Invalid signature"} ``` ## Nettoyage de vos ressources Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS. **Pour supprimer la fonction Lambda** 1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda. 1. Sélectionnez la fonction que vous avez créée. 1. Sélectionnez **Actions**, **Supprimer**. 1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer). Lorsque vous avez créé la fonction Lambda dans la console, Lambda a également créé un [rôle d’exécution](lambda-intro-execution-role.md) pour votre fonction. **Pour supprimer le rôle d’exécution** 1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM. 1. Sélectionnez le rôle d’exécution que Lambda a créé. Le nom du rôle est au format `myLambdaWebhook-role-`. 1. Sélectionnez **Delete (Supprimer)**. 1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).