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 de plus amples informations, veuillez consulter 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.
| Nom | Identifiant | Système d’exploitation | Date d'obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
|---|---|---|---|---|---|
|
Node.js 20 |
|
Amazon Linux 2023 |
Non prévu |
Non prévu |
Non prévu |
|
Node.js 18 |
|
Amazon Linux 2 |
31 juillet 2025 |
1 sept. 2025 |
1 octobre 2025 |
|
Python 3.12 |
|
Amazon Linux 2023 |
Non prévu |
Non prévu |
Non prévu |
|
Python 3.11 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
Python 3.10 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
Python 3.9 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
Python 3.8 |
|
Amazon Linux 2 |
14 octobre 2024 |
28 février 2025 |
31 mars 2025 |
|
Java 21 |
|
Amazon Linux 2023 |
Non prévu |
Non prévu |
Non prévu |
|
Java 17 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
Java 11 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
Java 8 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
. NET8 |
|
Amazon Linux 2023 |
Non prévu |
Non prévu |
Non prévu |
|
. NET6 |
|
Amazon Linux 2 |
20 déc. 2024 |
28 février 2025 |
31 mars 2025 |
|
Ruby 3.3 |
|
Amazon Linux 2023 |
Non prévu |
Non prévu |
Non prévu |
|
Ruby 3.2 |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
|
Exécution réservée au système d'exploitation |
|
Amazon Linux 2023 |
Non prévu |
Non prévu |
Non prévu |
|
Exécution réservée au système d'exploitation |
|
Amazon Linux 2 |
Non prévu |
Non prévu |
Non prévu |
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
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 linguistiques uniquement lorsque la version atteint la phase de support à long terme (LTS) du cycle de publication du langage. Par exemple, pour le cycle de publication de Node.js
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 publication n'est pas prévue. LTS
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 l'environnement d'exécution atteint la fin du support à long terme de la communauté (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 déconseillé car le système d'exploitation (OS) arrive à la fin de. 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
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.
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 Modes de mise à jour pendant 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 déconseillé. |
| 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 en fonction de chaque dépréciation et selon les besoins. 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 LATEST versions $ de toutes les fonctions utilisant le moteur d'exécution. Pour consulter la liste complète des versions de fonctions concernées, utilisez Trusted Advisor ou consultezRécupérer des données sur les fonctions Lambda 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 LATEST versions $ 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écupérer des données sur les fonctions Lambda 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 les versions $ LATEST et publiées et les mises à jour sont automatiquement mises à jour 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.
Environnements d’exécution obsolètes
Les environnements d’exécution suivants ont atteint la fin de prise 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 16 |
nodejs16.x
|
Amazon Linux 2 |
12 juin 2024 |
28 février 2025 |
31 mars 2025 |
|
. NET7 (contenant uniquement) |
dotnet7
|
Amazon Linux 2 |
14 mai 2024 |
N/A |
N/A |
|
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 |
|
. NETNoyau 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 |
|
. NET5 (contenant uniquement) |
dotnet5.0
|
Amazon Linux 2 |
10 mai 2022 |
N/A |
N/A |
|
. NETNoyau 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 |
N/A |
6 mars 2020 |
|
Node.js 4.3 |
nodejs4.3
|
Amazon Linux |
5 mars 2020 |
N/A |
5 mars 2020 |
|
Node.js 4.3 edge |
nodejs4.3-edge
|
Amazon Linux |
5 mars 2020 |
N/A |
30 avril 2019 |
|
Node.js 6.10 |
nodejs6.10
|
Amazon Linux |
12 août 2019 |
12 août 2019 |
N/A |
|
. NETNoyau 1.0 |
dotnetcore1.0
|
Amazon Linux |
27 juin 2019 |
N/A |
30 juillet 2019 |
|
. NETNoyau 2.0 |
dotnetcore2.0
|
Amazon Linux |
30 mai 2019 |
N/A |
30 mai 2019 |
|
Node.js 0.10 |
nodejs
|
Amazon Linux |
N/A |
N/A |
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
-
Node.js – github.com
-
Python – devguide.python.org
-
Ruby – www.ruby-lang.org
-
Go – golang.org
-
. NET— dotnet.microsoft.com
