Comprendre les concepts de base de Lambda

Lambda étant un service de calcul sans serveur piloté par les événements, il utilise un paradigme de programmation différent de celui des applications Web traditionnelles. Si vous découvrez Lambda ou le développement sans serveur, les sections suivantes décrivent certains concepts fondamentaux qui vous aideront à démarrer votre parcours d'apprentissage. Outre une explication de chaque concept, les sections contiennent également des liens vers des didacticiels, une documentation détaillée et d'autres ressources que vous pouvez utiliser pour approfondir votre compréhension de chaque sujet.

Sur cette page, vous découvrirez les informations suivantes :

• Fonctions Lambda : les éléments de base de Lambda que vous utilisez pour créer des applications

• Runtimes Lambda : les environnements spécifiques au langage dans lesquels vos fonctions s'exécutent

• Déclencheurs et mappages de sources d'événements : moyens pour les autres d' Services AWS invoquer vos fonctions en réponse à des événements spécifiques

• L'objet d'événement : un objet JSON contenant des données d'événement que votre fonction doit traiter

• Autorisations Lambda : la façon dont vous contrôlez les autres fonctions avec lesquelles Services AWS vos fonctions peuvent interagir et qui peut accéder à vos fonctions

Astuce

Si vous souhaitez commencer par comprendre le développement sans serveur de manière plus générale, consultez la section Comprendre la différence entre le développement traditionnel et le développement sans serveur dans le Guide du développeur AWS sans serveur.

Fonctions Lambda

Dans Lambda, les fonctions sont les éléments fondamentaux que vous utilisez pour créer des applications. Une fonction Lambda est un morceau de code qui s'exécute en réponse à des événements, tels qu'un utilisateur clique sur un bouton sur un site Web ou le chargement d'un fichier dans un bucket Amazon Simple Storage Service (Amazon S3). Vous pouvez considérer une fonction comme une sorte de programme autonome possédant les propriétés suivantes.

• Une fonction a une fonction ou un objectif spécifique

• Ils ne fonctionnent que lorsque cela est nécessaire en réponse à des événements spécifiques

• Ils s'arrêtent automatiquement lorsqu'ils ont terminé

Lorsqu'une fonction s'exécute en réponse à un événement, Lambda exécute la fonction de gestion de la fonction. Les données relatives à l'événement à l'origine de l'exécution de la fonction sont transmises directement au gestionnaire. Alors que le code d'une fonction Lambda peut contenir plusieurs méthodes ou fonctions, les fonctions Lambda ne peuvent avoir qu'un seul gestionnaire.

Pour créer une fonction Lambda, vous devez regrouper le code de votre fonction et ses dépendances dans un package de déploiement. Lambda prend en charge deux types de packages de déploiement : les archives de fichiers .zip et les images de conteneur.

Pour mieux comprendre les fonctions Lambda, nous vous recommandons de commencer par suivre le Création de votre première fonction Lambda didacticiel, si ce n'est pas déjà fait. Ce didacticiel fournit plus de détails sur la fonction de gestion et sur la manière de transmettre des données à l'intérieur et à l'extérieur de votre fonction. Il fournit également une introduction à la création de journaux de fonctions.

Environnement d'exécution et environnements d'exécution Lambda

Les fonctions Lambda s'exécutent dans un environnement d'exécution sécurisé et isolé que Lambda gère pour vous. Cet environnement d'exécution gère les processus et les ressources nécessaires à l'exécution de votre fonction. Lorsqu'une fonction est invoquée pour la première fois, Lambda crée un nouvel environnement d'exécution dans lequel la fonction doit s'exécuter. Une fois l'exécution de la fonction terminée, Lambda n'arrête pas immédiatement l'environnement d'exécution ; si la fonction est à nouveau invoquée, Lambda peut réutiliser l'environnement d'exécution existant.

L'environnement d'exécution Lambda contient également un environnement d'exécution, un environnement spécifique au langage qui relaie les informations sur les événements et les réponses entre Lambda et votre fonction. Lambda fournit un certain nombre d'environnements d'exécution gérés pour les langages de programmation les plus courants, ou vous pouvez créer les vôtres.

Pour les environnements d'exécution gérés, Lambda applique automatiquement les mises à jour de sécurité et les correctifs aux fonctions utilisant le moteur d'exécution.

Déclencheurs et mappages de sources d'événements

Bien que vous puissiez invoquer une fonction Lambda manuellement à l'aide du AWS Command Line Interface (AWS CLI) ou de l'API Lambda, il est plus courant dans une application de production que votre fonction soit invoquée par une autre Service AWS en réponse à un événement particulier. Par exemple, vous souhaiterez peut-être qu'une fonction s'exécute chaque fois qu'un élément est ajouté à une table Amazon DynamoDB.

Pour configurer une fonction afin qu'elle s'exécute en réponse à un événement spécifique, vous ajoutez un déclencheur. Lorsque vous créez un déclencheur, d'autres personnes Services AWS peuvent appeler directement votre fonction en envoyant un objet d'événement vers Lambda chaque fois qu'un événement particulier se produit. Une fonction peut avoir plusieurs déclencheurs, chacun invoquant votre fonction indépendamment.

Certains types de services de streaming et de file d'attente, tels qu'Amazon Kinesis ou Amazon Simple Queue Service (Amazon SQS), ne peuvent pas appeler directement Lambda à l'aide d'un déclencheur. Pour ces services, vous devez plutôt créer un mappage des sources d'événements. Les mappages de sources d'événements sont un type spécial de ressource Lambda qui interroge en permanence un flux ou une file d'attente pour vérifier la présence de nouveaux événements. Par exemple, un mappage de source d'événement peut interroger une file d'attente Amazon SQS pour vérifier si de nouveaux messages ont été ajoutés. Lambda regroupe les nouveaux messages en une seule charge utile jusqu'à ce qu'une limite que vous configurez soit atteinte, puis appelle votre fonction avec un seul objet d'événement contenant tous les enregistrements du lot.

Le moyen le plus simple de créer un mappage de déclencheurs ou de sources d'événements consiste à utiliser la console Lambda. Bien que les ressources sous-jacentes créées par Lambda et la manière dont votre fonction est invoquée soient différentes, le processus de création d'un déclencheur ou d'un mappage de source d'événement dans la console utilise la même méthode.

Pour voir un exemple de déclencheur en action, commencez par suivre le didacticiel Utiliser un déclencheur Amazon S3 pour invoquer une fonction Lambda, ou pour une présentation générale de l'utilisation des déclencheurs et des instructions sur la création d'un déclencheur à l'aide de la console Lambda, consultez. Invoquer Lambda avec des événements provenant d'autres services AWS

L'objet de l'événement

Lambda est un service de calcul piloté par les événements. Cela signifie que votre code s'exécute en réponse à des événements générés par des producteurs externes. Les données d'événements sont transmises à votre fonction sous forme de document au format JSON, que le moteur d'exécution convertit en objet à traiter par votre code. Par exemple, en Python, le moteur d'exécution convertit un objet JSON en dictionnaire Python et le transmet à la fonction en tant qu'argument event d'entrée.

Lorsque l'événement est généré par un autre Service AWS, le format de l'événement dépend du service qui le génère. Par exemple, un événement Amazon S3 inclut le nom du compartiment qui a déclenché votre fonction et des informations sur les objets de ce compartiment. Pour en savoir plus sur le format des événements générés par différents Services AWS, reportez-vous aux chapitres correspondants dansInvoquer Lambda avec des événements provenant d'autres services AWS.

Vous pouvez également appeler une fonction Lambda directement à l'aide de la console Lambda ou de l'un des kits de développement AWS logiciel (). AWS CLISDKs Lorsque vous appelez directement une fonction, vous déterminez le format et le contenu de l'événement JSON. Supposons, par exemple, que vous disposiez d'une fonction Lambda qui écrit des données météorologiques dans une base de données. Vous pouvez définir le format JSON suivant pour votre événement. Comme pour les événements générés par d'autres Services AWS, le moteur d'exécution Lambda convertit ce JSON en objet avant de le transmettre au gestionnaire de votre fonction.

Exemple événement Lambda personnalisé

{
  "Location": "SEA",
  "WeatherData":{
    "TemperaturesF":{
      "MinTempF": 22,
      "MaxTempF": 78
    },
    "PressuresHPa":{
      "MinPressureHPa": 1015,
      "MaxPressureHPa": 1027
    }
  }
}

Comme le moteur d'exécution Lambda convertit l'événement en objet, vous pouvez facilement attribuer des valeurs de l'événement à des variables sans avoir à désérialiser le JSON. Les extraits de code suivants montrent comment attribuer la valeur de température minimale de l'événement précédent à une variable à l'MinTempaide des environnements d'exécution Python et Node.js. Dans les deux cas, l'objet d'événement est transmis à la fonction de gestion de votre fonction sous forme d'argument nomméevent.

Exemple Extrait de code Python

MinTemp = event['WeatherData']['TemperaturesF']['MinTempF']

Exemple Extrait de code Node.js

let MinTemp = event.WeatherData.TemperaturesF.MinTempF;

Pour un exemple d'appel d'une fonction Lambda avec un événement personnalisé, consultez. Création de votre première fonction Lambda

Autorisations Lambda

Pour Lambda, il existe deux principaux types d'autorisations que vous devez configurer :

• Autorisations dont votre fonction a besoin pour accéder à d'autres Services AWS

• Autorisations dont les autres utilisateurs Services AWS ont besoin pour accéder à votre fonction

Les sections suivantes décrivent ces deux types d'autorisation et décrivent les meilleures pratiques pour appliquer les autorisations du moindre privilège.

Autorisations permettant aux fonctions d'accéder à d'autres AWS ressources

Les fonctions Lambda ont souvent besoin d'accéder à d'autres AWS ressources et d'effectuer des actions sur celles-ci. Par exemple, une fonction peut lire des éléments d'une table DynamoDB, stocker un objet dans un compartiment S3 ou écrire dans une file d'attente Amazon SQS. Pour donner aux fonctions les autorisations dont elles ont besoin pour effectuer ces actions, vous utilisez un rôle d'exécution.

Un rôle d'exécution Lambda est un type spécial de rôle AWS Identity and Access Management (IAM), une identité que vous créez dans votre compte et à laquelle des autorisations spécifiques sont associées, définies dans une politique.

Chaque fonction Lambda doit avoir un rôle d'exécution, et un seul rôle peut être utilisé par plusieurs fonctions. Lorsqu'une fonction est invoquée, Lambda assume le rôle d'exécution de la fonction et est autorisée à effectuer les actions définies dans la politique du rôle.

Lorsque vous créez une fonction dans la console Lambda, Lambda crée automatiquement un rôle d'exécution pour votre fonction. La politique du rôle donne à votre fonction les autorisations de base pour écrire les sorties de journal dans Amazon CloudWatch Logs. Pour autoriser votre fonction à effectuer des actions sur d'autres AWS ressources, vous devez modifier le rôle afin d'ajouter les autorisations supplémentaires. Le moyen le plus simple d'ajouter des autorisations consiste à utiliser une politique AWS gérée. Les politiques gérées sont créées et administrées par de nombreux cas d'utilisation courants AWS et fournissent des autorisations pour de nombreux cas d'utilisation courants. Par exemple, si votre fonction effectue des opérations CRUD sur une table DynamoDB, vous pouvez ajouter AmazonDynamoDBFullla politique d'accès à votre rôle.

Autorisations permettant à d'autres utilisateurs et ressources d'accéder à votre fonction

Pour accorder d'autres Service AWS autorisations d'accès à votre fonction Lambda, vous devez utiliser une politique basée sur les ressources. Dans IAM, les politiques basées sur les ressources sont associées à une ressource (dans ce cas, votre fonction Lambda) et définissent les personnes autorisées à accéder à la ressource et les actions qu'elles sont autorisées à effectuer.

Pour Service AWS qu'une autre personne invoque votre fonction via un déclencheur, la politique basée sur les ressources de votre fonction doit autoriser ce service à utiliser l'lambda:InvokeFunctionaction. Si vous créez le déclencheur à l'aide de la console, Lambda ajoute automatiquement cette autorisation pour vous.

Pour autoriser d'autres AWS utilisateurs à accéder à votre fonction, vous pouvez le définir dans la politique basée sur les ressources de votre fonction exactement de la même manière que pour une autre fonction Service AWS ou ressource. Vous pouvez également utiliser une politique basée sur l'identité associée à l'utilisateur.

Bonnes pratiques pour les autorisations Lambda

Lorsque vous définissez des autorisations à l'aide de politiques IAM, la meilleure pratique en matière de sécurité consiste à n'accorder que les autorisations nécessaires à l'exécution d'une tâche. C'est ce que l'on appelle le principe du moindre privilège. Pour commencer à accorder des autorisations pour votre fonction, vous pouvez choisir d'utiliser une politique AWS gérée. Les politiques gérées peuvent être le moyen le plus rapide et le plus simple d'accorder des autorisations pour effectuer une tâche, mais elles peuvent également inclure d'autres autorisations dont vous n'avez pas besoin. Au fur et à mesure que vous passez du stade initial du développement aux tests et à la production, nous vous recommandons de limiter les autorisations aux seules autorisations nécessaires en définissant vos propres politiques gérées par le client.

Le même principe s'applique lorsque vous accordez des autorisations d'accès à votre fonction à l'aide d'une politique basée sur les ressources. Par exemple, si vous souhaitez autoriser Amazon S3 à appeler votre fonction, la meilleure pratique consiste à limiter l'accès à des compartiments individuels, ou à des compartiments en particulier Comptes AWS, plutôt que d'accorder des autorisations générales au service S3.