Une fonction Lambda nécessite une bibliothèque tierce composée de nombreux fichiers totalisant 100 Mo. La bibliothèque doit être disponible dans l'environnement d'exécution Lambda, et le développeur souhaite minimiser la taille du package de déploiement et la surcharge opérationnelle. Quelle approche répond à ces exigences avec le moins de travail opérationnel ?

La création d'une couche Lambda est la solution la plus efficace pour gérer les dépendances de bibliothèques volumineuses. Elle permet de séparer le code de la fonction des dépendances, réduisant ainsi la taille du package de déploiement de la fonction et facilitant la réutilisation de la bibliothèque par plusieurs fonctions. Cela minimise la surcharge opérationnelle car la couche est gérée indépendamment. Télécharger la bibliothèque dans un compartiment S3 et monter ce dossier S3 dans l'environnement d'exécution Lambda n'est pas une fonctionnalité native de Lambda pour les dépendances de code. S3 est généralement utilisé pour le stockage d'objets, pas pour le montage direct de bibliothèques exécutables. Placer la bibliothèque dans le répertoire /tmp de la fonction pendant le déploiement n'est pas idéal car /tmp est un stockage éphémère et limité (512 Mo maximum), non persistant entre les invocations et non destiné aux dépendances de code volumineuses. Créer un système de fichiers Amazon EFS et le monter dans la fonction Lambda est une option viable pour les données persistantes et volumineuses, mais elle introduit une complexité opérationnelle et des coûts supplémentaires par rapport aux couches Lambda pour la simple gestion de bibliothèques.