FAQ sur AWS Lambda

Veuillez consulter notre documentation pour obtenir la liste complète des sources d’événements.

AWS Lambda prend en charge le code issu de Java, Go, PowerShell, Node.js, C#, Python et Ruby et fournit une API d’environnement d’exécution qui vous permet d’utiliser n’importe quels langages de programmation supplémentaires pour éditer vos fonctions. Reportez-vous à notre documentation sur l’utilisation de Node.js, Python, Java, Ruby, C#, Go et PowerShell.

Chaque fonction d’AWS Lambda s’exécute dans son propre environnement isolé, avec un affichage de ses propres ressources et de son propre système de fichiers. AWS Lambda utilise les mêmes techniques qu’Amazon EC2 pour fournir sécurité et séparation au niveau de l’infrastructure et de l’exécution. Pour en savoir plus, consultez la documentation.

AWS Lambda stocke le code dans Amazon S3 et le chiffre au repos. AWS Lambda effectue des vérifications d’intégrité supplémentaires pendant l’utilisation de votre code. Pour les informations sensibles telles que les mots de passe de base de données, nous vous conseillons d’utiliser le chiffrement côté client à l’aide d’AWS Key Management Service, puis de stocker les valeurs obtenues en tant que texte chiffré dans votre variable d’environnement. Pour déchiffrer ces valeurs, vous devrez inclure une opération logique dans le code de votre fonction AWS Lambda. Pour en savoir plus, consultez la documentation.

Oui. Vous pouvez facilement créer et modifier des variables d'environnement via la console AWS Lambda, la CLI ou les kits SDK. Pour en savoir plus sur les variables d’environnement, consultez la documentation.

Pour les informations sensibles telles que les mots de passe de base de données, nous vous conseillons d’utiliser le chiffrement côté client à l’aide d’AWS Key Management Service, puis de stocker les valeurs obtenues en tant que texte chiffré dans votre variable d’environnement. Pour déchiffrer ces valeurs, vous devrez inclure une opération logique dans le code de votre fonction AWS Lambda.

Oui, vous pouvez conditionner n’importe quel code (cadres, kits SDK, bibliothèques, etc.) en tant que couche Lambda, et gérer et partager facilement celui-ci dans des fonctions multiples.

AWS Lambda surveille automatiquement les fonctions Lambda à votre place. En effet, il signale des mesures en temps réel via Amazon CloudWatch, y compris le total des requêtes, l’utilisation simultanée au niveau compte et au niveau fonction, la latence, les taux d’erreurs et les requêtes limitées. Vous pouvez afficher les statistiques de chacune de vos fonctions Lambda via la console Amazon CloudWatch ou la console AWS Lambda. Vous pouvez également appeler des API de surveillance tierces dans votre fonction Lambda.
 

Pour en savoir plus, consultez Résolution de problèmes relatifs aux métriques CloudWatch. Les frais standard d’AWS Lambda s’appliquent à l’utilisation des mesures intégrées à Lambda.

Dans le modèle de ressources AWS Lambda, vous choisissez la quantité de mémoire que vous souhaitez pour votre fonction, puis la puissance CPU et les autres ressources sont attribuées en conséquence. Par exemple, le fait de choisir 256 Mo de mémoire attribue approximativement deux fois plus de puissance CPU à votre fonction Lambda que si vous aviez opté pour 128 Mo, et moitié moins de puissance CPU que si vous aviez sélectionné 512 Mo de mémoire. Pour en savoir plus, consultez notre documentation sur la configuration de la fonction.

Vous pouvez régler votre mémoire de 128 Mo à 10240 Mo.

La facturation d’AWS Lambda s’effectue en fonction de l’utilisation du service. Pour en savoir plus, consultez la page de tarification d’AWS Lambda.

Oui. Par défaut, chaque fonction AWS Lambda dispose d'une version actuelle du code unique. Les clients de votre fonction Lambda peuvent appeler une version spécifique ou obtenir la dernière implémentation. Reportez-vous à notre documentation sur les fonctions Lambda de gestion des versions.

AWS Lambda propose des options de déploiement flexibles : vous pouvez regrouper et déployer vos fonctions sous forme d’archives .zip que vous pouvez télécharger directement via la console, l’interface de ligne de commande (CLI) ou les kits SDK, ou encore sous forme d’images de conteneur. Ces deux méthodes offrent le même environnement d’exécution, la même évolutivité et la même simplicité opérationnelle, ce qui vous permet de choisir l’approche la mieux adaptée à votre flux de travail.

Vous pouvez appeler une fonction Lambda en utilisant un événement personnalisé via l’API invoke d’AWS Lambda. Seuls le propriétaire de la fonction ou un autre compte AWS auquel le propriétaire a donné son autorisation peuvent appeler la fonction. Pour en savoir plus, consultez le Guide des développeurs Lambda.

AWS Lambda SnapStart peut améliorer les performances de start-up de quelques secondes à moins d’une seconde pour les applications sensibles à la latence. SnapStart fonctionne en capturant l’état initialisé de la mémoire (et du disque) de votre fonction et en mettant en cache cet instantané pour un accès à faible latence. Lorsque votre fonction est ensuite invoquée, Lambda reprend les environnements d’exécution à partir de cet instantané pré-initialisé au lieu de les initialiser à partir de zéro, ce qui améliore la latence de start-up. Pour des raisons de résilience, Lambda conserve des copies en cache de votre instantané et leur applique automatiquement les mises à jour logicielles, telles que les mises à niveau de l’environnement d’exécution et les correctifs de sécurité. Pour en savoir plus, consultez la documentation.

Lambda SnapStart est une configuration simple au niveau de la fonction qui peut être configurée pour les fonctions nouvelles et existantes en utilisant l’API Lambda, la Console de gestion AWS, l’AWS Command Line Interface (CLI), l’AWS SDK, l’AWS Cloud Development Kit (CDK), l’AWS CloudFormation et le Modèle d’application sans serveur AWS (SAM). Lorsque vous configurez Lambda SnapStart, chaque version de fonction publiée par la suite bénéficie de l’amélioration des performances de démarrage offerte par Lambda SnapStart. Pour en savoir plus sur Lambda SnapStart, consultez la documentation.

Lambda SnapStart est une optimisation des performances qui aide vos fonctions à atteindre des temps de démarrage plus rapides, en réduisant la latence variable encourue pendant l’exécution du code d’initialisation unique. Bien que Lambda SnapStart réduise la latence de démarrage, il fonctionne comme une optimisation au mieux et ne garantit pas l’élimination des démarrages à froid. Si votre application a des exigences strictes en matière de latence et nécessite des temps de démarrage à deux chiffres en millisecondes, nous vous recommandons d'utiliser PC.

Lambda SnapStart prend en charge plusieurs environnements d’exécution, notamment Java 11 (et versions ultérieures), Python 3.12 (et versions ultérieures) et .NET 8 (et versions ultérieures). Les futures versions d’environnements d’exécution seront prises en charge dès leur sortie. Pour toutes les exécutions prises en charge par Lambda, consultez la documentation sur les exécutions de Lambda.

Oui. Vous pouvez configurer une fonction Lambda SnapStart pour accéder aux ressources d'un cloud privé virtuel (VPC). Pour plus d'informations sur la manière de configurer votre fonction avec un VPC, consultez la documentation Lambda.

Oui, la mise en cache d’un instantané vous sera facturée à la période pendant laquelle la version de votre fonction est active, pendant au moins 3 heures et par milliseconde par la suite. Le prix est fonction de la quantité de mémoire que vous allouez à votre fonction. Vous êtes également facturé chaque fois que Lambda reprend un environnement d’exécution en restaurant votre instantané, le prix dépendant de la quantité de mémoire que vous allouez à votre fonction. Pour en savoir plus sur la tarification de SnapStart, consultez la page de la tarification d’AWS Lambda.

La tarification de SnapStart ne s’applique pas aux environnements d’exécution gérés par Java pris en charge, qui ne peuvent mettre en cache un instantané que pendant 14 jours maximum.

Avec la simultanéité allouée, vous contrôlez mieux les performances de vos applications sans serveur. Lorsqu’elle est activée, la simultanéité allouée conserve les fonctions initialisées et hyperprêtes à réagir en millisecondes à deux chiffres.

Vous pouvez configurer la simultanéité de vos fonctions via AWS Management Console, l’API Lambda, AWS CLI et AWS CloudFormation. La façon la plus simple de bénéficier de la simultanéité allouée est d'utiliser AWS Auto Scaling. Vous pouvez utiliser l'auto scaling de l'application pour configurer les calendriers ou faire appel à auto scaling pour ajuster automatiquement le niveau de simultanéité allouée en temps réel lorsque la demande change. Pour en savoir plus sur la simultanéité allouée, consultez la documentation.

La simultanéité allouée ajoute un élément de prix appelé « simultanéité allouée » pour maintenir les fonctions initialisées. Lorsque cette option est activée, vous payez pour le montant de la simultanéité que vous configurez et pour la période de temps pendant laquelle vous la configurez. Lorsque votre fonction s'exécute alors que la simultanéité provisionnée allouée y est configurée, vous payez également pour les requêtes et la durée de l'exécution. Pour en savoir plus sur la tarification de la simultanéité allouée, consultez la tarification d’AWS Lambda.

Lambda@Edge vous permet d’exécuter du code dans des emplacements AWS du monde entier, sans mettre en service ni gérer de serveurs, répondant aux utilisateurs finaux à la latence réseau la plus faible. Il vous suffit de charger votre code Node.js ou Python dans AWS Lambda et de configurer votre fonction pour qu'elle se déclenche en réponse aux demandes Amazon CloudFront (par exemple, quand une demande utilisateur arrive, quand une demande est transmise à l'origine ou renvoyée par celle-ci, ou juste avant de répondre à l'utilisateur final). Le code est ensuite prêt à s'exécuter aux emplacements AWS du monde entier lors de la réception d'une demande de contenu. Il se met à l'échelle en fonction du volume des demandes Amazon CloudFront à l'échelle mondiale. Pour en savoir plus, reportez-vous à notre documentation.

Pour utiliser Lambda@Edge, il vous suffit de charger votre code dans AWS Lambda et d’associer une version de la fonction pour qu’elle se déclenche en réponse aux requêtes Amazon CloudFront. Le code doit respecter les limites de service de Lambda@Edge. Pour le moment, Lambda@Edge prend en charge les fonctions Node.js et Python pour l'invocation à l'échelle mondiale par les événements Amazon CloudFront. Pour en savoir plus, reportez-vous à notre documentation.

Lambda@Edge est optimisé pour les cas d’utilisation sensibles à la latence si vos utilisateurs finaux sont répartis dans le monde entier. Toutes les informations dont vous avez besoin pour prendre une décision se trouvent à l'emplacement périphérique d'Amazon CloudFront, dans la fonction et la demande. Cela signifie que lorsque vous cherchez à décider du mode de diffusion d’un contenu en fonction des caractéristiques de l’utilisateur (lieu, appareil client utilisé, etc.), vous pouvez le faire directement auprès de vos utilisateurs sans avoir à repasser par un serveur centralisé.

Vous pouvez associer des fonctions Lambda existantes aux événements Amazon CloudFront pour une invocation à l’échelle mondiale si la fonction respecte les exigences et les limites de service de Lambda@Edge. Cliquez ici pour savoir comment mettre à jour les propriétés de vos fonctions.

Non. AWS Lambda est conçu pour exécuter plusieurs instances de vos fonctions en parallèle. Toutefois, AWS Lambda a une limitation de sécurité par défaut pour le nombre d’exécutions simultanées par compte et par région (cliquez ici pour obtenir des informations sur les limites de sécurité par défaut). Vous pouvez également contrôler les exécutions simultanées maximales pour les fonctions AWS Lambda individuelles, ce qui vous permet de réserver un partie de la limite de simultanéité de votre compte pour les fonctions critiques, ou de plafonner les taux de trafic vers les ressources en aval.

Si vous souhaitez soumettre une demande d’augmentation de la limite d’exécution simultanée, vous pouvez utiliser Service Quotas pour demander une augmentation de limite.

Si vous dépassez limite maximale d’exécutions simultanées, un message d’erreur de limitation (code d’erreur 429) apparaîtra chaque fois qu’une fonction AWS Lambda sera invoquée simultanément. Les fonctions Lambda invoquées de manière asynchrone peuvent supporter, dans la mesure du raisonnable, des pics de trafic d'environ 15 à 30 minutes. Au-delà de cette période, les événements entrants seront automatiquement limités. Lorsque la fonction Lambda est appelée en réponse à des événements Amazon S3, des événements rejetés par AWS Lambda peuvent être conservés et relancés par S3 durant 24 heures. Les événements provenant des flux Amazon Kinesis et Amazon DynamoDB Streams sont relancés jusqu'à ce que la fonction Lambda s'exécute avec succès ou que les données expirent. Amazon Kinesis et Amazon DynamoDB Streams conservent les données pendant 24 heures.

La limite maximale d’exécution simultanée par défaut est appliquée au niveau du compte. Cependant, vous pouvez également définir des limites sur des fonctions individuelles (pour avoir plus d’informations sur la concurrence réservée, cliquez ici).

Chaque fonction Lambda invoquée de manière synchrone peut évoluer jusqu’à 1 000 exécutions simultanées toutes les 10 secondes. Bien que le taux de mise à l'échelle de Lambda soit adapté à la plupart des cas d'utilisation, il est particulièrement idéal pour ceux qui ont des pics de trafic prévisibles ou imprévisibles. Par exemple, le traitement des données lié aux SLA nécessiterait une mise à l'échelle prévisible mais rapide pour répondre à la demande de traitement. De même, la diffusion d'informations de dernière minute ou de ventes flash peut générer des niveaux de trafic imprévisibles en peu de temps. Le taux de mise à l'échelle de Lambda peut faciliter de tels cas d'utilisation sans configuration ni outillage supplémentaires. En outre, la limite de mise à l’échelle de simultanéité est une limite au niveau des fonctions, ce qui signifie que chaque fonction de votre compte est mis à l’échelle indépendamment des autres fonctions.

Si vous dépassez le nombre de tentatives fixé pour les invocations asynchrones, vous pouvez configurer une « file d’attente de lettre morte » (Dead Letter Queue, DLQ) dans laquelle placer l’événement ; en l’absence de DLQ configurée, l’événement risque d’être rejeté. Si vous dépassez le nombre de tentatives fixé pour les invocations basés sur les flux, les données expirent et sont rejetées.

Vous pouvez autoriser votre fonction Lambda à accéder à d’autres ressources à l’aide d’un rôle IAM. AWS Lambda endosse ce rôle lors de l'exécution de votre fonction, de manière à ce que vous conserviez toujours le contrôle total et sécurisé des ressources AWS exactes qu'il peut utiliser. Pour en savoir plus sur les rôles, consultez Configurer AWS Lambda.

Lorsque vous configurerez un compartiment Amazon S3 pour envoyer des messages vers une fonction AWS Lambda, une règle de politique de ressources accordant l’accès est créée. Consultez le guide des développeurs Lambda pour en savoir plus sur les politiques de ressources et les contrôles d’accès des fonctions Lambda.

Les contrôles d’accès sont gérés à l’aide du rôle de la fonction Lambda. Le rôle que vous attribuez à votre fonction Lambda détermine également la ou les ressources AWS Lambda pouvant être interrogées en son nom. Pour en savoir plus, consultez le Guide du développeur Lambda.

Vous pouvez permettre aux fonctions Lambda d’accéder aux ressources de votre VPC en spécifiant le sous-réseau et le groupe de sécurité dans le cadre de la configuration de vos fonctions. Les fonctions Lambda configurées de manière à accéder aux ressources au sein d'un VPC en particulier ne peuvent pas accéder à Internet dans leur configuration par défaut. Pour permettre à Internet d'accéder à ces fonctions, utilisez des passerelles Internet. Par défaut, les fonctions Lambda communiquent avec les ressources d'un VPC à double pile via IPv4. Vous pouvez configurer vos fonctions pour accéder aux ressources d'un VPC à double pile via IPv6. Pour plus de détails sur les fonctions Lambda configurées avec VPC, consultez la section Mise en réseau privée Lambda avec VPC.

La signature de code pour AWS Lambda offre des contrôles de confiance et d’intégrité qui vous permettent de vérifier que seul le code non modifié provenant de développeurs approuvés est déployé dans vos fonctions Lambda. Vous pouvez utiliser AWS Signer, un service de signature de code entièrement géré pour des artefacts de code signés de façon numérique et configurer vos fonctions Lambda pour vérifier les signatures lors du déploiement. La signature de code pour AWS Lambda n’est actuellement disponible que pour les fonctions présentées sous forme d’archives ZIP.

Vous pouvez créer des artefacts de code signé de façon numérique à l’aide de Signing Profile via la console AWS Signer, l’API Signer, SAM CLI ou AWS CLI. Pour en savoir plus, consultez la documentation d’AWS Signer.

AWS Lambda peut effectuer les vérifications de signature suivantes lors du déploiement:

• Signature corrompue : cela se produit si l'artefact de code a été modifié depuis la signature.
• Signature incompatible - Cela se produit si l'artefact de code est signé par un profil de signature non approuvé.
• Signature expirée - Cela se produit si la signature a dépassé la date d'expiration configurée.
• Signature révoquée - Cela se produit si le propriétaire du profil de signature révoque les travaux de signature.

Pour en savoir plus, consultez la documentation AWS Lambda .

Il n’y a aucun coût supplémentaire lors de l’utilisation de la signature de code pour AWS Lambda. Vous payez seulement le prix standard pour AWS Lambda. Pour en savoir plus, consultez la tarification.

Pour vous offrir une expérience de journalisation simplifiée et améliorée par défaut, AWS Lambda propose des contrôles de journalisation avancés, tels que la possibilité de capturer de manière native les journaux des fonctions Lambda au format structuré JSON, de contrôler le filtrage au niveau des journaux des fonctions Lambda sans apporter de modifications au code et de personnaliser le groupe de journaux Amazon CloudWatch auquel Lambda envoie les journaux.

Vous pouvez capturer les journaux de fonction Lambda au format structuré JSON sans avoir à utiliser vos propres bibliothèques de journalisation. Les journaux structurés JSON facilitent la recherche, le filtrage et l'analyse de grands volumes d'entrées de journal. Vous pouvez contrôler le filtrage au niveau des journaux des fonctions Lambda sans modifier le code, ce qui vous permet de choisir le niveau de granularité de journalisation requis pour les fonctions Lambda sans passer au crible de gros volumes de journaux lors du débogage et de la résolution des erreurs. Vous pouvez également définir à quel groupe de journaux Amazon CloudWatch Lambda envoie les journaux, ce qui facilite l'agrégation des journaux provenant de plusieurs fonctions au sein d'une application en un seul endroit. Vous pouvez ensuite appliquer des politiques de sécurité, de gouvernance et de conservation aux journaux au niveau de l’application plutôt qu’individuellement à chaque fonction.

Vous pouvez spécifier des contrôles de journalisation avancés pour vos fonctions Lambda à l’aide de l’API AWS Lambda, de la console AWS Lambda, de l’AWS CLI, du modèle d’application sans serveur AWS (SAM) et d’AWS CloudFormation. Pour en savoir plus, consultez l’article de blog de lancement pour les contrôles de journalisation avancés ou le guide du développeur Lambda.

Oui, vous pouvez utiliser vos propres bibliothèques de journalisation pour générer des journaux Lambda au format structuré JSON. Pour garantir que vos bibliothèques de journalisation fonctionnent parfaitement avec la fonctionnalité de journalisation structurée JSON native de Lambda, Lambda n'encodera pas deux fois les journaux générés par votre fonction qui sont déjà codés au format JSON. Vous pouvez également utiliser la bibliothèque Powertools for AWS Lambda pour capturer les journaux Lambda au format structuré JSON.

L’utilisation des contrôles de journalisation avancés sur Lambda est gratuite. L'ingestion et le stockage de vos journaux Lambda continueront de vous être facturés par Amazon CloudWatch Logs. Pour les informations de tarification, reportez-vous à la page de tarification de CloudWatch.

Application Signals de CloudWatch est une solution de surveillance des performances des applications (APM) qui permet aux développeurs et aux opérateurs de surveiller facilement l’état et les performances des applications sans serveur créées avec Lambda. Application Signals fournit des tableaux de bord standardisés et prédéfinis pour les métriques critiques des applications, les traces corrélées et les interactions entre les fonctions Lambda et leurs dépendances, le tout sans nécessiter d’instrumentation manuelle ni de modifications de code de la part des développeurs.

CloudWatch Logs Live Tail est une fonctionnalité interactive de flux et d’analyse des journaux qui fournit une visibilité en temps réel sur les journaux, ce qui facilite le développement et le dépannage des fonctions Lambda. Cela permet aux développeurs de tester et de valider rapidement les modifications de code ou de configuration en temps réel, accélérant ainsi le cycle auteur-test-déploiement (également appelé « boucle de développement interne ») lors de la création d’applications avec Lambda. L’expérience Live Tail permet également aux opérateurs et aux équipes DevOps de détecter et de déboguer les défaillances et les erreurs critiques dans le code des fonctions Lambda de manière plus efficace, réduisant ainsi le temps moyen de restauration (MTTR) lors de la résolution des erreurs de fonction Lambda.

Utilisez les fonctions Lambda durables lorsque vous souhaitez créer une logique au sein du modèle de programmation familier de Lambda, avec des tests locaux, l’intégration d’un IDE et votre langage de programmation préféré. Utilisez AWS Step Functions lorsque vous avez besoin d’une conception visuelle des flux de travail, d’une visibilité inter-équipes, de plus de 220 intégrations de services natifs ou d’une infrastructure sans maintenance. De nombreuses applications tirent parti de l’utilisation conjointe des deux.

Les fonctions durables AWS Lambda prennent actuellement en charge JavaScript, TypeScript, Python et Java. En savoir plus sur les exécutions prises en charge.

Pour connaître les dernières disponibilités, consultez la page sur les fonctionnalités AWS par région.

Oui. Bien que le délai d’expiration par invocation reste de 15 minutes, les fonctions durables Lambda peuvent être suspendues et reprises sur plusieurs invocations à l’aide de fonctionnalités d’attente telles que des minuteries, des rappels et des conditions de sondage. Lorsque vous invoquez des fonctions durables de manière asynchrone, le délai d’exécution durable peut s’étendre jusqu’à un an, ce qui permet des cas d’utilisation tels que les flux de travail nécessitant une validation humaine, les rappels programmés et les pipelines de traitement sur plusieurs jours. Pour les fonctions à la demande, il n’y a pas de frais de calcul pendant la suspension.

Le délai d’exécution (jusqu’à 1 an) détermine la durée pendant laquelle une exécution peut se poursuivre. La période de conservation (jusqu’à 90 jours) détermine la durée pendant laquelle l’historique et les données de point de contrôle sont conservés une fois que l’exécution a atteint un état terminal. La conservation n’affecte pas les exécutions en cours. Consultez Configuration des fonctions durables.

Non. Pour les fonctions à la demande, lorsque vous utilisez les fonctionnalités d’attente du SDK d’exécution durable, il n’y a pas de frais de calcul pendant la suspension. Pour plus d’informations, consultez la page de tarification et le guide du développeur.

Vous pouvez encapsuler chaque unité de travail dans une étape avec des tentatives automatiques. Si une étape échoue après une nouvelle tentative, votre code de gestionnaire peut détecter l’erreur et exécuter des étapes de compensation, telles que le remboursement d’un paiement ou la libération d’une réservation. Comme chaque étape terminée fait l’objet d’un point de contrôle, y compris les compensations, le travail terminé avec succès n’est pas répété lors d’une nouvelle tentative. Ce modèle vous aide à créer des processus fiables en plusieurs étapes, tels que l’exécution des commandes ou les flux de paiement, sans avoir à écrire de logique personnalisée de nouvelle tentative et de suivi d’état.

L’état d’exécution est stocké dans un magasin d’état interne entièrement géré. Chaque opération enregistrée dans un point de contrôle, telle qu’une étape ou un rappel, peut stocker jusqu’à 256 Ko de données. Cette limite s’applique aux données renvoyées par l’opération. Les données traitées au cours d’une opération, telles que la lecture et l’écriture d’objets S3 volumineux, ne sont pas prises en compte dans cette limite. Si une opération doit renvoyer un résultat volumineux, vous pouvez configurer des sérialiseurs personnalisés dans le SDK pour décharger les charges utiles vers Amazon S3 ou Amazon DynamoDB et ne transmettre qu’une référence via le point de contrôle.

Les fonctions durables Lambda utilisent le même pool de concurrence au niveau du compte que les fonctions Lambda standard. Les slots de concurrence sont libérés pendant les temps d’attente, ce qui permet à des milliers d’exécutions d’attendre sans consommer de concurrence. En savoir plus sur les quotas AWS Lambda.

Vous pouvez tester les fonctions durables localement sans informations d’identification AWS à l’aide du kit SDK d’exécution durable pour votre langage de programmation pris en charge. La CLI AWS SAM prend également en charge l’invocation locale, les rappels et la gestion de l’exécution durable, ce qui facilite le développement et le débogage avant le déploiement. En savoir plus sur le test des fonctions durables.