Exécutions Lambda

Lorsque Lambda exécute une fonction en votre nom, il gère l'allocation et la configuration des systèmes sous-jacents nécessaires à l'exécution du code. Les développeurs peuvent ainsi se concentrer sur la logique métier et l'écriture de code, et non sur l'administration et la gestion des systèmes sous-jacents.

Le service Lambda est réparti entre le plan de contrôle et le plan de données. Chaque plan a une fonction distincte dans le service. Le plan de contrôle fournit les API de gestion (par exemple, CreateFunction, UpdateFunctionCode, PublishLayerVersion, etc.) et gère les intégrations à tous les services AWS. Les communications vers le plan de contrôle de Lambda sont protégées en transit par TLS. Toutes les données client stockées dans le plan de contrôle de Lambda sont chiffrées au repos en utilisant AWS KMS, qui est conçu pour les protéger contre toute divulgation non autorisée ou falsification.

Le plan de données est l'API Invoke de Lambda déclenche l'appel des fonctions Lambda. Lorsqu'une fonction Lambda est invoquée, le plan de données alloue un environnement d'exécution sur un worker AWS Lambda (ou simplement worker, qui est un type d'instance Amazon EC2) à cette version de fonction, ou choisit un environnement d'exécution existant déjà configuré pour cette version de fonction, qu'il utilise ensuite pour terminer l'appel. Pour en savoir plus, consultez la section « Micro-machines virtuelles et workers AWS Lambda » de ce document.

Environnements d'exécution Lambda

Chaque appel est acheminé par le service d'appel de Lambda vers un environnement d'exécution sur un worker capable de traiter la demande. En dehors du plan de données, les clients et les autres utilisateurs ne peuvent pas directement initier des communications réseau entrantes/d'entrée avec un environnement d'exécution. Il est ainsi possible de garantir que les communications vers votre environnement d'exécution sont authentifiées et autorisées.

Les environnements d'exécution sont réservés à une version de fonction spécifique et ne peuvent pas être réutilisés entre des versions de fonction, des fonctions ou des comptes AWS. Cela signifie qu'une fonction unique qui peut avoir deux versions différentes aboutirait à au moins deux environnements d'exécution uniques.

Chaque environnement d'exécution peut être utilisé pour un seul appel simultané à la fois, et il peut être réutilisé pour plusieurs appels de la même version de fonction pour des raisons de performances. Selon un certain nombre de facteurs (par exemple, le taux d'appel, la configuration de la fonction, etc.), un ou plusieurs environnements d'exécution peuvent exister pour une version de fonction donnée. Grâce à cette approche, Lambda est en mesure de fournir à ses clients une isolation au niveau de la version des fonctions.

Lambda n'isole actuellement pas les appels dans l'environnement d'exécution d'une version de fonction. Cela signifie qu'un appel peut laisser un état susceptible d'affecter le prochain appel (par exemple, des fichiers écrits dans /tmp ou des données en mémoire). Si vous voulez vous assurer qu'un appel ne peut pas affecter un autre appel, Lambda recommande de créer des fonctions distinctes supplémentaires. Par exemple, vous pouvez créer des fonctions distinctes pour des opérations d'analyse complexes qui sont plus sujettes aux erreurs, et réutiliser des fonctions qui n'effectuent pas d'opérations affectant la sécurité. Actuellement, Lambda ne limite pas le nombre de fonctions que les clients peuvent créer. Pour en savoir plus sur les restrictions, consultez la page Quotas Lambda.

Lambda surveille et gère en permanence les environnements d'exécution, qui peuvent être créés ou détruits pour un certain nombre de raisons, notamment :

Les clients peuvent gérer le nombre d'environnements d'exécution préalloués qui existent pour une version de fonction en configurant la simultanéité allouée sur leur configuration de fonction. Lorsqu'il est configuré pour cela, Lambda crée et gère le nombre configuré d'environnements d'exécution, et veille à ce qu'ils existent toujours. Les clients profitent ainsi d'un plus grand contrôle sur les performances au démarrage de leurs applications sans serveur, quelle que soit l'échelle.

En dehors d'une configuration de la simultanéité allouée, les clients ne peuvent pas contrôler de manière déterministe le nombre d'environnements d'exécution créés ou gérés par Lambda en réponse aux appels.

Rôle d'exécution

Chaque fonction Lambda doit également être configurée avec un rôle d'exécution, qui est un rôle IAM assumé par le service Lambda lors de l'exécution d'opérations de plan de contrôle et de plan de données liées à la fonction. Le service Lambda assume ce rôle afin de récupérer les informations d'identification de sécurité temporaires qui sont ensuite disponibles en tant que variables d'environnement lors de l'appel d'une fonction. Pour des raisons de performances, le service Lambda met en mémoire cache ces informations d'identification et peut les réutiliser dans différents environnements d'exécution qui reposent sur le même rôle d'exécution.

Conformément au principe du moindre privilège, Lambda recommande que chaque fonction possède son propre rôle unique, configuré avec le jeu minimum d'autorisations nécessaires.

Le service Lambda peut également assumer le rôle d'exécution afin d'effectuer certaines opérations du plan de contrôle, telles que celles liées à la création et à la configuration d'interfaces réseau Elastic (ENI) pour les fonctions VPC, à l'envoi de journaux vers Amazon CloudWatch Application Insights ou à l'envoi de traces vers AWS X-Ray, ou encore d'autres opérations non liées à l'appel. Les clients peuvent toujours passer en revue et auditer ces cas d'utilisation en consultant les journaux d'audit dans AWS CloudTrail.

Pour en savoir plus à ce sujet, consultez la page de documentation du rôle d'exécution AWS Lambda.

Micro-machines virtuelles et workers AWS Lambda

Lambda crée ses environnements d'exécution sur une flotte d'instances Amazon EC2 appelées workers AWS Lambda. Les workers sont des instances EC2 Nitro de matériel nu qui sont lancées et gérées par Lambda dans un compte AWS isolé distinct non visible pour les clients. Ils s'accompagnent d'une ou de plusieurs micro-machines virtuelles (MVM) virtualisées par le matériel et créées par Firecracker. Firecracker est un moniteur de machine virtuelle (VMM) open source qui utilise la machine virtuelle basée sur le noyau (KVM) de Linux pour créer et gérer des micro-machines virtuelles. Il est spécialement conçu pour créer et gérer des conteneurs multi-locataire sécurisés et des services basés sur des fonctions qui fournissent des modèles opérationnels sans serveur. Pour en savoir plus sur le modèle de sécurité de Firecracker, consultez le site web du projet Firecracker.

Dans le cadre du modèle de responsabilité partagée, Lambda est responsable du maintien de la configuration de sécurité, des contrôles et du niveau de correctifs des workers. L'équipe Lambda utilise Amazon Inspector pour détecter les problèmes de sécurité potentiels connus, ainsi que d'autres mécanismes de notification des problèmes de sécurité personnalisés et des listes de prédivulgation, afin que les clients n'aient pas à gérer la posture de sécurité sous-jacente de leur environnement d'exécution.

Figure 3 – Modèle d'isolation pour les workers AWS Lambda

Les workers ont une durée de bail maximale de 14 heures. Lorsqu'un worker approche du terme de la durée de bail, aucun autre appel n'est acheminé vers lui, les micro-machines virtuelles sont arrêtées de manière appropriée et l'instance sous-jacente du worker est arrêtée. Lambda surveille en permanence les activités du cycle de vie de sa flotte et émet des alarmes.

Toutes les communications du plan de données vers les workers sont chiffrées selon la norme de chiffrement AES-GCM (Advanced Encryption Standard with Galois/Counter Mode). En dehors des opérations de plan de données, les clients ne peuvent pas interagir directement avec un worker, car celui-ci est hébergé dans un Amazon VPC isolé du réseau géré par Lambda dans les comptes de service de Lambda.

Lorsqu'un worker doit créer un nouvel environnement d'exécution, il reçoit une autorisation limitée dans le temps pour accéder aux artefacts de fonction du client. Ces artefacts sont spécifiquement optimisés pour l'environnement d'exécution et les workers de Lambda. Le code de fonction chargé au format ZIP est optimisé une fois, puis stocké dans un format chiffré à l'aide d'une clé gérée par AWS et de la norme AES-GCM.

Les fonctions chargées vers Lambda au format d'image de conteneur sont également optimisées. L'image de conteneur est d'abord téléchargée à partir de sa source d'origine, optimisée en fragments distincts, puis stockée sous la forme de fragments chiffrés à l'aide d'un procédé de chiffrement convergent authentifié qui utilise une combinaison des normes AES-CTR et AES-GCM et d'un code SHA-256 MAC. Grâce à la méthode de chiffrement convergent, Lambda peut dédupliquer en toute sécurité les fragments chiffrés. Toutes les clés nécessaires au déchiffrement des données du client sont protégées à l'aide de AWS KMSclés principales client (CMK) gérées par le client. Les clients peuvent consulter l'utilisation de clés CMK par le service Lambda dans les journaux AWS CloudTrail à des fins de suivi et d'audit.