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.
Lambda est indépendant de votre choix d’environnement d’exécution. Pour les fonctions simples, les langages interprétés tels que Python et Node.js offrent les performances les plus rapides. Pour les fonctions nécessitant des calculs plus complexes, les langages compilés tels que Java sont souvent plus lents à initialiser, mais s’exécutent rapidement dans le gestionnaire Lambda. Le choix de l’environnement d’exécution dépend également des préférences du développeur et de sa connaissance du langage.
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 `nodejs24.x` ou `python3.14`. 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](images-create.md), 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](configuration-function-zip.md). 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](configuration-envvars.md) supplémentaires auxquelles vous pouvez accéder depuis le code de votre fonction.
Lambda invoque votre fonction dans un [environnement d’exécution](lambda-runtime-environment.md). 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](lambda-golang.md) ou [Rust](lambda-rust.md), utilisez un [environnement d'exécution uniquement pour le système d'exploitation](runtimes-provided.md). L’environnement d’exécution de Lambda fournit une [interface d’environnement d’exécution](runtimes-api.md) 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](runtimes-custom.md) en association avec le code de votre fonction, ou dans une [couche](chapter-layers.md).
## 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](#runtime-deprecation-levels). Le tableau fournit les dates actuellement prévues pour la dépréciation de l’exécution sur la base de notre [politique d’obsolescence de l’exécution](#runtime-support-policy). Ces dates sont fournies à des fins de planification et sont susceptibles d'être modifiées.
**Important**
La fin de vie d'Amazon Linux 2 est prévue pour le 30 juin 2026. Les environnements d'exécution Lambda et les images de base de conteneur pour Java 8 (AL2), Java 11, Java 17, Python 3.10, Python 3.11 et provided.al2 continueront de recevoir des correctifs pour des problèmes de sécurité [critiques et certains problèmes de sécurité importants](https://alas.aws.amazon.com/faqs.html) d'Amazon Linux 2, en plus des correctifs d'exécution du langage, jusqu'aux dates d'obsolescence indiquées dans le tableau ci-dessous.
Nous recommandons aux clients de passer à un environnement d'exécution basé sur Amazon Linux 2023 dès que possible. Pour les clients effectuant une mise à niveau vers Java 21 ou Java 25, vous pouvez utiliser la fonction [AWS Transform personnalisée](https://docs.aws.amazon.com/transform/latest/userguide/custom.html) pour les aider à effectuer ces mises à niveau. Pour les clients qui ne sont pas en mesure de mettre à niveau leur version de Java, nous prévoyons de publier des environnements d'exécution basés sur Amazon Linux 2023 pour Java 8, Java 11 et Java 17 avant la fin du deuxième trimestre 2026.
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30 avril 2028 | 1 juin 2028 | 1 juillet 2028 |
| Node.js 22 | `nodejs22.x` | Amazon Linux 2023 | 30 avril 2027 | 1 juin 2027 | 1 juillet 2027 |
| Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | 30 avril 2026 | 31 août 2026 | 30 sept. 2026 |
| Python 3.14 | `python3.14` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Python 3.13 | `python3.13` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Python 3.12 | `python3.12` | Amazon Linux 2023 | 31 octobre 2028 | 30 novembre 2028 | 10 janvier 2029 |
| Python 3.11 | `python3.11` | Amazon Linux 2 | 30 juin 2027 | 31 juillet 2027 | 31 août 2027 |
| Python 3.10 | `python3.10` | Amazon Linux 2 | 31 octobre 2026 | 30 novembre 2026 | 15 janvier 2027 |
| Java 25 | `java25` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Java 21 | `java21` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Java 17 | `java17` | Amazon Linux 2 | 30 juin 2027 | 31 juillet 2027 | 31 août 2027 |
| Java 11 | `java11` | Amazon Linux 2 | 30 juin 2027 | 31 juillet 2027 | 31 août 2027 |
| Java 8 | `java8.al2` | Amazon Linux 2 | 30 juin 2027 | 31 juillet 2027 | 31 août 2027 |
| .NET 10 | `dotnet10` | Amazon Linux 2023 | 14 novembre 2028 | 14 déc. 2028 | 15 janvier 2029 |
| .NET 9 (conteneur uniquement) | `dotnet9` | Amazon Linux 2023 | 10 novembre 2026 | Non planifié | Non planifié |
| .NET 8 | `dotnet8` | Amazon Linux 2023 | 10 novembre 2026 | 10 déc. 2026 | 11 janvier 2027 |
| Ruby 3.4 | `ruby3.4` | Amazon Linux 2023 | 31 mars 2028 | 30 avril 2028 | 31 mai 2028 |
| Ruby 3.3 | `ruby3.3` | Amazon Linux 2023 | 31 mars 2027 | 30 avril 2027 | 31 mai 2027 |
| Ruby 3.2 | `ruby3.2` | Amazon Linux 2 | 31 mars 2026 | 31 août 2026 | 30 sept. 2026 |
| Exécution réservée au système d’exploitation | `provided.al2023` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Exécution réservée au système d’exploitation | `provided.al2` | Amazon Linux 2 | 31 juillet 2026 | 31 août 2026 | 30 sept. 2026 |
**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](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html).
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é](runtimes-update.md#runtime-update-compatibility) 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](chapter-layers.md).
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. 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 SDK AWS incluse dans l’environnement d’exécution que vous utilisez, consultez les sections suivantes :
+ [Versions du SDK incluses dans l’environnement d’exécution (Node.js)](lambda-nodejs.md#nodejs-sdk-included)
+ [Versions du SDK incluses dans l’environnement d’exécution (Python)](lambda-python.md#python-sdk-included)
+ [Versions du SDK incluses dans l’environnement d’exécution (Ruby)](lambda-ruby.md#ruby-sdk-included)
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](https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-from-the-go1-x-runtime-to-the-custom-runtime-on-amazon-linux-2/) sur le AWS blog Compute.*
Tous les environnements d’exécution Lambda pris en charge supportent les architectures x86\$164 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](https://nodejs.org/en/about/previous-releases), 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.
+ **Ruby 3.5** - mars 2026
+ **Java 8, 11 et 17 du AL2 23 au deuxième trimestre 2026**
+ **Node.js 26** - novembre 2026
+ **Python 3.15** - novembre 2026
## politique d’obsolescence de l’exécution
Les environnements d’exécution 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 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](https://aws.amazon.com/blogs/compute/managing-aws-lambda-runtime-upgrades/) 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.
## 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](runtime-management-shared.md). 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.
| Phase de cycle de vie de l’environnement d’exécution | Responsabilité de Lambda | Vos responsabilités |
| --- | --- | --- |
| Environnement d’exécution géré pris en charge | Fournissez des mises à jour d’environnement d’exécution régulières avec des correctifs de sécurité et d’autres mises à jour. Appliquer les mises à jour de l’environnement d’exécution automatiquement par défaut (consultez [Modes de mise à jour de l’environnement d’exécution](runtimes-update.md#runtime-management-controls) pour les comportements autres que ceux par défaut). | Mettez à jour votre code de fonction, y compris ses 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 autres mises à jour. | Mettez à jour votre code de fonction, y compris ses 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. |
| Environnement d’exécution géré proche de l’obsolescence | Avertissez les clients avant la dépréciation de l'exécution via la documentation Tableau de bord Health, le courrier électronique et. Trusted Advisor La responsabilité des mises à jour de l’environnement d’exécution prend fin en cas d’obsolescence. | Surveillez la documentation Lambda Tableau de bord Health, 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 de conteneur approche de l’obsolescence | Les notifications d’obsolescence ne sont pas disponibles pour les fonctions utilisant des images de conteneur. La responsabilité des mises à jour de l’image de base du conteneur s’arrête à la date d’obsolescence. | Tenez compte des planifications d’obsolescence et mettez à niveau les fonctions vers une image de base prise en charge avant que l’image précédente ne soit obsolète. |
## 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. Bien que vous puissiez continuer à invoquer vos fonctions indéfiniment, il AWS est vivement recommandé de migrer vers un environnement d'exécution compatible. Les 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.
Vous pouvez mettre à jour une fonction pour qu’elle utilise un environnement d’exécution plus récent à tout moment après qu’un environnement d’exécution soit devenu obsolète. Nous vous recommandons de tester votre fonction avec le nouveau moteur d’exécution avant d’appliquer les modifications aux environnements de production. Vous ne pourrez plus revenir à l’environnement d’exécution obsolète une fois les mises à jour des fonctions bloquées. Nous vous recommandons d’utiliser des [versions](configuration-versions.md) et [alias](configuration-aliases.md) de fonctions pour permettre un déploiement sécurisé avec restauration.
La chronologie suivante décrit ce qui se produit lorsqu’un environnement d’exécution est obsolète :
| Phase de cycle de vie de l’environnement d’exécution | Lorsque | Quoi |
| --- | --- | --- |
| Période d’avis d’obsolescence | Au moins 180 jours avant l’obsolescence | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/lambda-runtimes.html) |
| Obsolescence | Date d’obsolescence | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/lambda-runtimes.html) |
| Créer la fonction de blocage | Au moins 30 jours après l’obsolescence | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/lambda-runtimes.html) |
| Mettre à jour la fonction de blocage | Au moins 60 jours après l’obsolescence | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/lambda-runtimes.html) |
**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](#runtimes-supported) et [Environnements d’exécution obsolètes](#runtimes-deprecated) pour connaître les dates relatives à votre environnement d’exécution. Lambda ne commencera pas à bloquer les créations ou les mises à jour de fonctions avant les dates indiquées dans ces tables.
## 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 Tableau de bord Health 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 \$1LATEST de toutes les fonctions utilisant le runtime. Pour consulter la liste complète des versions de fonctions concernées, utilisez Trusted Advisor ou consultez[Récupération de données sur les fonctions Lambda qui utilisent un environnement d’exécution obsolète](runtimes-list-deprecated.md).
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](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html) dans la *Référence générale AWS *.
+ Recevoir des notifications par le biais de Tableau de bord Health :
Tableau de bord Health 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](https://health.aws.amazon.com/health/home#/account/dashboard/other-notifications). L'onglet **Ressources affectées** de la notification répertorie les versions \$1LATEST 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 consultez[Récupération de données sur les fonctions Lambda qui utilisent un environnement d’exécution obsolète](runtimes-list-deprecated.md).
Tableau de bord Health 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 au moins **180 jours** avant qu'un environnement d'exécution ne soit obsolète. Les notifications apparaissent sur la page [Sécurité](https://console.aws.amazon.com/trustedadvisor/home#/category/security). 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 \$1LATEST 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](https://console.aws.amazon.com/trustedadvisor/home?#/preferences) 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 :
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Python 3.9 | python3.9 | Amazon Linux 2 | 15 déc. 2025 | 31 août 2026 | 30 sept. 2026 |
| Node.js 18 | nodejs18.x | Amazon Linux 2 | 1e septembre 2025 | 31 août 2026 | 30 sept. 2026 |
| .NET 6 | dotnet6 | Amazon Linux 2 | 20 décembre 2024 | 31 août 2026 | 30 sept. 2026 |
| Python 3.8 | python3.8 | Amazon Linux 2 | 14 octobre 2024 | 31 août 2026 | 30 sept. 2026 |
| Node.js 16 | nodejs16.x | Amazon Linux 2 | 12 juin 2024 | 31 août 2026 | 30 sept. 2026 |
| .NET 7 (conteneur uniquement) | dotnet7 | Amazon Linux 2 | 14 mai 2024 | N/A | N/A |
| Java 8 | java8 | Amazon Linux | 8 janvier 2024 | 8 février 2024 | 30 sept. 2026 |
| Go 1.x | go1.x | Amazon Linux | 8 janvier 2024 | 8 février 2024 | 30 sept. 2026 |
| Exécution réservée au système d'exploitation | provided | Amazon Linux | 8 janvier 2024 | 8 février 2024 | 30 sept. 2026 |
| Ruby 2.7 | ruby2.7 | Amazon Linux 2 | 7 décembre 2023 | 9 janvier 2024 | 30 sept. 2026 |
| Node.js 14 | nodejs14.x | Amazon Linux 2 | 4 décembre 2023 | 9 janvier 2024 | 30 sept. 2026 |
| Python 3.7 | python3.7 | Amazon Linux | 4 décembre 2023 | 9 janvier 2024 | 30 sept. 2026 |
| .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 | N/A | N/A |
| .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 | 4 février 2020 | 6 mars 2020 |
| Node.js 4.3 | nodejs4.3 | Amazon Linux | 5 mars 2020 | 3 février 2020 | 5 mars 2020 |
| Node.js 4.3 edge | nodejs4.3-edge | Amazon Linux | 5 mars 2020 | 31 mars 2019 | 30 avril 2019 |
| Node.js 6.10 | nodejs6.10 | Amazon Linux | 12 août 2019 | 12 juillet 2019 | 12 août 2019 |
| .NET Core 1.0 | dotnetcore1.0 | Amazon Linux | 27 juin 2019 | 30 juin 2019 | 30 juillet 2019 |
| .NET Core 2.0 | dotnetcore2.0 | Amazon Linux | 30 mai 2019 | 30 avril 2019 | 30 mai 2019 |
| Node.js 0.10 | nodejs | Amazon Linux | 30 août 2016 | 30 sept. 2016 | 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](https://github.com/nodejs/Release#release-schedule)
+ **Python** – [devguide.python.org](https://devguide.python.org/versions/#versions)
+ **Ruby** – [www.ruby-lang.org](https://www.ruby-lang.org/en/downloads/branches/)
+ **Java** [— [www.oracle.com](https://www.oracle.com/java/technologies/java-se-support-roadmap.html) et Corretto FAQs](https://aws.amazon.com/corretto/faqs/)
+ **Go** – [golang.org](https://golang.org/doc/devel/release.html)
+ **.NET** – [dotnet.microsoft.com](https://dotnet.microsoft.com/platform/support/policy/dotnet-core)
# Comprendre comment Lambda gère les mises à jour de version de l’environnement d’exécution
Lambda maintient à jour chaque environnement d’exécution géré avec des mises à jour de sécurité, des corrections de bogues, de nouvelles fonctionnalités, des améliorations de performance et la prise en charge des versions mineures. Ces mises à jour d’environnement d’exécution sont publiées sous forme de *versions d’environnement d’exécution*. Lambda applique les mises à jour d’environnement d’exécution aux fonctions en faisant migrer la fonction d’une version antérieure vers une nouvelle version.
Par défaut, pour les fonctions utilisant des exécutions gérées, Lambda applique des mises à jour automatiquement. Avec les mises à jour de l’environnement d’exécution automatiques, Lambda prend en charge la charge opérationnelle de l’application de correctifs aux versions de l’environnement d’exécution. Pour la plupart des clients, les mises à jour automatiques sont le bon choix. Vous pouvez modifier ce comportement par défaut en [configurant les paramètres de gestion de l’environnement d’exécution](runtime-management-configure-settings.md).
Lambda publie également chaque nouvelle version de l’environnement d’exécution sous forme d’image de conteneur. Pour mettre à jour les versions des environnements d’exécution pour les fonctions basées sur des conteneurs, vous devez [créer une nouvelle image de conteneur](images-create.md) à partir de l’image de base mise à jour et redéployer votre fonction.
Chaque version de l’environnement d’exécution est associée à un numéro de version et à un ARN (Amazon Resource Name). Les numéros de version de l’environnement d’exécution utilisent un schéma de numérotation que Lambda définit, indépendamment des numéros de version utilisés par le langage de programmation. Les numéros de version des environnements d’exécution ne sont pas toujours séquentiels. Par exemple, la version 42 peut être suivie de la version 45. L’ARN de la version de l’environnement d’exécution est un identifiant unique pour chaque version. Vous pouvez voir l’ARN de la version de l’environnement d’exécution actuelle de votre fonction dans la console Lambda ou dans la [ligne `INIT_START` des journaux de votre fonction](runtime-management-identify.md).
Les versions des environnements d’exécution ne doivent pas être confondues avec les identifiants des environnements d’exécution. Chaque environnement d’exécution possède un **identifiant unique**, tel que `python3.14` ou `nodejs24.x`. Ceux-ci correspondent à chaque version majeure du langage de programmation. Les versions de l’environnement d’exécution décrivent la version corrective d’un environnement d’exécution individuel.
**Note**
L'ARN pour le même numéro de version d'exécution peut varier selon Régions AWS les architectures de processeur.
**Topics**
+ [
## Rétrocompatibilité
](#runtime-update-compatibility)
+ [
## Modes de mise à jour de l’environnement d’exécution
](#runtime-management-controls)
+ [
## Déploiement des versions de l’environnement d’exécution en deux phases
](#runtime-management-two-phase)
+ [
# Configuration des paramètres de gestion de l’environnement d’exécution Lambda
](runtime-management-configure-settings.md)
+ [
# Rétablissement d’une version de l’environnement d’exécution Lambda
](runtime-management-rollback.md)
+ [
# Identification des changements de version de l’environnement d’exécution Lambda
](runtime-management-identify.md)
+ [
# Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda
](runtime-management-shared.md)
+ [
# Contrôle des autorisations de mise à jour de l’environnement d’exécution Lambda pour les applications hautement conformes
](runtime-management-hc-applications.md)
## Rétrocompatibilité
Lambda s’efforce de fournir des mises à jour d’environnement d’exécution qui sont rétrocompatibles avec les fonctions existantes. Cependant, comme pour les correctifs logiciels, il existe de rares cas dans lesquels une mise à jour de l’environnement d’exécution peut avoir un impact négatif sur une fonction existante. Par exemple, les correctifs de sécurité peuvent exposer un problème sous-jacent à une fonction existante qui dépend du comportement précédent, non sécurisé.
Lorsque vous créez et déployez votre fonction, il est important de comprendre comment gérer vos dépendances afin d’éviter d’éventuelles incompatibilités lors d’une future mise à jour d’environnement d’exécution. Supposons, par exemple, que votre fonction soit dépendante du package A, lui-même dépendant du package B. Les deux packages sont inclus dans l’environnement d’exécution Lambda (par exemple, ils peuvent faire partie du SDK ou de ses dépendances, ou faire partie des bibliothèques du système d’exécution).
Réfléchissez aux scénarios suivants :
| Déploiement | Compatible avec les correctifs | Raison |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html) | Oui | Les futures mises à jour d’environnement d’exécution des packages A et B seront rétrocompatibles. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html) | Oui | Votre déploiement étant prioritaire, les futures mises à jour d’environnement d’exécution des packages A et B n’auront aucun effet. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html) | Oui\$1 | Les futures mises à jour d’environnement d’exécution du package B seront rétrocompatibles. \$1Si A et B sont étroitement couplés, des problèmes de compatibilité peuvent survenir. Par exemple, les `botocore` packages `boto3` et du AWS SDK pour Python doivent être déployés ensemble. |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/runtimes-update.html) | Non | Les futures mises à jour d’environnement d’exécution du package A peuvent nécessiter une version mise à jour du package B. Cependant, la version déployée du package B est prioritaire et risque de ne pas être compatible avec la version mise à jour du package A. |
Pour maintenir la compatibilité avec les futures mises à jour d’environnement d’exécution, suivez les bonnes pratiques suivantes :
+ Dans la mesure du **possible, regroupez toutes les dépendances :** incluez toutes les bibliothèques requises, y compris le AWS SDK et ses dépendances, dans votre package de déploiement. Cela garantit que votre ensemble de composants reste stable et compatible.
+ **Utilisez l'environnement d'exécution SDKs avec parcimonie :** utilisez uniquement le SDK fourni par l'exécution lorsque vous ne pouvez pas inclure de packages supplémentaires (par exemple, lorsque vous utilisez l'éditeur de code de la console Lambda ou du code en ligne dans un modèle). AWS CloudFormation
+ **Évitez de remplacer les bibliothèques système :** ne déployez pas de bibliothèques de système d’exploitation personnalisées susceptibles d’entrer en conflit avec les futures mises à jour d’environnement d’exécution.
## Modes de mise à jour de l’environnement d’exécution
Lambda s’efforce de fournir des mises à jour d’environnement d’exécution qui sont rétrocompatibles avec les fonctions existantes. Cependant, comme pour les correctifs logiciels, il existe de rares cas dans lesquels une mise à jour de l’environnement d’exécution peut avoir un impact négatif sur une fonction existante. Par exemple, les correctifs de sécurité peuvent exposer un problème sous-jacent à une fonction existante qui dépend du comportement précédent, non sécurisé. Les contrôles de gestion de l’environnement d’exécution Lambda permettent de réduire le risque d’impact sur vos charges de travail dans le cas rare d’une incompatibilité de version. Pour chaque [version de fonction](configuration-versions.md) (`$LATEST` ou version publiée), vous pouvez choisir l’un des modes de mise à jour de l’environnement d’exécution suivants :
+ **Auto (par défaut)** – Mettre automatiquement à jour vers la version de l’environnement d’exécution la plus sécurisée et la plus sûre à l’aide de [Déploiement des versions de l’environnement d’exécution en deux phases](#runtime-management-two-phase). Nous recommandons ce mode à la plupart des clients afin que vous puissiez toujours bénéficier des mises à jour de l’environnement d’exécution.
+ **Mise à jour de fonction** – Mise à jour vers la version d’exécution la plus récente et la plus sécurisée lorsque vous mettez à jour votre fonction. Lorsque vous mettez à jour votre fonction, Lambda met à jour l’exécution de votre fonction vers la version la plus récente et la plus sécurisée. Cette approche synchronise les mises à jour de l’environnement d’exécution avec les déploiements de fonctions, ce qui vous permet de contrôler le moment où Lambda applique les mises à jour de l’environnement d’exécution. Avec ce mode, vous pouvez détecter et atténuer rapidement les rares incompatibilités de mise à jour de l’environnement d’exécution. Lorsque vous utilisez ce mode, vous devez régulièrement mettre à jour vos fonctions pour maintenir leur environnement d’exécution à jour.
+ **Manuel** – Mise à jour manuelle de la version de votre exécution. Vous spécifiez une version de l’exécution dans la configuration de votre fonction. La fonction utilise cette version de l’environnement d’exécution indéfiniment. Dans les rares cas où une nouvelle version de l’environnement d’exécution est incompatible avec une fonction existante, vous pouvez utiliser ce mode pour ramener votre fonction à une version antérieure. Nous vous déconseillons d’utiliser le mode **Manual** (Manuel) pour tenter d’obtenir une cohérence de l’environnement d’exécution entre les déploiements. Pour de plus amples informations, veuillez consulter [Rétablissement d’une version de l’environnement d’exécution Lambda](runtime-management-rollback.md).
La responsabilité de l’application des mises à jour de l’environnement d’exécution à vos fonctions varie en fonction du mode de mise à jour que vous choisissez. Pour de plus amples informations, veuillez consulter [Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda](runtime-management-shared.md).
## Déploiement des versions de l’environnement d’exécution en deux phases
Lambda introduit de nouvelles gestions des versions d’exécution dans l’ordre suivant :
1. Dans la première phase, Lambda applique la nouvelle version d’exécution chaque fois que vous créez ou mettez à jour une fonction. Une fonction est mise à jour lorsque vous appelez les opérations de [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)l'API [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)or.
1. Dans la deuxième phase, Lambda met à jour toute fonction qui utilise le mode de mise à jour **Auto** de l’environnement d’exécution et qui n’a pas encore été mise à jour vers la nouvelle version.
La durée totale du processus de déploiement varie en fonction de plusieurs facteurs, notamment la gravité de tout correctif de sécurité inclus dans la mise à jour de l’environnement d’exécution.
Si vous développez et déployez activement vos fonctions, vous obtiendrez très probablement de nouvelles versions de l’environnement d’exécution au cours de la première phase. Cela permet de synchroniser les mises à jour de l’environnement d’exécution avec les mises à jour des fonctions. Dans le cas rare où la dernière version d’exécution aurait un impact négatif sur votre application, cette approche vous permet de prendre rapidement des mesures correctives. Les fonctions qui ne sont pas en cours de développement bénéficient toujours des avantages opérationnels des mises à jour automatiques de l’environnement d’exécution au cours de la deuxième phase.
Cette approche n’affecte pas les fonctions définies en mode **Function update** (Mise à jour de fonction) ou en mode **Manual** (Manuel). Les fonctions utilisant le mode **Function update** (Mise à jour de fonction) reçoivent les dernières mises à jour de l’environnement d’exécution uniquement lorsque vous les créez ou les mettez à jour. Les fonctions utilisant le mode **Manual** (Manuel) ne reçoivent pas de mises à jour de l’environnement d’exécution.
Lambda publie les nouvelles versions de l’environnement d’exécution de manière progressive et continue à travers Régions AWS. Si vos fonctions sont configurées en mode **Auto** ou **Function update** (Mise à jour de fonction), il est possible que les fonctions déployées au même moment dans différentes régions, ou à différents moments dans la même région, reçoivent des versions de l’environnement d’exécution différentes. Les clients qui exigent une cohérence garantie des versions de l’environnement d’exécution dans leurs environnements doivent [utiliser des images de conteneurs pour déployer leurs fonctions Lambda](images-create.md). Le mode **Manuel** est conçu comme une mesure d’atténuation temporaire pour permettre de restaurer la version d’exécution dans le rare cas où une version d’exécution est incompatible avec votre fonction.
# Configuration des paramètres de gestion de l’environnement d’exécution Lambda
Vous pouvez configurer les paramètres de gestion de l’environnement d’exécution à l’aide de la console Lambda ou de AWS Command Line Interface (AWS CLI).
**Note**
Vous pouvez configurer les paramètres de gestion de l’environnement d’exécution séparément pour chaque [version de fonction](configuration-versions.md).
**Pour configurer la façon dont Lambda met à jour la version de votre environnement d’exécution (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Dans l’onglet **Code**, sous **Runtime settings** (Paramètres de l’environnement d’exécution), choisissez **Edit runtime management configuration** (Modifier la configuration de gestion de l’environnement d’exécution).
1. Sous **Runtime management configuration** (Configuration de la gestion de l’environnement d’exécution), choisissez l’une des options suivantes :
+ Pour que votre fonction se mette automatiquement à jour vers la dernière version de l’environnement d’exécution, sélectionnez **Auto**.
+ Pour que votre fonction se mette à jour vers la dernière version de l’environnement d’exécution lorsque vous modifiez la fonction, sélectionnez **Function update** (Mise à jour de fonction).
+ Pour que votre fonction soit mise à jour vers la dernière version de l’environnement d’exécution uniquement lorsque vous modifiez la version de l’environnement d’exécution ARN, sélectionnez **Manual** (Manuel). Vous trouverez l’ARN de la version de l’environnement d’exécution sous **Runtime management configuration** (Configuration de la gestion de l’environnement d’exécution). Vous pouvez également trouver l’ARN dans la ligne `INIT_START` des journaux de votre fonction.
Pour de plus amples informations sur ces options, veuillez consulter [Modes de mise à jour de l’environnement d’exécution](runtimes-update.md#runtime-management-controls).
1. Choisissez **Enregistrer**.
**Pour configurer la façon dont Lambda met à jour votre version de l’environnement d’exécution (AWS CLI)**
Pour configurer la gestion de l’environnement d’exécution d’une fonction, exécutez la commande [put-runtime-management-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/put-runtime-management-config.html) de l’AWS CLI. Lorsque vous utilisez le mode `Manual`, vous devez également fournir l’ARN de la version de l’environnement d’exécution.
```
aws lambda put-runtime-management-config \
--function-name my-function \
--update-runtime-on Manual \
--runtime-version-arn arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1
```
Vous devez voir des résultats similaires à ce qui suit :
```
{
"UpdateRuntimeOn": "Manual",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"RuntimeVersionArn": "arn:aws:lambda:us-east-2::runtime:8eeff65f6809a3ce81507fe733fe09b835899b99481ba22fd75b5a7338290ec1"
}
```
# Rétablissement d’une version de l’environnement d’exécution Lambda
Dans le cas rare où une nouvelle version de l’environnement d’exécution est incompatible avec votre fonction existante, vous pouvez rétablir sa version à une version antérieure. Cela permet à votre application de continuer à fonctionner et de minimiser les perturbations, en laissant le temps de remédier à l’incompatibilité avant de revenir à la dernière version de l’environnement d’exécution.
Lambda n’impose pas de limite de temps à l’utilisation d’une version de l’environnement d’exécution particulière. Cependant, nous vous recommandons vivement de passer à la dernière version de l’environnement d’exécution dès que possible pour bénéficier des derniers correctifs de sécurité, des améliorations de performances et des fonctionnalités. Lambda offre la possibilité de revenir à une version antérieure de l’environnement d’exécution uniquement à titre d’atténuation temporaire dans le cas rare d’un problème de compatibilité de mise à jour de l’environnement d’exécution. Les fonctions qui utilisent une version d’exécution antérieure pendant une période prolongée peuvent subir une dégradation des performances ou des problèmes, tels que l’expiration d’un certificat, qui peuvent les empêcher de fonctionner correctement.
Vous pouvez rétablir une version de l’environnement d’exécution de l’une des manières suivantes :
+ [En utilisant le mode de mise à jour Manual (Manuel) de l’environnement d’exécution](#runtime-management-rollback-manual)
+ [En utilisant les versions de la fonction publiée](#runtime-management-rollback-published)
Pour plus d’informations, consultez [Introduction aux contrôles de gestion de l’environnement d’exécution AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/) sur le blog AWS.
## Rétablissement d’une version de l’environnement d’exécution à l’aide du mode de mise à jour Manual (Manuel)
Si vous utilisez le mode de mise à jour **Auto** de la version de l’environnement d’exécution, ou si vous utilisez la version `$LATEST`, vous pouvez rétablir la version de votre environnement d’exécution en utilisant le mode **Manual** (Manuel). Pour la [version de la fonction](configuration-versions.md) que vous voulez rétablir, définissez le mode de mise à jour de la version de l’environnement d’exécution sur **Manual** (Manuel) et indiquez l’ARN de la version précédente. Pour plus d’informations sur la recherche de l’ARN de la version de l’environnement d’exécution précédente, consultez [Identification des changements de version de l’environnement d’exécution Lambda](runtime-management-identify.md).
**Note**
Si la version `$LATEST` de votre fonction est configurée pour utiliser le mode **Manual** (Manuel), vous ne pouvez pas modifier l’architecture du processeur ou la version de l’environnement d’exécution que votre fonction utilise. Pour effectuer ces modifications, vous devez passer en mode **Auto** ou **Function update** (Mise à jour de fonction).
## Rétablissement d’une version de l’environnement d’exécution à l’aide des versions de fonction publiées
Les [versions de fonction](configuration-versions.md) publiées sont un instantané immuable du code et de la configuration de la fonction `$LATEST` au moment où vous les avez créées. En mode **Auto**, Lambda met automatiquement à jour la version de l’environnement d’exécution des versions de fonctions publiées pendant la phase deux du déploiement de la version de l’environnement d’exécution. En mode **Function update** (Mise à jour de fonction), Lambda ne met pas à jour la version de l’environnement d’exécution des versions de fonctions publiées.
Les versions de fonctions publiées utilisant le mode **Function update** (Mise à jour de fonction) créent donc un instantané statique du code de la fonction, de la configuration et de la version de l’environnement d’exécution. En utilisant le mode **Function update** (Mise à jour de fonction) avec les versions de fonctions, vous pouvez synchroniser les mises à jour de l’environnement d’exécution avec vos déploiements. Vous pouvez également coordonner le rétablissement des versions de code, de configuration et de l’environnement d’exécution en redirigeant le trafic vers une version de fonction publiée antérieurement. Vous pouvez intégrer cette approche à votre système d’intégration et de livraison continues (CI/CD) afin de rétablir automatiquement la situation dans les rares cas d’incompatibilité des mises à jour de l’environnement d’exécution. Lorsque vous utilisez cette approche, vous devez mettre à jour votre fonction régulièrement et publier de nouvelles versions de la fonction pour récupérer les dernières mises à jour de l’exécution. Pour de plus amples informations, consultez [Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda](runtime-management-shared.md).
# Identification des changements de version de l’environnement d’exécution Lambda
Le [numéro de version de l’environnement d’exécution](runtimes-update.md) et l’ARN sont consignés dans la ligne de journal `INIT_START`, que Lambda émet vers CloudWatch Logs chaque fois qu’il crée un nouvel [environnement d’exécution](concepts-basics.md#gettingstarted-concepts-runtime). Étant donné que l’environnement d’exécution utilise la même exécution pour tous les invocations de fonction, Lambda émet la ligne de journal `INIT_START` uniquement lorsqu’il exécute la phase init. Lambda n’émet pas cette ligne de journal pour chaque invocation de fonction. Lambda émet la ligne de journal vers CloudWatch Logs, mais elle n’est pas visible dans la console.
**Note**
Les numéros de version des environnements d’exécution ne sont pas toujours séquentiels. Par exemple, la version 42 peut être suivie de la version 45.
**Example Exemple de ligne de journal INIT\$1START**
```
INIT_START Runtime Version: python:3.13.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I
```
Plutôt que de travailler directement avec les journaux, vous pouvez utiliser [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-CreateRule.html) pour identifier les transitions entre les versions de l’environnement d’exécution. La règle suivante compte les versions de l’environnement d’exécution distinctes de chaque ligne de journal `INIT_START`. Pour utiliser la règle, remplacez l’exemple de nom de groupe de journaux `/aws/lambda/*` par le préfixe approprié pour votre fonction ou groupe de fonctions.
```
{
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "eventType",
"In": [
"INIT_START"
]
}
],
"Keys": [
"runtimeVersion",
"runtimeVersionArn"
]
},
"LogFormat": "CLF",
"LogGroupNames": [
"/aws/lambda/*"
],
"Fields": {
"1": "eventType",
"4": "runtimeVersion",
"8": "runtimeVersionArn"
}
}
```
Le rapport suivant de CloudWatch Contributor Insights montre un exemple de transition de version de l’environnement d’exécution tel que capturé par la règle précédente. La ligne orange montre l’initialisation de l’environnement d’exécution pour la version précédente (**python:3.13.v12**), et la ligne bleue montre l’initialisation de l’environnement d’exécution pour la nouvelle version (**python:3.13.v14**).
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/runtime_version_graph.png)
# Comprendre le modèle de responsabilité partagée pour la gestion des environnements d’exécution Lambda
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 conteneurs pris en charge. La responsabilité de la mise à jour des fonctions existantes pour utiliser la dernière version de l’environnement d’exécution varie en fonction du mode de mise à jour que vous utilisez.
Lambda est responsable de l’application des mises à jour de l’environnement d’exécution à toutes les fonctions configurées pour utiliser le mode de mise à jour **Auto**.
Pour les fonctions configurées avec le mode de mise à jour d’exécution **Function update** (Mise à jour de fonction), vous êtes responsable de la mise à jour régulière de votre fonction. Lambda est responsable de l’application des mises à jour de l’environnement d’exécution lorsque vous effectuez ces mises à jour. Si vous ne mettez pas à jour votre fonction, Lambda ne met pas à jour l’environnement d’exécution. Si vous ne mettez pas régulièrement à jour votre fonction, nous vous recommandons vivement de la configurer pour les mises à jour automatiques de l’environnement d’exécution afin qu’elle continue à recevoir les mises à jour de sécurité.
Pour les fonctions configurées pour utiliser le mode de mise à jour **Manual** (Manuel), vous êtes responsable de la mise à jour de votre fonction pour utiliser la dernière version de l’environnement d’exécution. Nous vous recommandons vivement d’utiliser ce mode uniquement pour rétablir la version de l’environnement d’exécution à titre de mesure d’atténuation temporaire dans le cas rare d’une incompatibilité de mise à jour. Nous vous recommandons également de passer en mode **Auto** le plus rapidement possible afin de minimiser le temps pendant lequel vos fonctions ne sont pas corrigées.
Si vous [utilisez des images de conteneur pour déployer vos fonctions](images-create.md), Lambda est responsable de la publication des images de base mises à jour. Dans ce cas, vous êtes responsable de la recréation 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.
Ceci est résumé dans le tableau suivant :
****
| Mode de déploiement | Responsabilité de Lambda | Responsabilité du client |
| --- | --- | --- |
| Environnement d’exécution géré, mode Auto | Publiez de nouvelles versions de l’environnement d’exécution contenant les derniers correctifs. Appliquez les correctifs de l’environnement d’exécution aux fonctions existantes. | Rétablissez une version de l’environnement d’exécution précédente dans le cas rare d’un problème de compatibilité de mise à jour de l’environnement d’exécution. Suivez les meilleures pratiques de [rétrocompatibilité](runtimes-update.md#runtime-update-compatibility). |
| Environnement d’exécution géré, mode Function update (Mise à jour de fonction) | Publiez de nouvelles versions de l’environnement d’exécution contenant les derniers correctifs. | Mettez régulièrement à jour les fonctions afin de bénéficier de la dernière version de l’environnement d’exécution. Passez une fonction en mode **Auto** lorsque vous ne la mettez pas régulièrement à jour. Rétablissez une version de l’environnement d’exécution précédente dans le cas rare d’un problème de compatibilité de mise à jour de l’environnement d’exécution. Suivez les meilleures pratiques de [rétrocompatibilité](runtimes-update.md#runtime-update-compatibility). |
| Environnement d’exécution géré, mode Manual (Manuel) | Publiez de nouvelles versions de l’environnement d’exécution contenant les derniers correctifs. | Utilisez ce mode uniquement pour restaurer temporairement l’environnement d’exécution dans le cas rare d’un problème de compatibilité de mise à jour. Passez les fonctions en mode **Auto** ou **Function update** (Mise à jour de fonction) et la dernière version de l’environnement d’exécution dès que possible. |
| Image de conteneur | Publiez de nouvelles images de conteneur contenant les derniers correctifs. | Redéployez régulièrement les fonctions en utilisant la dernière image de base du conteneur pour bénéficier des derniers correctifs. |
Pour plus d’informations sur la responsabilité partagée avec AWS, consultez [Modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Contrôle des autorisations de mise à jour de l’environnement d’exécution Lambda pour les applications hautement conformes
Pour répondre aux exigences de correctifs, les clients Lambda s’appuient généralement sur des mises à jour automatiques de l’environnement d’exécution. Si votre application est soumise à des exigences strictes en matière de nouveauté des correctifs, vous voudrez peut-être limiter l’utilisation de versions de l’environnement d’exécution antérieures. Vous pouvez restreindre les contrôles de gestion de l’environnement d’exécution de Lambda en utilisant Gestion des identités et des accès AWS (IAM) pour refuser aux utilisateurs de votre compte AWS l’accès à l’opération d’API [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html). Cette opération est utilisée pour choisir le mode de mise à jour de l’environnement d’exécution d’une fonction. En refusant l’accès à cette opération, toutes les fonctions passent par défaut au mode **Auto**. Vous pouvez appliquer cette restriction à l’échelle de votre organisation en utilisant des [politiques de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Si vous devez rétablir une fonction à une version de l’environnement d’exécution antérieure, vous pouvez accorder une exception de politique au cas par cas.
# Récupération de données sur les fonctions Lambda qui utilisent un environnement d’exécution obsolète
Lorsqu'un environnement d'exécution Lambda est sur le point de devenir obsolète, Lambda vous avertit par e-mail et vous envoie des notifications dans le et. Tableau de bord Health Trusted Advisor Ces e-mails et notifications répertorient les versions \$1LATEST des fonctions utilisant l’environnement d’exécution. Pour répertorier toutes les versions de vos fonctions qui utilisent un environnement d'exécution particulier, vous pouvez utiliser le AWS Command Line Interface (AWS CLI) ou l'un des AWS SDKs.
Si un grand nombre de fonctions utilisent un environnement d'exécution destiné à être obsolète, vous pouvez également utiliser le AWS CLI ou pour vous aider AWS SDKs à prioriser les mises à jour de vos fonctions les plus fréquemment invoquées.
Reportez-vous aux sections suivantes pour savoir comment utiliser AWS CLI et AWS SDKs pour collecter des données sur les fonctions qui utilisent un environnement d'exécution particulier.
## Liste des versions de fonctions qui utilisent un environnement d’exécution particulier
Pour utiliser le AWS CLI pour répertorier toutes les versions de vos fonctions qui utilisent un environnement d'exécution particulier, exécutez la commande suivante. `RUNTIME_IDENTIFIER`Remplacez-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 \$1LATEST, 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.
Vous pouvez également répertorier les fonctions qui utilisent un environnement d'exécution particulier à l'aide de l'un des AWS SDKs. L'exemple de code suivant utilise le V3 AWS SDK pour JavaScript et le AWS SDK pour Python (Boto3) pour renvoyer une liste des fonctions ARNs utilisant un environnement d'exécution particulier. L'exemple de code renvoie également le groupe de CloudWatch journaux pour chacune des fonctions répertoriées. Vous pouvez utiliser ce groupe de journaux pour trouver la date de la dernière invocation de la fonction. Consultez la section [Identification des fonctions les plus fréquemment et les plus récemment invoquées](#runtimes-list-deprecated-statistics) suivante pour plus d’informations.
------
#### [ Node.js ]
**Example JavaScript code pour répertorier les fonctions utilisant un environnement d'exécution particulier**
```
import { LambdaClient, ListFunctionsCommand } from "@aws-sdk/client-lambda";
const lambdaClient = new LambdaClient();
const command = new ListFunctionsCommand({
FunctionVersion: "ALL",
MaxItems: 50
});
const response = await lambdaClient.send(command);
for (const f of response.Functions){
if (f.Runtime == ''){ // Use the runtime id, e.g. 'nodejs24.x' or 'python3.14'
console.log(f.FunctionArn);
// get the CloudWatch log group of the function to
// use later for finding the last invocation date
console.log(f.LoggingConfig.LogGroup);
}
}
// If your account has more functions than the specified
// MaxItems, use the returned pagination token in the
// next request with the 'Marker' parameter
if ('NextMarker' in response){
let paginationToken = response.NextMarker;
}
```
------
#### [ Python ]
**Example Code Python pour répertorier les fonctions utilisant un environnement d’exécution particulier**
```
import boto3
from botocore.exceptions import ClientError
def list_lambda_functions(target_runtime):
lambda_client = boto3.client('lambda')
response = lambda_client.list_functions(
FunctionVersion='ALL',
MaxItems=50
)
if not response['Functions']:
print("No Lambda functions found")
else:
for function in response['Functions']:
if function['PackageType']=='Zip' and function['Runtime'] == target_runtime:
print(function['FunctionArn'])
# Print the CloudWatch log group of the function
# to use later for finding last invocation date
print(function['LoggingConfig']['LogGroup'])
if 'NextMarker' in response:
pagination_token = response['NextMarker']
if __name__ == "__main__":
# Replace python3.12 with the appropriate runtime ID for your Lambda functions
list_lambda_functions('python3.12')
```
------
Pour en savoir plus sur l'utilisation d'un AWS SDK pour répertorier vos fonctions à l'aide de l'[ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)action, consultez la [documentation du SDK correspondant](https://aws.amazon.com/developer/tools/) à votre langage de programmation préféré.
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 \$1LATEST 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](https://docs.aws.amazon.com/config/latest/developerguide/querying-AWS-resources.html) dans le *guide du AWS Config développeur*.
## Identification des fonctions les plus fréquemment et les plus récemment invoquées
Si vous utilisez Compte AWS des fonctions qui utilisent un environnement d'exécution destiné à être obsolète, vous souhaiterez peut-être donner la priorité à la mise à jour des fonctions fréquemment invoquées ou des fonctions qui ont été invoquées récemment.
Si vous ne disposez que de quelques fonctions, vous pouvez utiliser la console CloudWatch Logs pour recueillir ces informations en consultant les flux de journaux de vos fonctions. Voir [Afficher les données de journal envoyées à CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) pour plus d'informations.
Pour connaître le nombre d'appels de fonctions récents, vous pouvez également utiliser les informations de CloudWatch métriques affichées dans la console Lambda. Pour afficher ces informations, procédez comme suit :
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction dont vous souhaitez consulter les statistiques d’invocation.
1. Choisissez l’onglet **Surveiller**.
1. Définissez la période pendant laquelle vous souhaitez consulter les statistiques à l’aide du sélecteur de plage de dates. Les invocations récentes sont affichées dans le volet **Invocations**.
Pour les comptes dotés d'un plus grand nombre de fonctions, il peut être plus efficace de collecter ces données par programmation en utilisant l'une AWS CLI ou l'une des AWS SDKs actions d'[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)API [DescribeLogStreams](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DescribeLogStreams.html)et.
Les exemples suivants fournissent des extraits de code utilisant la V3 AWS SDK pour JavaScript et le AWS SDK pour Python (Boto3) pour identifier la date du dernier appel pour une fonction particulière et pour déterminer le nombre d'appels pour une fonction particulière au cours des 14 derniers jours.
------
#### [ Node.js ]
**Example JavaScript code pour trouver l'heure du dernier appel d'une fonction**
```
import { CloudWatchLogsClient, DescribeLogStreamsCommand } from "@aws-sdk/client-cloudwatch-logs";
const cloudWatchLogsClient = new CloudWatchLogsClient();
const command = new DescribeLogStreamsCommand({
logGroupName: '',
orderBy: 'LastEventTime',
descending: true,
limit: 1
});
try {
const response = await cloudWatchLogsClient.send(command);
const lastEventTimestamp = response.logStreams.length > 0 ?
response.logStreams[0].lastEventTimestamp : null;
// Convert the UNIX timestamp to a human-readable format for display
const date = new Date(lastEventTimestamp).toLocaleDateString();
const time = new Date(lastEventTimestamp).toLocaleTimeString();
console.log(`${date} ${time}`);
} catch (e){
console.error('Log group not found.')
}
```
------
#### [ Python ]
**Example Code Python pour trouver l’heure de la dernière invocation d’une fonction**
```
import boto3
from datetime import datetime
cloudwatch_logs_client = boto3.client('logs')
response = cloudwatch_logs_client.describe_log_streams(
logGroupName='',
orderBy='LastEventTime',
descending=True,
limit=1
)
try:
if len(response['logStreams']) > 0:
last_event_timestamp = response['logStreams'][0]['lastEventTimestamp']
print(datetime.fromtimestamp(last_event_timestamp/1000)) # Convert timestamp from ms to seconds
else:
last_event_timestamp = None
except:
print('Log group not found')
```
------
**Astuce**
Vous pouvez trouver le nom du groupe de journaux de votre fonction à l'aide de l'opération [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)API. Consultez le code dans [Liste des versions de fonctions qui utilisent un environnement d’exécution particulier](#runtimes-list-deprecated-versions) pour obtenir un exemple montrant la façon de procéder.
------
#### [ Node.js ]
**Example JavaScript code pour trouver le nombre d'invocations au cours des 14 derniers jours**
```
import { CloudWatchClient, GetMetricStatisticsCommand } from "@aws-sdk/client-cloudwatch";
const cloudWatchClient = new CloudWatchClient();
const command = new GetMetricStatisticsCommand({
Namespace: 'AWS/Lambda',
MetricName: 'Invocations',
StartTime: new Date(Date.now()-86400*1000*14), // 14 days ago
EndTime: new Date(Date.now()),
Period: 86400 * 14, // 14 days.
Statistics: ['Sum'],
Dimensions: [{
Name: 'FunctionName',
Value: ''
}]
});
const response = await cloudWatchClient.send(command);
const invokesInLast14Days = response.Datapoints.length > 0 ?
response.Datapoints[0].Sum : 0;
console.log('Number of invocations: ' + invokesInLast14Days);
```
------
#### [ Python ]
**Example Code Python pour trouver le nombre d’invocations au cours des 14 derniers jours**
```
import boto3
from datetime import datetime, timedelta
cloudwatch_client = boto3.client('cloudwatch')
response = cloudwatch_client.get_metric_statistics(
Namespace='AWS/Lambda',
MetricName='Invocations',
Dimensions=[
{
'Name': 'FunctionName',
'Value': ''
},
],
StartTime=datetime.now() - timedelta(days=14),
EndTime=datetime.now(),
Period=86400 * 14, # 14 days
Statistics=[
'Sum'
]
)
if len(response['Datapoints']) > 0:
invokes_in_last_14_days = int(response['Datapoints'][0]['Sum'])
else:
invokes_in_last_14_days = 0
print(f'Number of invocations: {invokes_in_last_14_days}')
```
------
# Modification de l’environnement d’exécution
Vous pouvez utiliser des [extensions internes](lambda-extensions.md) pour modifier le processus de runtime. Les extensions internes ne sont pas des processus séparés. Elles s’exécutent dans le cadre du processus du runtime.
Lambda fournit des [variables d’environnement](configuration-envvars.md) spécifiques du langage, que vous pouvez définir pour ajouter des options et des outils au runtime. Lambda intègre également des [scripts encapsuleurs](#runtime-wrapper) qui lui permettent de déléguer le démarrage du runtime à votre script. Vous pouvez créer un script encapsuleur pour personnaliser le comportement de démarrage du runtime.
## Variables d’environnement spécifiques à un langage
Lambda prend en charge des méthodes de configuration pour permettre le pré-chargement de code lors de l’initialisation de la fonction via les variables d’environnement spécifiques du langage suivantes :
+ `JAVA_TOOL_OPTIONS` : sur Java, Lambda prend en charge cette variable d’environnement pour définir des variables de ligne de commande supplémentaires dans Lambda. Cette variable d’environnement vous permet de spécifier l’initialisation des outils, en particulier le lancement d’agents de langage de programmation natifs ou Java à l’aide des options `agentlib` ou `javaagent`. Pour plus d’informations, veuillez consulter la rubrique [Variables d’environnement `JAVA_TOOL_OPTIONS`](https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html#java-tool-options).
+ `NODE_OPTIONS`— Disponible dans les environnements d’[exécution de Node.js.](lambda-nodejs.md)
+ `DOTNET_STARTUP_HOOKS` – Sur .NET Core 3.1 et versions ultérieures, cette variable d’environnement précise le chemin d’accès d’un assembly (dll) que Lambda peut utiliser.
L’utilisation de variables d’environnement spécifiques à un langage est la méthode privilégiée pour définir les propriétés de démarrage.
## Scripts encapsuleurs
Vous pouvez créer un *script encapsuleur* pour personnaliser le comportement de démarrage du runtime de votre fonction Lambda. Un script encapsuleur vous permet de définir des paramètres de configuration qui ne peuvent pas être définis via des variables d’environnement spécifiques à un langage.
**Note**
Les invocations peuvent échouer si le script encapsuleur ne démarre pas correctement le processus de runtime.
Les scripts encapsulateurs sont pris en charge sur tous les [environnements d’exécution Lambda](lambda-runtimes.md) natifs. Les scripts Wrapper ne sont pas pris en charge sur [Exécutions uniquement basées sur le système d’exploitation](runtimes-provided.md) (famille d’environnements d’exécution `provided`).
Lorsque vous utilisez un script encapsuleur pour votre fonction, Lambda démarre le runtime en utilisant votre script. Lambda envoie à votre script le chemin d’accès de l’interpréteur et tous les arguments d’origine pour le démarrage du runtime standard. Votre script peut étendre ou transformer le comportement de démarrage du programme. Par exemple, le script peut injecter et modifier des arguments, définir des variables d’environnement ou capturer des métriques, des erreurs et d’autres informations de diagnostic.
Vous spécifiez le script en définissant la valeur de la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER` comme étant le chemin vers le système de fichiers d’un fichier binaire ou d’un script exécutable.
### Exemple : Créer et utiliser un script encapsuleur en tant que couche Lambda
Dans l’exemple suivant, vous créez un script encapsuleur pour démarrer l’interpréteur Python avec l’option `-X importtime`. Lorsque vous exécutez la fonction, Lambda génère une entrée de journal pour indiquer la durée de chaque importation.
**Pour créer et utiliser un script encapsuleur en tant que couche**
1. Créez un répertoire pour la couche :
```
mkdir -p python-wrapper-layer/bin
cd python-wrapper-layer/bin
```
1. Dans le répertoire `bin`, collez le code suivant dans un nouveau fichier nommé `importtime_wrapper`. Il s’agit du script encapsuleur.
```
#!/bin/bash
# the path to the interpreter and all of the originally intended arguments
args=("$@")
# the extra options to pass to the interpreter
extra_args=("-X" "importtime")
# insert the extra options
args=("${args[@]:0:$#-1}" "${extra_args[@]}" "${args[@]: -1}")
# start the runtime with the extra options
exec "${args[@]}"
```
1. Fournissez au script des autorisations d’exécution :
```
chmod +x importtime_wrapper
```
1. Créez un fichier .zip pour la couche :
```
cd ..
zip -r ../python-wrapper-layer.zip .
```
1. Vérifiez que votre fichier .zip possède la structure de répertoire suivante :
```
python-wrapper-layer.zip
└ bin
└ importtime_wrapper
```
1. [Créez une couche](creating-deleting-layers.md#layers-create) à l’aide du package .zip.
1. Créez une fonction à l’aide de la console Lambda.
1. Ouvrez la [console Lambda](https://console.aws.amazon.com/lambda).
1. Choisissez **Créer une fonction**.
1. Indiquez un **Function name** (Nom de fonction).
1. Pour **Environnement d’exécution**, choisissez le dernier environnement d’exécution Python pris en charge (**Dernier pris en charge**).
1. Choisissez **Créer une fonction**.
1. Ajoutez la couche à votre fonction.
1. Choisissez votre fonction, puis choisissez l’onglet **Code** s’il n’est pas déjà sélectionné.
1. Faites défiler jusqu’à la section **Couches**, puis choisissez **Ajouter une couche**.
1. Pour **Source de la couche**, sélectionnez **Couches personnalisées**, puis choisissez votre couche dans la liste déroulante **Couches personnalisées**.
1. Pour **Version**, choisissez **1**.
1. Choisissez **Ajouter**.
1. Ajoutez la variable d’environnement encapsuleur.
1. Choisissez **Configuration**, puis **Variables d’environnement**.
1. Sous **Variables d’environnement**, choisissez **Modifier**.
1. Choisissez **Ajouter une variable d’environnement**.
1. Pour **Clé**, entrez `AWS_LAMBDA_EXEC_WRAPPER`.
1. Dans **Valeur**, saisissez `/opt/bin/importtime_wrapper` (`/opt/` \$1 la structure de dossiers de votre couche .zip).
1. Choisissez **Enregistrer**.
1. Testez le script encapsuleur.
1. Choisissez l’onglet **Test**.
1. Sous **Événement de test**, choisissez **Tester**. Il n’est pas nécessaire de créer un événement de test, l’événement par défaut fonctionnera.
1. Faites défiler la page jusqu’à **Sortie de journal**. Votre script encapsuleur ayant lancé l’interpréteur Python avec l’option `-X importtime`, les journaux indiquent le temps requis pour chaque importation. Exemples :
```
532 | collections
import time: 63 | 63 | _functools
import time: 1053 | 3646 | functools
import time: 2163 | 7499 | enum
import time: 100 | 100 | _sre
import time: 446 | 446 | re._constants
import time: 691 | 1136 | re._parser
import time: 378 | 378 | re._casefix
import time: 670 | 2283 | re._compiler
import time: 416 | 416 | copyreg
```
# Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés
AWS Lambda [fournit une API HTTP permettant aux environnements d'[exécution personnalisés de recevoir](runtimes-custom.md) des événements d'appel de Lambda et de renvoyer les données de réponse dans l'environnement d'exécution Lambda.](lambda-runtimes.md) Cette section contient la référence de l’API de l’environnement d’exécution Lambda.
**Les instances gérées Lambda prennent en charge les demandes simultanées**
Les instances gérées Lambda utilisent la même API d'exécution que les fonctions Lambda (par défaut). La principale différence réside dans le fait que les instances gérées peuvent accepter `/next` des `/response` demandes simultanées et jusqu'à la `AWS_LAMBDA_MAX_CONCURRENCY` limite configurée. Cela permet de traiter plusieurs appels simultanément dans un environnement d'exécution unique. Pour plus d'informations sur les instances gérées, consultez[Comprendre l'environnement d'exécution des instances gérées Lambda](lambda-managed-instances-execution-environment.md).
![\[Diagramme d’architecture de l’environnement d’exécution.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
La spécification OpenAPI pour la version d’API de l’exécution **2018-06-01** est disponible dans [runtime-api.zip](samples/runtime-api.zip)
Pour créer une URL de requête d’API, les exécutions obtiennent le point de terminaison de l’API à partir de la variable d’environnement `AWS_LAMBDA_RUNTIME_API` et ajoutent la version de l’API ainsi que le chemin d’accès de ressource souhaité.
**Example Demande**
```
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
```
**Topics**
+ [
## Invocation suivante
](#runtimes-api-next)
+ [
## Réponse d’invocation
](#runtimes-api-response)
+ [
## Erreur d’initialisation
](#runtimes-api-initerror)
+ [
## Erreur d’invocation
](#runtimes-api-invokeerror)
## Invocation suivante
**Chemin** – `/runtime/invocation/next`
**Méthode** – **GET**
L’exécution envoie ce message à Lambda pour demander un événement d’invocation. Le corps de la réponse contient la charge utile provenant de l’invocation, qui est un document JSON contenant les données d’événements du déclencheur de la fonction. Les en-têtes de la réponse contiennent des données supplémentaires sur l’invocation.
**En-têtes de réponse**
+ `Lambda-Runtime-Aws-Request-Id` – ID de demande qui identifie la demande ayant déclenché l’invocation de la fonction.
Par exemple, `8476a536-e9f4-11e8-9739-2dfe598c3fcd`.
+ `Lambda-Runtime-Deadline-Ms` – Date à laquelle la fonction expire, exprimée en millisecondes au format horaire Unix.
Par exemple, `1542409706888`.
+ `Lambda-Runtime-Invoked-Function-Arn` – ARN de la fonction Lambda, de la version ou de l’alias spécifiés dans l’invocation.
Par exemple, `arn:aws:lambda:us-east-2:123456789012:function:custom-runtime`.
+ `Lambda-Runtime-Trace-Id` – [En-tête de suivi AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-tracingheader).
Par exemple, `Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1`.
+ `Lambda-Runtime-Client-Context`— Pour les appels depuis le SDK AWS mobile, les données relatives à l'application client et à l'appareil.
+ `Lambda-Runtime-Cognito-Identity`— Pour les appels depuis le SDK AWS mobile, les données relatives au fournisseur d'identité Amazon Cognito.
Ne définissez pas de délai d’expiration pour la demande `GET`, car la réponse peut être retardée. Entre le moment où Lambda amorce le runtime et celui où le runtime a un événement à renvoyer, le processus d’exécution peut être bloqué pendant plusieurs secondes.
L’ID de demande suit l’invocation au sein de Lambda. Utilisez-le pour spécifier l’invocation lorsque vous envoyez la réponse.
L’en-tête de suivi contient l’ID de suivi, l’ID parent et la décision d’échantillonnage. Si la demande est échantillonnée, elle a été échantillonnée par Lambda ou un service en amont. Le runtime doit définir l’`_X_AMZN_TRACE_ID` avec la valeur de l’en-tête. Le SDK X-Ray le lit pour obtenir IDs et déterminer s'il convient de suivre la demande.
## Réponse d’invocation
**Chemin** – `/runtime/invocation/AwsRequestId/response`
**Méthode** – **POST**
Une fois l’exécution de la fonction terminée, le runtime envoie une réponse à l’invocation à Lambda. Pour les invocations synchrones, Lambda envoie la réponse au client.
**Example demande d’opération réussie**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS"
```
## Erreur d’initialisation
Si la fonction renvoie une erreur ou si le runtime rencontre une erreur lors de l’initialisation, le runtime utilise cette méthode pour signaler l’erreur à Lambda.
**Chemin** – `/runtime/init/error`
**Méthode** – **POST**
**En-têtes**
`Lambda-Runtime-Function-Error-Type` – Type d’erreur que l’environnement d’exécution a rencontré. Requis : non.
Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n’importe quelle chaîne, mais nous recommandons le format . Par exemple :
+ Durée d'exécution. NoSuchHandler
+ Durée d'exécution. APIKeyNotFound
+ Durée d'exécution. ConfigInvalid
+ Durée d'exécution. UnknownReason
**Paramètres de corps**
`ErrorRequest` : informations sur l’erreur. Requis : non.
Ce champ est un objet JSON avec la structure suivante :
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Notez que Lambda accepte n’importe quelle valeur pour `errorType`.
L’exemple suivant montre un message d’erreur de fonction Lambda indiquant que la fonction n’a pas pu analyser les données d’événement fournies dans l’invocation.
**Example Erreur de fonction**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Paramètres du corps de la réponse**
+ `StatusResponse` – String. Informations d’état, envoyées avec les codes de réponse 202.
+ `ErrorResponse`— Informations d'erreur supplémentaires, envoyées avec les codes de réponse d'erreur. ErrorResponse contient un type d'erreur et un message d'erreur.
**Codes de réponse**
+ 202 – Accepté
+ 403 – Interdit
+ 500 – Erreur de conteneur. État non récupérable. L’environnement d’exécution doit se terminer rapidement.
**Example demande d’erreur d’initialisation**
```
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
## Erreur d’invocation
Si la fonction renvoie une erreur ou si le runtime rencontre une erreur, le runtime utilise cette méthode pour signaler l’erreur à Lambda.
**Chemin** – `/runtime/invocation/AwsRequestId/error`
**Méthode** – **POST**
**En-têtes**
`Lambda-Runtime-Function-Error-Type` – Type d’erreur que l’environnement d’exécution a rencontré. Requis : non.
Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n’importe quelle chaîne, mais nous recommandons le format . Par exemple :
+ Durée d'exécution. NoSuchHandler
+ Durée d'exécution. APIKeyNotFound
+ Durée d'exécution. ConfigInvalid
+ Durée d'exécution. UnknownReason
**Paramètres de corps**
`ErrorRequest` : informations sur l’erreur. Requis : non.
Ce champ est un objet JSON avec la structure suivante :
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Notez que Lambda accepte n’importe quelle valeur pour `errorType`.
L’exemple suivant montre un message d’erreur de fonction Lambda indiquant que la fonction n’a pas pu analyser les données d’événement fournies dans l’invocation.
**Example Erreur de fonction**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Paramètres du corps de la réponse**
+ `StatusResponse` – String. Informations d’état, envoyées avec les codes de réponse 202.
+ `ErrorResponse`— Informations d'erreur supplémentaires, envoyées avec les codes de réponse d'erreur. ErrorResponse contient un type d'erreur et un message d'erreur.
**Codes de réponse**
+ 202 – Accepté
+ 400 – Demande erronée.
+ 403 – Interdit
+ 500 – Erreur de conteneur. État non récupérable. L’environnement d’exécution doit se terminer rapidement.
**Example demande d’erreur**
```
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9
ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}"
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
```
# Quand utiliser les environnements d’exécution réservés aux systèmes d’exploitation de Lambda
Lambda fournit des [environnements d’exécution gérés](lambda-runtimes.md) pour Java, Python, Node.js, .NET et Ruby. Pour créer des fonctions Lambda dans un langage de programmation qui n’est pas disponible en tant qu’environnement d’exécution géré, utilisez un environnement d’exécution uniquement basé sur le système d’exploitation (famille des environnements d’exécution `provided`). Il existe trois principaux cas d’utilisation pour les environnements d’exécution uniquement basés sur le système d’exploitation :
+ **Compilation native ahead-of-time (AOT)** : des langages tels que Go, Rust, Swift et C\$1\$1 se compilent nativement en un binaire exécutable, qui ne nécessite pas d'exécution de langage dédié. Ces langages ont uniquement besoin d’un environnement de système d’exploitation dans lequel le binaire compilé peut s’exécuter. Vous pouvez également utiliser des environnements d'exécution uniquement pour le système d'exploitation Lambda pour déployer des fichiers binaires compilés avec .NET Native AOT et Java GraalVM Native Image.
Vous devez inclure un client d’interface d’exécution. Le client de l’interface d’exécution appelle l’[Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés](runtimes-api.md) pour récupérer les invocations de fonction, puis appelle votre gestionnaire de fonctions. Lambda fournit des clients d'interface d'exécution pour [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime) (expérimental) et [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (expérimental).
Vous devez compiler votre binaire pour un environnement Linux et pour la même architecture de jeu d’instructions que celle que vous prévoyez d’utiliser pour la fonction (x86\$164 ou arm64).
+ **Runtimes tiers** : vous pouvez exécuter des fonctions Lambda à off-the-shelf l'aide d'environnements d'exécution [tels que](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2) Bref pour PHP.
+ **Exécutions personnalisées** : vous pouvez créer votre propre environnement d’exécution pour une langue ou une version de langue pour laquelle Lambda ne fournit pas d’environnement d’exécution géré, comme Node.js 19. Pour de plus amples informations, veuillez consulter [Création d'un environnement d'exécution personnalisé pour AWS Lambda](runtimes-custom.md). Il s’agit du cas d’utilisation le moins courant pour les environnements d’exécution uniquement basés sur le système d’exploitation.
Lambda prend en charge les environnements d’exécution uniquement basés sur le système d’exploitation suivants :
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Exécution réservée au système d’exploitation | `provided.al2023` | Amazon Linux 2023 | 30 juin 2029 | 31 juillet 2029 | 31 août 2029 |
| Exécution réservée au système d’exploitation | `provided.al2` | Amazon Linux 2 | 31 juillet 2026 | 31 août 2026 | 30 sept. 2026 |
L’environnement d’exécution Amazon Linux 2023 (`provided.al2023`) offre plusieurs avantages par rapport à Amazon Linux 2, notamment un encombrement de déploiement réduit et des versions mises à jour de bibliothèques telles que `glibc`.
L’environnement d’exécution `provided.al2023` utilise `dnf` comme gestionnaire de packages au lieu de `yum`, qui est le gestionnaire de packages par défaut dans Amazon Linux 2. Pour plus d'informations sur les différences entre `provided.al2023` et`provided.al2`, consultez [Présentation du runtime Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sur le blog AWS Compute.
# Création d'un environnement d'exécution personnalisé pour AWS Lambda
Vous pouvez implémenter un AWS Lambda environnement d'exécution dans n'importe quel langage de programmation. Un environnement d’exécution est un programme qui exécute la méthode de gestionnaire d’une fonction Lambda lors de l’invocation de la fonction. Vous pouvez inclure le runtime dans le package de déploiement de votre fonction ou le distribuer dans une [couche](chapter-layers.md). Lorsque vous créez la fonction Lambda, choisissez un [environnement d’exécution uniquement pour le système d’exploitation](runtimes-provided.md) (la famille d’exécution `provided`).
**Note**
La création d’un environnement d’exécution personnalisé est un cas d’utilisation avancé. Si vous recherchez des informations sur la compilation vers un binaire natif ou sur l'utilisation d'un off-the-shelf environnement d'exécution tiers, consultez[Quand utiliser les environnements d’exécution réservés aux systèmes d’exploitation de Lambda](runtimes-provided.md).
Pour une présentation détaillée du processus de déploiement d’un environnement d’exécution personnalisé, voir [Tutoriel : création d’un environnement d’exécution personnalisé](runtimes-walkthrough.md).
**Topics**
+ [
## Exigences
](#runtimes-custom-build)
+ [
## Implémentation du flux de réponses dans un environnement d’exécution personnalisé
](#runtimes-custom-response-streaming)
+ [
## Création d'environnements d'exécution personnalisés pour les instances gérées Lambda
](#runtimes-custom-managed-instances)
## Exigences
Les environnements d’exécution personnalisés doivent effectuer certaines tâches d’initialisation et de traitement. Une exécution exécute le code d’installation de la fonction, lit le nom du gestionnaire à partir d’une variable d’environnement et lit les événements d’invocation à partir de l’API d’exécution Lambda. L’environnement d’exécution transmet les données d’événements au gestionnaire de la fonction, et renvoie la réponse du gestionnaire à Lambda.
### Tâches d’initialisation
Les tâches d’initialisation sont exécutées une seule fois [par instance de la fonction](lambda-runtime-environment.md) pour préparer l’environnement à la gestion des invocations.
+ **Récupérer les paramètres** – Lecture des variables d’environnement pour obtenir des détails sur la fonction et l’environnement.
+ `_HANDLER` – Emplacement du gestionnaire, issu de la configuration de la fonction. Le format standard est `file.method`, où `file` est le nom du fichier sans extension et `method` est le nom d’une méthode ou fonction qui est définie dans le fichier.
+ `LAMBDA_TASK_ROOT` – Répertoire contenant le code de la fonction.
+ `AWS_LAMBDA_RUNTIME_API` – Hôte et port de l’API d’exécution.
Pour obtenir la liste complète des variables disponibles, consultez [Variables d’environnement d’exécution définies](configuration-envvars.md#configuration-envvars-runtime).
+ **Initialiser la fonction** – Charger le fichier de gestionnaire et exécuter tout code global ou statique qu’il contient. Les fonctions doivent créer des ressources statiques telles que des clients de kit SDK et des connexions de base de données une seule fois, puis les réutiliser pour plusieurs invocations.
+ **Gérer les erreurs** : si une erreur se produit, appelez l’API [erreur de l’initialisation](runtimes-api.md#runtimes-api-initerror) et quittez immédiatement.
L’initialisation est comptabilisée dans le délai d’attente et la durée d’exécution facturés. Lorsqu’une exécution déclenche l’initialisation d’une nouvelle instance de votre fonction, vous pouvez voir le temps d’initialisation dans les journaux et [le suivi AWS X-Ray](services-xray.md).
**Example journal**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### Traitement des tâches
Pendant son exécution, l’environnement d’exécution utilise l’[interface d’environnement d’exécution Lambda](runtimes-api.md) pour gérer les événements entrants et signaler des erreurs. Après avoir terminé les tâches d’initialisation, l’environnement d’exécution traite les événements entrants dans une boucle. Dans votre code d’exécution, effectuez les étapes suivantes dans l’ordre.
+ **Obtenir un événement** – Appeler l’API d’[invocation suivante](runtimes-api.md#runtimes-api-next) pour obtenir l’événement suivant. Le corps de la réponse contient les données de l’événement. Les en-têtes de la réponse contiennent l’ID de la demande et d’autres informations.
+ **Propager l’en-tête de suivi** – Obtenir l’en-tête de suivi X-Ray à partir de l’en-tête `Lambda-Runtime-Trace-Id` dans la réponse de l’API. Définissez la variable d’environnement `_X_AMZN_TRACE_ID` localement avec la même valeur. Le kit SDK X-Ray utilise cette valeur pour connecter les données de suivi entre les services.
+ **Créer un objet de contexte** – Créer un objet avec des informations de contexte à partir des variables d’environnement et des en-têtes de la réponse de l’API.
+ **Invoquer le gestionnaire de fonctions** – Transmettre l’événement et l’objet contexte au gestionnaire.
+ **Gérer la réponse** – Appeler l’API [réponse d’invocation](runtimes-api.md#runtimes-api-response) pour afficher la réponse du gestionnaire.
+ **Gérer les erreurs** : si une erreur se produit, appelez l’API [erreur de l’invocation](runtimes-api.md#runtimes-api-invokeerror).
+ **Nettoyage** : libérer les ressources inutilisées, envoyer des données à d’autres services ou accomplir des tâches supplémentaires avant de passer à l’événement suivant.
### Entrypoint
Le point d’entrée d’un runtime personnalisé est un fichier exécutable nommé `bootstrap`. Le fichier d’amorçage peut être l’environnement d’exécution, ou il peut invoquer un autre fichier qui crée le runtime. Si la racine de votre package de déploiement ne contient pas de fichier nommé `bootstrap`, Lambda recherche le fichier dans les couches de la fonction. Si le fichier `bootstrap` n’existe pas ou n’est pas exécutable, votre fonction renvoie une erreur `Runtime.InvalidEntrypoint` au moment de l’invocation.
Voici un exemple de `bootstrap` fichier qui utilise une version groupée de Node.js pour exécuter un JavaScript environnement d'exécution dans un fichier distinct nommé`runtime.js`.
**Example bootstrap**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## Implémentation du flux de réponses dans un environnement d’exécution personnalisé
Pour les [fonctions de streaming de réponses](configuration-response-streaming.md), les points de terminaison `response` et `error` ont un comportement légèrement modifié qui permet à l’exécution de diffuser des réponses partielles au client et de renvoyer les charges utiles par morceaux. Pour plus d’informations sur le comportement spécifique, consultez ce qui suit :
+ `/runtime/invocation/AwsRequestId/response` : propage l’en-tête `Content-Type` de l’environnement d’exécution pour l’envoyer au client. Lambda renvoie la charge utile de la réponse en morceaux via l’encodage de transfert en bloc HTTP/1.1. Pour envoyer le flux de réponse à Lambda, l’environnement d’exécution doit :
+ Définir l’en-tête HTTP `Lambda-Runtime-Function-Response-Mode` sur `streaming`.
+ Définissez l’en-tête `Transfer-Encoding` sur `chunked`.
+ Écrire la réponse conformément à la spécification d’encodage de transfert en bloc HTTP/1.1.
+ Fermer la connexion sous-jacente après avoir écrit la réponse avec succès.
+ `/runtime/invocation/AwsRequestId/error` : l’exécution peut utiliser ce point de terminaison pour signaler des erreurs de fonction ou d’exécution à Lambda, qui accepte également l’en-tête `Transfer-Encoding`. Ce point de terminaison ne peut être appelé qu’avant que l’environnement d’exécution ne commence à envoyer une réponse à l’invocation.
+ Signaler les erreurs en cours de diffusion à l’aide des en-têtes de suivi d’erreur dans `/runtime/invocation/AwsRequestId/response`. Pour signaler les erreurs qui se produisent après que l’exécution commence à écrire la réponse à l’invocation, l’exécution peut optionnellement attacher des en-têtes de fin HTTP nommés `Lambda-Runtime-Function-Error-Type` et `Lambda-Runtime-Function-Error-Body`. Lambda considère cette réponse comme une réponse réussie et transmet les métadonnées d’erreur que l’exécution fournit au client.
**Note**
Pour joindre des en-têtes de fin, l’environnement d’exécution doit définir la valeur de l’en-tête `Trailer` au début de la demande HTTP. C’est une exigence de la spécification de l’encodage de transfert en bloc HTTP/1.1.
+ `Lambda-Runtime-Function-Error-Type` : le type d’erreur que l’exécution a rencontré. Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n'importe quelle chaîne, mais nous recommandons un format de. ** Par exemple, `Runtime.APIKeyNotFound`.
+ `Lambda-Runtime-Function-Error-Body` : informations encodées en Base64 sur l’erreur.
## Création d'environnements d'exécution personnalisés pour les instances gérées Lambda
Les instances gérées Lambda utilisent la même API d'exécution que les fonctions Lambda (par défaut). Cependant, il existe des différences majeures dans la manière dont les environnements d'exécution personnalisés doivent être mis en œuvre pour prendre en charge le modèle d'exécution simultanée des instances gérées.
### Gestion des demandes simultanées
La principale différence lors de la création d'environnements d'exécution personnalisés pour les instances gérées est la prise en charge des appels simultanés. Contrairement aux fonctions Lambda (par défaut) où le moteur d'exécution traite un appel à la fois, les instances gérées peuvent traiter plusieurs appels simultanément au sein d'un même environnement d'exécution.
Votre environnement d'exécution personnalisé doit :
+ **Support des `/next` demandes simultanées** : le moteur d'exécution peut effectuer plusieurs appels simultanés à l'API [d'appel suivante](runtimes-api.md#runtimes-api-next), jusqu'à la limite spécifiée par la variable d'`AWS_LAMBDA_MAX_CONCURRENCY`environnement.
+ **Gérer les `/response` demandes simultanées** : plusieurs invocations peuvent appeler simultanément l'API de [réponse à](runtimes-api.md#runtimes-api-response) l'appel.
+ **Mettez en œuvre une gestion des demandes adaptée aux threads** : assurez-vous que les appels simultanés n'interfèrent pas les uns avec les autres en gérant correctement les ressources et les états partagés.
+ **Utiliser une demande unique IDs** : suivez chaque appel séparément à l'aide de l'`Lambda-Runtime-Aws-Request-Id`en-tête pour faire correspondre les réponses aux demandes correspondantes.
### Modèle de mise en œuvre
Un modèle d'implémentation typique pour les environnements d'exécution des instances gérées implique la création de threads de travail ou de processus pour gérer les invocations simultanées :
1. **Lire la limite de simultanéité** : lors de l'initialisation, lisez la variable d'`AWS_LAMBDA_MAX_CONCURRENCY`environnement pour déterminer le nombre d'appels simultanés à prendre en charge.
1. **Créer un pool de travailleurs** : initialisez un pool de travailleurs (threads, processus ou tâches asynchrones) égal à la limite de simultanéité.
1. **Boucle de traitement des travailleurs** — Chaque travailleur indépendamment :
+ Appels `/runtime/invocation/next` pour obtenir un événement d'invocation
+ Invoque le gestionnaire de fonctions avec les données de l'événement
+ Publie la réponse sur `/runtime/invocation/AwsRequestId/response`
+ Répète la boucle
### Considérations supplémentaires
+ **Format de journalisation** : les instances gérées ne prennent en charge que le format de journal JSON. Assurez-vous que votre environnement d'exécution respecte la variable d'`AWS_LAMBDA_LOG_FORMAT`environnement et utilise uniquement le format JSON. Pour de plus amples informations, veuillez consulter [Configuration des formats de journal JSON et en texte brut](monitoring-cloudwatchlogs-logformat.md).
+ **Ressources partagées** : soyez prudent lorsque vous utilisez des ressources partagées telles que le `/tmp` répertoire avec des invocations simultanées. Mettez en place des mécanismes de verrouillage appropriés pour éviter les conditions de course.
Pour plus d'informations sur les environnements d'exécution des instances gérées Lambda, consultez. [Comprendre l'environnement d'exécution des instances gérées Lambda](lambda-managed-instances-execution-environment.md)
# Tutoriel : création d’un environnement d’exécution personnalisé
Dans ce didacticiel, vous allez créer une fonction Lambda avec un runtime personnalisé. Vous commencez par inclure le runtime dans le package de déploiement de la fonction. Ensuite, vous le migrez vers une couche que vous gérez indépendamment de la fonction. Enfin, vous partagez la couche du runtime en mettant à jour sa stratégie d’autorisations basée sur les ressources.
## Prérequis
Ce didacticiel suppose que vous avez quelques connaissances des opérations Lambda de base et de la console Lambda. Si ce n’est déjà fait, suivez les instructions fournies dans [Créer une fonction Lambda à l'aide de la console](getting-started.md#getting-started-create-function) pour créer votre première fonction Lambda.
Pour effectuer les étapes suivantes, vous avez besoin de l’[AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Les commandes et la sortie attendue sont répertoriées dans des blocs distincts :
```
aws --version
```
Vous devriez voir la sortie suivante:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Pour les commandes longues, un caractère d’échappement (`\`) est utilisé pour les fractionner en plusieurs lignes.
Sur Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash. Les exemples de commandes CLI de ce guide utilisent le formatage Linux. Les commandes qui incluent des documents JSON en ligne doivent être reformatées si vous utilisez la CLI Windows.
Vous avez besoin d’un rôle IAM pour créer une fonction Lambda. Le rôle a besoin d’une autorisation pour envoyer des journaux à CloudWatch Logs et accéder aux Services AWS que votre fonction utilise. Si vous ne possédez pas de rôle pour le développement de fonction, créez-en un.
**Pour créer un rôle d’exécution**
1. Ouvrez la page [Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) dans la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Créez un rôle avec les propriétés suivantes :
+ **Entité de confiance** – **Lambda**.
+ **Autorisations** – **AWSLambdaBasicExecutionRole**.
+ **Nom de rôle** – **lambda-role**.
La stratégie **AWSLambdaBasicExecutionRole** possède les autorisations dont la fonction a besoin pour écrire des journaux dans CloudWatch Logs.
## Créer une fonction
Créez une fonction Lambda avec un runtime personnalisé. Cet exemple comprend deux fichiers : un fichier `bootstrap` d’exécution et un gestionnaire de fonctions. Tous deux sont mis en œuvre en Bash.
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. Créez un nouveau fichier appelé `bootstrap`. Il s’agit de l’environnement d’exécution personnalisé.
**Example amorçage**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
Le runtime charge un script de fonction à partir du package de déploiement. Il utilise deux variables pour localiser le script. `LAMBDA_TASK_ROOT` lui indique où le package a été extrait et `_HANDLER` inclut le nom du script.
Une fois que l’environnement d’exécution charge le script de la fonction, il utilise l’API d’exécution pour récupérer un événement d’invocation à partir de Lambda, transmet l’événement au gestionnaire, puis renvoie la réponse à Lambda. Pour obtenir l’ID de la demande, le runtime enregistre les en-têtes à partir de la réponse de l’API dans un fichier temporaire et lit l’en-tête `Lambda-Runtime-Aws-Request-Id` à partir du fichier.
**Note**
Les runtimes ont d’autres responsabilités, notamment la gestion des erreurs et la fourniture d’informations de contexte au gestionnaire. Pour plus d'informations, consultez [Exigences](runtimes-custom.md#runtimes-custom-build).
1. Créez un script pour la fonction. L’exemple de script suivant définit une fonction de gestionnaire qui accepte les données des événements, la consigne dans `stderr`, puis la renvoie.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
Le répertoire `runtime-tutorial` devrait maintenant ressembler à ceci :
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. Rendez les fichiers exécutables et ajoutez-les dans une archive ZIP. Vous obtiendrez alors le package de déploiement.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. Créez une fonction nommée `bash-runtime`. Pour `--role`, entrez l’ARN de votre [rôle d’exécution](lambda-intro-execution-role.md) Lambda.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. Invoquer la fonction.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L’option **cli-binary-format** est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez obtenir une réponse comme celle-ci :
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Vérifiez la réponse.
```
cat response.txt
```
Vous devriez obtenir une réponse comme celle-ci :
```
Echoing request: '{"text":"Hello"}'
```
## Créer une couche
Pour séparer le code du runtime du code de la fonction, créez une couche qui contient uniquement le runtime. Les couches vous permettent de développer les dépendances de votre fonction de manière indépendante et peuvent réduire l’utilisation du stockage lorsque vous utilisez la même couche avec plusieurs fonctions. Pour de plus amples informations, consultez [Gestion des dépendances Lambda à l’aide de couches](chapter-layers.md).
1. Créez un fichier .zip contient le fichier `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Créez une couche avec la commande [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x).
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
Cela crée la première version de la couche.
## Mettre à jour la fonction
Pour utiliser la couche d’exécution dans la fonction, configurez la fonction pour utiliser la couche et supprimez le code de l’environnement d’exécution de la fonction.
1. Mettez à jour la configuration de la fonction pour extraire la couche.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
Cela ajoute le runtime à la fonction dans le répertoire `/opt`. Pour garantir que Lambda utilise l’environnement d’exécution dans la couche, vous devez supprimer `boostrap` du package de déploiement de la fonction, comme indiqué dans les deux étapes suivantes.
1. Créez un fichier .zip reprenant le code de la fonction.
```
zip function-only.zip function.sh
```
1. Mettez à jour le code de la fonction de façon à inclure uniquement le script du gestionnaire.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. Invoquez la fonction pour confirmer qu’elle fonctionne avec la couche de l’environnement d’exécution.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
L’option **cli-binary-format** est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez obtenir une réponse comme celle-ci :
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. Vérifiez la réponse.
```
cat response.txt
```
Vous devriez obtenir une réponse comme celle-ci :
```
Echoing request: '{"text":"Hello"}'
```
## Mettre à jour le runtime
1. Pour enregistrer des informations sur l’environnement d’exécution, mettez à jour le script du runtime pour générer les variables d’environnement.
**Example amorçage**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. Créez un fichier .zip reprenant la nouvelle version du fichier `bootstrap`.
```
zip runtime.zip bootstrap
```
1. Créer une nouvelle version de la couche `bash-runtime`.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. Configurez la fonction pour utiliser la nouvelle version de la couche.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## Partager la couche
Pour partager une couche avec un autre Compte AWS, ajoutez une instruction d’autorisations entre comptes à la [politique basée sur les ressources](access-control-resource-based.md) de la couche. Exécutez la commande [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) et spécifiez l’ID du compte en tant que `principal`. Dans chaque instruction, vous pouvez accorder une autorisation à un compte unique, à tous les comptes ou à une organisation dans [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
L’exemple suivant autorise le compte 111122223333 à accéder à la version 2 de la couche `bash-runtime`.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
Vous devez voir des résultats similaires à ce qui suit :
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
Les autorisations ne s’appliquent qu’à une seule version de couche. Répétez le processus chaque fois que vous créez une nouvelle version de la couche.
## Nettoyage
Supprimez chaque version de la couche.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
Étant donné que la fonction contient une référence à la version 2 de la couche, elle existe toujours dans Lambda. La fonction continue de fonctionner, mais les fonctions ne peuvent plus être configurées pour utiliser la version supprimée. Si vous modifiez la liste des couches sur la fonction, vous devez spécifier une nouvelle version ou omettre la couche supprimée.
Supprimez la fonction à l’aide de la commande [delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html).
```
aws lambda delete-function --function-name bash-runtime
```
# Référentiels open source
AWS Lambda fournit une variété d'outils, de bibliothèques et de composants open source pour vous aider à créer, personnaliser et optimiser vos applications sans serveur. Ces ressources incluent des clients d'interface d'exécution, des bibliothèques d'événements, des images de base de conteneurs, des outils de développement et des exemples de projets gérés AWS et disponibles sur GitHub. En tirant parti de ces référentiels open source, vous pouvez étendre les fonctionnalités de Lambda, créer des environnements d'exécution personnalisés, traiter des événements provenant de différents AWS services et mieux comprendre les performances de votre fonction. Cette page fournit une présentation des principaux projets open source qui soutiennent le développement de Lambda.
## Clients d’interface d’exécution
Les clients d'interface d'exécution Lambda (RICs) sont des bibliothèques open source qui implémentent l'[API Runtime](runtimes-api.md) et gèrent l'interaction entre le code de votre fonction et le service Lambda. Ces clients gèrent la réception des événements d’invocation, la transmission des informations de contexte et le signalement des erreurs.
Les clients d’interface d’exécution utilisés par les environnements d’exécution gérés et les images de base de conteneurs de Lambda sont open source. Lorsque vous créez des environnements d’exécution personnalisés ou que vous étendez des environnements existants, vous pouvez utiliser ces bibliothèques open source pour simplifier la mise en œuvre. Les GitHub référentiels open source suivants contiennent le code source de Lambda : RICs
+ [Client d’interface d’environnement d’exécution Node.js](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client)
+ [Clients d’interface d’exécution Python](https://github.com/aws/aws-lambda-python-runtime-interface-client)
+ [Client d’interface d’environnement d’exécution Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-runtime-interface-client)
+ [Client d’interface d’environnement d’exécution Ruby](https://github.com/aws/aws-lambda-ruby-runtime-interface-client)
+ [Client d’interface d’exécution .NET](https://github.com/aws/aws-lambda-dotnet)
+ [Client d'interface d'exécution Rust](https://github.com/aws/aws-lambda-rust-runtime)
+ [Client d’interface d’environnement d’exécution Go](https://github.com/aws/aws-lambda-go)
+ [Client d'interface Swift Runtime](https://github.com/awslabs/swift-aws-lambda-runtime) (expérimental)
+ [Client d'interface d'exécution C\$1\$1](https://github.com/awslabs/aws-lambda-cpp) (expérimental)
+ [Images de base Lambda](https://github.com/aws/aws-lambda-base-images)
Pour plus d’informations sur l’utilisation de ces clients pour créer une exécution personnalisée, consultez [Création d'un environnement d'exécution personnalisé pour AWS Lambda](runtimes-custom.md).
## Bibliothèques d’événements
Les bibliothèques d'événements Lambda fournissent des définitions de type et des utilitaires d'assistance pour le traitement des événements provenant de différents services. AWS Ces bibliothèques vous aident à analyser et gérer les données d’événements de manière sécurisée, ce qui facilite l’utilisation d’événements provenant de services comme Amazon S3, Amazon DynamoDB et Amazon API Gateway.
Pour les langages compilés, AWS fournit les bibliothèques d'événements suivantes :
+ [Bibliothèque d’événements Java](https://github.com/aws/aws-lambda-java-libs/tree/main/aws-lambda-java-events)
+ [Bibliothèques d’événements .NET](https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src)
+ [Bibliothèque d’événements Go](https://github.com/aws/aws-lambda-go/tree/main/events)
+ [Bibliothèque d’événements Rust](https://github.com/awslabs/aws-lambda-rust-runtime)
Pour les langages interprétés comme Node.js, Python et Ruby, les événements peuvent être analysés directement sous forme d’objets JSON sans nécessiter de bibliothèque distincte. Toutefois, les développeurs utilisant Node.js et Python peuvent tirer parti de powertools for AWS Lambda, qui fournit des schémas intégrés pour les AWS événements proposant des indications de type, une validation des données et des fonctionnalités similaires à celles fournies par les bibliothèques de langage compilées.
+ [Outils électriques pour TypeScript](https://docs.powertools.aws.dev/lambda/typescript/latest/features/parser/#built-in-schemas)
+ [Powertools pour Python](https://docs.powertools.aws.dev/lambda/python/latest/utilities/parser/#built-in-models)
## Images de base de conteneur
AWS fournit des images de base de conteneurs open source que vous pouvez utiliser comme point de départ pour créer des images de conteneur pour vos fonctions Lambda. Ces images de base incluent le client d’interface d’environnement d’exécution et les autres composants nécessaires pour exécuter vos fonctions dans l’environnement d’exécution Lambda.
Pour plus d’informations sur les images de base disponibles et sur leur utilisation, consultez le référentiel [Images de base AWS Lambda](https://github.com/aws/aws-lambda-base-images) et [Création d’une fonction Lambda à l’aide d’une image de conteneur](images-create.md).
## Outils de développement
AWS fournit des outils de développement open source supplémentaires pour vous aider à créer et à optimiser vos fonctions Lambda :
### Outils électriques pour AWS Lambda
Powertools for AWS Lambda simplifie le développement sans serveur grâce à des utilitaires essentiels pour empêcher le traitement en double, et au traitement par lots pour la gestion de plusieurs enregistrements et à la bibliothèque Kafka destinée aux consommateurs. Ces fonctionnalités vous aident à minimiser la complexité du code et les frais d’exploitation.
Vous pouvez également tirer parti de la validation intégrée du schéma d'événements, de la journalisation et du suivi structurés, ainsi que de l'intégration du magasin de paramètres, qui sont conçus pour accélérer la création de fonctions Lambda prêtes pour la production tout en suivant les AWS meilleures pratiques bien conçues.
GitHub référentiels :
+ [Python](https://github.com/aws-powertools/powertools-lambda-python)
+ [TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript)
+ [Java](https://github.com/aws-powertools/powertools-lambda-java)
+ [.NET](https://github.com/aws-powertools/powertools-lambda-dotnet)
### Outils de développement Java
+ [Java Profiler (expérimental)](https://github.com/aws/aws-lambda-java-libs/tree/main/experimental/aws-lambda-java-profiler) : un outil pour profiler les fonctions Java Lambda.
+ [Bibliothèques Java](https://github.com/aws/aws-lambda-java-libs) : référentiel contenant une collection complète de bibliothèques et d'outils Java pour le développement Lambda, y compris des projets clés tels que des utilitaires de JUnit test et des outils de profilage.
+ [Conteneur Java sans serveur](https://github.com/aws/serverless-java-container) : bibliothèque qui vous permet d’exécuter des applications Java existantes sur Lambda avec un minimum de modifications.
### Outils de développement .NET
Le référentiel [AWS Lambda .NET](https://github.com/aws/aws-lambda-dotnet) fournit des bibliothèques et des outils .NET pour le développement Lambda, y compris des projets clés tels que les AWS Lambda outils pour la CLI .NET et le serveur .NET Core pour l'hébergement d'applications .NET Core.
## Exemples de projets
Découvrez une collection complète d’exemples de projets et d’applications Lambda dans les [référentiels Serverless Land](https://serverlessland.com/repos). Ces exemples présentent différents cas d’utilisation, modèles d’intégration et bonnes pratiques Lambda pour vous aider à démarrer avec vos applications sans serveur.