Environnements d’exécution (runtimes) Lambda - AWS Lambda

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.

Environnements d’exécution (runtimes) Lambda

Lambda prend en charge plusieurs langages via l’utilisation d’environnements d’exécution. Une exécution fournit un environnement spécifique au langage qui relaie les événements d’invocation, les informations de contexte et les réponses entre Lambda et la fonction. Vous pouvez utiliser les runtimes que Lambda fournit, ou créer vos propres runtimes.

Chaque version majeure du langage de programmation possède un environnement d’exécution distinct, avec un identifiant de l’environnement d’exécution unique, tel que nodejs20.x ou python3.12. Pour configurer une fonction afin d’utiliser une nouvelle version majeure du langage, vous devez modifier l’identifiant d’exécution. Comme il AWS Lambda n'est pas possible de garantir la rétrocompatibilité entre les versions principales, il s'agit d'une opération pilotée par le client.

Pour une fonction définie en tant qu’image de conteneur, vous choisissez une exécution et la distribution Linux lorsque vous créez l’image de conteneur. Pour modifier l’environnement d’exécution, vous créez une image de conteneur.

Lorsque vous utilisez une archive de fichiers .zip pour le package de déploiement, vous choisissez un environnement d’exécution lorsque vous créez la fonction. Pour modifier l’environnement d’exécution, vous pouvez mettre à jour la configuration de votre fonction. L’environnement d’exécution est associé à l’une des distributions Amazon Linux. L’environnement d’exécution sous-jacent fournit des bibliothèques et des variables d’environnement supplémentaires auxquelles vous pouvez accéder depuis le code de votre fonction.

Lambda invoque votre fonction dans un environnement d’exécution. L’environnement d’exécution fournit un environnement d’environnement d’exécution sécurisé et isolé qui gère les ressources nécessaires à l’exécution de votre fonction. Lambda réutilise l’environnement d’exécution à partir d’une invocation antérieure dans le cas où il y en a un disponible, ou il peut en créer un nouveau.

Pour utiliser d'autres langages dans Lambda, tels que Go ou Rust, utilisez un environnement d'exécution uniquement pour le système d'exploitation. L’environnement d’exécution de Lambda fournit une interface d’environnement d’exécution pour obtenir des événements d’invocations et envoyer des réponses. Vous pouvez déployer les autres langages en implémentant un environnement d’exécution en association avec le code de votre fonction, ou dans une couche.

Environnements d'exécution pris en charge

Le tableau suivant répertorie les durées d'exécution Lambda prises en charge et les dates d'obsolescence prévues. Une fois qu'un environnement d'exécution est obsolète, vous pouvez toujours créer et mettre à jour des fonctions pendant une période limitée. Pour plus d’informations, consultez Utilisation à l'exécution après la dépréciation. Le tableau fournit les dates actuellement prévues pour la dépréciation de l'exécution. Ces dates sont fournies à des fins de planification et sont susceptibles d'être modifiées.

Environnements d’exécution pris en charge
Nom Identifiant Système d’exploitation Date d'obsolescence Créer la fonction de blocage Mettre à jour la fonction de blocage

Node.js 20

nodejs20.x

Amazon Linux 2023

Node.js 18

nodejs18.x

Amazon Linux 2

Node.js 16

nodejs16.x

Amazon Linux 2

12 juin 2024

28 février 2025

31 mars 2025

Python 3.12

python3.12

Amazon Linux 2023

Python 3.11

python3.11

Amazon Linux 2

Python 3.10

python3.10

Amazon Linux 2

Python 3.9

python3.9

Amazon Linux 2

Python 3.8

python3.8

Amazon Linux 2

14 octobre 2024

28 février 2025

31 mars 2025

Java 21

java21

Amazon Linux 2023

Java 17

java17

Amazon Linux 2

Java 11

java11

Amazon Linux 2

Java 8

java8.al2

Amazon Linux 2

.NET 8

dotnet8

Amazon Linux 2023

.NET 6

dotnet6

Amazon Linux 2

12 novembre 2024

28 février 2025

31 mars 2025

Ruby 3.3

ruby3.3

Amazon Linux 2023

Ruby 3.2

ruby3.2

Amazon Linux 2

Exécution réservée au système d'exploitation

provided.al2023

Amazon Linux 2023

Exécution réservée au système d'exploitation

provided.al2

Amazon Linux 2

Note

Pour les nouvelles régions, Lambda ne prendra pas en charge les environnements d'exécution qui devraient devenir obsolètes dans les six prochains mois.

Lambda tient à jour les environnements d’exécution gérés et de leurs images de conteneur correspondantes à jour grâce à des correctifs et à la prise en charge des versions mineures. Pour plus d'informations, consultez Mises à jour de l'exécution Lambda.

Lambda continue de prendre en charge le langage de programmation Go après l’obsolescence de l’environnement d’exécution Go 1.x. Pour plus d'informations, consultez la section Migration des AWS Lambda fonctions de l'environnement d'exécution Go1.x vers le runtime personnalisé sur Amazon Linux 2 sur le AWS blog Compute.

Tous les environnements d'exécution Lambda pris en charge prennent en charge les architectures x86_64 et arm64.

Nouvelles versions d'exécution

Lambda fournit des environnements d’exécution gérés pour les nouvelles versions de langage uniquement lorsque la version atteint la phase LTS (support à long terme) du cycle de distribution du langage. Par exemple, pour le cycle de distribution de Node.js, lorsque la version atteint la phase Active LTS.

Avant que la version n'atteigne la phase de support à long terme, elle reste en développement et peut encore faire l'objet de modifications majeures. Lambda applique automatiquement les mises à jour d’environnements d'exécution par défaut, de sorte que l'interruption des modifications apportées à une version d’environnement d'exécution peut empêcher vos fonctions de fonctionner comme prévu.

Lambda ne fournit pas d'environnements d'exécution gérés pour les versions linguistiques dont la sortie du LTS n'est pas prévue.

La liste suivante montre le mois de lancement cible pour les environnements d’exécution Lambda à venir. Ces dates ne sont données qu’à titre indicatif et sont susceptibles d’être modifiées.

  • Python 3.13 - novembre 2024

  • Node.js 22 - novembre 2024

politique d’obsolescence de l’exécution

Environnements d’exécution (runtimes) Lambda pour les archives de fichiers .zip combinent un système d’exploitation, un langage de programmation et des bibliothèques de logiciels qui font l’objet d’une maintenance et de mises à jour de sécurité. La politique d'obsolescence standard de Lambda consiste à déprécier un environnement d'exécution lorsqu'un composant majeur de celui-ci atteint la fin du support communautaire à long terme (LTS) et que les mises à jour de sécurité ne sont plus disponibles. Le plus souvent, il s’agit de l’environnement d’exécution du langage, bien que dans certains cas, un environnement d’exécution puisse être obsolète car le système d’exploitation (OS) atteint la fin du LTS.

Une fois qu'un environnement d'exécution est obsolète, il ne AWS peut plus y appliquer de correctifs ou de mises à jour de sécurité, et les fonctions utilisant cet environnement d'exécution ne sont plus éligibles au support technique. Ces environnements d'exécution obsolètes sont fournis « tels quels », sans aucune garantie, et peuvent contenir des bogues, des erreurs, des défauts ou d'autres vulnérabilités.

Pour en savoir plus sur la gestion des mises à niveau d'exécution et de la dépréciation, consultez les sections suivantes et la gestion des mises à niveau AWS Lambda d'exécution sur le blog AWS Compute.

Important

Lambda retarde parfois l’obsolescence d’un environnement d’exécution Lambda pendant une période limitée au-delà de la date de fin du support de la version du langage prise en charge par l’environnement d’exécution. Pendant cette période, Lambda applique uniquement des correctifs de sécurité au système d’exploitation de l’environnement d’exécution. Lambda n’applique pas de correctifs de sécurité aux environnements d’exécution des langages de programmation une fois leur date de fin de support atteinte.

Obsolescence de l’environnement d’exécution Node.js 16

En réponse aux commentaires des clients, AWS reporte la dépréciation du runtime Node.js 16 à 9 mois après la fin de la communauté LTS. L’environnement d’exécution de Node.js 16 sera obsolète à la date indiquée dans le tableau des environnements d’exécution pris en charge. Comme indiqué dans la note précédente, entre la fin de LTS le 11 septembre 2023 et la date d’obsolescence, Lambda appliquera uniquement les correctifs du système d’exploitation à l’environnement d’exécution. Aucun correctif de sécurité pour l’environnement d’exécution du langage ne sera appliqué pendant cette période.

Le report de l’obsolescence de Node.js 16 donne aux utilisateurs de cet environnement d’exécution la possibilité de migrer leurs fonctions directement vers Node.js 20, sans passer par Node.js 18.

Modèle de responsabilité partagée

Lambda est responsable de l'organisation et de la publication des mises à jour de sécurité pour tous les environnements d'exécution gérés et les images de base de conteneurs pris en charge. Par défaut, Lambda appliquera ces mises à jour automatiquement aux fonctions utilisant des environnements d'exécution gérés. Lorsque le paramètre de mise à jour automatique de l'exécution par défaut a été modifié, consultez le modèle de responsabilité partagée des contrôles de gestion de l'exécution. Pour les fonctions déployées à l'aide d'images de conteneur, vous êtes chargé de reconstruire l'image de conteneur de votre fonction à partir de la dernière image de base et de redéployer l'image de conteneur.

Lorsqu'un environnement d'exécution est obsolète, la responsabilité de Lambda en matière de mise à jour de l'environnement d'exécution géré et des images de base du conteneur cesse. Vous êtes responsable de la mise à niveau de vos fonctions afin d'utiliser un environnement d'exécution ou une image de base compatible.

Dans tous les cas, vous êtes responsable de l'application des mises à jour de votre code de fonction, y compris de ses dépendances. Vos responsabilités dans le cadre du modèle de responsabilité partagée sont résumées dans le tableau suivant.

Phase du cycle de vie d'exécution Responsabilités de Lambda Vos responsabilités
Runtime géré pris en charge

Fournissez des mises à jour d'exécution régulières avec des correctifs de sécurité et d'autres mises à jour.

Appliquez les mises à jour d'exécution automatiquement par défaut (voir Contrôles de la gestion de l’environnement d’exécution pour les comportements autres que ceux par défaut).

Mettez à jour le code de votre fonction, y compris les dépendances, pour corriger les éventuelles failles de sécurité.
Image de conteneur prise en charge Fournissez des mises à jour régulières de l'image de base du conteneur avec des correctifs de sécurité et d'autres mises à jour.

Mettez à jour le code de votre fonction, y compris les dépendances, pour corriger les éventuelles failles de sécurité.

Reconstruisez et redéployez régulièrement votre image de conteneur à l'aide de la dernière image de base.

Runtime géré proche de la dépréciation

Avertissez les clients avant la dépréciation de l'exécution via la documentation AWS Health Dashboard, le courrier électronique et. Trusted Advisor

La responsabilité des mises à jour d'exécution prend fin en cas de dépréciation.

Surveillez la documentation Lambda AWS Health Dashboard, les e-mails ou les informations relatives à la Trusted Advisor dépréciation de l'exécution.

Mettez à niveau les fonctions vers un environnement d'exécution compatible avant que le précédent ne soit obsolète.

L'image du conteneur approche de la dépréciation

Les notifications d'obsolescence ne sont pas disponibles pour les fonctions utilisant des images de conteneur.

La responsabilité des mises à jour des images de base des conteneurs prend fin à la dépréciation.

Tenez compte des programmes de dépréciation et des fonctions de mise à niveau vers une image de base prise en charge avant que l'image précédente ne soit déconseillée.

Utilisation à l'exécution après la dépréciation

Une fois qu'un environnement d'exécution est obsolète, il ne AWS peut plus y appliquer de correctifs ou de mises à jour de sécurité, et les fonctions utilisant cet environnement d'exécution ne sont plus éligibles au support technique. Ces environnements d'exécution obsolètes sont fournis « tels quels », sans aucune garantie, et peuvent contenir des bogues, des erreurs, des défauts ou d'autres vulnérabilités. Les fonctions qui utilisent un environnement d'exécution obsolète peuvent également connaître une dégradation des performances ou d'autres problèmes, tels que l'expiration d'un certificat, susceptibles de les empêcher de fonctionner correctement.

Pendant au moins 30 jours après l’obsolescence d'un environnement d'exécution, vous pouvez toujours créer de nouvelles fonctions Lambda à l'aide de cet environnement d'exécution. À partir de 30 jours après l’obsolescence, Lambda commence à bloquer la création de nouvelles fonctions.

Pendant au moins 60 jours après la désapprobation d'un environnement d'exécution, vous pouvez toujours mettre à jour le code de fonction et la configuration des fonctions existantes. À partir de 60 jours après la dépréciation, Lambda commence à bloquer la mise à jour du code de fonction et de la configuration des fonctions existantes.

Note

Pour certains environnements d'exécution, AWS cela retarde les block-function-update dates block-function-create et au-delà des 30 et 60 jours habituels après la dépréciation. AWS a apporté cette modification en réponse aux commentaires des clients afin de vous donner plus de temps pour améliorer vos fonctionnalités. Reportez-vous aux tableaux figurant dans Environnements d'exécution pris en charge et Environnements d’exécution obsolètes pour connaître les dates de votre exécution.

Vous pouvez mettre à jour une fonction pour utiliser indéfiniment un environnement d'exécution compatible plus récent une fois qu'un environnement d'exécution est devenu obsolète. Vous devez vérifier que votre fonction fonctionne avec le nouveau moteur d'exécution avant d'appliquer le changement d'exécution dans les environnements de production, car vous ne pourrez pas revenir à l'environnement d'exécution obsolète une fois la période de 60 jours écoulée. Nous vous recommandons d'utiliser des versions de fonctions et des alias pour permettre un déploiement sécurisé avec restauration.

Notez que la durée exacte pendant laquelle vous pouvez continuer à créer et à mettre à jour des fonctions n'est pas fixée. Cette période peut varier pour chaque dépréciation et pour différents. Régions AWS Les dates nominales pour le blocage des créations et des mises à jour de fonctions sont fournies dans le tableau des environnements d’exécution pris en charge dans la première section de cette page. Lambda ne commencera pas à bloquer les créations ou les mises à jour de fonctions avant les dates indiquées dans ce tableau.

Vous pouvez continuer à invoquer vos fonctions indéfiniment une fois que l’environnement d’exécution est devenu obsolète. Toutefois, il AWS est vivement recommandé de migrer les fonctions vers un environnement d'exécution compatible afin que celles-ci continuent de recevoir des correctifs de sécurité et restent éligibles au support technique.

Réception de notifications d'obsolescence lors de l'exécution

Lorsqu'un environnement d'exécution approche de sa date d'obsolescence, Lambda vous envoie une alerte par e-mail si l'une de vos Compte AWS fonctions utilise cet environnement d'exécution. Les notifications sont également affichées dans AWS Health Dashboard et dans AWS Trusted Advisor.

  • Réception de notifications par e-mail :

    Lambda vous envoie une alerte par e-mail au moins 180 jours avant qu'un environnement d'exécution ne soit obsolète. Cet e-mail répertorie les versions $LATEST de toutes les fonctions utilisant le runtime. Pour consulter la liste complète des versions de fonctions concernées, utilisez Trusted Advisor ou consultezRépertorier les fonctions qui utilisent un environnement d'exécution obsolète.

    Lambda envoie une notification par e-mail au contact principal Compte AWS de votre compte. Pour plus d'informations sur l'affichage ou la mise à jour des adresses e-mail de votre compte, consultez la section Mise à jour des informations de contact dans la Référence générale AWS .

  • Recevoir des notifications par le biais de AWS Health Dashboard :

    AWS Health Dashboard Affiche une notification au moins 180 jours avant qu'un environnement d'exécution ne soit obsolète. Les notifications apparaissent sur la page État de votre compte sous Autres notifications. L'onglet Ressources affectées de la notification répertorie les versions $LATEST de toutes les fonctions utilisant le runtime.

    Note

    Pour voir l'intégralité et la up-to-date liste des versions des fonctions concernées, utilisez Trusted Advisor ou consultezRépertorier les fonctions qui utilisent un environnement d'exécution obsolète.

    AWS Health Dashboard les notifications expirent 90 jours après que le runtime concerné soit devenu obsolète.

  • En utilisant AWS Trusted Advisor

    Trusted Advisor affiche une notification 180 jours avant qu'un environnement d'exécution ne soit obsolète. Les notifications apparaissent sur la page Sécurité. La liste des fonctions concernées s'affiche sous Fonctions AWS Lambda utilisant des environnements d'exécution obsolètes. Cette liste de fonctions affiche à la fois $LATEST et les versions publiées et les mises à jour automatiques pour refléter l'état actuel de vos fonctions.

    Vous pouvez activer les notifications hebdomadaires par e-mail depuis Trusted Advisor la page des préférences de la Trusted Advisor console.

Répertorier les fonctions qui utilisent un environnement d'exécution obsolète

Outre l' Trusted Advisor affichage d'une liste en temps réel des fonctions affectées par les dépréciations d'exécution planifiées, vous pouvez également utiliser le AWS Command Line Interface (AWS CLI) ou l'un des AWS SDK pour répertorier toutes les versions de vos fonctions qui utilisent un environnement d'exécution particulier.

Pour générer cette liste à l'aide de AWS CLI, exécutez la commande suivante. RUNTIME_IDENTIFIERRemplacez-le par le nom du moteur d'exécution qui est obsolète et choisissez le vôtre. Région AWS Pour répertorier uniquement les versions de fonction $LATEST, omettez --function-version ALL dans la commande.

aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='RUNTIME_IDENTIFIER'].FunctionArn"
Astuce

L'exemple de commande répertorie les fonctions d'une us-east-1 région en particulier. Compte AWS Vous devrez répéter cette commande pour chaque région dans laquelle votre compte possède des fonctions et pour chacune de vos Comptes AWS.

Pour en savoir plus sur l'utilisation d'un AWS SDK pour répertorier vos fonctions à l'aide de l'ListFunctionsaction, consultez la documentation du SDK correspondant à votre langage de programmation préféré. Vous pouvez également utiliser l'un des AWS SDK pour recueillir des statistiques sur les most-recently-invoked fonctions que vous avez le plus appelées à l'aide des actions de l'API DescribeLogStreams et GetMetricStatistics.

Vous pouvez également utiliser la fonctionnalité de requêtes AWS Config avancées pour répertorier toutes les fonctions qui utilisent un environnement d'exécution affecté. Cette requête renvoie uniquement les versions $LATEST de la fonction, mais vous pouvez agréger les requêtes pour répertorier les fonctions dans toutes les régions et plusieurs Comptes AWS avec une seule commande. Pour en savoir plus, consultez la section Interrogation de l'état de configuration actuel des AWS Auto Scaling ressources dans le guide du AWS Config développeur.

Environnements d’exécution obsolètes

Les environnements d’exécution suivants ont atteint la fin de prise en charge :

Environnements d’exécution obsolètes
Nom Identifiant Système d’exploitation Date d'obsolescence Créer la fonction de blocage Mettre à jour la fonction de blocage

.NET 7 (conteneur uniquement)

dotnet7

Amazon Linux 2

14 mai 2024

Java 8

java8

Amazon Linux

8 janvier 2024

8 février 2024

28 février 2025

Go 1.x

go1.x

Amazon Linux

8 janvier 2024

8 février 2024

28 février 2025

Exécution réservée au système d'exploitation

provided

Amazon Linux

8 janvier 2024

8 février 2024

28 février 2025

Ruby 2.7

ruby2.7

Amazon Linux 2

7 décembre 2023

9 janvier 2024

28 février 2025

Node.js 14

nodejs14.x

Amazon Linux 2

4 décembre 2023

9 janvier 2024

28 février 2025

Python 3.7

python3.7

Amazon Linux

4 décembre 2023

9 janvier 2024

28 février 2025

.NET Core 3.1

dotnetcore3.1

Amazon Linux 2

3 avril 2023

3 avril 2023

3 mai 2023

Node.js 12

nodejs12.x

Amazon Linux 2

31 mars 2023

31 mars 2023

30 avril 2023

Python 3.6

python3.6

Amazon Linux

18 juillet 2022

18 juillet 2022

29 août 2022

.NET 5 (conteneur uniquement)

dotnet5.0

Amazon Linux 2

10 mai 2022

.NET Core 2.1

dotnetcore2.1

Amazon Linux

5 janvier 2022

5 janvier 2022

13 avril 2022

Node.js 10

nodejs10.x

Amazon Linux 2

30 juillet 2021

30 juillet 2021

14 février 2022

Ruby 2.5

ruby2.5

Amazon Linux

30 juillet 2021

30 juillet 2021

31 mars 2022

Python 2.7

python2.7

Amazon Linux

15 juillet 2021

15 juillet 2021

30 mai 2022

Node.js 8.10

nodejs8.10

Amazon Linux

6 mars 2020

6 mars 2020

Node.js 4.3

nodejs4.3

Amazon Linux

5 mars 2020

5 mars 2020

Node.js 4.3 edge

nodejs4.3-edge

Amazon Linux

5 mars 2020

30 avril 2019

Node.js 6.10

nodejs6.10

Amazon Linux

12 août 2019

12 août 2019

.NET Core 1.0

dotnetcore1.0

Amazon Linux

27 juin 2019

30 juillet 2019

.NET Core 2.0

dotnetcore2.0

Amazon Linux

30 mai 2019

30 mai 2019

Node.js 0.10

nodejs

Amazon Linux

31 octobre 2016

Dans presque tous les cas, la end-of-life date d'une version linguistique ou d'un système d'exploitation est connue bien à l'avance. Les liens suivants fournissent des end-of-life plannings pour chaque langage pris en charge par Lambda en tant qu'environnement d'exécution géré.

Stratégies de prise en charge des langages et des infrastructures