Fonctionnement de Lambda

Les fonctions Lambda sont les blocs de construction de base que vous utilisez pour créer des applications Lambda. Pour écrire des fonctions, il est essentiel de comprendre les concepts et composants fondamentaux du modèle de programmation Lambda. Cette section vous guidera à travers les éléments fondamentaux que vous devez connaître pour commencer à créer des applications sans serveur avec Lambda.

Fonctions Lambda et gestionnaires de fonctions

Dans Lambda, les fonctions sont les blocs de construction fondamentaux que vous utilisez pour créer des applications. Une fonction Lambda est un élément de code qui s’exécute en réponse à des événements, par exemple lorsqu’un utilisateur clique sur un bouton d’un site Web ou qu’un fichier est chargé dans un compartiment 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. Un gestionnaire de fonction Lambda est la méthode dans le code de votre fonction qui traite les événements. Lorsqu’une fonction s’exécute en réponse à un événement, Lambda exécute le gestionnaire de fonction. Les données relatives à l’événement à l’origine de l’exécution de la fonction sont transmises directement au gestionnaire. Là où 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 groupez 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 fichier .zip et les images conteneurs.

Environnement d’exécution et exécutions 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 spécifique au langage (runtime), qui relaie les informations d’un événement 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 correctifs aux fonctions lors de l’exécution.

Événements et déclencheurs

Vous pouvez également invoquer une fonction Lambda directement avec la console Lambda, AWS CLI ou l’un des kits de développement logiciel (SDK) AWS. Dans une application de production, il est plus courant que votre fonction soit invoquée par un 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 que votre fonction réagisse aux événements, vous devez configurer un déclencheur. Un déclencheur connecte votre fonction à une source d’événements, et votre fonction peut avoir plusieurs déclencheurs. Lorsqu’un événement se produit, Lambda reçoit les données de l’événement sous forme de document JSON et les convertit en un objet que votre code peut traiter. Vous pouvez définir le format JSON suivant pour votre événement, et l’environnement d’exécution Lambda convertit ce JSON en objet avant de le transmettre au gestionnaire de votre fonction.

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

Pour les services de diffusion en continu et de mise en file d’attente comme Amazon Kinesis ou Amazon SQS, Lambda utilise un mappage des sources d’événements au lieu d’un déclencheur standard. Les mappages des sources d’événements interrogent la source à la recherche de nouvelles données, regroupent les enregistrements, puis invoquent votre fonction avec les événements par lots. Pour de plus amples informations, consultez Différence entre les mappages de sources d’événements et les déclencheurs directs.

Pour comprendre le fonctionnement d’un déclencheur, commencez par suivre le didacticiel Utiliser un déclencheur Amazon S3 ou, pour obtenir 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 Intégration d’autres services.

Autorisations et rôles Lambda

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

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

Autorisations pour les fonctions d’accéder à d’autres ressources AWS

Les fonctions Lambda ont besoin d’accéder à d’autres ressources AWS et d’effectuer des actions dessus. 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 même 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é à 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 autorise votre fonction à écrire des sorties de journal dans Amazon CloudWatch Logs. Pour autoriser votre fonction à effectuer des actions sur d’autres ressources AWS, 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 gérée AWS. Les politiques gérées sont créées et administrées par 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 la politique AmazonDynamoDBFullAccess à votre rôle.

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

Pour accorder d’autres autorisations Service AWS pour l’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 attachées à une ressource (dans ce cas, votre fonction Lambda) et définissent qui peut accéder à la ressource et quelles actions peuvent être effectuées.

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

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

Bonnes pratiques relatives aux autorisations Lambda

Lorsque vous définissez des autorisations avec des stratégies IAM, la bonne pratique de sécurité est d’accorder uniquement les autorisations nécessaires à l’exécution d’une seule 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 gérée AWS. 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. À 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 à invoquer votre fonction, la meilleure pratique consiste à limiter l’accès à des compartiments individuels, ou à des compartiments dans des Comptes AWS spécifiques, plutôt que d’accorder des autorisations générales au service S3.