FAQ sur AWS Lambda

Le code que vous exécutez sur AWS Lambda est chargé en tant que « fonction lambda ». Chaque fonction est associée à des informations de configuration telles que son nom, sa description, son point d'entrée et ses besoins en ressources. Le code doit être écrit dans un style « statique », c'est-à-dire qu'il doit supposer qu'aucune affinité n'existe avec l'infrastructure de calcul sous-jacente. L'accès au système de fichiers local, les traitements d'éléments enfants et autres artefacts similaires ne doivent pas aller au-delà de la durée de vie de la requête, et toute donnée à statut permanent doit être stockée dans Amazon S3, Amazon DynamoDB, Amazon EFS ou un autre service de stockage disponible sur Internet. Les fonctions Lambda peuvent inclure des bibliothèques, même natives.

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 configurer chaque fonction Lambda avec son propre magasin éphémère entre 512 Mo et 10 240 Mo, par incréments de 1 Mo à l’aide de la console AWS Lambda, de l’API AWS Lambda ou du modèle AWS CloudFormation lors de la création ou de la mise à jour de la fonction.

Oui. Toutes les données stockées dans le magasin éphémère sont chiffrées au repos avec une clé gérée par AWS.

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 configurer chaque fonction Lambda avec son propre magasin éphémère entre 512 Mo et 10 240 Mo, par incréments de 1 Mo à l’aide de la console AWS Lambda, de l’API AWS Lambda ou du modèle AWS CloudFormation lors de la création ou de la mise à jour de la fonction.

Oui. Toutes les données stockées dans le magasin éphémère sont chiffrées au repos avec une clé gérée par AWS.

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.

Conserver les fonctions statiques permet à AWS Lambda de lancer rapidement autant de copies de la fonction que nécessaire pour dimensionner le débit d'événements entrants. Tandis que le modèle de programmation d'AWS Lambda est statique, votre code peut accéder à des données dynamiques en appelant d'autres services Web tels qu'Amazon S3 ou Amazon DynamoDB.

Oui. AWS Lambda vous permet d'utiliser les fonctionnalités normales de langage et de système d'exploitation, comme la création de threads et de processus supplémentaires. Les ressources allouées à la fonction Lambda, y compris la mémoire, le temps d'exécution, le disque et l'utilisation du réseau, doivent être partagées entre tous les processus qu'elle utilise. Vous pouvez lancer des processus à l'aide de n'importe quel langage pris en charge par Amazon Linux.

Lambda vise à imposer le moins de restrictions possible aux activités normales de langage et de système d'exploitation, mais certaines activités sont désactivées : les connexions réseau entrantes sont bloquées par AWS Lambda, et pour ce qui est des connexions sortantes, seules les interfaces de connexion TCP/IP et UDP/IP sont prises en charge, et les appels au système ptrace (débogage) sont bloqués. Dans le cadre d'une mesure anti-spam, le trafic du port TCP 25 est également bloqué.

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.

Vous n'avez pas à mettre à l'échelle vos fonctions Lambda, AWS Lambda s'en charge automatiquement à votre place. A chaque réception d'une notification d'événement pour votre fonction, AWS Lambda localise rapidement une capacité disponible au sein de sa flotte de calcul et exécute votre code. Etant donné que votre code est statique, AWS Lambda peut lancer autant de copies de votre fonction que nécessaire sans longueurs dans le déploiement, ni délais liés à la configuration. Il n'existe aucune limite fondamentale au dimensionnement d'une fonction. AWS Lambda allouera de la capacité de façon dynamique pour faire face aux événements entrants.

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.

Les clients qui exécutent des applications utilisant beaucoup de mémoire et le calcul peuvent désormais utiliser davantage de mémoire pour leurs fonctions. Les fonctions de mémoire plus importantes permettent aux applications multithread de s'exécuter plus rapidement, ce qui les rend idéales pour les données et les applications à niveau élevé de calcul telles que le machine learning, les travaux par lots et ETL, la modélisation financière, la génomique, le calcul intensif et le traitement des médias.

Les fonctions AWS Lambda peuvent être configurées pour que chaque exécution dure jusqu’à 15 minutes. Vous pouvez définir le délai de réponse sur une valeur comprise entre 1 seconde et 15 minutes.

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. En plus d'économiser de l'argent sur Amazon EC2 et AWS Fargate, vous pouvez également utiliser des Compute Savings Plans pour économiser de l'argent sur AWS Lambda. Compute Savings Plans offrent jusqu'à 17 % de réduction sur la durée, l'accès simultané alloué et la durée (accès simultané alloué). Compute Savings Plans n'offrent pas de réduction sur les demandes dans votre facture Lambda. Cependant, votre engagement Compute Savings Plans peut s'appliquer aux demandes au tarif normal.

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.

Les temps de déploiement peuvent varier selon la taille de votre code, mais il est généralement possible d'appeler les fonctions AWS Lambda quelques secondes après le chargement.

Oui. Vous pouvez inclure votre propre copie d'une bibliothèque (y compris le kit SDK AWS) de manière à utiliser une version différente de celle proposée par défaut par AWS Lambda.

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.

Une source d'événement est un service AWS ou une application créée par un développeur qui déclenche l'exécution d'une fonction AWS Lambda. Certains services publient ces événements sur Lambda en appelant directement la fonction cloud (par exemple, Amazon S3). Lambda peut également interroger des ressources dans d'autres services qui ne publient pas d'événements sur Lambda. Par exemple, Lambda peut extraire des enregistrements d'un flux Amazon Kinesis ou d'une file d'attente Amazon SQS et exécuter une fonction Lambda pour chaque message récupéré. De nombreux autres services, tels qu'AWS CloudTrail, peuvent agir en tant que sources d'événements simplement en se connectant à Amazon S3 et en utilisant les notifications de compartiment S3 pour déclencher des fonctions AWS Lambda.

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.

Concernant la console AWS Lambda, vous pouvez sélectionner une fonction et l'associer à des notifications émanant d'un compartiment Amazon S3. Sinon, vous pouvez utiliser la console Amazon S3 et configurer les notifications du compartiment à envoyer à votre fonction AWS Lambda. Cette même fonctionnalité est également disponible via le SDK et l'interface de ligne de commande AWS.

Vous pouvez déclencher une fonction Lambda lorsque des mises à jour sont apportées à une table DynamoDB en abonnant votre fonction Lambda au flux DynamoDB associé à la table. Vous pouvez associer un flux DynamoDB à une fonction Lambda à l'aide de la console Amazon DynamoDB, de la console AWS Lambda ou de l'API Lambda registerEventSource.

Depuis la console AWS Lambda, vous pouvez sélectionner une fonction Lambda et l'associer à un flux Amazon Kinesis détenu par le même compte. Cette même fonctionnalité est également disponible via le SDK et l'interface de ligne de commande AWS.

Les enregistrements des flux Amazon Kinesis et Amazon DynamoDB envoyés à votre fonction AWS Lambda sont strictement numérotés, par partition. Ainsi, si vous placez deux enregistrements dans la même partition, Lambda s'assure que votre fonction Lambda est appelée avec succès avec le premier enregistrement avant d'être appelée avec le deuxième enregistrement. Si l'appel pour un enregistrement est écoulé ou limité, ou s'il rencontre d'autres erreurs, Lambda essaiera de nouveau d'appeler votre fonction jusqu'à ce qu'il y parvienne (ou que l'enregistrement arrive à son délai d'expiration de 24 heures) avant de passer à l'enregistrement suivant. L'ordre des enregistrements dans différentes partitions n'est pas garanti et le traitement de chaque partition s'effectue en parallèle.

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.
 

	AWS Lambda	Amazon KDA
Fenêtre bascule	Oui	Oui
Fenêtre échelonnée	Non	Oui
Fenêtre glissante	Non	Oui
Fenêtre échelonnée	Non	Oui
Enrichissement	Non	Oui
Tables communes d'entrée et de référence	Non	Oui
Flux d'entrée divisé	Non	Oui
Traitement unique	Non	Oui
Fenêtre de temps maximum	15 min	Illimité
Périmètre d'agrégation	Partition / fragment	Le flot
Sémantique du temps	Heure de l'évènement	Heure de l'événement, temps de traitement

Depuis la console AWS Lambda, vous pouvez sélectionner une fonction Lambda et l'associer à une rubrique Amazon SNS. Cette même fonctionnalité est également disponible via le SDK et l'interface de ligne de commande AWS.

Depuis la console Amazon SES, vous pouvez configurer votre règle de réception afin de faire en sorte qu'Amazon SES envoie vos messages à une fonction AWS Lambda. Cette même fonctionnalité est disponible via le SDK et l'interface de ligne de commande AWS.

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.

AWS Lambda est conçu pour traiter les événements en quelques millisecondes. La latence sera plus importante immédiatement après la création et la mise à jour d'une fonction Lambda, ou si celle-ci n'a pas été utilisée récemment.

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 appeler une fonction Lambda via HTTPS en définissant une API RESTful personnalisée à l'aide d'Amazon API Gateway. Celle-ci vous fournit un point de terminaison pour votre fonction qui peut répondre aux appels REST comme GET, PUT et POST. Obtenez plus d'informations sur l'utilisation d'AWS Lambda avec Amazon API Gateway.

Lorsqu'elles sont appelées par le kit SDK AWS Mobile, les fonctions AWS Lambda obtiennent automatiquement des informations précises sur l'appareil et l'application qui effectuent l'appel via l'objet « contexte ».

Lorsque votre application utilise l'identité Amazon Cognito, les utilisateurs finaux peuvent s'authentifier via différents fournisseurs d'identifiants publics tels qu'Amazon, Facebook, Google et d'autres services compatibles avec OpenID Connect. L'identité de l'utilisateur est alors automatiquement présentée, de manière sécurisée, à votre fonction Lambda sous la forme d'un identifiant Amazon Cognito, qui lui permet d'accéder aux données utilisateur d'Amazon Cognito, ou sous la forme d'une clé lui permettant de stocker et de récupérer des données dans Amazon DynamoDB ou d'autres services Web.

AWS Lambda est intégré à Alexa Skills Kit, un ensemble d'API, d'outils, de documents et d'exemples de code open source qui simplifient la création de fonctionnalités (ou « skills ») à commande vocale pour Alexa. Il vous suffit de charger le code de fonction Lambda de la nouvelle skill Alexa que vous créez, et AWS Lambda s'occupe du reste, exécutant le code en réponse aux interactions vocales Alexa et gérant automatiquement les ressources de calcul pour vous. Consultez la documentation Alexa Skills Kit pour en savoir plus.

Concernant les notifications des compartiments Amazon S3 et les événements personnalisés, AWS Lambda tentera d'exécuter votre fonction à trois reprises dans le cas d'une condition d'erreur dans votre code ou d'un dépassement de la limite d'un service ou d'une ressource. Concernant les sources d'événements ordonnancées qu'AWS Lambda interroge à votre place (flux Amazon DynamoDB Streams et Amazon Kinesis, par exemple), Lambda continuera à tenter l'exécution en cas d'erreur de code du développeur jusqu'à ce que les données expirent. Vous pouvez surveiller la progression via les consoles Amazon Kinesis et Amazon DynamoDB, et via les mesures Amazon CloudWatch qu'AWS Lambda génère pour votre fonction. Vous pouvez également définir des alarmes Amazon CloudWatch en fonction de vos taux d'erreurs et de limitation d'exécution.

Les applications basées sur Lambda (également appelées applications sans serveur) se composent de fonctions déclenchées par des événements. En règle générale, une application sans serveur contient une ou plusieurs fonctions déclenchées par des événements tels que le chargement d'objets dans Amazon S3, des notifications Amazon SNS ou des actions d'API. Ces fonctions peuvent être autonomes ou s'appuyer sur d'autres ressources, comme des tables DynamoDB ou des compartiments Amazon S3. Dans sa forme la plus rudimentaire, une application sans serveur est tout simplement une fonction.

Vous pouvez déployer et gérer votre application sans serveur à l'aide du modèle d'application sans serveur AWS (AWS Serverless Application Model, ou AWS SAM). AWS SAM est une spécification qui prévoit les règles d'expression des applications sans serveur sur AWS. Cette spécification est conforme à la syntaxe utilisée actuellement par AWS CloudFormation et est prise en charge en natif au sein de ce service en tant qu'ensemble de ressources (appelé « ressources sans serveur »). Grâce à ces ressources, les clients AWS peuvent utiliser plus facilement CloudFormation, afin de configurer et de déployer des applications sans serveur à l'aide d'API CloudFormation existantes.

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.

AWS Lambda vous permet désormais d'emmagasiner des fonctions et de les déployer sous forme d'images de conteneur. Les clients peuvent bénéficier de la flexibilité et de la familiarité des outils de conteneur, ainsi que de l'agilité et de la simplicité opérationnelle d'AWS Lambda pour créer des applications.

Vous pouvez commencer avec des images de base fournies par AWS pour Lambda ou en utilisant l'une de vos images de communauté ou d'entreprise privée de votre choix. Ensuite, utilisez simplement Docker CLI pour créer l'image, la téléchargez sur Amazon ECR, puis créez la fonction à l'aide de tous les interfaces et outils Lambda familiers, tels que la console de gestion AWS, AWS CLI, AWS SDK, AWS SAM et AWS CloudFormation .

Vous pouvez déployer des images de base Linux tierces (par exemple, Alpine ou Debian) sur Lambda en plus des images fournies par Lambda. AWS Lambda prend en charge toutes les images basées sur les formats de manifestes d'image suivants : Docker Image Manifest V2 Schéma 2 (utilisé avec Docker version 1.10 et plus récente) ou Open Container Initiative (OCI) Spec (v1.0 et plus récente). Lambda prend en charge les images d'une taille allant jusqu'à 10 Go.

AWS Lambda fournit une variété d'images de base que les clients peuvent étendre, et les clients peuvent également utiliser leurs images Linux préférées d'une taille allant jusqu'à 10 Go.

Vous pouvez utiliser n'importe quel outil de conteneur tant qu'il prend en charge l'un des formats de manifeste d'image de conteneur suivants: Docker Image Manifest V2 Schema 2 (utilisé avec Docker version 1.10 et plus récente) ou Open Container Initiative (OCI) Spécifications (v1.0 et plus) . Par exemple, vous pouvez utiliser des outils de conteneur natifs (c'est-à-dire docker run, docker compose, Buildah et Packer) pour définir vos fonctions en tant qu'image de conteneur et les déployer sur Lambda.

Toutes les fonctionnalités AWS Lambda existantes, à l'exception des couches Lambda et de la signature de code, peuvent être utilisées avec des fonctions déployées en tant qu'images de conteneur. Une fois déployée, AWS Lambda traitera une image comme immuable. Les clients peuvent utiliser des couches de conteneur pendant leur processus de construction pour inclure des dépendances.

Pas à l'heure actuelle. Votre image, une fois déployée sur AWS Lambda, sera immuable. Le service ne corrigera pas l'image et ne la mettra pas à jour. Cependant, AWS Lambda publiera des images de base organisées pour tous les environnements d'exécution pris en charge basés sur l'environnement géré Lambda. Ces images publiées seront corrigées et mises à jour avec les mises à jour des environnements d'exécution gérés par AWS Lambda. Vous pouvez extraire et utiliser la dernière image de base de DockerHub ou Amazon ECR Public, recréer votre image de conteneur et la déployer sur AWS Lambda via Amazon ECR. Cela vous permet de créer et de tester les images et les environnements d'exécution mis à jour avant de déployer l'image en production.

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.

Non. AWS Lambda garantit que les profils de performance pour les fonctions empaquetées sous forme d'images de conteneur sont les mêmes que pour celles empaquetées dans des archives ZIP, y compris généralement des temps de démarrage inférieurs à la seconde.

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.

L'API Lambda Runtime du service Lambda en cours d'exécution accepte les événements JSON et renvoie des réponses. L'émulateur d'interface d'exécution Lambda permet à la fonction conditionnée en tant qu'image de conteneur d'accepter les requêtes HTTP lors des tests locaux avec des outils tels que cURL, et de les transmettre localement via la même interface à la fonction. Il vous permet d'utiliser la commande docker run ou docker-compose up pour tester localement votre application lambda.

Vous pouvez utiliser l'émulateur pour vérifier que votre code de fonction est compatible avec l'environnement Lambda, s'exécute correctement et fournit la sortie attendue. Par exemple, vous pouvez simuler des événements de test provenant de différentes sources d'événements. Vous pouvez également l'utiliser pour tester les extensions et les agents intégrés dans l'image du conteneur par rapport à l'API des extensions Lambda.

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 Lambda SnapStart pour Java offre des performances de démarrage de fonction jusqu'à 10 fois plus rapides. Pour les fonctions à la demande, la phase d'initialisation (où AWS Lambda charge le code de la fonction et initialise les dépendances externes) est le plus grand contributeur à la latence de démarrage, et se produit lors de la première invocation. Avec Lambda SnapStart, Lambda initialise le code de la fonction d'initialisation unique à l'avance lorsque vous publiez une version de la fonction, au lieu d'invoquer la fonction pour la première fois. Ensuite, Lambda prend un instantané et met en cache l'état de la mémoire et du disque de l'environnement d'exécution initialisé. Lorsque vous invoquez la fonction, et au fur et à mesure de son augmentation, Lambda reprend la fonction à partir de l'instantané mis en cache au lieu d'initialiser la fonction depuis le début.

Lambda SnapStart est une configuration simple au niveau de la fonction qui peut être configurée pour les fonctions Java 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 Java à atteindre des temps de démarrage jusqu'à 10 fois plus rapides, en réduisant la latence variable encourue pendant l'exécution du code d'initialisation unique. Lambda SnapStart fonctionne de manière générale sur toutes les fonctions de votre application ou de votre compte, sans coût supplémentaire. Lorsqu'un client publie une version de fonction avec Lambda SnapStart, le code de la fonction est initialisé à l'avance, au lieu d'être initialisé lors de la première invocation. Puis, Lambda prend un instantané de l'environnement d'exécution initialisé et l'intègre dans un cache à plusieurs niveaux pour un accès à faible latence. Lorsque la fonction est invoquée pour la première fois, puis mise à l'échelle, Lambda reprend la fonction à partir de l'instantané mis en cache au lieu de l'initialiser à partir de zéro, ce qui entraîne une latence de démarrage plus faible. 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 l'exécution Java 11. Les futures versions de Java 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.

Non. Lambda SnapStart et PC ne peuvent pas être activés en même temps, sur la même fonction.

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.

Non. Pour l'instant, vous ne pouvez configurer Lambda SnapStart que pour les fonctions exécutées sur une architecture x86.

Non. Pour le moment, vous ne pouvez pas activer Lambda SnapStart avec Amazon EFS.

Non. Pour le moment, vous ne pouvez pas activer Lambda SnapStart avec un stockage éphémère (/tmp) supérieur à 512 Mo.

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.

Non. L'activation de Lambda SnapStart n'entraîne pas de coût supplémentaire. Vous êtes facturé en fonction du nombre de requêtes pour vos fonctions et de la durée d'exécution de votre code, sur la base de la tarification Lambda actuelle. Les frais de durée s'appliquent au code qui s'exécute dans le gestionnaire d'une fonction et aux crochets d'exécution, ainsi qu'au code d'initialisation qui est déclaré en dehors du gestionnaire. Veuillez noter qu'AWS Lambda peut périodiquement recycler les environnements d'exécution avec des correctifs de sécurité, et réexécuter votre code d'initialisation. Pour plus de détails, consultez la documentation Modèle de programmation Lambda.

Avec Lambda SnapStart, Lambda conserve un instantané de l'environnement d'exécution initialisé pour les trois dernières versions de fonctions publiées, tant que les versions publiées continuent à recevoir des invocations. L'instantané associé à une version de 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.

La durée maximale d'initialisation autorisée pour Lambda SnapStart correspondra à la durée du délai d'exécution que vous avez configurée pour votre fonction. Le délai d'exécution maximal configurable pour une fonction est de 15 minutes.

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.

Vous n'avez pas besoin d'apporter de modifications à votre code pour utiliser la simultanéité allouée. Elle fonctionne de manière harmonieuse avec toutes les fonctions et durées d'exécution existantes. Il n'y a aucun changement au modèle d'appel et d'exécution de Lambda lors de l'utilisation de la simultanéité allouée.

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.

La simultanéité allouée est idéale pour la création d'applications sensibles à la latence comme les backends Web ou mobiles, les API appelées de manière synchrone et les microservices interactifs. Vous pouvez facilement configurer le niveau appropriée de simultanéité en fonction de la demande unique de votre application. Vous pouvez augmenter le niveau de simultanéité pendant les périodes de forte demande. Vous pouvez aussi diminuer ce niveau ou désactiver totalement la simultanéité lorsque la demande diminue.

Si la simultanéité d'une fonction atteint le niveau configuré, les appels ultérieurs de la fonction ont les caractéristiques de latence et d'échelle des fonctions lambda normales. Vous pouvez limiter votre fonction au niveau configuré. Ceci empêche la fonction de dépasser le niveau configuré de simultanéité allouée. Il s'agit d'un mécanisme qui permet d'éviter une variabilité indésirable de votre application lorsque la demande dépasse le niveau prévu.

AWS Lambda vous permet d'exécuter vos fonctions sur des processeurs basés sur x86 ou sur Arm. Les processeurs AWS Graviton2 sont personnalisés par Amazon Web Services à l'aide de cœurs Arm Neoverse 64 bits, afin de fournir un meilleur rapport prix/performances pour les applications cloud. Les clients bénéficient des mêmes avantages d'AWS Lambda, à savoir : exécution du code sans allouer ni gérer de serveurs, scalabilité automatique, haute disponibilité et tarification des ressources à l'utilisation.

Axées sur une architecture de processeurs basés sur Arm développée par AWS, les fonctions AWS Lambda à technologie de processeurs Graviton2 sont conçues pour fournir jusqu'à 34 % de rapport prix/performances en plus par rapport aux fonctions exécutées sur les processeurs x86. Cette amélioration couvre une variété d'applications sans serveur, telles que les backends web et mobiles, les données et le traitement des flux. Avec une latence réduite, jusqu'à 19 % de performances en plus, 20 % de réduction des coûts et le meilleur ratio puissance/efficacité actuellement disponible chez AWS, les fonctions Graviton2 peuvent alimenter les applications sans serveur stratégiques. Les clients peuvent configurer les fonctions existantes et nouvelles afin de cibler le processeur Graviton2. Ils peuvent déployer les fonctions qui s'exécutent sur Graviton2 en tant que fichiers zip ou images de conteneurs.

Vous pouvez configurer les fonctions de façon qu'elles s'exécutent sur Graviton2 via la console de gestion AWS, l'API AWS Lambda, AWS CLI et AWS CloudFormation,et ce en paramétrant l'indicateur d'architecture sur « arm64 » pour votre fonction.

Il n'y a aucun différence de déploiement entre les fonctions basées sur x86 et celles basées sur Arm. Téléchargez simplement votre code via la console de gestion AWS, le fichier zip ou l'image de conteneurs, et AWS Lambda exécute automatiquement le code en cas de déclenchement, sans que vous ayez besoin d'allouer ni de gérer l'infrastructure.

Une application peut contenir des fonctions qui s'exécutent sur les deux architectures. AWS Lambda vous permet de modifier l'architecture (« x86_64 » ou « arm64 ») de la version actuelle de votre fonction. Une fois que vous créez une version spécifique de votre fonction, l'architecture ne plus être modifiée.

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.

Non. Chaque version de fonction peut utiliser uniquement une seule image de conteneur.

Oui. Les couches et extensions peuvent être ciblées sur des architectures compatibles « x86_64 » ou « arm64 ». L'architecture par défaut pour les fonctions et les couches est « x86_64 ».

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.

Les fonctions AWS Lambda à technologie de processeurs AWS Graviton2 sont 20 % plus économiques que les fonctions Lambda basées sur x86. L'offre gratuite Lambda s'applique aux fonctions AWS Lambda à technologie d'architecture basée sur x86 et Arm.

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.

Avec Amazon Elastic File System (Amazon EFS) pour AWS Lambda, les clients peuvent lire, écrire et conserver en toute sécurité de gros volumes de données à pratiquement n'importe quelle échelle en utilisant un système de fichiers NFS élastique entièrement géré qui peut évoluer à la demande sans qu'il soit nécessaire de provisionner ou de gérer les capacités. Auparavant, les développeurs ajoutaient à leurs fonctions un code permettant de télécharger les données à partir de S3 ou des bases de données vers un stockage temporaire local, limité à 512 Mo. Avec EFS pour Lambda, les développeurs n'ont pas à écrire de code pour télécharger des données vers un stockage temporaire afin de les traiter.

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.

Oui. Les cibles de montage pour Amazon EFS sont associées à un sous-réseau dans un VPC. La fonction AWS Lambda doit être configurée pour accéder à ce VPC.

L'utilisation d'EFS pour Lambda est idéale pour créer des applications de machine learning ou charger des fichiers ou des modèles de référence volumineux, traiter ou sauvegarder de grandes quantités de données, héberger du contenu web ou développer des systèmes de génération internes. Les clients peuvent également utiliser EFS pour Lambda pour maintenir l'état entre les appels au sein d'une architecture de microservices avec état ou dans un flux Step Functions, ou pour partager des fichiers entre des applications sans serveur et des applications basées sur des instances ou des conteneurs.

Oui. Le chiffrement des données en transit utilise le protocole Transport Layer Security (TLS) 1.2, standard pour chiffrer les données envoyées entre les fonctions AWS Lambda et le systèmes de fichiers Amazon EFS.

Les clients peuvent provisionner Amazon EFS pour chiffrer les données au repos. Les données chiffrées au repos le sont de manière transparente lorsqu'elles sont écrites et déchiffrées de la même manière lorsqu'elles sont lues afin de ne pas avoir à modifier vos applications. Les clés de chiffrement sont gérées par AWS Key Management Service (KMS), ce qui élimine le besoin de concevoir et de maintenir une infrastructure de gestion clé sécurisée.

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.

Non. Chaque fonction Lambda pourra accéder à un seul système de fichiers EFS.

Oui. Amazon EFS prend en charge les fonctions Lambda, les conteneurs ECS et Fargate et les instances EC2. Vous pouvez partager le même système de fichiers et utiliser une stratégie IAM et des points d'accès pour contrôler ce à quoi chaque fonction, conteneur ou instance a accès.  

Oui. Les fonctions Lambda peuvent être configurées à l'aide de l'URL d'une fonction, d'un point de terminaison HTTPS intégré qui peut être appelé à l'aide du navigateur, de curl et d'un client HTTP. Les URL de fonctions constituent un moyen facile de créer des fonctions accessibles par HTTPS.

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.

Les URL de fonctions Lambda sont sécurisées par défaut avec l'autorisation IAM. Vous pouvez choisir de désactiver l'autorisation IAM pour créer un point de terminaison public ou si vous envisagez d'implémenter une autorisation personnalisée dans le cadre de la logique métier de la fonction.

Vous pouvez facilement appeler votre fonction à partir de votre navigateur web en accédant à l'URL de fonction Lambda, à partir du code de votre application client en utilisant une bibliothèque HTTP, ou à partir de la ligne de commande en utilisant curl.

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.

Les URL de fonctions ne prennent pas actuellement en charge les noms de domaines personnalisés. Vous pouvez utiliser un domaine personnalisé avec l'URL de votre fonction en créant une distribution Amazon CloudFront et un CNAME pour mapper votre domaine personnalisé au nom de votre distribution CloudFront. Ensuite, mappez le nom de domaine de votre distribution CloudFront de sorte qu'il soit acheminé vers l'URL de votre fonction en tant qu'origine.

Oui, les URL de fonctions Lambda peuvent être utilisées pour appeler une fonction dans un VPC.

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.

AWS Lambda est conçu pour fournir, via la réplication et la redondance, une haute disponibilité à la fois pour le service lui-même et pour les fonctions qu'il exploite. Il n'y a ni fenêtres de maintenance ni arrêts programmés.

Oui. Lors de la mise à jour d'une fonction Lambda, un petit laps de temps, généralement inférieur à une minute, se produit lorsque les requêtes peuvent être distribuées via l'ancienne ou la nouvelle version de votre fonction.

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.

En cas d'échec, les fonctions Lambda étant appelées de façon synchrone répondront via une exception. Les fonctions Lambda invoquées de manière asynchrone donnent lieu à au moins 3 nouvelles tentatives. 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. Les flux Kinesis et DynamoDB conservent les données pendant 24 heures minimum.

Vous pouvez configurer une file d'attente Amazon SQS ou une rubrique Amazon SNS en tant que file d'attente de lettre morte.

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.

Les contrôles d'accès peuvent être gérés par le rôle de la fonction Lambda ou par un paramètre de politique de ressource sur la file d'attente elle-même. Si les deux politiques sont présentes, la plus restrictive des deux autorisations s'applique.

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.

Vous pouvez activer la signature de code en créant une configuration de signature de code via AWS Management Console, l'API Lambda, l'AWS CLI, AWS CloudFormation et AWS SAM. Code Signing Configuration vous aide à spécifier les profils de signature approuvés et à configurer s'il faut avertir ou rejeter les déploiements si les vérifications de signature échouent. Les Code Signing Configuration peuvent être associées à des fonctions Lambda individuelles pour activer la fonction de signature de code. Ces fonctions commencent maintenant à vérifier les signatures lors du déploiement.

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 .

Vous pouvez le faire à l'aide de la console AWS Lambda, de l'API Lambda, de l'AWS CLI, de AWS CloudFormation et d'AWS SAM. Vous pouvez le faire à l'aide de la console AWS Lambda, de l'API Lambda, de l'AWS CLI, de AWS CloudFormation et d'AWS SAM.

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.

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.

Lambda utilise la version Amazon Linux d'OpenJDK 1.8.

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.

Oui. Vous pouvez utiliser pip pour installer tous les packages Python nécessaires.

Vous pouvez créer une fonction C# Lambda à l'aide d'un IDE Visual Studio en sélectionnant « Publish to AWS Lambda » (Publier dans AWS Lambda) dans l'explorateur de solutions. Autrement, vous pouvez exécuter directement la commande « dotnet lambda publish » depuis la CLI dotnet sur laquelle le [patch d'outils CLI C# Lambda] est installé. Un fichier ZIP de votre code source C# est alors créé avec toutes les dépendances NuGet et vos ensembles DLL publiés. Il est ensuite automatiquement téléchargé vers AWS Lambda à l'aide du paramètre d'exécution « dotnetcore1.0 »

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. 

Pour déployer une fonction Lambda écrite en Ruby, créez un package comprenant votre code et vos gemmes Ruby sous la forme d’un ZIP. Vous pouvez charger le fichier ZIP depuis votre environnement local ou spécifier un emplacement Amazon S3 où enregistrer le fichier ZIP.

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.

AWS Lambda est intégré à AWS CloudTrail. AWS CloudTrail peut enregistrer et transmettre des fichiers journaux à votre compartiment Amazon S3 qui décrivent l'utilisation de l'API de votre compte.

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.

Oui, AWS Lambda prend en charge le jeu d'instructions Advanced Vector Extensions 2 (AVX2). Pour en savoir plus sur la façon de compiler votre code d'application pour cibler cet ensemble d'instructions afin d'améliorer les performances, consultez la documentation du développeur AWS Lambda.