Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Création de fonctions Lambda avec Node.js

Mode de mise au point
Création de fonctions Lambda avec Node.js - AWS Lambda

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vous pouvez exécuter JavaScript du code avec Node.js dans AWS Lambda. Lambda fournit des environnements d’exécution pour Node.js, qui exécutent votre code afin de traiter des événements. Votre code s'exécute dans un environnement qui inclut le AWS SDK for JavaScript, avec les informations d'identification d'un rôle AWS Identity and Access Management (IAM) que vous gérez. Pour en savoir plus sur les versions du kit SDK incluses dans les environnements d’exécution Node.js, consultez Versions du SDK incluses dans l’environnement d’exécution.

Lambda prend en charge les environnements d’exécution Node.js suivants.

Nom Identifiant Système d’exploitation Date d’obsolescence Créer la fonction de blocage Mettre à jour la fonction de blocage

Node.js 22

nodejs22.x

Amazon Linux 2023

30 avril 2027

1 juin 2027

1 juillet 2027

Node.js 20

nodejs20.x

Amazon Linux 2023

30 avril 2026

1 juin 2026

1 juillet 2026

Node.js 18

nodejs18.x

Amazon Linux 2

1e septembre 2025

1e octobre 2025

1 novembre 2025

Pour créer une fonction Node.js.
  1. Ouvrez la console Lambda.

  2. Sélectionnez Créer une fonction.

  3. Configurez les paramètres suivants :

    • Nom de la fonction : saisissez le nom de la fonction.

    • Environnement d’exécution : choisissez Node.js 22.x.

  4. Sélectionnez Create function (Créer une fonction).

La console crée une fonction Lambda avec un seul fichier source nommé index.mjs. Vous pouvez modifier ce fichier et ajouter d'autres fichiers dans l'éditeur de code intégré. Dans la section DÉPLOYER, choisissez Déployer pour mettre à jour le code de votre fonction. Ensuite, pour exécuter votre code, choisissez Créer un événement de test dans la section ÉVÉNEMENTS DE TEST.

Le fichier index.mjs exporte une fonction nommée handler qui accepte un objet événement et un objet contexte. Il s’agit de la fonction de gestionnaire que Lambda appelle lors de l’appel de la fonction. Le runtime de la fonction Node.js obtient des événements d’invocations à partir de Lambda et les transmet au gestionnaire. Dans la configuration de fonction, la valeur de gestionnaire est index.handler.

Lorsque vous enregistrez votre code de fonction, la console Lambda crée un package de déploiement d’archive de fichiers .zip. Lorsque vous développez votre code de fonction en dehors de la console (à l’aide d’un IDE), vous devez créer un package de déploiement pour charger votre code dans la fonction Lambda.

Le runtime de la fonction transmet un objet de contexte au gestionnaire, en plus de l’événement d’invocation. L’objet de contexte contient des informations supplémentaires sur l’invocation, la fonction et l’environnement d’exécution. Des informations supplémentaires sont disponibles dans les variables d’environnement.

Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs. La fonction runtime envoie les détails de chaque appel à CloudWatch Logs. Il relaie tous les journaux que votre fonction génère pendant l’invocation. Si votre fonction renvoie une erreur, Lambda met en forme l’erreur et la renvoie à l’appelant.

Initialisation de Node.js

Node.js possède un modèle de boucle d’événements exclusif qui rend son comportement d’initialisation différent des autres exécutions. Plus précisément, Node.js utilise un modèle d’I/O non bloquant qui prend en charge les opérations asynchrones. Ce modèle permet à Node.js de fonctionner efficacement pour la plupart des charges de travail. Par exemple, si une fonction Node.js effectue un appel réseau, cette demande peut être désignée comme une opération asynchrone et placée dans une file d’attente de rappel. La fonction peut continuer à traiter d’autres opérations dans la pile d’appels principale sans être bloquée en attendant le retour de l’appel réseau. Une fois l’appel réseau terminé, son rappel est exécuté, puis supprimé de la file d’attente de rappel.

Certaines tâches d’initialisation peuvent s’exécuter de manière asynchrone. L’exécution de ces tâches asynchrones n’est pas garantie avant l’invocation. Par exemple, le code qui effectue un appel réseau pour récupérer un paramètre depuis AWS le Parameter Store peut ne pas être terminé au moment où Lambda exécute la fonction de gestion. Par conséquent, la variable peut être nulle lors d’une invocation. Pour éviter cela, assurez-vous que les variables et autres codes asynchrones sont entièrement initialisés avant de poursuivre le reste de la logique métier principale de la fonction.

Vous pouvez également désigner votre code de fonction comme module ES, ce qui vous permet d’utiliser await au niveau supérieur du fichier, hors du champ d’application de votre gestionnaire de fonctions. Lorsque vous utilisez await chaque Promise, le code d’initialisation asynchrone se termine avant les invocations du gestionnaire, maximisant ainsi l’efficacité de la simultanéité provisionnée dans la réduction de la latence de démarrage à froid. Pour obtenir des informations et un exemple, consultez Utilisation des modules ES Node.js et de premier niveau d’attente dans AWS Lambda.

Désignation d’un gestionnaire de fonctions en tant que module ES

Par défaut, Lambda traite les fichiers portant le suffixe .js comme des modules CommonJS. En option, vous pouvez désigner votre code comme un module ES. Vous pouvez le faire de deux manières : en spécifiant le suffixe type comme module dans le fichier package.json de la fonction, ou en utilisant l’extension de nom de fichier .mjs. Dans la première approche, le code de votre fonction traite tous les fichiers .js comme des modules ES, tandis que dans le second scénario, seul le fichier que vous spécifiez avec .mjs est un module ES. Vous pouvez mélanger les modules ES et les modules CommonJS en les nommant respectivement .mjs et .cjs, car les fichiers .mjs sont toujours des modules ES et les fichiers .cjs sont toujours des modules CommonJS.

Lambda recherche les dossiers dans la variable d’environnement NODE_PATH lors du chargement des modules ES. Vous pouvez charger le AWS SDK inclus dans le runtime à l'aide des import instructions du module ES. Vous pouvez également charger des modules ES à partir de couches.

Versions du SDK incluses dans l’environnement d’exécution

La version du AWS SDK incluse dans le runtime Node.js dépend de la version d'exécution et de votre Région AWS. Pour trouver la version du kit SDK incluse dans l’environnement d’exécution que vous utilisez, créez une fonction Lambda avec le code suivant.

Exemple index.mjs
import packageJson from '@aws-sdk/client-s3/package.json' with { type: 'json' }; export const handler = async () => ({ version: packageJson.version });

Ceci renvoie une réponse au format suivant :

{ "version": "3.632.0" }

Utilisation de keep-alive pour les connexions TCP

L’agent HTTP/HTTPS Node.js par défaut crée une nouvelle connexion TCP pour chaque nouvelle demande. Pour éviter le coût lié à l’établissement de nouvelles connexions, keep-alive est activé par défaut dans l’environnement d’exécution Lambda nodejs18.x et ses versions ultérieures. Keep-alive peut réduire les temps de requête pour les fonctions Lambda qui effectuent plusieurs appels d’API à l’aide du kit SDK.

Pour désactiver keep-alive, consultez la section Réutilisation des connexions avec keep-alive dans le fichier Node.js du guide du développeur du AWS SDK pour 3.x. JavaScript Pour plus d'informations sur l'utilisation de keep-alive, voir HTTP keep-alive est activé par défaut dans le AWS SDK modulaire ou sur le blog des outils de JavaScript développement. AWS

Chargement des certificats CA

Pour les versions de l’environnement d’exécution Node.js antérieures à Node.js 18, Lambda charge automatiquement les certificats CA (autorité de certification) spécifiques à Amazon afin de vous permettre de créer plus facilement des fonctions qui interagissent avec d’autres Services AWS. Par exemple, Lambda inclut les certificats Amazon RDS nécessaires pour valider le certificat d’identité du serveur installé sur votre base de données Amazon RDS. Ce comportement peut avoir un impact sur les performances lors des démarrages à froid.

À partir de Node.js 20, Lambda ne charge plus de certificats CA supplémentaires par défaut. L’exécution Node.js 20 contient un fichier de certificat contenant tous les certificats Amazon CA situés à l’adresse /var/runtime/ca-cert.pem. Pour restaurer le même comportement à partir de Node.js 18 et exécutions antérieures, définissez la variable d’environnement NODE_EXTRA_CA_CERTSsur /var/runtime/ca-cert.pem.

Pour des performances optimales, nous vous recommandons d’effectuer la création d’une offre groupée uniquement pour les certificats dont vous avez besoin avec votre package de déploiement et de les charger via la variable d’environnement NODE_EXTRA_CA_CERTS. Le fichier de certificats doit être composé d’un ou de plusieurs certificats d’autorité de certification racine ou intermédiaire sécurisés au format PEM. Par exemple, pour RDS, incluez les certificats requis à côté de votre code en tant que certificates/rds.pem. Chargez ensuite les certificats en réglant NODE_EXTRA_CA_CERTS sur /var/task/certificates/rds.pem.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.