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 nodejs22.x ou python3.13. 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 Environnement d’exécution utilisé après la date d’obsolescence. 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.

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.

Pour interagir par programmation avec d'autres ressources Services AWS de votre fonction Lambda, vous pouvez utiliser l'un des. AWS SDKs Les environnements d'exécution Node.js, Python et Ruby incluent une version du AWS SDK. Toutefois, pour conserver le contrôle total de vos dépendances et optimiser la rétrocompatibilité lors des mises à jour automatiques de l'exécution, nous vous recommandons de toujours inclure les modules SDK utilisés par votre code (ainsi que les dépendances éventuelles) dans le package de déploiement de votre fonction ou dans une couche Lambda.

Nous vous recommandons d'utiliser la version du SDK incluant l'environnement d'exécution uniquement lorsque vous ne pouvez pas inclure de packages supplémentaires dans votre déploiement. Par exemple, lorsque vous créez votre fonction à l'aide de l'éditeur de code de la console Lambda ou à l'aide du code de fonction intégré dans un modèle. AWS CloudFormation

Lambda met régulièrement à jour les versions AWS SDKs incluses dans les environnements d'exécution Node.js, Python et Ruby. Pour déterminer la version du AWS SDK incluse dans le moteur d'exécution que vous utilisez, consultez les sections suivantes :

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 supportent 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.

politique d’obsolescence de l’exécution

Les environnements d'exécution Lambda pour les archives de fichiers .zip sont conçus autour d'une combinaison de systèmes d'exploitation, de langages de programmation et de bibliothèques de logiciels soumis à des mises à jour de maintenance et de sécurité. La stratégie d’obsolescence standard de Lambda consiste à rendre obsolète 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 « en l’état », 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.

Modèle de responsabilité partagée

Lambda est responsable de la conservation 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 conteneur 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’environnement d’exécution par défaut a été modifié, consultez le modèle de responsabilité partagée des contrôles de gestion de l’environnement d’exécution. Pour les fonctions déployées à l’aide d’images de conteneurs, vous êtes responsable de la reconstruction de l’image de conteneur de votre fonction à partir de la dernière image de base et du redéploiement de l’image de conteneur.

Lorsqu’un environnement d’exécution devient 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 de 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 ses dépendances. Vos responsabilités dans le cadre du modèle de responsabilité partagée sont résumées dans le tableau suivant.

Environnement d’exécution utilisé après la date d’obsolescence

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 « en l’état », 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 subir une dégradation des performances ou d’autres problèmes, tels que l’expiration d’un certificat, qui peuvent 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 l’obsolescence d’un environnement d’exécution, vous pouvez toujours mettre à jour le code et la configuration des fonctions existantes. À partir de 60 jours suivant la date d’obsolescence, Lambda commence à bloquer la mise à jour du code de fonction pour les fonctions existantes.

Vous pouvez mettre à jour une fonction pour qu’elle utilise un environnement d’exécution plus récent indéfiniment après qu’un environnement d’exécution soit devenu obsolète. Vous devez vérifier que votre fonction fonctionne avec le nouvel environnement d’exécution avant d’appliquer le changement d’environnement d’exécution en 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 et alias de fonctions 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.

Environnements d’exécution obsolètes

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

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é.