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.

Runtimes des fonctions Web Lambda

Les fonctions Web Lambda exécutent le code de votre serveur HTTP à l'aide d'environnements d'exécution gérés. Votre application doit démarrer un serveur HTTP qui écoute sur l'hôte et le port spécifiés par la variable d'AWS_LAMBDA_HTTP_ENDPOINTenvironnement. Les fonctions Web Lambda sont actuellement prises en charge. Node.js Par défaut, le moteur d'exécution index.js se charge à la racine du package de déploiement. Pour utiliser un autre fichier d'entrée, définissez la variable d'AWS_LAMBDA_NODEJS_ENTRYPOINTenvironnement. Pour plus de détails, consultez Variables d’environnement.

Pris en charge Node.js versions

Spécifiez l'identifiant d'exécution dans la runtimeConfig section lorsque vous créez une révision. Par exemple :

"runtimeConfig": { "runtime": "nodejs24.x" }

Le moteur d'exécution des fonctions nodejs24.x Web suit le même cycle d'obsolescence que le moteur d'exécution des fonctions d'événement Lambda correspondant. Pour les dates de dépréciation et le processus de dépréciation, voir. politique d’obsolescence de l’exécution

Correctif automatique lors de l'exécution

Lambda corrige automatiquement le Node.js moteur d'exécution avec des mises à jour de sécurité et des corrections de bogues. Les correctifs s'appliquent à la couche d'exécution sous-jacente et ne modifient pas le code de votre application. L'runtimeidentifiant de votre révision (par exemple,nodejs24.x) correspond toujours à la dernière version corrigée de ce moteur d'exécution majeur.

Pour plus d'informations sur la façon dont Lambda gère les mises à jour d'exécution, consultez. Comprendre comment Lambda gère les mises à jour de version de l’environnement d’exécution

Frameworks Web pris en charge

Vous pouvez utiliser n'importe quel framework Node.js Web qui démarre un serveur HTTP. Les frameworks les plus populaires incluent :

Vous n'avez pas besoin de l'adaptateur Event-to-HTTP AWS Lambda Web Adapter ou d'un autre. Votre application gère les requêtes HTTP directement à l'aide du routage standard et du middleware du framework. Certains frameworks, comme Next.js en mode autonome, lisent leurs propres variables d'environnement pour l'adresse d'écoute. Pour ces frameworks, utilisez un fichier index.js d'entrée qui définit ces variables AWS_LAMBDA_HTTP_ENDPOINT avant le démarrage du serveur. Pour plus de détails, consultez Variables d’environnement. Pour une demande complète, voirMinimale Express vigie.

Node.js modèle d'exécution

Node.jsutilise un modèle d'exécution piloté par les événements. Par défaut, votre JavaScript code Node.js est exécuté sur un seul thread principal et les I/O opérations (appels réseau, accès au système de fichiers) ne sont pas bloquantes et pilotées par des événements. Votre application peut créer des threads supplémentaires avec le worker_threads module si elle en a besoin. Ce modèle a des implications importantes pour les fonctions Web :

Pour obtenir des conseils sur la configuration en maxConcurrencyPerEnvironment fonction des caractéristiques de votre application I/O et du processeur, consultezComportement de dimensionnement pour les fonctions Web Lambda.

La mémoire et le Node.js tas

Chaque environnement d'exécution dispose de 2 Go de mémoire. Ce qui suit s'applique au Node.js tas V8 :

Comment Lambda achemine les demandes vers votre application

Les points de terminaison des fonctions Web acceptent le trafic HTTPS uniquement, sur le port 443. Le protocole HTTP ordinaire n'étant pas diffusé, vous n'avez pas besoin de rediriger le HTTP vers HTTPS ou de configurer le protocole TLS dans votre application.

Lambda met fin au protocole TLS au point de terminaison et transmet chaque requête au serveur HTTP de votre application dans l'environnement d'exécution. Votre application envoie du HTTP simple à l'adresse fournie par Lambda ; vous ne gérez jamais les certificats ou la configuration TLS dans votre code.

Lambda choisit l'hôte et le port sur lesquels votre serveur doit écouter. Lambda communique l'adresse à votre application par le biais de la variable d'AWS_LAMBDA_HTTP_ENDPOINTenvironnement, au host:port format. Utilisez cette variable, définie par Lambda, pour déterminer où votre serveur écoute. Votre application doit lire la variable au démarrage :

const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host);

Lambda ne définit pas la variable sur votre ordinateur local. L'adresse de secours ne s'applique que lorsque la variable n'est pas définie, elle n'est donc utilisée que dans les exécutions locales. Pour utiliser une adresse locale différente, AWS_LAMBDA_HTTP_ENDPOINT configurez-la vous-même. Pour obtenir un exemple, consultez Exécutez le serveur HTTP localement.

Lambda ajoute un lambda-web-request-id en-tête à chaque demande qu'il transmet à votre application et renvoie la même valeur qu'un en-tête de réponse, afin que vous puissiez corréler une demande client avec les journaux de votre application.

Lambda achemine les requêtes Web vers l'adresse spécifiée par. AWS_LAMBDA_HTTP_ENDPOINT Si votre serveur écoute sur un hôte ou un port différent, les demandes ne parviennent pas à votre application.

Votre serveur doit commencer à écouter dans les 10 secondes suivant le démarrage, et chaque demande qu'il traite est liée aux timeoutSeconds paramètres de la révision. Pour la séquence de démarrage et d'arrêt, voirCycle de vie des environnements d'exécution. Pour savoir comment procéder à la configurationtimeoutSeconds, consultezGestion des révisions des fonctions Web.