FAQ sur AWS Lambda

Pour améliorer les performances, AWS Lambda peut choisir de conserver une instance de votre fonction et de la réutiliser pour répondre à une requête ultérieure, plutôt que de créer une nouvelle copie. Pour en savoir plus sur la façon dont Lambda réutilise les instances des fonctions, consultez notre documentation. Votre code ne doit pas supposer que cela sera toujours le cas.

Vous pouvez configurer chaque fonction Lambda avec son propre magasin éphémère entre 512 Mo et 10 240 Mo, par incréments d’1 Mo. Le magasin éphémère est disponible dans le répertoire /tmp de chaque fonction.

Chaque fonction a accès à 512 Mo de stockage sans frais supplémentaires. Si vous configurez vos fonctions avec plus de 512 Mo de magasin éphémère, vous serez facturé en fonction de la quantité de stockage que vous configurez et de la durée d’exécution de votre fonction, mesurée par incréments d’1 ms. À titre de comparaison, dans la région USA Est (Ohio), le prix du magasin éphémère AWS Fargate est de 0,000111 USD par Go-heure, ou 0,08 USD par Go-mois. Le tarif du volume de stockage Amazon EBS gp3 dans la région USA Est (Ohio) est de 0,08 USD par Go-mois. La tarification du magasin éphémère AWS Lambda est de 0,0000000309 USD par Go-seconde, ou 0,000111 USD par Go-heure et 0,08 USD par Go-mois. Pour en savoir plus, consultez la tarification AWS Lambda.

Vous pouvez utiliser les métriques AWS CloudWatch Lambda Insight pour surveiller votre utilisation du magasin éphémère. Pour en savoir plus, consultez la documentation d’AWS CloudWatch Lambda Insights.

Si votre application a besoin d’un stockage durable et permanent, vous pouvez envisager d’utiliser Amazon S3 ou Amazon EFS. Si votre application nécessite le stockage de données nécessaires au code dans un seul appel de fonction, vous pourriez envisager d’utiliser le magasin éphémère AWS Lambda comme cache transitoire. Pour en savoir plus, voir Choisir parmi les options de stockage de données AWS Lambda dans les applications Web.

Oui. Toutefois, si votre application a besoin d’un stockage permanent, vous pouvez envisager d’utiliser Amazon EFS ou Amazon S3. Lorsque vous activez la Simultanéité provisionnée pour votre fonction, le code d’initialisation de votre fonction s’exécute pendant l’allocation et toutes les quelques heures, car les instances en cours d’exécution de votre fonction se recyclent. Vous pouvez voir le temps d’initialisation dans les journaux et les traces lorsqu’une instance a traité une requête. Cependant, l’initialisation vous sera facturée même si l’instance ne traite jamais de requête. Ce comportement d’initialisation de la simultanéité provisionnée peut affecter la manière dont votre fonction interagit avec les données que vous stockez dans le magasin éphémère, même lorsque votre fonction ne traite pas les demandes. Pour en savoir plus sur la Simultanéité provisionnée, veuillez consulter la documentation correspondante.

Vous pouvez utiliser les métriques AWS CloudWatch Lambda Insight pour surveiller votre utilisation du magasin éphémère. Pour en savoir plus, consultez la documentation d’AWS CloudWatch Lambda Insights.

Si vous utilisez Node.js ou Python, vous pouvez créer le code de votre fonction à l'aide de l'éditeur de code disponible dans la console AWS Lambda. Ce dernier vous permet de créer et tester vos fonctions et d'afficher les résultats de ces dernières dans un environnement robuste de type IDE. Accédez à la console pour démarrer.

Vous pouvez également compresser le code (et toute bibliothèque qui s'y rapporte) dans un fichier ZIP et le charger depuis votre environnement local à l'aide de la console AWS Lambda, ou spécifier un emplacement Amazon S3 où enregistrer le fichier ZIP. Les chargements ne doivent pas dépasser 50 Mo (fichier compressé). Vous pouvez utiliser le module d'extension AWS Eclipse pour créer et déployer des fonctions Lambda en Java. Vous pouvez utiliser le module d'extension Visual Studio pour créer et déployer des fonctions Lambda en C# et Node.js.

Vous pouvez compresser le code (et toute bibliothèque qui s'y rapporte) dans un fichier ZIP et le charger depuis votre environnement local à l'aide de l'interface de ligne de commande AWS, ou spécifier un emplacement Amazon S3 où enregistrer le fichier ZIP. Les chargements ne doivent pas dépasser 50 Mo (fichier compressé). Consultez le guide de démarrage Lambda pour démarrer.

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.

Vous pouvez ajuster et sécuriser les ressources associées à votre fonction Lambda à l’aide de l’API ou de la console Lambda. Pour en savoir plus, consultez la documentation.

Oui, vous pouvez conditionner n'importe quel code (frameworks, SDK, bibliothèques et bien plus encore) 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 mesures CloudWatch. Les frais standard d'AWS Lambda s'appliquent à l'utilisation des mesures intégrées à Lambda.

AWS Lambda s'intègre automatiquement à Amazon CloudWatch logs en créant un journal de groupe pour chacune de vos fonctions Lambda, et en fournissant des entrées de journal basiques sur les événements de cycle de vie de l'application, y compris les ressources consommées pour chaque utilisation de cette fonction. Vous pouvez facilement adjoindre des instructions de journalisation supplémentaires à votre code. Vous pouvez également appeler des API de journalisation tierces dans votre fonction Lambda. Pour en savoir plus, consultez la rubrique Résolution des problèmes liés à des fonctions Lamba. Les tarifs Amazon CloudWatch Logs s'appliqueront.

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 relative à la 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 niveaux de tarification avec remise pour toute durée à la demande mensuelle des fonctions supérieure à certains seuils. La tarification progressive est disponible pour les fonctions exécutées aussi bien sur les architectures x86 et Arm. Les niveaux de tarification Lambda sont appliquées à la durée à la demande mensuelle regroupée des fonctions s'exécutant sur la même architecture (x86 ou Arm, respectivement), dans la même région, au sein du compte. Si vous faites appel à la facturation consolidée dans AWS Organizations, les niveaux de tarification sont appliqués à la durée mensuelle regroupée de vos fonctions s'exécutant sur la même architecture, dans la même région, sur les différents comptes de l'organisation. Par exemple, si vous exécutez des fonctions Lambda x86 dans la région USA Est (Ohio), vous payerez chaque mois 0,0000166667 USD pour chaque Go-seconde des 6 premiers milliards de Go-secondes, 0,0000150000 USD pour chaque Go-seconde des 9 milliards de Go-secondes suivants et 0,0000133334 USD pour chaque Go-seconde au-delà du seuil des 15 milliards. La tarification des requêtes, de la simultanéité allouée et de la durée pour la simultanéité allouée reste inchangée. Pour en savoir plus, consultez Tarification AWS Lambda.

Oui. L'utilisation de Lambda couverte par votre engagement Savings Plan est facturée au tarif et au taux CSP applicable. Toute autre utilisation n'étant pas couverte par cet engagement sera facturée au taux correspondant au niveau de la durée mensuelle de votre fonction de regroupement.

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

Les événements sont transmis à une fonction Lambda en tant que paramètre d'entrée d'événement. Pour les sources d'événements où les événements arrivent par lots, comme Amazon SQS, Amazon Kinesis et Amazon DynamoDB Streams, le paramètre d'événement peut contenir plusieurs événements dans un seul appel, en fonction de la taille du lot que vous demandez. Pour en savoir plus sur les notifications d'événements Amazon S3, consultez, Configuration des notifications des événements Amazon S3. Pour en savoir plus sur Amazon DynamoDB Streams, consultez le Guide des développeurs DynamoDB Stream. Pour en savoir plus sur l'appel des fonctions Lambda via Amazon SNS, consultez le Guide des développeurs Amazon SNS. Pour en savoir plus sur les événements Amazon Cognito, consultez Amazon Cognito. Pour en savoir plus sur les journaux AWS CloudTrail et les appels d'API d'audit sur les services AWS, consultez AWS CloudTrail.

AWS Lambda vous permet d'effectuer des agrégations basées sur le temps (telles que le nombre, le maximum, la somme, la moyenne, etc.) sur une courte fenêtre de 15 minutes maximum pour vos données dans Amazon Kinesis ou Amazon DynamoDB Streams, sur une seule partition logique telle que comme une partition. Cela vous permet de configurer facilement des analyses simples pour votre application événementielle sans ajouter de complexité architecturale puisque votre logique commerciale et analytique peut se trouver dans la même fonction. Lambda autorise les agrégations sur une période de basculement maximale de 15 minutes, en fonction de l'horodatage de l'événement. Amazon Kinesis Data Analytics vous permet de créer des applications analytiques plus complexes qui prennent en charge des choix de traitement flexibles et possèdent une tolérance aux pannes robustes avec un traitement une seule fois sans doublons, et des analyses qui peuvent être effectuées sur un flux de données entier sur plusieurs partitions logiques. Avec KDA, vous pouvez analyser les données sur plusieurs types de fenêtres d'agrégation (fenêtre bascule, fenêtre échelonnée, fenêtre glissante, fenêtre de session) en utilisant soit l'heure de l'événement, soit le temps de traitement.
 

Configurez tout d'abord l'alarme pour envoyer des notifications Amazon SNS. Puis, à partir de la console AWS Lambda, sélectionnez une fonction Lambda et associez-la à cette rubrique Amazon SNS. Consultez le guide du développeur Amazon CloudWatch pour découvrir comment configurer des alarmes Amazon CloudWatch.

Depuis la console AWS Lambda, vous pouvez sélectionner une fonction qui doit être déclenchée lorsque des jeux de données associés à une réserve d'identités Amazon Cognito sont synchronisés. Cette même fonctionnalité est également disponible via le SDK et l'interface de ligne de commande AWS. Consultez la rubrique Amazon Cognito pour découvrir comment utiliser Amazon Cognito pour partager et synchroniser les données entre les différents appareils d'un utilisateur.

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.

Chargez le code que vous souhaitez exécuter avec AWS Lambda, puis appelez-le depuis votre application mobile à l'aide du kit SDK AWS Lambda qui est inclus dans le kit SDK AWS Mobile. Vous pouvez effectuer des appels directs (synchrones) pour récupérer ou vérifier des données en temps réel, ainsi que des appels asynchrones. Vous pouvez également définir une API personnalisée en utilisant Amazon API Gateway et appeler vos fonctions Lambda par le biais de n'importe quel client REST compatible. Pour en savoir plus sur AWS Mobile SDK, consultez la page AWS Mobile SDK. Pour en savoir plus sur Amazon API Gateway, consultez la page Amazon API Gateway.

Vous pouvez faire votre choix parmi un éventail d'applications sans serveur publiées par des développeurs, des entreprises et des partenaires de la communauté AWS à l'aide du référentiel AWS Serverless Application Repository. Après avoir trouvé une application, vous pouvez la configurer et la déployer directement à partir de la console Lambda.

Vous pouvez automatiser le processus de publication de votre application sans serveur à l'aide d'AWS CodePipeline et d'AWS CodeDeploy. CodePipeline est un service de diffusion continue qui vous permet de modéliser, visualiser et automatiser les étapes nécessaires à la publication de votre application sans serveur. CodeDeploy vous offre un moteur d'automatisation de déploiement pour vos applications reposant sur Lambda. CodeDeploy vous permet d'orchestrer vos déploiements selon des méthodologies établies et recommandées, comme les déploiements « canary » et linéaires. Il vous aide également à mettre en place les garde-fous nécessaires pour vérifier que le code qui vient d'être déployé est sûr, stable et prêt à passer totalement en production.
 

Pour en savoir plus sur les déploiements/intégrations continus sans serveur, consultez notre documentation.

Pour commencer, accédez à la console AWS Lambda et téléchargez un des plans détaillés. Le fichier que vous téléchargez contient un fichier AWS SAM (qui définit les ressources AWS de votre application) et un fichier .ZIP (qui inclut le code de votre fonction). Vous pouvez alors utiliser les commandes AWS CloudFormation pour créer un package destiné à l'application sans serveur que vous venez de télécharger et la déployer. Pour plus de détails, consultez la documentation.

Vous pouvez avoir recours à l'outil AWS Step Functions pour coordonner un ensemble de fonctions AWS Lambda selon un ordre précis. Il est possible d'invoquer plusieurs fonctions Lambda de manière séquentielle, en transmettant le résultat de sortie de l'une à la suivante, et/ou en parallèle ; l'outil Step Functions se charge de maintenir leur état pendant les exécutions.

Vous pouvez demander à votre fonction Lambda d'effectuer un traçage avec AWS X-Ray en ajoutant les autorisations X-Ray au rôle d'exécution de votre fonction Lambda et en activant le « mode de traçage » de votre fonction. Lorsque X-Ray est activé pour votre fonction Lambda, AWS Lambda émet des données de traçabilité à X-Ray concernant la surcharge service de Lambda lors de l'appel de votre fonction. Ainsi, vous obtenez des informations telles que les frais de service de Lambda, le temps d'initialisation de la fonction et le temps d'exécution de celle-ci. De plus, vous pouvez inclure le kit SDK X-Ray dans votre package de déploiement Lambda. De cette manière, vous créez vos propres segments traces, annotez vos traces ou affichez les segments traces pour les appels en aval réalisés par votre fonction Lamba. Les kits SDK X-Ray sont actuellement disponibles pour Node.js et Java. Consultez Dépannage des applications Lambda pour en savoir plus. Les tarifs d'AWS X-Ray s'appliquent.

Oui. Vous pouvez créer des applications sans serveur hautement évolutives, sécurisées et basées sur Lambda qui se connectent aux bases de données relationnelles en utilisant le proxy Amazon RDS, un proxy de base de données hautement disponible qui gère des milliers de connexions simultanées aux bases de données relationnelles. Actuellement, RDS Proxy prend en charge les bases de données MySQL et Aurora. Vous pouvez commencer à utiliser RDS Proxy via la console Amazon RDS ou la console AWS Lambda. Les applications sans serveur qui utilisent des pools de connexions entièrement gérés à partir de RDS Proxy seront facturées selon la tarification du proxy RDS.

La spécification est en open source sous Apache 2.0, ce qui permet à chacun d'adopter et d'intégrer AWS SAM dans les outils de conception, de déploiement, de surveillance et de gestion avec une licence autorisant un usage commercial. Vous pouvez accéder au répertoire AWS SAM sur GitHub ici.

Il existe trois différences principales entre les fonctions créées à l'aide d'archives ZIP et d'images de conteneurs:

1. Les fonctions créées à l'aide d'archives ZIP ont une taille de package de code maximale de 250 Mo décompressés, et celles créées à l'aide d'images de conteneur ont une taille d'image maximale de 10 Go. 
2. Lambda utilise Amazon ECR comme stockage de code sous-jacent pour les fonctions définies comme images de conteneur, de sorte qu'une fonction peut ne pas être invocable lorsque l'image sous-jacente est supprimée d'ECR. 
3. Les fonctions ZIP sont automatiquement corrigées pour les dernières corrections de bugs et de sécurité d'exécution. Les fonctions définies comme des images de conteneurs sont non modifiables et les clients sont responsables des composants conditionnés dans leur fonction. Les clients peuvent exploiter les images de base fournies par AWS qui sont régulièrement mises à jour par AWS pour la sécurité et les corrections de bugs, en utilisant les correctifs les plus récents à disposition.

Il n'y a pas de frais supplémentaires pour le conditionnement et le déploiement de fonctions en tant qu'images de conteneur sur AWS Lambda. Lorsque vous invoquez votre fonction déployée en tant qu'image de conteneur, vous payez le prix normal des requêtes et de la durée d'exécution. Pour en savoir plus, consultez la tarification AWS Lambda. Vous serez facturé pour le stockage des images de vos conteneurs dans Amazon ECR aux prix ECR standard. Pour en savoir plus, consultez tarification Amazon ECR.

L'émulateur d'interface d'exécution Lambda est un proxy pour l'API Lambda Runtime qui permet aux clients de tester localement leur fonction Lambda empaquetée en tant qu'image de conteneur. Il s'agit d'un serveur Web léger qui convertit les requêtes HTTP en événements JSON et émule l'API Lambda Runtime. Il vous permet de tester localement vos fonctions à l'aide d'outils familiers tels que cURL et la CLI Docker (lors du test de fonctions conditionnées sous forme d'images de conteneur). Cela simplifie également l'exécution de votre application sur des services de calcul supplémentaires. Vous pouvez inclure l'émulateur d'interface d'exécution Lambda dans l'image de votre conteneur pour qu'il accepte les requêtes HTTP en natif au lieu des événements JSON requis pour le déploiement sur Lambda. Ce composant n'émule pas l'orchestrateur Lambda, ni les configurations de sécurité et d'authentification. L'émulateur d'interface d'exécution est en open source sur GitHub. Vous pouvez commencer par le télécharger et l'installer sur votre ordinateur local.

Les clients peuvent ajouter l'émulateur d'interface d'exécution comme point d'entrée à l'image du conteneur ou le conditionner en tant que side-car pour garantir que l'image du conteneur accepte désormais les requêtes HTTP au lieu des événements JSON. Cela simplifie les modifications requises pour exécuter leur image de conteneur sur des services de calcul supplémentaires. Les clients seront responsables de s'assurer qu'ils respectent toutes les meilleures pratiques en matière de sécurité, de performances et de concurrence pour l'environnement de leur choix. RIE est pré-conditionné dans les images fournies par AWS Lambda et disponible par défaut dans AWS SAM CLI. Les fournisseurs d'images de base peuvent utiliser la documentation pour fournir la même expérience pour leurs images de base.

Vous pouvez déployer une application en conteneur sur AWS Lambda si elle répond aux exigences ci-dessous:

1. L'image de conteneur doit implémenter l'API Lambda Runtime. Nous mis en open source un ensemble de packages logiciels, Runtime Interface Clients (RIC), qui implémentent l'API d'environnement d'exécution Lambda, vous permettant ainsi d'étendre de manière transparente vos images de base préférées pour qu'elles soient compatibles avec Lambda.
2. L'image du conteneur doit pouvoir s'exécuter sur un système de fichiers en lecture seule. Votre code de fonction peut accéder à un répertoire de stockage inscriptible / tmp de 512 Mo. Si vous utilisez une image qui nécessite un répertoire racine accessible en écriture, configurez-la pour écrire dans le répertoire /tmp.
3. Les fichiers nécessaires à l'exécution du code de fonction peuvent être lus par l'utilisateur Lambda par défaut. Lambda définit un utilisateur Linux par défaut avec les autorisations les moins privilégiées qui suivent les bonnes pratiques de sécurité. Vous devez vérifier que votre code d'application ne repose pas sur des fichiers dont l'exécution est restreinte par d'autres utilisateurs Linux.
4. C'est une image de conteneur basée sur Linux.

AWS 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é.

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. Vous pouvez configurer Lambda SnapStart pour les fonctions exécutées aussi bien sur les architectures x86 et Arm.

Oui. Si votre code suppose l'unicité de l'état, vous devez évaluer la résistance de votre code aux opérations d'instantané (comme le clonage et la reprise). Pour en savoir plus sur les considérations d'unicité avec Lambda SnapStart, consultez la documentation et le blog sur l'unicité dans les instantanés de VM avec Lambda SnapStart.

Oui. Vous pouvez mettre en œuvre votre propre journal logiciel avant la création (point de contrôle) d'un instantané et après la restauration d'un instantané en utilisant des hooks d'exécution. Pour en savoir plus, consultez la documentation Lambda SnapStart.

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.

Comme toutes les fonctions Lambda, des frais de durée s’appliquent aux fonctions SnapStart. Pour les fonctions utilisant SnapStart, la durée inclut le temps nécessaire au chargement de l’environnement d’exécution, tout code qui est exécuté dans un hook d’exécution et le code d’initialisation exécuté lors de la création de copies instantanées à des fins de résilience.

Avec Lambda SnapStart pour Python et .NET, les instantanés de vos fonctions restent actifs tant que votre fonction est active. Pour les fonctions Java, l’instantané associé à une fonction publiée expire s’il reste inactif pendant plus de 14 jours.

Les instantanés sont chiffrés par défaut avec des clés AWS Key Management Service (KMS) uniques pour le client, détenues et gérées par le service Lambda. Les clients peuvent également chiffrer les instantanés en utilisant une clé KMS qu'ils possèdent et gèrent.

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.

En règle générale, les langages interprétés, comme Python, Java et Node, ne nécessitent pas la recompilation, sauf si votre code fait référence à des bibliothèques qui utilisent des composants spécifiques d'architecture. Dans ces cas, vous devrez fournir les bibliothèques ciblées sur arm64. Pour plus d'informations, consultez la page Démarrer avec AWS Graviton. Les langages non interprétés nécessitent la compilation de votre code afin qu'il cible arm64. Alors que davantage de compilateurs modernes fournissent du code compilé pour arm64, vous devrez le déployer dans un environnement basé sur Arm aux fins de test. Pour en savoir plus sur l'utilisation des fonctions Lambda avec Graviton2, consultez la documentation.

Au lancement, les clients peuvent utiliser Python, Node.js, Java, Ruby, .Net Core, Custom Runtime (provided.al2) et les images OCI Base. Pour en savoir plus, consultez les Exécutions AWS Lambda.

Chaque application étant unique, nous recommandons aux clients de tester leurs fonctions afin d'identifier l'amélioration prix/performances qu'ils recherchent. À cet effet, nous vous recommandons d'utiliser l'outil AWS Lambda Power Tuning. Nous recommandons de démarrer avec les backends web et mobiles, les données et le traitement des flux lors du test des potentielles améliorations prix/performances pour vos applications.

Les développeurs peuvent facilement se connecter à un système de fichiers EFS à une fonction Lambda via un point d'accès EFS en utilisant la console, une CLI ou un kit SDK. Lorsque la fonction est appelée pour la première fois, le système de fichiers est automatiquement monté et rendu accessible au code de la fonction. Pour en savoir plus, consultez la documentation.

Amazon EFS pour AWS Lambda est disponible sans frais supplémentaires. Les clients payent le prix standard pour AWS Lambda et pour Amazon EFS. Lorsqu’ils utilisent Lambda et EFS dans la même zone de disponibilité, les clients ne sont pas facturés pour le transfert des données. Toutefois, s’ils utilisent l’appairage de VPC pour les accès entre comptes, ils devront payer les frais de transfert de données. Pour en savoir plus, consultez la tarification.

Vous pouvez configurer une URL de fonction pour votre fonction au moyen de la console de gestion AWS, de l'API AWS Lambda, d'AWS CLI, d'AWS CloudFormation et d'AWS Serverless Application Model. Les URL de fonctions peuvent être activées sur la version $LATEST non qualifiée de votre fonction ou sur n'importe quel alias de fonction. Pour en savoir plus sur la configuration d'une URL de fonction, consultez la documentation.

Oui. Les URL de fonctions Lambda peuvent être activées sur une fonction ou un alias de fonction. Si aucun alias n'est spécifié, l'URL pointe vers $LATEST par défaut. Les URL de fonctions ne peuvent pas cibler une version de fonction individuelle.

L'utilisation des URL de fonctions n'implique aucun coût supplémentaire. Vous payez seulement le prix standard pour AWS Lambda. Pour en savoir plus, voir Tarification 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.

Vos fonctions se déclenchent automatiquement suite aux événements Amazon CloudFront suivants :

• Demande utilisateur : cet événement se produit lorsqu'un utilisateur final ou un appareil sur Internet adresse une demande HTTP(S) à CloudFront et que la demande arrive à l'emplacement périphérique le plus proche de cet utilisateur.
• Réponse utilisateur – cet événement se produit lorsque le serveur CloudFront en périphérie est prêt à répondre à l'utilisateur final ou à l'appareil ayant formulé la requête.
• Demande d'origine : cet événement se produit lorsque le serveur CloudFront périphérique n'a pas l'objet demandé dans sont cache et que la demande utilisateur est prête à être envoyée à votre serveur Web d'origine backend (par exemple Amazon EC2, Application Load Balancer ou Amazon S3).
• Réponse d'origine : cet événement se produit lorsque le serveur CloudFront périphérique reçoit une réponse de votre serveur d'origine backend.

La différence, c'est qu'API Gateway et Lambda sont des services régionaux. L'utilisation de Lambda@Edge et Amazon CloudFront vous permet d'exécuter une logique sur plusieurs emplacements AWS basés sur l'emplacement de vos visionneurs finaux.

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 appels 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 appels 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.

Vous pouvez activer les signaux d'application pour votre fonction d'un simple clic dans la section « Outils de surveillance et opérationnels » de l'onglet Configuration de la console Lambda. Après avoir activé Application Signals, vous pouvez consulter des tableaux de bord prédéfinis, une carte des services, etc., et analyser les performances et l'état de vos applications sans serveur dans la console CloudWatch. Pour en savoir plus, consultez le Guide du développeur Lambda et le Guide du développeur Application Signals. Consultez la page de tarification de CloudWatch pour en savoir plus sur la manière dont vous êtes facturé pour l'utilisation de Application Signals avec vos fonctions Lambda.

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.

Pour utiliser Live Tail pour votre fonction Lambda, rendez-vous sur la console Lambda et cliquez sur le bouton « Ouvrir CloudWatch Live Tail » dans l'éditeur de code. Pour plus d'informations, consultez le Guide du développeur Lambda. Consultez la page de tarification de CloudWatch pour en savoir plus sur la facturation de l'utilisation de Live Tail avec vos fonctions Lambda.

Pour compiler votre fonction Lambda, vous pouvez utiliser des outils standard, tels que Maven ou Gradle. Le processus de génération est normalement similaire à celui que vous appliqueriez pour compiler n'importe quel code Java dépendant du kit SDK AWS. Exécutez votre outil de compilation Java sur vos fichiers sources, en incluant le kit SDK AWS 1.9 (ou version ultérieure) avec ses dépendances transitives dans votre classpath. Pour en savoir plus, consultez la documentation.

Oui. Vous pouvez utiliser des packages NPM ainsi que des packages personnalisés. Consultez cette page pour en savoir plus.

Oui. L'environnement de test intégré à Lambda vous permet d'exécuter des scripts en paquets (« shell »), des moteurs d'exécution dans d'autres langages, des tâches utilitaires de routine et des exécutables. Consultez cette page pour en savoir plus.

Oui. Tout module natif lié de manière statique peut être inclus dans le fichier ZIP que vous téléchargez. En cas de liaison dynamique, l'inclusion est possible si les modules sont compilés avec un chemin rpath pointant vers le répertoire racine de votre fonction Lambda. Consultez cette page pour en savoir plus.

Oui. Vous pouvez utiliser la commande child_process de Node.js pour exécuter un fichier binaire que vous avez inclus dans votre fonction ou tout exécutable d'Amazon Linux visible dans votre fonction. Il existe aussi différents packages NPM qui encapsulent des fichiers binaires de ligne de commande, par exemple node-ffmpeg. Consultez cette page pour en savoir plus.

Pour déployer une fonction Lambda écrite en Node.js, compressez simplement au format ZIP votre code Javascript et les bibliothèques associées. Vous pouvez charger le fichier ZIP depuis votre environnement local ou spécifier un emplacement Amazon S3 où enregistrer le fichier ZIP. Pour en savoir plus, consultez la documentation.

Un package de déploiement PowerShell Lambda est un fichier ZIP qui contient votre script PowerShell, les modules PowerShell requis pour votre script PowerShell et les assemblages requis pour héberger votre PowerShell Core. Vous utilisez ensuite le module PowerShell AWSLambdaPSCore que vous pouvez installer depuis la PowerShell Gallery pour créer votre package de déploiement PowerShell Lambda.

Chargez votre artéfact exécutable Go en tant que fichier ZIP via AWS CLI ou la console Lambda et exécutez la version go1.x. Avec Lambda, vous pouvez utiliser les outils natifs de Go pour concevoir votre code et le mettre en paquets. Pour plus de détails, consultez notre documentation. 

Vous pouvez consulter ici la liste des versions prises en charge.

Non. AWS Lambda propose une version unique du système d'exploitation et de l'environnement d'exécution du langage géré à tous les utilisateurs du service. Vous pouvez apporter votre propre environnement d'exécution du langage pour l'utiliser dans Lambda.

Vous pouvez avoir recours à l'outil Amazon Step Functions pour coordonner plusieurs fonctions Lambda d'appel. Il est possible d'invoquer plusieurs fonctions Lambda en série, en transmettant le résultat de sortie de l'une à la suivante, et/ou en parallèle. Pour plus de détails, consultez notre documentation.