Couches Lambda et paquets de déploiement

Les paquets de déploiement Lambda doivent être autonomes : toutes les dépendances (bibliothèques, SDK, fichiers binaires) doivent être incluses dans le fichier ZIP. La taille du paquet augmente rapidement : une fonction Python de science des données utilisant NumPy, Pandas et SciPy peut dépasser 200 MB une fois décompressée. Chaque mise à jour du code de votre fonction nécessite de téléverser à nouveau l’ensemble du paquet, y compris les bibliothèques inchangées. Les couches Lambda résolvent ce problème en séparant les dépendances partagées du code de votre fonction.

Une couche Lambda est une archive ZIP qui contient des bibliothèques, des environnements d’exécution personnalisés, des données ou des fichiers de configuration. Les couches sont stockées séparément du code de votre fonction et montées dans l’environnement d’exécution de la fonction sous /opt. Plusieurs fonctions peuvent partager la même couche : il vous suffit de mettre à jour la couche une seule fois pour que toutes les fonctions qui l’utilisent en bénéficient. Chaque fonction Lambda peut avoir jusqu’à 5 couches, et la taille totale après décompression doit rester inférieure à 250 MB.

Pour créer une couche, regroupez vos dépendances dans la structure de répertoires appropriée pour votre environnement d’exécution (par exemple, python/lib/python3.12/site-packages/ pour Python), compressez-les au format ZIP, puis publiez-la. Une fois publiée, la couche reçoit un ARN de version. Référencez cet ARN lorsque vous associez la couche à une fonction. Une nouvelle version est créée chaque fois que vous mettez la couche à jour ; les fonctions continuent d’utiliser la version avec laquelle elles ont été configurées jusqu’à ce que vous les mettiez explicitement à jour.

Ajoutez des couches à une fonction à l’aide du paramètre --layers lors de la création ou de la mise à jour d’une fonction. Lambda monte toutes les couches associées dans /opt avant le démarrage de la fonction. Les paquets Python situés sous /opt/python sont automatiquement ajoutés au chemin Python ; les modules Node.js situés sous /opt/nodejs/node_modules sont automatiquement trouvés. Votre code de fonction peut import ou require les paquets des couches comme s’ils étaient installés localement.

AWS publie des couches officielles que vous pouvez utiliser sans créer les vôtres. Parmi les exemples figurent la couche AWS Lambda Powertools (journalisation structurée, traçage, indicateurs de fonctionnalité), les couches de pilotes de bases de données et la couche prolongement Lambda AWS Parameters and Secrets, qui met en cache localement les valeurs de SSM/Secrets Manager. Des fournisseurs tiers comme Datadog et New Relic publient également des couches publiques pour leurs agents de surveillance. Consultez le référentiel d’applications sans serveur et la console Lambda pour connaître les couches publiques disponibles.

Les prolongements Lambda s’exécutent comme des processus distincts aux côtés de votre code de fonction, dans le même environnement d’exécution. Ils s’intègrent aux événements du cycle de vie de Lambda (initialisation, invocation, arrêt) pour effectuer des tâches telles que la collecte de données de télémétrie, l’analyse de sécurité ou la mise en cache de la configuration. Les prolongements sont distribués sous forme de couches Lambda. AWS fournit le prolongement CloudWatch Lambda Insights et le prolongement AWS AppConfig ; les fournisseurs proposent des agents de surveillance personnalisés sous forme de prolongements.

Lambda prend en charge deux formats de déploiement :

• ZIP (jusqu’à 50 MB compressés, 250 MB après décompression) : téléversement rapide, prise en charge des couches, compatible avec tous les environnements d’exécution.
• image de conteneur (jusqu’à 10 GB) : stockée dans Amazon ECR, utilise les outils Docker standard, ne prend pas en charge les couches et convient particulièrement aux dépendances très volumineuses (modèles d’apprentissage automatique, binaires volumineux).

Les images de conteneur doivent implémenter la interface d’exécution Lambda (en utilisant les images de base fournies par AWS) afin que Lambda sache comment invoquer votre gestionnaire.

La création et le déploiement d’une image de conteneur Lambda suivent un flux de travail standard : créez l’image avec docker build, envoyez-la vers Amazon ECR, puis référencez l’URI de l’image lors de la création ou de la mise à jour de la fonction Lambda. Les images de conteneur sont immutables : chaque étiquette d’image correspond à une version précise de la fonction. Lambda met les images de conteneur en cache dans son infrastructure ; les démarrages à froid suivants sont donc plus rapides que le premier.

Les versions Lambda sont des instantanés immuables du code et de la configuration de votre fonction. Chaque fois que vous publiez une version, Lambda fige le paquet de déploiement, les variables d’environnement et les couches. Les alias sont des pointeurs nommés vers des versions précises : prod peut pointer vers la version 5 et staging vers la version 6. Vous pouvez également utiliser des alias pondérés pour acheminer un pourcentage du trafic vers une nouvelle version lors de déploiements progressifs (par exemple, 10 % vers v6 et 90 % vers v5).

Les couches sont elles aussi soumises à une gestion des versions. Lorsque vous publiez une nouvelle version d’une couche, les fonctions existantes continuent d’utiliser leur version spécifiée jusqu’à ce que vous les mettiez à jour. Vous pouvez ainsi mettre à jour une couche partagée en toute sécurité sans interrompre toutes les fonctions simultanément : déployez progressivement la nouvelle version. À terme, retirez les anciennes versions des couches afin de réduire les besoins de stockage et de maintenance. Lambda conserve les versions des couches même si vous les supprimez de la console, jusqu’à ce qu’aucune fonction ne les référence.

Utilisez les couches lorsque la taille totale après décompression est inférieure à 250 MB, que vous souhaitez partager des dépendances entre plusieurs fonctions et que vous voulez itérer rapidement (mettez la couche à jour une seule fois pour que toutes les fonctions en bénéficient). Utilisez les images de conteneur lorsque les dépendances dépassent 250 MB, que vous devez utiliser des paquets personnalisés du système d’exploitation, que vous disposez déjà de flux de travail Docker ou que vous souhaitez regrouper des ressources volumineuses (modèles d’apprentissage automatique, bases de données de référence). Les images de conteneur ne sont pas compatibles avec les couches Lambda, mais offrent davantage de flexibilité.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les couches Lambda regroupent les dépendances partagées séparément du code des fonctions, ce qui réduit la taille des paquets et permet leur réutilisation entre plusieurs fonctions ; que les images de conteneur (jusqu’à 10 GB via ECR) sont le bon choix lorsque les dépendances dépassent la limite de 250 MB des fichiers ZIP ou lorsque des flux de travail Docker sont déjà utilisés ; et que la gestion des versions et les alias permettent des mises en production immuables ainsi que des déploiements progressifs avec répartition pondérée du trafic. Nous allons maintenant étudier Lambda@Edge et les modèles pilotés par les événements.