FAQ sur AWS Lambda 

Q : Qu'est-ce qu'AWS Lambda ?

AWS Lambda vous permet d'exécuter du code sans avoir à mettre en service ou gérer des serveurs. Vous payez uniquement pour le temps de calcul consommé, il n'y a aucun frais lorsque votre code n'est pas exécuté. Avec Lambda, vous pouvez exécuter du code pour pratiquement n'importe quel type d'application ou backend, sans aucune tâche administrative. Il vous suffit de charger votre code, et Lambda fait le nécessaire pour l'exécuter et le mettre à l'échelle en assurant une haute disponibilité. Vous pouvez configurer votre code de sorte qu'il se déclenche automatiquement depuis d'autres services AWS, ou l'appeler directement à partir de n'importe quelle application Web ou mobile.

Q : Qu'est-ce que le calcul sans serveur ?

Le calcul sans serveur permet de concevoir et d'exécuter des applications et des services sans se soucier des serveurs. Avec le calcul sans serveur, votre application s'exécute toujours sur des serveurs, mais la gestion des serveurs est effectuée par AWS. Au cœur du calcul sans serveur se trouve AWS Lambda, qui vous permet d'exécuter votre code sans mettre en service ou gérer de serveurs.

Q : Quels sont les événements qui peuvent déclencher une fonction AWS Lambda ?

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

Q : Dans quels cas dois-je utiliser AWS Lambda plutôt qu'Amazon EC2 ?

Amazon Web Services propose un ensemble de services de calcul pour répondre à toute une variété de besoins.

Amazon EC2 offre la flexibilité, avec un large éventail de types d'instances et la possibilité de personnaliser le système d'exploitation, le réseau, les paramètres de sécurité et la totalité de la pile logicielle, vous permettant ainsi de déplacer aisément des applications existantes vers le cloud. Grâce à Amazon EC2, vous gérez le dimensionnement des capacités, la surveillance de l'état de santé et des performances de la flotte, ainsi que la conception de la tolérance aux pannes et de l'évolutivité. AWS Elastic Beanstalk offre un service facile à utiliser pour déployer et mettre à l'échelle des applications Web dans lesquelles vous conservez la propriété et le contrôle total sur les instances EC2 sous-jacentes. Amazon EC2 Container Service est un service de gestion de conteneurs évolutif qui prend en charge les conteneurs Docker et vous permet d'exécuter facilement des applications distribuées sur un cluster géré d'instances Amazon EC2.

AWS Lambda facilite l'exécution du code en réponse à des événements tels que des modifications de compartiments Amazon S3, des mises à jour de tables Amazon DynamoDB, ou encore des événements personnalisés générés par vos applications ou vos appareils. Grâce à Lambda, vous n'avez pas à allouer vos propres instances. Lambda effectue toutes les activités opérationnelles et administratives à votre place, y compris l'allocation de capacité, le contrôle de l'état de santé de la flotte, l'application des correctifs de sécurité aux ressources de calcul sous-jacentes, le déploiement de votre code, l'exécution d'un service Web frontal, ainsi que le contrôle et la journalisation de votre code. AWS Lambda offre à une mise à l'échelle simple et une haute disponibilité sans aucun effort supplémentaire de votre part.

Q : Quel type de code peut-on exécuter sur AWS Lambda ?

AWS Lambda vous permet d'effectuer très facilement de nombreuses tâches dans le cloud. Par exemple, vous pouvez utiliser AWS Lambda pour concevoir des back-end mobiles qui récupèrent et transforment des données d'Amazon DynamoDB, des gestionnaires qui compressent ou transforment des objets dès lors qu'ils sont chargés dans Amazon S3, pour effectuer un audit et publier des appels d'API effectués vers n'importe quelle offre Amazon Web Service, et pour procéder au traitement sans serveur de données diffusées en continu à l'aide d'Amazon Kinesis.

Q : Quels sont les langages pris en charge par AWS Lambda ?

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

Q : Puis-je accéder à l'infrastructure sur laquelle AWS Lambda s'exécute ?

Non. AWS Lambda gère l'infrastructure de calcul à votre place, lui permettant d'effectuer des vérifications de l'état de santé, d'appliquer des correctifs de sécurité et de réaliser d'autres opérations de maintenance quotidienne.

Q : Comment AWS Lambda isole-t-il mon code ?

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

Q : Comment AWS Lambda sécurise-t-il mon code ?

AWS Lambda stocke le code dans Amazon S3 et le chiffre au repos. AWS Lambda effectue des vérifications d'intégrité supplémentaires pendant l'utilisation de votre code.

Q : Quelles sont les régions AWS disponibles pour AWS Lambda ?

Consultez le tableau des régions de l'infrastructure mondiale AWS.

Q : Qu'est-ce qu'une fonction 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.

Q : AWS Lambda réutilise-t-il les instances des fonctions ?

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 AWS Lambda réutilise les instances des fonctions, consultez notre documentation. Votre code ne doit pas supposer que cela sera toujours le cas.

Q : Que se passe-t-il si j’ai besoin d'espace disque temporaire pour ma fonction 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 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.

Q : Comment configurer mon application pour utiliser le magasin éphémère 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.

Q : Le magasin éphémère AWS Lambda est-il chiffré ?

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.

Q : Quelles métriques puis-je utiliser pour surveiller mon utilisation du magasin éphémère 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.

Q : Quand dois-je utiliser le magasin éphémère Amazon S3, Amazon EFS ou AWS Lambda pour mes applications sans serveur ?

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.

Q : Puis-je utiliser le magasin éphémère alors que la Simultanéité provisionnée est activée pour ma fonction ?

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.

Q : Comment configurer mon application pour utiliser le magasin éphémère 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.

Q : Le magasin éphémère AWS Lambda est-il chiffré ?

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.

Q : Quelles métriques puis-je utiliser pour surveiller mon utilisation du magasin éphémère 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.

Q : Pourquoi les fonctions AWS Lambda doivent-elles être sans état ?

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.

Q : Puis-je utiliser des threads et des processus dans le code de ma fonction AWS Lambda ?

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.

Q : Quelles restrictions s'appliquent aux codes de fonction AWS Lambda ?

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 contre le courrier indésirable, le trafic du port TCP 25 est également bloqué.

Q : Comment créer une fonction AWS Lambda à l'aide de la console Lambda ?

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.

Q : Comment créer une fonction AWS Lambda à l'aide de l'interface de ligne de commande Lambda ?

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 Manuel de mise en route Lambda pour démarrer.

Q : AWS Lambda prend-il en charge les variables d'environnement ?

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.

Q : Puis-je stocker des informations sensibles dans des variables d'environnement ?

Pour les informations sensibles tels 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 de chiffrement 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.

Q : Comment gérer mes fonctions AWS Lambda ?

Vous pouvez facilement référencer, supprimer, mettre à jour et surveiller vos fonctions Lambda à l'aide du tableau de bord de la console AWS Lambda. Vous pouvez également utiliser l'interface de ligne de commande et le SDK AWS pour gérer vos fonctions Lambda. Pour en savoir plus, consultez le manuel Lambda Developer Guide.

Q : Est-ce que je peux partager du code entre des fonctions ?

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.

Q : Comment surveiller une fonction AWS Lambda ?

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.

Q : Comment résoudre les problèmes de défaillance d'une fonction AWS 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.

Q : Comment mettre à l'échelle une fonction AWS Lambda ?

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.

Q : Comment s'effectue l'attribution de ressources de calcul à une fonction AWS Lambda ?

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

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

Q: Quand dois-je utiliser les fonctions AWS Lambda avec plus de 3008 Mo de mémoire?

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.

Q : Quel est le temps d'exécution maximal d'une fonction AWS Lambda ?

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.

Q : Comment l'utilisation des fonctions AWS Lambda est-elle facturée ?

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

Q : Est-ce que je peux économiser de l'argent sur AWS Lambda avec Compute Savings Plan ?

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.

Q : AWS Lambda prend-il en charge la gestion des versions ?

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.

Q : Combien de temps après le chargement de mon code serai-je en mesure d'appeler ma fonction AWS Lambda ?

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.

Q : Puis-je utiliser ma propre version d'une des bibliothèques compatibles ?

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.

Q : Comment la tarification progressive fonctionne-t-elle ?

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.

Q : Puis-je tirer parti à la fois de la tarification progressive et des Compute Savings Plans ?

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.

Q : Qu'est-ce qu'une source d'événement ?

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 interroger les enregistrements d'un flux Amazon Kinesis ou d'une file d'attente Amazon SQS et exécuter une fonction Lambda pour chaque message rapporté.

Beaucoup d'autres services, comme AWS CloudTrail, peuvent agir en tant que sources d'événements en se connectant tout simplement à Amazon S3 et en utilisant les notifications de compartiments S3 pour déclencher les fonctions AWS Lambda.

Q : Quelles sont les sources d'événements utilisables avec AWS Lambda ?

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

Q : Comment les événements sont-ils représentés dans AWS Lambda ?

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.

Q : Comment faire en sorte qu'une fonction AWS Lambda réagisse à des modifications dans un compartiment (bucket) Amazon S3 ?

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.

Q : Comment faire en sorte qu'une fonction AWS Lambda réagisse à des mises à jour dans une table Amazon DynamoDB ?

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.

Q : Comment utiliser une fonction AWS Lambda pour traiter des enregistrements dans un flux Amazon Kinesis ?

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.

Q : De quelle façon AWS Lambda traite-t-il les données des Amazon Kinesis Streams et Amazon DynamoDB ?

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 entre différentes partitions n'est pas garanti et le traitement de chaque partition se déroule en parallèle.

Q : Comment choisir entre AWS Lambda et le service géré Amazon pour Apache Flink pour mes besoins d'analyse ?

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. Le service géré Amazon pour Apache Flink 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 robuste 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.

Q : Comment utiliser une fonction AWS Lambda pour répondre aux notifications envoyées par Amazon Simple Notification Service (SNS) ?

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.

Q : Comment utiliser une fonction AWS Lambda pour réagir aux e-mails envoyés par Amazon Simple Email Service (SES) ?

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.

Q : Comment utiliser une fonction AWS Lambda pour réagir à des alarmes Amazon CloudWatch ?

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 manuel Amazon CloudWatch Developer Guide pour découvrir comment configurer des alarmes Amazon CloudWatch.

Q : Comment utiliser une fonction AWS Lambda pour répondre aux changements de données de l'utilisateur ou du périphérique gérées par Amazon Cognito ?

Depuis la console AWS Lambda, vous pouvez sélectionner une fonction qui doit être déclenchée lorsque des ensembles de données associés à un pool 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.

Q : Comment mon application peut-elle déclencher directement une fonction AWS Lambda ?

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.

Q : Quelle est la latence suite à l'appel d'une fonction AWS Lambda en réponse à un événement ?

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.

Q : Comment créer un backend mobile à l'aide d'AWS 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 le kit SDK AWS Mobile, consultez la page Kit SDK AWS Mobile. Pour en savoir plus sur Amazon API Gateway, consultez la page Amazon API Gateway.

Q : Comment appeler une fonction AWS Lambda par HTTPS ?

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 de détails sur l'utilisation d'AWS Lambda avec Amazon API Gateway.

Q : Comment ma fonction AWS Lambda peut-elle personnaliser son comportement sur l'appareil et l'application qui effectuent la demande ?

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

Q : Comment ma fonction AWS Lambda peut-elle personnaliser son comportement en fonction de l'identité de l'utilisateur final d'une application ?

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.

Q : Comment créer une skill Alexa à l'aide d'AWS Lambda ?

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.

Q : Que se passe-t-il en cas de défaillance de ma fonction pendant le traitement d'un événement ?

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.

Q : Qu'est-ce qu'une application sans serveur ?

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.

Q : Comment déployer et gérer une application sans serveur ?

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.

Q : Comment découvrir des applications sans serveur existantes développées par la communauté AWS ?

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.

Q : Comment automatiser le déploiement d'une application sans serveur ?

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.

Q : Comment commencer à concevoir une application sans serveur ?

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.

Q : Comment coordonner les appels entre plusieurs fonctions AWS Lambda ?

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.

Q : Comment réparer une application sans serveur ?

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.

Q. Puis-je créer des applications sans serveur qui se connectent à des bases de données relationnelles ?

Oui. Vous pouvez créer des applications sans serveur hautement scalables, sécurisées et basées sur Lambda qui se connectent aux bases de données relationnelles en utilisant Amazon RDS Proxy, 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 de RDS Proxy.

Q : Quel est le modèle de licences pour AWS SAM ?

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.

Q: Qu'est-ce que la prise en charge des images de conteneurs pour AWS Lambda?

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.

Comment puis-je utiliser Container Image Support pour AWS Lambda?

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 .

Q: Quels types d'images de conteneur sont pris en charge?

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.

Q: Quelles images de base puis-je utiliser?

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.

Q: Quels outils de conteneur puis-je utiliser pour empaqueter et déployer des fonctions sous forme d'images de conteneur?

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.

Q: Q: Quelles fonctionnalités AWS Lambda sont disponibles pour les fonctions déployées en tant qu'images de conteneur?

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.

Q: AWS Lambda corrigera-t-il l'image de mon conteneur déployé et la mettra-t-il à jour ?

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.

Q: Quelles sont les différences entre les fonctions créées à l'aide d'archives ZIP et d'images de conteneurs?

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.

Q: Y a-t-il une différence de performances entre les fonctions définies en tant qu'images zip et conteneur ?

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.

Q: Comment serai-je facturé pour le déploiement des fonctions Lambda en tant qu'images de conteneur ?

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.

Q: Qu'est-ce que l'émulateur d'interface d'exécution Lambda (RIE)?

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.

Q: Pourquoi ai-je besoin de l'émulateur d'interface d'exécution Lambda (RIE) pendant les tests locaux?

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.

Q: Quels comportements de fonction puis-je tester localement avec l'émulateur ?

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.

Q: Comment l'émulateur d'interface d'exécution (RIE) m'aide-t-il à exécuter mon image compatible Lambda sur des services de calcul supplémentaires?

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.

Q: Comment puis-je déployer mon application conteneurisée existante sur AWS Lambda?

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.
   

Q : Qu’est-ce que la simultanéité allouée d’AWS Lambda ?

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.

Q : Comment puis-je configurer et gérer la simultanéité allouée ?

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.

Q : Dois-je changer mon code si je veux utiliser la simultanéité allouée ?

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.

Q : Comment serai-je facturé pour 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.

Q : Dans quelles circonstances puis-le utiliser la simultanéité allouée ?

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.

Q : Que se passe-t-il si une fonction reçoit des appels supérieurs au niveau de simultanéité allouée défini ?

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.

Q : Qu'est-ce que les fonctions AWS Lambda à technologie de processeurs Graviton2 ?

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.

Q : Pourquoi devrais-je utiliser les fonctions AWS Lambda à technologie de processeurs Graviton2 ?

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.

Q : Comment configurer mes fonctions de sorte qu'elles s'exécutent sur les processeurs Graviton2 ?

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.

Q : Comment déployer mon application créée à l'aide de fonctions à technologie de processeurs Graviton2 ?

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.

Q : Une application peut-elle utiliser les fonctions à technologie de processeurs Graviton2 et de processeurs x86 ?

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.

Q : Le service AWS Lambda prend-il en charge les images de conteneurs multi-architectures ?

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

Q : Puis-je créer des couches AWS Lambda qui ciblent les fonctions à technologie de processeurs AWS Graviton2 ?

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

Q : Quels langages et exécutions sont-ils pris en charge par les fonctions Lambda qui s'exécutent sur des processeurs Graviton2 ?

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.

Q : Quelle est la tarification des fonctions AWS Lambda à technologie de processeurs AWS Graviton2 ? L'offre gratuite AWS Lambda s'applique-t-elle aux fonctions à technologie de processeurs Graviton2 ?

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.

Q : Comment choisir entre exécuter mes fonctions sur les processeurs Graviton2 et les exécuter sur x86 ?

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.

Q : Ai-je besoin d'une machine de développement basée sur Arm pour créer et tester des fonctions à technologie de processeurs Graviton2 localement ?

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.

Q : Qu’est-ce qu’Amazon EFS pour AWS Lambda ?

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.

Q : Comment configurer Amazon EFS pour Lambda ?

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.

Q : Dois-je configurer ma fonction avec des paramètres VPC avant de pouvoir utiliser mon système de fichiers EFS Amazon ?

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.

Q : À qui s’adresse Amazon EFS pour Lambda ?

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.

Q : Mes données seront-elles chiffrées en transit ?

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.

Q : Mes données sont-elles chiffrées au repos ?

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.

Q : Combien me coûtera EFS pour AWS Lambda ?

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.

Q : Puis-je associer plusieurs systèmes de fichiers Amazon EFS avec ma fonction AWS Lambda ?

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

Q : Puis-je utiliser le même système de fichiers Amazon EFS sur plusieurs fonctions, conteneurs ou instances ?

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.  

Q : Que sont les extensions AWS Lambda ?

Les extensions AWS Lambda vous permettent d'intégrer Lambda à vos outils préférés de surveillance, d'observabilité, de sécurité et de gouvernance. Les extensions vous permettent, à vous et aux fournisseurs de vos outils préférés, de vous connecter au cycle de vie de Lambda et de vous intégrer plus profondément dans l'environnement d'exécution Lambda.

Q : Comment fonctionnent les extensions Lambda ?

Les extensions Lambda sont des processus compagnons qui s'exécutent dans l'environnement d'exécution Lambda, dans lequel est exécuté le code de votre fonction. De plus, elles peuvent s'exécuter en dehors de l'invocation de fonction : elles démarrent avant l'initialisation de la fonction, s'exécutent en parallèle de la fonction, peuvent s'exécuter après l'exécution de la fonction, et peuvent également s'exécuter avant que le service Lambda n'arrête l'environnement d'exécution.

Q : Dans quels cas est-il possible d'utiliser les extensions Lambda ?

Vous pouvez utiliser les extensions pour les outils de surveillance, d'observabilité, de sécurité et de gouvernance développés par AWS ainsi que les partenaires suivants : AppDynamics, Coralogix, Datadog, Dynatrace, Epsagon, HashiCorp, Honeycomb, Imperva, Lumigo, Check Point CloudGuard, New Relic, Thundra, Splunk, Sentry, Site24x7, Sumo Logic, AWS AppConfig, Amazon CodeGuru Profiler, Amazon CloudWatch Lambda Insights, AWS Distro for OpenTelemetry. Pour en savoir plus sur ces extensions, consultez l' article de blog de lancement.

Q : Comment installer et gérer les extensions Lambda ?

Vous pouvez déployer les extensions par couches sur une ou plusieurs fonctions Lambda via la console, l'interface de ligne de commande (CLI) ou des outils d'Infrastructure en tant que code tels que CloudFormation, le modèle d'application sans serveur AWS et Terraform. Pour démarrer, consultez la documentation.

Q : Avec quels environnements d'exécution puis-je utiliser les extensions AWS Lambda ?

Vous pouvez consulter la liste des environnements d'exécution qui prennent en charge ces extensions ici.

Q : Les extensions sont-elles comptabilisées dans la limite de taille du package de déploiement ?

Oui, la taille totale après décompression de la fonction et de toutes les extensions ne peut pas dépasser la limite de taille du package de déploiement fixée à 250 Mo.

Q : L'utilisation d'une extension affecte-t-elle les performances ?

Les extensions peuvent affecter les performances de votre fonction, car elles partagent des ressources comme les CPU, la mémoire et le stockage avec la fonction et parce que les extensions sont initialisées avant le code de la fonction. Par exemple, si une extension effectue de nombreuses opérations de calcul, il est possible que vous observiez une augmentation de la durée d'exécution de la fonction, car l'extension et le code de votre fonction partagent les mêmes ressources CPU. Comme Lambda alloue proportionnellement les processeurs sur la base du paramètre de mémoire que vous choisissez, vous pouvez constater une durée d'exécution et d'initialisation plus importante avec des paramètres de mémoire inférieurs, car plusieurs processus sont en compétition sur les mêmes ressources CPU.

Vous pouvez utiliser la métrique PostRuntimeExecutionDuration pour mesurer le temps supplémentaire pris par l'extension après l'exécution de la fonction, ainsi que la métrique MaxMemoryUsed pour mesurer l'augmentation de la mémoire utilisée. Pour comprendre l'impact d'une extension spécifique, vous pouvez également utiliser la métrique de durée. À l'heure actuelle, la réponse d'exécution de la fonction est retournée après l'exécution de la fonction et l'exécution de l'extension. Pour en savoir plus, consultez la documentation des développeurs Lambda.

Q : Comment l'utilisation des extensions Lambda est-elle facturée ?

Le même modèle de facturation que les fonctions Lambda est appliqué aux extensions. Lorsque vous utilisez les fonctions Lambda avec des extensions, vous payez les demandes traitées et le temps de calcul combiné utilisé pour exécuter votre code et toutes les extensions, par tranche de 1 ms. Vous êtes facturé pour le temps de calcul selon la tarification à la durée Lambda actuellement en vigueur. Pour en savoir plus, consultez la tarification AWS Lambda.

Le cycle de vie de Lambda est composé de trois phases distinctes : « init », lorsqu'AWS Lambda initialise la fonction, les dépendances et les extensions ; « invoke », lorsque Lambda exécute le code de la fonction et des extensions en réponse aux déclencheurs ; et « shut down », après l'exécution de la fonction, mais le code des extensions peut encore être en cours d'exécution, ce qui peut prendre jusqu’à deux secondes. Vous êtes facturé pour le temps de calcul utilisé pour exécuter votre code des extensions aux trois phases du cycle de vie de Lambda. Pour en savoir plus sur le cycle de vie de Lambda, consultez la documentation relative à l'environnement d'exécution Lambda.

L'installation des extensions n'entraîne aucun coût supplémentaire, bien que les offres partenaires puissent être payantes. Consultez les sites Web des partenaires pour plus de détails.

Q : Puis-je créer mes propres extensions Lambda personnalisées ?

Oui, en utilisant l'API AWS Lambda Runtime Extensions. Consultez la documentation pour en savoir plus.

Q : Comment les extensions fonctionnent-elles lorsque la simultanéité allouée est activée ?

La simultanéité allouée garde les fonctions initialisées et prêtes à répondre en quelques dizaines de millisecondes. Lorsqu'elle est activée, la simultanéité allouée initialise également les extensions et les gardes prêtes à s'exécuter avec le code de la fonction.

Q : De quelles autorisations les extensions disposent-elles?

Comme les extensions sont exécutées dans le même environnement qu'une fonction Lambda, elles ont accès aux mêmes ressources que la fonction, et les autorisations sont partagées entre la fonction et l'extension. Elles partagent donc les informations d'identification, le rôle et les variables d'environnement. Les extensions disposent d'un accès en lecture seule au code de la fonction et peuvent lire et écrire dans /tmp.

Q : Qu'est-ce que l'API de télémétrie AWS Lambda ?

L'API de télémétrie AWS Lambda vous permet d'utiliser des extensions pour capturer des données de surveillance et d'observabilité améliorées directement à partir de Lambda et les envoyer à une destination de votre choix.

Q : Comment fonctionne l'API de télémétrie ?

Le service Lambda capture et diffuse automatiquement les données de télémétrie vers Amazon CloudWatch et AWS X-Ray. L'API de télémétrie fournit une interface HTTP ou TCP simple permettant aux extensions pour recevoir les mêmes données de télémétrie ainsi que les événements du cycle de vie de l'environnement d'exécution Lambda, et les mesures au niveau de l'invocation de la fonction. Les extensions peuvent utiliser l'API de télémétrie pour consommer ces flux de télémétrie directement à partir de Lambda, puis les traiter, les filtrer et les envoyer à toute destination préférée.

Q : Comment commencer à utiliser l'API de télémétrie ?

Vous pouvez déployer des extensions compatibles avec l'API de télémétrie pour vos fonctions Lambda à l'aide de l'AWS Lambda Console, de l'AWS CLI ou d'outils Infrastructure as Code tels que AWS CloudFormation, AWS Serverless Application Model (SAM) et Terraform. Vous n'avez pas besoin de modifier le code pour utiliser une extension activée par l'API de télémétrie avec votre fonction Lambda. Il suffit d'ajouter une extension du fournisseur d'outils de votre choix à votre fonction Lambda.  Pour commencer à utiliser les extensions des partenaires APN, suivez les liens fournis dansl'article du blog de lancement. Vous pouvez également créer votre propre extension qui utilise l'API de télémétrie. Pour en savoir plus, consultez le Guide des développeur AWS Lambda.

Q : L'utilisation de l'API de télémétrie a-t-elle un impact sur les performances ?

Vous pouvez uniquement utiliser l'API de télémétrie depuis les extensions AWS Lambda. Les extensions peuvent avoir un impact sur les performances de votre fonction car elles partagent des ressources telles que le processeur, la mémoire et le stockage avec la fonction. L'utilisation de la mémoire augmente linéairement à mesure que le nombre d'abonnements à l'API de télémétrie augmente, car chaque abonnement ouvre un nouveau tampon de mémoire pour stocker les données de télémétrie. Toutefois, vous pouvez optimiser l'utilisation de la mémoire en ajustant la configuration de la mise en mémoire tampon dans la demande d'abonnement à l'API de télémétrie. Nous recommandons aux vendeurs d'extensions de publier la consommation de ressources prévue afin de faciliter le choix d'une extension appropriée par les développeurs de fonctions. Veuillez vous référer à la documentation de votre fournisseur d'extension pour comprendre l'impact potentiel de l'utilisation de son extension sur les performances.

Q : Comment l'utilisation de l'API de télémétrie est-elle facturée ?

L'utilisation de l'API de télémétrie AWS Lambda est disponible sans frais supplémentaire. Les extensions qui utilisent l'API de télémétrie partagent le même modèle de facturation que les autres extensions et fonctions Lambda. Pour en savoir plus sur la tarification des extensions, veuillez consulter lla page des tarifs de Lambda.

Q : L'utilisation de l'API de télémétrie désactive-t-elle l'envoi de journaux à Amazon CloudWatch Logs ?

Non. Par défaut, la plateforme Lambda envoie tous les journaux vers CloudWatch Logs, et l'utilisation de l'API de télémétrie ne désactive pas l'envoi vers CloudWatch Logs.

Q : Les fonctions AWS Lambda prennent-elles en charge les points de terminaison HTTPS ?

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.

Q : Comment puis-je configurer l'URL d'une fonction Lambda pour ma fonction ?

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, reportez-vous à la documentation.

Q : Comment puis-je sécuriser l'URL de ma fonction Lambda ?

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.

Q : Comment appeler ma fonction avec une URL de fonction lambda ?

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.

Q : Les URL de fonctions Lambda fonctionnent-elles avec les versions et les alias des fonctions ?

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.

Q : Puis-je activer des domaines personnalisés pour l'URL de ma fonction Lambda ?

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.

 Q : Les URL de fonctions Lambda peuvent-elles être utilisées pour appeler une fonction dans un VPC ?

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

Q : Quelle est la tarification relative à l'utilisation des URL de fonctions Lambda ?

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.

Q : Qu'est-ce que Lambda@Edge ?

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.

Q : Comment utiliser Lambda@Edge ?

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.

Q : Dans quels cas dois-je utiliser Lambda@Edge ?

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

Q : Puis-je déployer mes fonctions Lambda existantes pour l'appel à l'échelle mondiale ?

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.

Q : Quels événements Amazon CloudFront peuvent servir à déclencher mes 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 demande.
• 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.
  

Q : En quoi AWS Lambda@Edge est-il différent d'AWS Lambda dans son utilisation derrière Amazon API Gateway ?

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.

Q : Quelle est la disponibilité des fonctions AWS Lambda ?

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.

Q : Mes fonctions AWS Lambda restent-elles disponibles lorsque je modifie mon code ou sa configuration ?

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.

Q : Peut-on exécuter simultanément autant de fonctions AWS Lambda qu'on le souhaite ?

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. 

Q : Que se passe-t-il si mon compte dépasse la limite par défaut d'exécutions simultanées ?

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 retiennent les données pendant 24 heures.

Q : Les limites maximales d'exécution simultanée par défaut sont-elles appliquées au niveau de chaque fonction ?

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

Q : À quelle vitesse mes fonctions AWS Lambda sont-elles mises à l'échelle ?

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.

Q : Que se passe-t-il en cas de défaillance de ma fonction Lambda pendant le traitement d'un événement ?

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.

Q : Que se passe-t-il si les appels de mes fonctions Lambda épuisent toutes les tentatives disponibles ?

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.

Q : Quelles ressources puis-je configurer en tant que file d'attente de lettre morte pour une fonction Lambda ?

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

Q : Comment puis-je autoriser ma fonction AWS Lambda à accéder à d'autres ressources AWS ?

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.

Q : Comment contrôler les compartiments Amazon S3 à même d'appeler des fonctions 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.

Q : Comment contrôler la table Amazon DynamoDB ou le flux Amazon Kinesis qu'une fonction AWS Lambda peut interroger ?

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 des développeur Lambda.

Q : Comment contrôler la file d'attente Amazon SQS qu'une fonction AWS Lambda peut interroger ?

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.

Q : Comment accéder aux ressources d'Amazon VPC depuis ma fonction AWS 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.

Q: Qu'est-ce que la signature de code pour AWS Lambda?

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.

Q: Comment créer des artefacts de code signés numériquement?

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.

Q: Comment configurer mes fonctions Lambda pour activer la signature de code?

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.

Q : Quelles vérifications de signature AWS Lambda effectue-t-elle 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 .

Q: Puis-je activer la signature de code pour les fonctions existantes?

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.

Q: Y a-t-il des frais supplémentaires liés à l'utilisation de la signature de code pour 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.

Q. Quels contrôles de journalisation avancés sont pris en charge sur Lambda ?

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.

Q. À quelles fins puis-je utiliser les commandes de journalisation avancées ?

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.

Q. Comment utiliser les commandes de journalisation avancées ?

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.

Q. Puis-je utiliser mes propres bibliothèques de journalisation pour générer des journaux structurés JSON pour ma fonction 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.

Q. Comment serai-je facturé pour l'utilisation des commandes de journalisation avancées ?

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.

Q : Comment puis-je compiler ma fonction AWS Lambda en code Java ?

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.

Q : Quel environnement JVM (machine virtuelle Java) Lambda utilise-t-il pour exécuter ma fonction ?

Lambda utilise la version Amazon Linux d'OpenJDK 1.8.

Q : Puis-je utiliser des packages avec AWS Lambda ?

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

Q : Puis-je exécuter d'autres programmes depuis ma fonction AWS Lambda écrite en Node.js ?

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.

Q : Est-il possible d'utiliser des modules natifs avec des fonctions AWS Lambda écrites en Node.js ?

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.

Q : Puis-je exécuter des fichiers binaires avec une fonction AWS Lambda écrite en Node.js ?

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.

Q : Comment déployer un code de fonction AWS Lambda écrit en Node.js ?

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.

Q : Puis-je utiliser des packages Python avec AWS Lambda ?

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

Q : Comment intégrer et déployer une fonction AWS Lambda dans C# ?

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 »

Q : Comment déployer un code de fonction AWS Lambda écrit en PowerShell ?

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.

Q : Comment intégrer et déployer une fonction AWS Lambda dans Go ? 

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. 

Q : Comment déployer un code de fonction AWS Lambda écrit en Ruby ? 

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.

Q : Quelles versions d'Amazon Linux, de Node.js, de Python, de JDK, de .NET Core, des kits SDK et d'autres bibliothèques le service AWS Lambda prend-il en charge ?

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

Q : Puis-je modifier la version d'Amazon Linux ou de tout environnement d'exécution de langage ?

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.

Q : Comment enregistrer et contrôler des appels effectués vers l'API AWS 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.

Q : Comment coordonner les appels entre plusieurs fonctions 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.

Q: AWS Lambda prend-il en charge Advanced Vector Extensions 2 (AVX2)?

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