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

Environnements d'exécution (runtimes) Lambda

Lambda prend en charge plusieurs langages via l'utilisation de runtimes. Pour une fonction définie en tant qu'image de conteneur, vous choisissez un environnement d'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.

Amazon Linux

Amazon Linux 2

  • Image – Personnalisée

  • Noyau Linux version 4.14

Lambda appelle votre fonction dans un environnement d'exécution. L'environnement d'exécution fournit un environnement de runtime 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'un appel antérieur dans le cas où il y en a un disponible, ou il peut en créer un nouveau.

Un environnement d'exécution peut prendre en charge une seule version d'un langage, plusieurs versions d'un langage ou plusieurs langages. Les environnements d'exécution spécifiques à un langage ou à une version d'infrastructure sont déconseillés lorsque la version arrive en fin de vie.

Environnements d'exécution Node.js
Nom Identifiant SDK pour JavaScript Système d'exploitation Architectures

Node.js 14

nodejs14.x

2.1001.0

Amazon Linux 2

x86_64, arm64

Node.js 12

nodejs12.x

2.1001.0

Amazon Linux 2

x86_64, arm64

Note

Pour obtenir des informations de support concernant Node.js 10, consultez Politique de dépréciation de l'exécution.

Environnements d'exécution Python
Nom Identifiant AWS SDK pour Python Système d'exploitation Architectures

Python 3.9

python3.9

boto3-1.20.32 botocore-1.23.32

Amazon Linux 2

x86_64, arm64

Python 3.8

python3.8

boto3-1.20.32 botocore-1.23.32

Amazon Linux 2

x86_64, arm64

Python 3.7

python3.7

boto3-1.20.32 botocore-1.23.32

Amazon Linux

x86_64

Python 3.6

python3.6

boto3-1.20.32 botocore-1.23.32

Amazon Linux

x86_64

Environnements d'exécution Ruby
Nom Identifiant Kit SDK pour Ruby Système d'exploitation Architectures

Ruby 2.7

ruby2.7

3.0.1

Amazon Linux 2

x86_64, arm64

Note

Pour obtenir des informations de support concernant Ruby 2.5, consultez Politique de dépréciation de l'exécution.

Environnements d'exécution Java
Nom Identifiant JDK Système d'exploitation Architectures

Java 11

java11

amazon-corretto-11

Amazon Linux 2

x86_64, arm64

Java 8

java8.al2

amazon-corretto-8

Amazon Linux 2

x86_64, arm64

Java 8

java8

amazon-corretto-8

Amazon Linux

x86_64

Environnements d'exécution Go
Nom Identifiant Système d'exploitation Architectures

Go 1.x

go1.x

Amazon Linux

x86_64

Note

Les exécutions qui utilisent le système d'exploitation Amazon Linux, tels que Go 1.x, ne prennent pas en charge l'architecture arm64. Pour utiliser l'architecture arm64, vous pouvez exécuter Go avec le moteur d'exécution .al2 fourni.

Environnements d'exécution .NET
Nom Identifiant Système d'exploitation Architectures

.NET 6

dotnet6

Amazon Linux 2

x86_64, arm64

.NET Core 3.1

dotnetcore3.1

Amazon Linux 2

x86_64, arm64

Note

Pour des informations sur la fin du support concernant .NET Core 2.1, consultez Politique de dépréciation de l'exécution.

Pour utiliser d'autres langages dans Lambda, vous pouvez implémenter un environnement d'exécution (runtime) personnalisé. L'environnement d'exécution de Lambda fournit une interface de runtime pour obtenir des événements d'appels et envoyer des réponses. Vous pouvez déployer un environnement d'exécution personnalisé en association avec le code de votre fonction, ou dans une couche.

Environnement d'exécution personnalisé
Nom Identifiant Système d'exploitation Architectures

Environnement d'exécution personnalisé

provided.al2

Amazon Linux 2

x86_64, arm64

Environnement d'exécution personnalisé

provided

Amazon Linux

x86_64

Politique de dépréciation de l'exécution

Environnements d'exécution (runtimes) Lambda pour les archives 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é. Lorsque les mises à jour de sécurité ne sont plus disponibles pour un composant d’exécution, Lambda rend l’exécution obsolète.

L'obsolescence (fin de prise en charge) d'un environnement d'exécution se produit en deux phases.

Phase 1 : Lambda n'applique plus de correctifs de sécurité ou d'autres mises à jour à l'exécution. Vous ne pouvez plus créer des fonctions qui utilisent l'exécution, mais vous pouvez continuer à mettre à jour les fonctions existantes. Cela inclut la mise à jour de la version d'exécution et la restauration vers la version d'exécution précédente. Notez que les fonctions qui utilisent une exécution obsolète ne sont plus éligibles au support technique.

Phase 2 : vous ne pouvez plus créer ou mettre à jour les fonctions qui utilisent l'exécution. Pour mettre à jour une fonction, vous devez la migrer vers une version d'exécution prise en charge. Après la migration de la fonction vers une version d'exécution prise en charge, vous ne pouvez pas restaurer la fonction vers l'exécution précédente. La phase 2 démarre au moins 30 jours après le début de la phase 1.

Lambda ne bloque pas les appels des fonctions qui utilisent des versions d’exécution obsolètes. Les appels de fonction se poursuivent indéfiniment après la fin de prise en charge de la version d'exécution. Toutefois, AWS vous recommande vivement de migrer les fonctions vers une version d'exécution prise en charge afin que vous puissiez continuer de recevoir des correctifs de sécurité et rester éligible à la prise en charge technique.

Dans le tableau ci-dessous, chaque phase démarre à minuit (fuseau horaire du Pacifique) à la date spécifiée. Les environnements d'exécution suivants ont atteint ou sont programmés pour une fin de prise en charge :

Fin d'exécution des dates de prise en charge
Nom Identifiant Système d'exploitation Phase 1 de la dépréciation Phase 2 de la dépréciation

.NET Core 2.1

dotnetcore2.1

Amazon Linux

5 janvier 2022

13 avril 2022

Python 3.6

python3.6

Amazon Linux

18 juillet 2022

17 août 2022

Python 2.7

python2.7

Amazon Linux

15 juillet 2021

14 février 2022

Ruby 2.5

ruby2.5

Amazon Linux

30 juillet 2021

31 mars 2022

Node.js 10.x

nodejs10.x

Amazon Linux 2

30 juillet 2021

14 février 2022

Node.js 8.10

nodejs8.10

Amazon Linux

6 mars 2020

Node.js 6.10

nodejs6.10

Amazon Linux

12 août 2019

Node.js 4.3 edge

nodejs4.3-edge

Amazon Linux

30 avril 2019

Node.js 4.3

nodejs4.3

Amazon Linux

6 mars 2020

Node.js 0.10

nodejs

Amazon Linux

31 octobre 2016

.NET Core 2.0

dotnetcore2.0

Amazon Linux

30 mai 2019

.NET Core 1.0

dotnetcore1.0

Amazon Linux

30 juillet 2019

Dans la plupart des cas, la date de fin de vie d'une version de langage ou d'un système d'exploitation est bien connue à l'avance. Lambda vous avertit par e-mail si vous disposez de fonctions utilisant une fonction dont la fin de la prise en charge est prévue dans les 60 prochains jours. Exceptionnellement, un préavis de fin de prise en charge n'est pas possible. Par exemple, les problèmes de sécurité nécessitant une mise à jour rétro-incompatible ou un composant d'exécution qui ne fournit pas de calendrier de support à long terme (LTS).

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