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.
# Création de fonctions Lambda avec Node.js
Vous pouvez exécuter JavaScript du code avec Node.js dans AWS Lambda. Lambda fournit des [environnements d’exécution](lambda-runtimes.md) 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 pour JavaScript, avec les informations d'identification d'un rôle Gestion des identités et des accès AWS (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](#nodejs-sdk-included).
Lambda prend en charge les environnements d’exécution Node.js suivants.
| Name | Identifiant | Système d’exploitation | Date d’obsolescence | Créer la fonction de blocage | Mettre à jour la fonction de blocage |
| --- | --- | --- | --- | --- | --- |
| Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | 30 avril 2028 | 1 juin 2028 | 1 juillet 2028 |
| 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 | 31 août 2026 | 30 sept. 2026 |
**Pour créer une fonction Node.js.**
1. Ouvrez la [console Lambda](https://console.aws.amazon.com/lambda).
1. Sélectionnez **Créer une fonction**.
1. Configurez les paramètres suivants :
+ **Nom de la fonction** : saisissez le nom de la fonction.
+ **Exécution** : Choisissez **Node.js 24.x**.
1. Choisissez **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](nodejs-handler.md) 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](nodejs-package.md) 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](nodejs-context.md) 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](nodejs-logging.md) pendant l’invocation. Si votre fonction renvoie une erreur, Lambda met en forme l’erreur et la renvoie à l’appelant.
**Topics**
+ [
## Versions du SDK incluses dans l’environnement d’exécution
](#nodejs-sdk-included)
+ [
## Utilisation de keep-alive pour les connexions TCP
](#nodejs-keep-alive)
+ [
## Chargement des certificats CA
](#nodejs-certificate-loading)
+ [
## Fonctionnalités expérimentales de Node.js
](#nodejs-experimental-features)
+ [
# Définition du gestionnaire de fonction Lambda dans Node.js
](nodejs-handler.md)
+ [
# Déployer des fonctions Lambda en Node.js avec des archives de fichiers .zip
](nodejs-package.md)
+ [
# Déployer des fonctions Lambda en Node.js avec des images conteneurs
](nodejs-image.md)
+ [
# Utilisation de couches pour les fonctions Lambda Node.js
](nodejs-layers.md)
+ [
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Node.js
](nodejs-context.md)
+ [
# Journalisation et surveillance des fonctions Lambda Node.js
](nodejs-logging.md)
+ [
# Instrumentation du code Node.js dans AWS Lambda
](nodejs-tracing.md)
## Versions du SDK incluses dans l’environnement d’exécution
[Tous les [environnements d'exécution Lambda Node.js pris en charge](#nodejs-supported-runtimes) incluent une version mineure spécifique de la AWS SDK pour JavaScript v3, et non la dernière version.](https://github.com/aws/aws-sdk-js-v3/releases) La version mineure spécifique incluse dans l’environnement d’exécution dépend de la version de l’environnement d’exécution et de votre Région AWS. Pour trouver la version spécifique du kit SDK incluse dans l’environnement d’exécution que vous utilisez, créez une fonction Lambda avec le code suivant.
**Example 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"
}
```
Pour de plus amples informations, veuillez consulter [Utilisation du SDK pour la JavaScript version 3 dans votre gestionnaire](nodejs-handler.md#nodejs-example-sdk-usage).
## Utilisation de keep-alive pour les connexions TCP
L' HTTP/HTTPS agent 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 tous les [environnements d’exécution Node.js pris en charge](#nodejs-supported-runtimes). 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](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html) 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](https://aws.amazon.com/blogs/developer/http-keep-alive-is-on-by-default-in-modular-aws-sdk-for-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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) 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](configuration-envvars.md) `NODE_EXTRA_CA_CERTS`sur `/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`.
## Fonctionnalités expérimentales de Node.js
Les versions en amont du langage Node.js activent certaines fonctionnalités expérimentales par défaut. Lambda désactive ces fonctionnalités pour garantir la stabilité de l’exécution et des performances constantes. Le tableau suivant répertorie les fonctionnalités expérimentales désactivées par Lambda.
| Fonctionnalité expérimentale | Versions de Node.js prises en charge | Indicateur Node.js appliqué par Lambda | Indicateur Lambda à réactiver |
| --- | --- | --- | --- |
| Prise en charge de l’importation de modules à l’aide de require dans les modules ES | Node.js 20, Node.js 22 | `--no-experimental-require-module` | `--experimental-require-module` |
| Prise en charge de la détection automatique des modules ES par rapport aux modules CommonJS | Node.js 22 | `--no-experimental-detect-module` | `--experimental-detect-module` |
Pour activer une fonctionnalité expérimentale désactivée, définissez l’indicateur de réactivation dans la variable d’environnement `NODE_OPTIONS`. Par exemple, pour activer la prise en charge de require dans les modules ES, réglez `NODE_OPTIONS` sur `--experimental-require-module`. Lambda détecte ce remplacement et supprime l’indicateur de désactivation correspondant.
**Important**
L’utilisation de fonctionnalités expérimentales peut entraîner des problèmes d’instabilité et de performance. Ces fonctionnalités sont susceptibles d’être modifiées ou supprimées dans les futures versions de Node.js. Les fonctions qui utilisent des fonctionnalités expérimentales ne sont pas éligibles au contrat de niveau de service (SLA) Lambda ou à AWS Support
# Définition du gestionnaire de fonction Lambda dans Node.js
Le *gestionnaire* de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.
Cette page explique comment utiliser les gestionnaires de fonctions Lambda dans Node.js, notamment des options pour la configuration du projet, les conventions de dénomination et les pratiques exemplaires. Cette page inclut également un exemple de fonction Lambda Node.js qui collecte des informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon Simple Storage Service (Amazon S3). Pour plus d’informations sur le déploiement de votre fonction après l’avoir écrite, consultez [Déployer des fonctions Lambda en Node.js avec des archives de fichiers .zip](nodejs-package.md) ou [Déployer des fonctions Lambda en Node.js avec des images conteneurs](nodejs-image.md).
**Topics**
+ [
## Configuration de votre projet de gestionnaire Node.js
](#nodejs-handler-setup)
+ [
## Exemple de fonction Lambda Node.js
](#nodejs-example-code)
+ [
## Modules CommonJS et ES
](#nodejs-commonjs-es-modules)
+ [
## Initialisation de Node.js
](#nodejs-initialization)
+ [
## Convention de nommage du gestionnaire
](#nodejs-handler-naming)
+ [
## Définition et accès à l’objet d’événement d’entrée
](#nodejs-example-input)
+ [
## Modèles de gestionnaire valides pour les fonctions Node.js
](#nodejs-handler-signatures)
+ [
## Utilisation du SDK pour la JavaScript version 3 dans votre gestionnaire
](#nodejs-example-sdk-usage)
+ [
## Accès aux variables d’environnement
](#nodejs-example-envvars)
+ [
## Utilisation de l'état global
](#nodejs-handler-state)
+ [
## Pratiques exemplaires en matière de code pour les fonctions Lambda Node.js
](#nodejs-best-practices)
## Configuration de votre projet de gestionnaire Node.js
Il existe plusieurs façons d’initialiser un projet Node.js Lambda. Par exemple, vous pouvez créer un projet Node.js standard en utilisant `npm`, créer une [application AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-init.html#using-sam-cli-init-new) ou créer une [application AWS CDK](lambda-cdk-tutorial.md#lambda-cdk-step-1).
Pour créer le projet avec `npm` :
```
npm init
```
Cette commande initialise votre projet et génère un fichier `package.json` qui gère les métadonnées et dépendances de votre projet.
Le code de votre fonction se trouve dans un `.mjs` JavaScript fichier `.js` or. Dans l’exemple suivant, nous nommons ce fichier `index.mjs`, car il utilise un gestionnaire de modules ES. Lambda prend en charge à la fois le module ES et les gestionnaires CommonJS. Pour de plus amples informations, veuillez consulter [Modules CommonJS et ES](#nodejs-commonjs-es-modules).
Un projet de fonction Lambda Node.js typique suit cette structure générale :
```
/project-root
├── index.mjs — Contains main handler
├── package.json — Project metadata and dependencies
├── package-lock.json — Dependency lock file
└── node_modules/ — Installed dependencies
```
## Exemple de fonction Lambda Node.js
L’exemple de code de fonction Lambda suivant prend en compte les informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon S3.
**Example index.mjs, fonction Lambda**
```
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
// Initialize the S3 client outside the handler for reuse
const s3Client = new S3Client();
/**
* Lambda handler for processing orders and storing receipts in S3.
* @param {Object} event - Input event containing order details
* @param {string} event.order_id - The unique identifier for the order
* @param {number} event.amount - The order amount
* @param {string} event.item - The item purchased
* @returns {Promise} Success message
*/
export const handler = async(event) => {
try {
// Access environment variables
const bucketName = process.env.RECEIPT_BUCKET;
if (!bucketName) {
throw new Error('RECEIPT_BUCKET environment variable is not set');
}
// Create the receipt content and key destination
const receiptContent = `OrderID: ${event.order_id}\nAmount: $${event.amount.toFixed(2)}\nItem: ${event.item}`;
const key = `receipts/${event.order_id}.txt`;
// Upload the receipt to S3
await uploadReceiptToS3(bucketName, key, receiptContent);
console.log(`Successfully processed order ${event.order_id} and stored receipt in S3 bucket ${bucketName}`);
return 'Success';
} catch (error) {
console.error(`Failed to process order: ${error.message}`);
throw error;
}
};
/**
* Helper function to upload receipt to S3
* @param {string} bucketName - The S3 bucket name
* @param {string} key - The S3 object key
* @param {string} receiptContent - The content to upload
* @returns {Promise}
*/
async function uploadReceiptToS3(bucketName, key, receiptContent) {
try {
const command = new PutObjectCommand({
Bucket: bucketName,
Key: key,
Body: receiptContent
});
await s3Client.send(command);
} catch (error) {
throw new Error(`Failed to upload receipt to S3: ${error.message}`);
}
}
```
Ce fichier `index.mjs` comprend les sections suivantes :
+ Bloc `import` : utilisez ce bloc pour inclure les bibliothèques que votre fonction Lambda requiert, comme les [clients du SDK AWS](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/the-request-object.html).
+ Déclaration `const s3Client` : initialise un [client Amazon S3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/) en dehors de la fonction du gestionnaire. Lambda exécute donc ce code pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib), et le client est conservé pour être [réutilisé lors de plusieurs appels](lambda-runtime-environment.md#execution-environment-reuse).
+ JSDoc bloc de commentaires : définissez les types d'entrée et de sortie pour votre gestionnaire à l'aide d'[JSDoc annotations](https://jsdoc.app/about-getting-started).
+ `export const handler` : le gestionnaire de la fonction principal que Lambda invoque. Lorsque vous déployez votre fonction, spécifiez `index.handler` pour la propriété [Gestionnaire](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-Handler). La valeur de la propriété `Handler` est le nom du fichier et le nom de la méthode du gestionnaire exporté, séparés par un point.
+ Fonction `uploadReceiptToS3` : une fonction d’assistance référencée par la fonction du gestionnaire principal.
Pour que cette fonction fonctionne correctement, son [rôle d’exécution](lambda-intro-execution-role.md) doit autoriser l’action `s3:PutObject`. Assurez-vous également de définir la variable d’environnement `RECEIPT_BUCKET`. Après une invocation réussie, le compartiment Amazon S3 doit contenir un fichier de reçu.
## Modules CommonJS et ES
Node.js prend en charge deux systèmes de modules : CommonJS et ECMAScript modules (modules ES). [Lambda recommande d'utiliser les modules ES car ils prennent en charge l'attente de haut niveau, ce qui permet d'effectuer des tâches asynchrones lors de l'initialisation de l'environnement d'exécution.](#nodejs-initialization)
Node.js traite les fichiers avec une extension de nom de `.cjs` fichier comme des modules CommonJS tandis qu'une `.mjs` extension désigne les modules ES. Par défaut, Node.js traite les fichiers portant l'extension de nom de `.js` fichier comme des modules CommonJS. Vous pouvez configurer Node.js pour traiter les `.js` fichiers comme des modules ES en spécifiant le `type` as `module` dans le `package.json` fichier de la fonction. Vous pouvez configurer Node.js dans Lambda pour détecter automatiquement si un `.js` fichier doit être traité comme CommonJS ou comme un module ES en ajoutant l'`—experimental-detect-module`indicateur à la `NODE_OPTIONS` variable d'environnement. Pour plus d'informations, consultez la section [Fonctionnalités expérimentales de Node.js](lambda-nodejs.md#nodejs-experimental-features).
Les exemples suivants montrent des gestionnaires de fonctions écrits à l'aide de modules ES et de modules CommonJS. Les autres exemples de cette page utilisent tous des modules ES.
------
#### [ ES module example ]
**Example – Gestionnaire de modules ES**
```
const url = "https://aws.amazon.com/";
export const handler = async(event) => {
try {
const res = await fetch(url);
console.info("status", res.status);
return res.status;
}
catch (e) {
console.error(e);
return 500;
}
};
```
------
#### [ CommonJS module example ]
**Example – Gestionnaire de modules CommonJS**
```
const https = require("https");
let url = "https://aws.amazon.com/";
exports.handler = async function (event) {
let statusCode;
await new Promise(function (resolve, reject) {
https.get(url, (res) => {
statusCode = res.statusCode;
resolve(statusCode);
}).on("error", (e) => {
reject(Error(e));
});
});
console.log(statusCode);
return statusCode;
};
```
------
## Initialisation de Node.js
Node.js utilise un I/O modèle non bloquant qui prend en charge des opérations asynchrones efficaces à l'aide d'une boucle d'événements. Par exemple, si Node.js effectue un appel réseau, la fonction continue de traiter les autres opérations sans bloquer une réponse réseau. Lorsque la réponse du réseau est reçue, elle est placée dans la file de rappel. Les tâches de la file d'attente sont traitées lorsque la tâche en cours est terminée.
Lambda recommande d'utiliser l'attente de haut niveau afin que les tâches asynchrones initiées lors de l'initialisation de l'environnement d'exécution soient terminées pendant l'initialisation. Les tâches asynchrones qui ne sont pas terminées lors de l'initialisation s'exécutent généralement lors du premier appel de fonction. Cela peut entraîner un comportement inattendu ou des erreurs. Par exemple, l'initialisation de votre fonction peut effectuer un appel réseau pour récupérer un paramètre depuis le Parameter Store AWS . Si cette tâche n'est pas terminée lors de l'initialisation, la valeur peut être nulle lors d'un appel. Il peut également y avoir un délai entre l'initialisation et l'appel, ce qui peut déclencher des erreurs lors d'opérations sensibles au facteur temps. En particulier, les appels de AWS service peuvent s'appuyer sur des signatures de demande urgentes, ce qui entraîne l'échec des appels de service si l'appel n'est pas terminé pendant la phase d'initialisation. L'exécution des tâches lors de l'initialisation améliore généralement les performances de démarrage à froid et les performances d'appel d'abord lors de l'utilisation de la concurrence provisionnée. Pour plus d'informations, consultez notre article de blog [Using Node.js ES modules and top-level await in AWS Lambda](https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level-await-in-aws-lambda).
## Convention de nommage du gestionnaire
Lorsque vous configurez une fonction, la valeur du paramètre [Gestionnaire](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-Handler) est le nom du fichier et le nom de la méthode du gestionnaire exporté, séparés par un point. La valeur par défaut des fonctions créées dans la console et dans les exemples de ce guide est `index.handler`. Cela indique la méthode `handler` qui est exportée à partir du fichier `index.js` ou `index.mjs`.
Si vous créez une fonction dans la console en utilisant un nom de fichier ou un nom de gestionnaire de fonction différent, vous devez modifier le nom du gestionnaire par défaut.
**Pour modifier le nom du gestionnaire de fonction (console)**
1. Ouvrez la page [Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Cliquez sur l’onglet **Code**.
1. Faites défiler l’écran jusqu’au volet **Paramètres d’exécution** et choisissez **Modifier**.
1. Dans **Gestionnaire**, saisissez le nouveau nom de votre gestionnaire de fonction.
1. Choisissez **Enregistrer**.
## Définition et accès à l’objet d’événement d’entrée
JSON est le format d’entrée le plus courant et standard pour les fonctions Lambda. Dans cet exemple, la fonction exige une entrée similaire à l’exemple suivant :
```
{
"order_id": "12345",
"amount": 199.99,
"item": "Wireless Headphones"
}
```
Lorsque vous utilisez des fonctions Lambda dans Node.js, vous pouvez définir la forme attendue de l'événement d'entrée à l'aide JSDoc d'annotations. Dans cet exemple, nous définissons la structure de saisie dans le JSDoc commentaire du gestionnaire :
```
/**
* Lambda handler for processing orders and storing receipts in S3.
* @param {Object} event - Input event containing order details
* @param {string} event.order_id - The unique identifier for the order
* @param {number} event.amount - The order amount
* @param {string} event.item - The item purchased
* @returns {Promise} Success message
*/
```
Après avoir défini ces types dans votre JSDoc commentaire, vous pouvez accéder aux champs de l'objet d'événement directement dans votre code. Par exemple, `event.order_id` récupère la valeur de `order_id` à partir de l’entrée d’origine.
## Modèles de gestionnaire valides pour les fonctions Node.js
[Nous vous recommandons d'utiliser [async/await](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/using-async-await.html) pour déclarer le gestionnaire de fonctions au lieu d'utiliser des rappels.](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/using-a-callback-function.html) Async/await est un moyen concis et lisible d'écrire du code asynchrone, sans avoir besoin de rappels imbriqués ou de promesses enchaînées. Avec async/await, vous pouvez écrire du code qui se lit comme du code synchrone, tout en étant asynchrone et non bloquant.
### gestionnaires de fonctions asynchrones (recommandé)
Le mot-clé `async` marque une fonction comme étant asynchrone, et le mot-clé `await` met en pause l’exécution de la fonction jusqu’à ce qu’une `Promise` soit résolue. Le gestionnaire accepte les arguments suivants :
+ `event` : contient les données d’entrée transmises à votre fonction.
+ `context` : contient des informations sur l’invocation, la fonction et l’environnement d’exécution. Pour de plus amples informations, veuillez consulter [Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Node.js](nodejs-context.md).
Voici les signatures valides pour le async/await modèle :
```
export const handler = async (event) => { };
```
```
export const handler = async (event, context) => { };
```
### Gestionnaires de fonctions synchrones
Lorsque votre fonction n'exécute aucune tâche asynchrone, vous pouvez utiliser un gestionnaire de fonctions synchrones en utilisant l'une des signatures de fonction suivantes :
```
export const handler = (event) => { };
```
```
export const handler = (event, context) => { };
```
### Gestionnaires de fonctions de diffusion des réponses
Lambda prend en charge le streaming des réponses avec Node.js. Les gestionnaires de fonctions de streaming de réponses utilisent le `awslambda.streamifyResponse()` décorateur et prennent 3 paramètres : `event``responseStream`, et. `context` La signature de la fonction est la suivante :
```
export const handler = awslambda.streamifyResponse(async (event, responseStream, context) => { });
```
Pour de plus amples informations, veuillez consulter [Streaming de réponses pour les fonctions Lambda](configuration-response-streaming.md).
### Gestionnaires de fonctions basés sur le rappel
**Note**
Les gestionnaires de fonctions basés sur le rappel ne sont pris en charge que jusqu'à Node.js 22. À partir de Node.js 24, les tâches asynchrones doivent être implémentées à l'aide de gestionnaires de fonctions asynchrones.
Les gestionnaires de fonctions basés sur le rappel doivent utiliser les arguments d'événement, de contexte et de rappel. Exemple :
```
export const handler = (event, context, callback) => { };
```
La fonction de rappel attend une `Error` et une réponse, qui doit être sérialisable en JSON. La fonction continue à s’exécuter jusqu’à ce que la [boucle d’événement](https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/) soit vide ou que la fonction s’arrête. La réponse n’est pas envoyée à l’appelant tant que toutes les tâches d’événement de boucle ne sont pas terminées. Si la fonction expire, une erreur est renvoyée à la place. Vous pouvez configurer le moteur d'exécution pour envoyer la réponse immédiatement en définissant [le contexte. callbackWaitsForEmptyEventLoop](nodejs-context.md)à faux.
**Example – Requête HTTP avec callback**
L’exemple suivant vérifie la fonction d’une URL et renvoie le code de statut au mécanisme d’appel.
```
import https from "https";
let url = "https://aws.amazon.com/";
export const handler = (event, context, callback) => {
https.get(url, (res) => {
callback(null, res.statusCode);
}).on("error", (e) => {
callback(Error(e));
});
};
```
## Utilisation du SDK pour la JavaScript version 3 dans votre gestionnaire
Vous utiliserez souvent les fonctions Lambda pour interagir avec d'autres AWS ressources ou pour les mettre à jour. Le moyen le plus simple d’interagir avec ces ressources est d’utiliser AWS SDK pour JavaScript. Tous les [environnements d'exécution Lambda Node.js pris en charge incluent](lambda-nodejs.md#nodejs-supported-runtimes) le [SDK pour la version 3. JavaScript ](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/introduction/) Toutefois, nous vous recommandons vivement d'inclure les clients AWS SDK dont vous avez besoin dans votre package de déploiement. Cela permet d’optimiser la [rétrocompatibilité](runtimes-update.md#runtime-update-compatibility) lors des futures mises à jour de l’environnement d’exécution Lambda. Ne vous fiez au SDK fourni par l'environnement d'exécution que lorsque vous ne pouvez pas inclure de packages supplémentaires (par exemple, lorsque vous utilisez l'éditeur de code de la console Lambda ou du code en ligne dans un modèle). AWS CloudFormation
Pour ajouter des dépendances au SDK à votre fonction, utilisez la commande `npm install` correspondant aux clients SDK spécifiques dont vous avez besoin. Dans l’exemple de code, nous avons utilisé le [client Amazon S3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/). Ajoutez cette dépendance en exécutant la commande suivante dans le répertoire qui contient votre fichier `package.json` :
```
npm install @aws-sdk/client-s3
```
Dans le code de fonction, importez le client et les commandes dont vous avez besoin, comme le montre l’exemple de fonction :
```
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
```
Initialisez ensuite un [client Amazon S3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/) :
```
const s3Client = new S3Client();
```
Dans cet exemple, nous avons initialisé notre client Amazon S3 en dehors de la fonction de gestionnaire principale pour éviter d’avoir à l’initialiser à chaque fois que nous invoquons notre fonction. Après avoir initialisé votre client SDK, vous pouvez l'utiliser pour effectuer des appels d'API pour ce AWS service. L'exemple de code appelle l'action d'[PutObject](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/s3/command/PutObjectCommand/)API Amazon S3 comme suit :
```
const command = new PutObjectCommand({
Bucket: bucketName,
Key: key,
Body: receiptContent
});
```
## Accès aux variables d’environnement
Dans le code de votre gestionnaire, vous pouvez référencer n’importe quelle [variable d’environnement](configuration-envvars.md) à l’aide de `process.env`. Dans cet exemple, nous référençons la variable d’environnement `RECEIPT_BUCKET` définie à l’aide des lignes de code suivantes :
```
// Access environment variables
const bucketName = process.env.RECEIPT_BUCKET;
if (!bucketName) {
throw new Error('RECEIPT_BUCKET environment variable is not set');
}
```
## Utilisation de l'état global
Lambda exécute votre code statique pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib) avant d’invoquer votre fonction pour la première fois. Les ressources créées pendant l’initialisation restent en mémoire entre les invocations, ce qui vous évite d’avoir à les créer chaque fois que vous invoquez votre fonction.
Dans l’exemple de code, le code d’initialisation du client S3 se trouve en dehors du gestionnaire. L’exécution initialise le client avant que la fonction n’exécute son premier événement, et le client reste disponible pour être réutilisé pendant toutes les invocations.
## Pratiques exemplaires en matière de code pour les fonctions Lambda Node.js
Suivez ces instructions pour créer des fonctions Lambda :
+ **Séparez le gestionnaire Lambda de votre logique principale.** Cela vous permet de créer une fonction testable plus unitaire.
+ **Contrôlez les dépendances du package de déploiement de vos fonctions. ** L'environnement AWS Lambda d'exécution contient un certain nombre de bibliothèques. Pour les environnements d'exécution Node.js et Python, ceux-ci incluent le AWS SDKs. Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.
+ **Réduisez la complexité de vos dépendances.** Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’[environnement d’exécution](lambda-runtime-environment.md).
+ **Réduisez la taille de votre package de déploiement selon ses besoins d’exécution. ** Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l'invocation.
**Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction**. Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire `/tmp`. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.
Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.
**Utilisez une directive keep-alive pour maintenir les connexions persistantes.** Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez [Réutilisation des connexions avec Keep-Alive dans Node.js](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/node-reusing-connections.html).
**Utilisez des [variables d’environnement](configuration-envvars.md) pour transmettre des paramètres opérationnels à votre fonction.** Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.
**Évitez d’utiliser des invocations récursives** dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur `0` afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.
**N'utilisez pas de code non documenté ni public APIs dans votre code** de fonction Lambda. Pour les AWS Lambda environnements d'exécution gérés, Lambda applique régulièrement des mises à jour de sécurité et fonctionnelles aux applications internes de Lambda. APIs Ces mises à jour internes de l'API peuvent être rétroincompatibles, ce qui peut entraîner des conséquences imprévues, telles que des échecs d'invocation si votre fonction dépend de ces mises à jour non publiques. APIs Consultez [la référence de l'API](https://docs.aws.amazon.com/lambda/latest/api/welcome.html) pour obtenir une liste des API accessibles au public APIs.
**Écriture du code idempotent.** L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulter[Comment faire en sorte que ma fonction Lambda soit idempotente ?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/).
# Déployer des fonctions Lambda en Node.js avec des archives de fichiers .zip
Le code de votre AWS Lambda fonction comprend un fichier .js ou .mjs contenant le code du gestionnaire de votre fonction, ainsi que les packages et modules supplémentaires dont dépend votre code. Pour déployer ce code de fonction vers Lambda, vous utilisez un *package de déploiement*. Ce package peut être une archive de fichier .zip ou une image de conteneur. Pour plus d’informations sur l’utilisation d’images de conteneur avec Node.js, consultez la page [Déployer des fonctions Lambda Node.js avec des images de conteneur](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-image.html).
Pour créer votre package de déploiement sous forme d’archive de fichier .zip, vous pouvez utiliser l’utilitaire d’archivage .zip intégré à votre outil de ligne de commande, ou tout autre utilitaire .zip tel que [7zip](https://www.7-zip.org/download.html). Les exemples présentés dans les sections suivantes supposent que vous utilisez un outil `zip` de ligne de commande dans un environnement Linux ou macOS. Pour utiliser les mêmes commandes sous Windows, vous pouvez [installer le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et de Bash.
Notez que Lambda utilise les autorisations de fichiers POSIX. Ainsi, vous pourriez devoir [définir des autorisations pour le dossier du package de déploiement](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-deployment-package-errors/) avant de créer l’archive de fichiers .zip.
**Topics**
+ [
## Dépendances d’exécution dans Node.js
](#nodejs-package-dependencies)
+ [
## Création d’un package de déploiement .zip sans dépendances
](#nodejs-package-create-no-dependencies)
+ [
## Création d’un package de déploiement .zip avec dépendances
](#nodejs-package-create-dependencies)
+ [
## Création d’une couche Node.js pour vos dépendances
](#nodejs-package-dependencies-layers)
+ [
## Chemin de recherche des dépendances et bibliothèques incluses dans l’exécution
](#nodejs-package-searchpath)
+ [
## Création et mise à jour de fonctions Lambda Node.js à l’aide de fichiers .zip
](#nodejs-package-create-update)
## Dépendances d’exécution dans Node.js
Pour les fonctions Lambda qui utilisent l’exécution Node.js, une dépendance peut être n’importe quel package ou module Node.js. L'exécution Node.js comprend un certain nombre de bibliothèques courantes, ainsi qu'une version de AWS SDK pour JavaScript. Tous les [environnements d’exécution Node.js pris en charge](lambda-nodejs.md#nodejs-supported-runtimes) incluent la version 3 du SDK. Pour utiliser la version 2 du SDK, vous devez ajouter le SDK à votre package de déploiement de fichiers .zip. Pour savoir quelle version spécifique du kit SDK est incluse dans l’environnement d’exécution que vous utilisez, consultez [Versions du SDK incluses dans l’environnement d’exécution](lambda-nodejs.md#nodejs-sdk-included).
Lambda met régulièrement à jour les bibliothèques du kit SDK dans l’exécution Node.js afin d’inclure les dernières fonctionnalités et mises à jour de sécurité. Lambda applique également des correctifs de sécurité et des mises à jour aux autres bibliothèques incluses dans l’exécution. Pour avoir un contrôle total sur les dépendances de votre package, vous pouvez ajouter votre version préférée de n’importe quelle dépendance incluse dans l’exécution à votre package de déploiement. Par exemple, si vous souhaitez utiliser une version particulière du SDK pour JavaScript, vous pouvez l'inclure dans votre fichier .zip en tant que dépendance. Pour plus d’informations sur l’ajout de dépendances incluses dans l’exécution à votre fichier .zip, consultez [Chemin de recherche des dépendances et bibliothèques incluses dans l’exécution](#nodejs-package-searchpath).
Dans le cadre du [modèle de responsabilité partagée AWS](lambda-runtimes.md#runtimes-shared-responsibility), vous êtes responsable de la gestion de toutes les dépendances dans les packages de déploiement de vos fonctions. Cela inclut l’application de mises à jour et de correctifs de sécurité. Pour mettre à jour les dépendances dans le package de déploiement de votre fonction, créez d’abord un nouveau fichier .zip, puis chargez-le sur Lambda. Pour plus d’informations, consultez [Création d’un package de déploiement .zip avec dépendances](#nodejs-package-create-dependencies) et [Création et mise à jour de fonctions Lambda Node.js à l’aide de fichiers .zip](#nodejs-package-create-update).
## Création d’un package de déploiement .zip sans dépendances
Si le code de votre fonction ne comporte aucune dépendance à l’exception des bibliothèques incluses dans l’exécution Lambda, votre fichier .zip contient uniquement le fichier `index.js` ou `index.mjs` avec le code du gestionnaire de votre fonction. Utilisez votre utilitaire zip préféré pour créer un fichier .zip avec votre fichier `index.js` ou `index.mjs` à la racine. Si le fichier contenant le code de votre gestionnaire ne se trouve pas à la racine de votre fichier .zip, Lambda ne sera pas en mesure d’exécuter votre code.
Pour savoir comment déployer votre fichier .zip pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante, veuillez consulter la rubrique [Création et mise à jour de fonctions Lambda Node.js à l’aide de fichiers .zip](#nodejs-package-create-update).
## Création d’un package de déploiement .zip avec dépendances
Si votre code de fonction dépend de packages ou de modules qui ne sont pas inclus dans l’environnement d’exécution Lambda Node.js, vous pouvez soit ajouter ces dépendances à votre fichier .zip avec votre code de fonction, soit utiliser une [couche Lambda](chapter-layers.md). Les instructions de cette section vous indiquent comment inclure vos dépendances dans votre package de déploiement .zip. Pour obtenir des instructions sur la façon d’inclure vos dépendances dans une couche, voir [Création d’une couche Node.js pour vos dépendances](#nodejs-package-dependencies-layers).
L’exemple de commandes de CLI suivant crée un fichier .zip nommé `my_deployment_package.zip` contenant le fichier `index.js` ou `index.mjs` avec le gestionnaire de code de votre fonction et ses dépendances. Dans l’exemple, vous installez les dépendances à l’aide du gestionnaire de packages npm.
**Pour créer le package de déploiement**
1. Accédez au répertoire du projet qui contient votre fichier de code source `index.js` ou `index.mjs`. Dans cet exemple, le répertoire est nommé `my_function`.
```
cd my_function
```
1. Installez les bibliothèques requises pour votre fonction dans le répertoire `node_modules` à l’aide de la commande `npm install`. Dans cet exemple, vous installez Kit SDK AWS X-Ray pour Node.js.
```
npm install aws-xray-sdk
```
Cela crée une structure de dossiers similaire à ce qui suit :
```
~/my_function
├── index.mjs
└── node_modules
├── async
├── async-listener
├── atomic-batcher
├── aws-sdk
├── aws-xray-sdk
├── aws-xray-sdk-core
```
Vous pouvez également ajouter des modules personnalisés que vous créez vous-même à votre package de déploiement. Créez un répertoire sous `node_modules` portant le nom de votre module et enregistrez-y vos packages écrits personnalisés.
1. Créez un fichier .zip reprenant le contenu de votre dossier de projet à la racine. Utilisez l’option `r` (récursive) pour veiller à ce que zip compresse les sous-dossiers.
```
zip -r my_deployment_package.zip .
```
## Création d’une couche Node.js pour vos dépendances
Les instructions de cette section vous indiquent comment inclure les dépendances dans une couche. Pour obtenir des instructions sur la façon d’inclure vos dépendances dans votre package de déploiement, voir [Création d’un package de déploiement .zip avec dépendances](#nodejs-package-create-dependencies).
Lorsque vous ajoutez une couche à une fonction, Lambda charge le contenu de la couche dans le répertoire `/opt` de cet environnement d’exécution. Pour chaque exécution Lambda, la variable `PATH` inclut déjà des chemins de dossiers spécifiques dans le répertoire `/opt`. Pour garantir que Lambda capture le contenu de votre couche, le fichier .zip de votre couche doit avoir ses dépendances un des chemins de dossier suivants :
+ `nodejs/node_modules`
+ `nodejs/node18/node_modules (NODE_PATH)`
+ `nodejs/node20/node_modules (NODE_PATH)`
+ `nodejs/node22/node_modules (NODE_PATH)`
Par exemple, la structure du fichier .zip de votre couche peut ressembler à ce qui suit :
```
xray-sdk.zip
└ nodejs/node_modules/aws-xray-sdk
```
En outre, Lambda détecte automatiquement toutes les bibliothèques dans le répertoire `/opt/lib` et tous les fichiers binaires dans le répertoire `/opt/bin`. Pour que Lambda trouve correctement le contenu de votre couche, vous pouvez aussi créer une couche avec la structure suivante :
```
custom-layer.zip
└ lib
| lib_1
| lib_2
└ bin
| bin_1
| bin_2
```
Après avoir empaqueté votre couche, reportez-vous à [Création et suppression de couches dans Lambda](creating-deleting-layers.md) et à [Ajout de couches aux fonctions](adding-layers.md) pour terminer la configuration de votre couche.
## Chemin de recherche des dépendances et bibliothèques incluses dans l’exécution
L’exécution Node.js comprend un certain nombre de bibliothèques courantes, ainsi qu’une version de AWS SDK pour JavaScript. Si vous souhaitez utiliser une version différente d’une bibliothèque incluse dans l’exécution, vous pouvez le faire en l’associant à votre fonction ou en l’ajoutant en tant que dépendance dans votre package de déploiement. Par exemple, vous pouvez utiliser une version différente du kit SDK en l’ajoutant à votre package de déploiement .zip. Vous pouvez également l’inclure dans une [couche Lambda](chapter-layers.md) pour votre fonction.
Lorsque vous utilisez une instruction `import` ou `require` dans votre code, l’exécution Node.js recherche les répertoires dans le chemin `NODE_PATH` jusqu’à ce qu’elle trouve le module. Par défaut, le premier emplacement dans lequel recherche l’exécution est le répertoire dans lequel votre package de déploiement .zip est décompressé et monté (`/var/task`). Si vous ajoutez une version d’une bibliothèque incluse dans l’exécution dans votre package de déploiement, cette version prévaudra sur la version incluse dans l’exécution. Les dépendances de votre package de déploiement ont également la priorité sur les dépendances des couches.
Lorsque vous ajoutez une dépendance à une couche, Lambda l’extrait vers `/opt/nodejs/nodexx/node_modules`, où `nodexx` représente la version de l’exécution que vous utilisez. Dans le chemin de recherche, ce répertoire a la priorité sur le répertoire contenant les bibliothèques incluses dans l’exécution (`/var/lang/lib/node_modules`). Les bibliothèques des couches de fonctions ont donc la priorité sur les versions incluses dans l’exécution.
Vous pouvez voir le chemin de recherche complet de votre fonction Lambda en ajoutant la ligne de code suivante.
```
console.log(process.env.NODE_PATH)
```
Vous pouvez également ajouter des dépendances dans un dossier distinct au sein de votre package .zip. Par exemple, vous pouvez ajouter un module personnalisé à un dossier votre package .zip appelé `common`. Lorsque votre package .zip est décompressé et monté, ce dossier est placé dans le répertoire `/var/task`. Pour utiliser une dépendance provenant d’un dossier de votre package de déploiement .zip dans votre code, utilisez une instruction `import { } from` ou `const { } = require()`, selon que vous utilisez la résolution du module CJS ou ESM. Par exemple :
```
import { myModule } from './common'
```
Si vous regroupez votre code à `esbuild`, `rollup`, ou similaire, les dépendances utilisées par votre fonction sont regroupées dans un ou plusieurs fichiers. Nous vous recommandons d’utiliser cette méthode pour vendre des dépendances chaque fois que cela est possible. Par rapport à l'ajout de dépendances à votre package de déploiement, le regroupement de votre code améliore les performances grâce à la réduction I/O des opérations.
## Création et mise à jour de fonctions Lambda Node.js à l’aide de fichiers .zip
Une fois que vous avez créé votre package de déploiement .zip, vous pouvez l’utiliser pour créer une nouvelle fonction Lambda ou mettre à jour une fonction Lambda existante. Vous pouvez déployer votre package .zip à l'aide de la console Lambda, de l'API Lambda et AWS Command Line Interface de l'API Lambda. Vous pouvez également créer et mettre à jour des fonctions Lambda à l’aide de l’ AWS Serverless Application Model (AWS SAM) et de CloudFormation.
La taille maximale d’un package de déploiement .zip pour Lambda est de 250 Mo (décompressé). Notez que cette limite s’applique à la taille combinée de tous les fichiers que vous chargez, y compris les couches Lambda.
Le runtime Lambda a besoin d’une autorisation pour lire les fichiers de votre package de déploiement. Dans la notation octale des autorisations Linux, Lambda a besoin de 644 autorisations pour les fichiers non exécutables (rw-r--r--) et de 755 autorisations () pour les répertoires et les fichiers exécutables. rwxr-xr-x
Sous Linux et macOS, utilisez la commande `chmod` pour modifier les autorisations de fichiers sur les fichiers et les répertoires de votre package de déploiement. Par exemple, pour octroyer à un fichier non exécutable les autorisations correctes, exécutez la commande suivante.
```
chmod 644
```
Pour modifier les autorisations relatives aux fichiers dans Windows, voir [Définir, afficher, modifier ou supprimer des autorisations sur un objet](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) dans la documentation Microsoft Windows.
**Note**
Si vous n'accordez pas à Lambda les autorisations nécessaires pour accéder aux répertoires de votre package de déploiement, Lambda définit les autorisations pour ces répertoires sur 755 (). rwxr-xr-x
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de la console
Pour créer une nouvelle fonction, vous devez d’abord créer la fonction dans la console, puis charger votre archive .zip. Pour mettre à jour une fonction existante, ouvrez la page de votre fonction, puis suivez la même procédure pour ajouter votre fichier .zip mis à jour.
Si votre fichier .zip fait moins de 50 Mo, vous pouvez créer ou mettre à jour une fonction en chargeant le fichier directement à partir de votre ordinateur local. Pour les fichiers .zip de plus de 50 Mo, vous devez d’abord charger votre package dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS Management Console, consultez [Getting started with Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). Pour télécharger des fichiers à l'aide de AWS CLI, voir [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
**Note**
Vous ne pouvez pas modifier le [type de package de déploiement](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-PackageType) (.zip ou image de conteneur) d’une fonction existante. Par exemple, vous ne pouvez pas convertir une fonction d’image de conteneur pour utiliser un fichier d’archive .zip à la place. Vous devez créer une nouvelle fonction.
**Pour créer une nouvelle fonction (console)**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez **Créer une fonction**.
1. Choisissez **Créer à partir de zéro**.
1. Sous **Informations de base**, procédez comme suit :
1. Pour **Nom de la fonction**, saisissez le nom de la fonction.
1. Pour **Exécution**, sélectionnez l’exécution que vous souhaitez utiliser.
1. (Facultatif) Pour **Architecture**, choisissez l’architecture de l’ensemble des instructions pour votre fonction. L’architecture par défaut est x86\$164. Assurez-vous que le package de déploiement .zip pour votre fonction est compatible avec l’architecture de l’ensemble d’instructions que vous sélectionnez.
1. (Facultatif) Sous **Permissions (Autorisations)**, développez **Change default execution role (Modifier le rôle d’exécution par défaut)**. Vous pouvez créer un **rôle d’exécution** ou en utiliser un existant.
1. Choisissez **Créer une fonction**. Lambda crée une fonction de base « Hello world » à l’aide de l’exécution de votre choix.
**Pour charger une archive .zip à partir de votre ordinateur local (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger le fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez **Fichier .zip**.
1. Pour charger un fichier .zip, procédez comme suit :
1. Sélectionnez **Charger**, puis choisissez votre fichier .zip dans le sélecteur de fichiers.
1. Choisissez **Ouvrir**.
1. Choisissez **Enregistrer**.
**Pour charger une archive .zip depuis un compartiment Amazon S3 (console)**
1. Sur la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda, choisissez la fonction pour laquelle vous souhaitez charger un nouveau fichier .zip.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez l’**emplacement Amazon S3**.
1. Collez l’URL du lien Amazon S3 de votre fichier .zip et choisissez **Enregistrer**.
### Mise à jour des fonctions du fichier .zip à l’aide de l’éditeur de code de la console
Pour certaines fonctions avec des packages de déploiement .zip, vous pouvez utiliser l’éditeur de code intégré de la console Lambda pour mettre à jour le code de votre fonction directement. Pour utiliser cette fonctionnalité, votre fonction doit répondre aux critères suivants :
+ Votre fonction doit utiliser l’une des exécutions des langages interprétés (Python, Node.js ou Ruby).
+ La taille du package de déploiement de votre fonction doit être inférieure à 50 Mo (décompressé).
Le code des fonctions avec les packages de déploiement d’images de conteneurs ne peut pas être édité directement dans la console.
**Pour mettre à jour le code de fonction à l’aide de l’éditeur de code de la console**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Sélectionnez l’onglet **Code**.
1. Dans le volet **Source du code**, sélectionnez votre fichier de code source et modifiez-le dans l’éditeur de code intégré.
1. Dans la section **DÉPLOYER**, choisissez **Déployer** pour mettre à jour le code de votre fonction :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/getting-started-tutorial/deploy-console.png)
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide du AWS CLI
Vous pouvez utiliser l’[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) pour créer une nouvelle fonction ou pour mettre à jour une fonction existante à l’aide d’un fichier .zip. Utilisez la [fonction de création](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html) et [update-function-code](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html)les commandes pour déployer votre package .zip. Si votre fichier .zip est inférieur à 50 Mo, vous pouvez charger le package .zip à partir d’un emplacement de fichier sur votre machine de génération locale. Pour les fichiers plus volumineux, vous devez charger votre package .zip à partir d’un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
**Note**
Si vous chargez votre fichier .zip depuis un compartiment Amazon S3 à l'aide de AWS CLI, le compartiment doit se trouver au même endroit Région AWS que votre fonction.
Pour créer une nouvelle fonction à l'aide d'un fichier .zip avec le AWS CLI, vous devez spécifier les éléments suivants :
+ Le nom de votre fonction (`--function-name`)
+ L’exécution de votre fonction (`--runtime`)
+ L’Amazon Resource Name (ARN) du [rôle d’exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de votre fonction (`--role`)
+ Le nom de la méthode du gestionnaire dans votre code de fonction (`--handler`)
Vous devez également indiquer l’emplacement de votre fichier .zip. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda create-function --function-name myFunction \
--runtime nodejs24.x --handler index.handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez l’option `--code` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `S3ObjectVersion` pour les objets soumis à la gestion des versions.
```
aws lambda create-function --function-name myFunction \
--runtime nodejs24.x --handler index.handler \
--role arn:aws:iam::111122223333:role/service-role/my-lambda-role \
--code S3Bucket=amzn-s3-demo-bucket,S3Key=myFileName.zip,S3ObjectVersion=myObjectVersion
```
Pour mettre à jour une fonction existante à l’aide de l’interface de ligne de commande, vous devez spécifier le nom de votre fonction à l’aide du paramètre `--function-name`. Vous devez également spécifier l’emplacement du fichier .zip que vous souhaitez utiliser pour mettre à jour votre code de fonction. Si votre fichier .zip se trouve dans un dossier sur votre machine de génération locale, utilisez l’option `--zip-file` pour spécifier le chemin d’accès du fichier, comme le montre l’exemple de commande suivant.
```
aws lambda update-function-code --function-name myFunction \
--zip-file fileb://myFunction.zip
```
Pour spécifier l’emplacement du fichier .zip dans un compartiment Amazon S3, utilisez les options `--s3-bucket` et `--s3-key` comme le montre l’exemple de commande suivant. Vous devez uniquement utiliser le paramètre `--s3-object-version` pour les objets soumis à la gestion des versions.
```
aws lambda update-function-code --function-name myFunction \
--s3-bucket amzn-s3-demo-bucket --s3-key myFileName.zip --s3-object-version myObject Version
```
### Création et mise à jour de fonctions avec des fichiers .zip à l’aide de l’API Lambda
Pour créer et mettre à jour des fonctions à l’aide d’une archive de fichiers .zip, utilisez les opérations d’API suivantes :
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide de AWS SAM
The AWS Serverless Application Model (AWS SAM) est une boîte à outils qui permet de rationaliser le processus de création et d'exécution d'applications sans serveur sur AWS. Vous définissez les ressources de votre application dans un modèle YAML ou JSON et vous utilisez l'interface de ligne de AWS SAM commande (AWS SAM CLI) pour créer, empaqueter et déployer vos applications. Lorsque vous créez une fonction Lambda à partir d'un AWS SAM modèle, elle crée AWS SAM automatiquement un package de déploiement ou une image de conteneur .zip avec le code de votre fonction et les dépendances que vous spécifiez. Pour en savoir plus sur l'utilisation des fonctions Lambda AWS SAM pour créer et déployer des fonctions Lambda, consultez [Getting started with AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started.html) dans le Guide du *AWS Serverless Application Model développeur*.
Vous pouvez également l'utiliser AWS SAM pour créer une fonction Lambda à l'aide d'une archive de fichiers .zip existante. Pour créer une fonction Lambda à l'aide de AWS SAM, vous pouvez enregistrer votre fichier .zip dans un compartiment Amazon S3 ou dans un dossier local sur votre machine de génération. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur*.
Dans votre AWS SAM modèle, la `AWS::Serverless::Function` ressource spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `CodeUri`- défini sur l'URI Amazon S3, le chemin d'accès au dossier local ou à l'[FunctionCode](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-functioncode.html)objet du code de fonction
+ `Runtime` : défini sur votre exécution choisie
Ainsi AWS SAM, si votre fichier .zip est supérieur à 50 Mo, vous n'avez pas besoin de le télécharger au préalable dans un compartiment Amazon S3. AWS SAM peut télécharger des packages .zip jusqu'à la taille maximale autorisée de 250 Mo (décompressés) à partir d'un emplacement sur votre machine de compilation locale.
Pour en savoir plus sur le déploiement de fonctions à l'aide d'un fichier .zip dans AWS SAM, consultez [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)le *manuel du AWS SAM développeur*.
### Création et mise à jour de fonctions avec des fichiers .zip à l'aide de CloudFormation
Vous pouvez l'utiliser CloudFormation pour créer une fonction Lambda à l'aide d'une archive de fichiers .zip. Pour créer une fonction Lambda à partir d’un fichier .zip, vous devez d’abord charger votre fichier dans un compartiment Amazon S3. Pour savoir comment charger un fichier dans un compartiment Amazon S3 à l'aide du AWS CLI, consultez la section [Déplacer des objets](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-move) dans le *guide de AWS CLI l'utilisateur.*
Dans votre CloudFormation modèle, la `AWS::Lambda::Function` ressource spécifie votre fonction Lambda. Dans cette ressource, définissez les propriétés suivantes pour créer une fonction à l’aide d’une archive de fichiers .zip :
+ `PackageType` : défini sur `Zip`
+ `Code` : saisissez le nom du compartiment Amazon S3 et le nom du fichier .zip dans les champs `S3Bucket` et `S3Key`
+ `Runtime` : défini sur votre exécution choisie
Le fichier .zip CloudFormation généré ne peut pas dépasser 4 Mo. Pour en savoir plus sur le déploiement de fonctions à l'aide d'un fichier .zip dans CloudFormation, consultez [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)le *Guide de l'CloudFormation utilisateur*.
# Déployer des fonctions Lambda en Node.js avec des images conteneurs
Il existe trois méthodes pour créer une image de conteneur pour une fonction Lambda Node.js :
+ [Utilisation d'une image AWS de base pour Node.js](#nodejs-image-instructions)
Les [images de base AWS](images-create.md#runtimes-images-lp) sont préchargées avec une exécution du langage, un client d’interface d’exécution pour gérer l’interaction entre Lambda et votre code de fonction, et un émulateur d’interface d’exécution pour les tests locaux.
+ [Utilisation d'une image de base AWS uniquement pour le système d'exploitation](images-create.md#runtimes-images-provided)
[AWS Les images de base réservées](https://gallery.ecr.aws/lambda/provided) au système d'exploitation contiennent une distribution Amazon Linux et l'émulateur [d'interface d'exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/). Ces images sont couramment utilisées pour créer des images de conteneur pour les langages compilés, tels que [Go](go-image.md#go-image-provided) et [Rust](lambda-rust.md), et pour une langue ou une version linguistique pour laquelle Lambda ne fournit pas d’image de base, comme Node.js 19. Vous pouvez également utiliser des images de base uniquement pour le système d'exploitation pour implémenter un [environnement d'exécution personnalisé](runtimes-custom.md). Pour rendre l’image compatible avec Lambda, vous devez inclure le [client d’interface d’exécution pour Node.js](#nodejs-image-clients) dans l’image.
+ [Utilisation d'une image non AWS basique](#nodejs-image-clients)
Vous pouvez utiliser une autre image de base à partir d’un autre registre de conteneur, comme Alpine Linux ou Debian. Vous pouvez également utiliser une image personnalisée créée par votre organisation. Pour rendre l’image compatible avec Lambda, vous devez inclure le [client d’interface d’exécution pour Node.js](#nodejs-image-clients) dans l’image.
**Astuce**
Pour réduire le temps nécessaire à l’activation des fonctions du conteneur Lambda, consultez [Utiliser des générations en plusieurs étapes](https://docs.docker.com/build/building/multi-stage/) (français non garanti) dans la documentation Docker. Pour créer des images de conteneur efficaces, suivez la section [Bonnes pratiques pour l’écriture de Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) (français non garanti).
Cette page explique comment créer, tester et déployer des images de conteneur pour Lambda.
**Topics**
+ [
## AWS images de base pour Node.js
](#nodejs-image-base)
+ [
## Utilisation d'une image AWS de base pour Node.js
](#nodejs-image-instructions)
+ [
## Utilisation d’une autre image de base avec le client d’interface d’exécution
](#nodejs-image-clients)
## AWS images de base pour Node.js
AWS fournit les images de base suivantes pour Node.js :
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| 24 | Node.js 24 | Amazon Linux 2023 | [Dockerfile pour Node.js 24 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/nodejs24.x/Dockerfile.nodejs24.x) | 30 avril 2028 |
| 22 | Node.js 22 | Amazon Linux 2023 | [Dockerfile pour Node.js 22 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/nodejs22.x/Dockerfile.nodejs22.x) | 30 avril 2027 |
| 20 | Node.js 20 | Amazon Linux 2023 | [Dockerfile pour Node.js 2.0 sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/nodejs20.x/Dockerfile.nodejs20.x) | 30 avril 2026 |
Référentiel Amazon ECR : [gallery.ecr. aws/lambda/nodejs](https://gallery.ecr.aws/lambda/nodejs)
Les images de base de Node.js 20 et versions ultérieures sont basées sur l'[image de conteneur minimale Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html). Les images de base antérieures utilisaient Amazon Linux 2. AL2023 offre plusieurs avantages par rapport à Amazon Linux 2, notamment un encombrement de déploiement réduit et des versions mises à jour de bibliothèques telles que`glibc`.
AL2023les images basées sur un lien symbolique sont utilisées `microdnf` comme gestionnaire de packages au lieu de`yum`, qui est le gestionnaire de packages par défaut dans Amazon Linux 2. `dnf` `microdnf`est une implémentation autonome de. `dnf` Pour obtenir la liste des packages inclus dans les images AL2023 basées, reportez-vous aux colonnes **Conteneur minimal** de la section [Comparaison des packages installés sur les images de conteneur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.html). Pour plus d'informations sur les différences entre Amazon Linux 2 AL2023 et Amazon, consultez [la section Présentation du runtime Amazon Linux 2023 AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sur le blog AWS Compute.
**Note**
Pour exécuter des images AL2023 basées localement, y compris avec AWS Serverless Application Model (AWS SAM), vous devez utiliser Docker version 20.10.10 ou ultérieure.
## Utilisation d'une image AWS de base pour Node.js
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Node.js
### Création d’une image à partir d’une image de base
**Pour créer une image de conteneur à partir d'une image AWS de base pour Node.js**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir example
cd example
```
1. Créez un nouveau projet Node.js avec `npm`. Appuyez sur `Enter` pour accepter les options par défaut fournies dans l’expérience interactive.
```
npm init
```
1. Créez un nouveau fichier appelé `index.js`. Vous pouvez ajouter l’exemple de code de fonction suivant au fichier pour le tester, ou utiliser le vôtre.
**Example Gestionnaire CommonJS**
```
exports.handler = async (event) => {
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
```
1. Si votre fonction dépend de bibliothèques autres que celles-ci AWS SDK pour JavaScript, utilisez [npm](https://www.npmjs.com/) pour les ajouter à votre package.
1. Créez un nouveau Dockerfile avec la configuration suivante :
+ Définir la propriété `FROM` sur l’[URI de l’image de base](https://gallery.ecr.aws/lambda/nodejs).
+ Utilisez la commande COPY pour copier le code de la fonction et les dépendances de l’environnement d’exécution dans `{LAMBDA_TASK_ROOT}`, une [variable d’environnement définie par Lambda](configuration-envvars.md#configuration-envvars-runtime).
+ Définir l’argument `CMD` pour le gestionnaire de la fonction Lambda.
Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
```
FROM public.ecr.aws/lambda/nodejs:22
# Copy function code
COPY index.js ${LAMBDA_TASK_ROOT}
# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "index.handler" ]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l'image localement
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Dans cet exemple, `docker-image` est le nom de l’image et `test` est la balise.
```
docker run --platform linux/amd64 -p 9000:8080 docker-image:test
```
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. À partir d’une nouvelle fenêtre de terminal, publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
## Utilisation d’une autre image de base avec le client d’interface d’exécution
Si vous utilisez une [image de base uniquement pour le système d’exploitation](images-create.md#runtimes-images-provided) ou une autre image de base, vous devez inclure le client d’interface d’exécution dans votre image. Le client d’interface d’exécution étend le[API de runtime](runtimes-api.md), qui gère l’interaction entre Lambda et votre code de fonction.
Installez le [client d’interface d’exécution Node.js](https://www.npmjs.com/package/aws-lambda-ric) à l’aide du gestionnaire de packages npm :
```
npm install aws-lambda-ric
```
Vous pouvez également télécharger le [client d'interface d'exécution Node.js](https://github.com/aws/aws-lambda-nodejs-runtime-interface-client) depuis GitHub.
L'exemple suivant montre comment créer une image de conteneur pour Node.js à l'aide d'une image non AWS basique. L’exemple Dockerfile utilise une image de base `bookworm`. Le Dockerfile inclut le client d’interface d’exécution.
### Conditions préalables
Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [Docker](https://docs.docker.com/get-docker) (version minimale 25.0.0)
+ Le [plug-in buildx](https://github.com/docker/buildx/blob/master/README.md) Docker.
+ Node.js
### Création d’une image à partir d’une image de base alternative
**Pour créer une image de conteneur à partir d'une image non AWS basique**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir example
cd example
```
1. Créez un nouveau projet Node.js avec `npm`. Appuyez sur `Enter` pour accepter les options par défaut fournies dans l’expérience interactive.
```
npm init
```
1. Créez un nouveau fichier appelé `index.js`. Vous pouvez ajouter l’exemple de code de fonction suivant au fichier pour le tester, ou utiliser le vôtre.
**Example Gestionnaire CommonJS**
```
exports.handler = async (event) => {
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
```
1. Créez un nouveau fichier Docker. Le Dockerfile suivant utilise une image de base `bookworm` au lieu d’une [image de base AWS](images-create.md#runtimes-images-lp). Le Dockerfile inclut le [client d’interface d’exécution](https://www.npmjs.com/package/aws-lambda-ric), ce qui rend l’image compatible avec Lambda. Le Dockerfile utilise une [création à plusieurs étapes](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds). La première étape crée une image de génération, qui est un environnement Node.js standard dans lequel les dépendances de la fonction sont installées. La deuxième étape crée une image plus fine qui inclut le code de la fonction et ses dépendances. Cela permet de réduire la taille de l’image finale.
+ Définissez la propriété `FROM` pour l’identifiant de l’image de base.
+ Utilisez la commande `COPY` pour copier le code de la fonction et les dépendances de l’exécution.
+ Définissez le `ENTRYPOINT` sur le module que vous souhaitez que le conteneur Docker exécute lorsqu’il démarre. Dans ce cas, le module est le client d’interface d’exécution.
+ Définir l’argument `CMD` pour le gestionnaire de la fonction Lambda.
Notez que l’exemple de Dockerfile n’inclut pas d’[instruction USER](https://docs.docker.com/reference/dockerfile/#user). Lorsque vous déployez une image de conteneur sur Lambda, Lambda définit automatiquement un utilisateur Linux par défaut disposant d’autorisations de moindre privilège. Ceci est différent du comportement standard de Docker qui est défini par défaut par l’utilisateur `root` lorsqu’aucune instruction `USER` n’est fournie.
**Example Dockerfile**
```
# Define custom function directory
ARG FUNCTION_DIR="/function"
FROM node:20-bookworm as build-image
# Include global arg in this stage of the build
ARG FUNCTION_DIR
# Install build dependencies
RUN apt-get update && \
apt-get install -y \
g++ \
make \
cmake \
unzip \
libcurl4-openssl-dev
# Copy function code
RUN mkdir -p ${FUNCTION_DIR}
COPY . ${FUNCTION_DIR}
WORKDIR ${FUNCTION_DIR}
# Install Node.js dependencies
RUN npm install
# Install the runtime interface client
RUN npm install aws-lambda-ric
# Grab a fresh slim copy of the image to reduce the final size
FROM node:20-bookworm-slim
# Required for Node runtimes which use npm@8.6.0+ because
# by default npm writes logs under /home/.npm and Lambda fs is read-only
ENV NPM_CONFIG_CACHE=/tmp/.npm
# Include global arg in this stage of the build
ARG FUNCTION_DIR
# Set working directory to function root directory
WORKDIR ${FUNCTION_DIR}
# Copy in the built dependencies
COPY --from=build-image ${FUNCTION_DIR} ${FUNCTION_DIR}
# Set runtime interface client as default command for the container runtime
ENTRYPOINT ["/usr/local/bin/npx", "aws-lambda-ric"]
# Pass the name of the function handler as an argument to the runtime
CMD ["index.handler"]
```
1. Générez l’image Docker à l’aide de la commande [docker build](https://docs.docker.com/engine/reference/commandline/build/). L’exemple suivant nomme l’image `docker-image` et lui donne la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) `test`. Pour rendre votre image compatible avec Lambda, vous devez utiliser l’option `--provenance=false`.
```
docker buildx build --platform linux/amd64 --provenance=false -t docker-image:test .
```
**Note**
La commande spécifie l’option `--platform linux/amd64` pour garantir la compatibilité de votre conteneur avec l’environnement d’exécution Lambda, quelle que soit l’architecture de votre machine de génération. Si vous avez l'intention de créer une fonction Lambda à l'aide de l'architecture du jeu ARM64 d'instructions, veillez à modifier la commande pour utiliser l'`--platform linux/arm64`option à la place.
### (Facultatif) Testez l’image localement
Utilisez l’[émulateur d’interface d’exécution](https://github.com/aws/aws-lambda-runtime-interface-emulator/) pour tester l’image localement. Vous pouvez [intégrer l’émulateur dans votre image](https://github.com/aws/aws-lambda-runtime-interface-emulator/?tab=readme-ov-file#build-rie-into-your-base-image) ou utiliser la procédure suivante pour l’installer sur votre machine locale.
**Pour installer et exécuter l’émulateur d’interface d’exécution sur votre ordinateur local**
1. Depuis le répertoire de votre projet, exécutez la commande suivante pour télécharger l'émulateur d'interface d'exécution (architecture x86-64) GitHub et l'installer sur votre machine locale.
------
#### [ Linux/macOS ]
```
mkdir -p ~/.aws-lambda-rie && \
curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && \
chmod +x ~/.aws-lambda-rie/aws-lambda-rie
```
Pour installer l'émulateur arm64, remplacez l'URL du GitHub référentiel dans la commande précédente par la suivante :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
#### [ PowerShell ]
```
$dirPath = "$HOME\.aws-lambda-rie"
if (-not (Test-Path $dirPath)) {
New-Item -Path $dirPath -ItemType Directory
}
$downloadLink = "https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie"
$destinationPath = "$HOME\.aws-lambda-rie\aws-lambda-rie"
Invoke-WebRequest -Uri $downloadLink -OutFile $destinationPath
```
Pour installer l’émulateur arm64, remplacez `$downloadLink` par ce qui suit :
```
https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie-arm64
```
------
1. Démarrez votre image Docker à l’aide de la commande **docker run**. Notez ce qui suit :
+ `docker-image` est le nom de l’image et `test` est la balise.
+ `/usr/local/bin/npx aws-lambda-ric index.handler` est le `ENTRYPOINT` suivi du `CMD` depuis votre Dockerfile.
------
#### [ Linux/macOS ]
```
docker run --platform linux/amd64 -d -v ~/.aws-lambda-rie:/aws-lambda -p 9000:8080 \
--entrypoint /aws-lambda/aws-lambda-rie \
docker-image:test \
/usr/local/bin/npx aws-lambda-ric index.handler
```
------
#### [ PowerShell ]
```
docker run --platform linux/amd64 -d -v "$HOME\.aws-lambda-rie:/aws-lambda" -p 9000:8080 `
--entrypoint /aws-lambda/aws-lambda-rie `
docker-image:test `
/usr/local/bin/npx aws-lambda-ric index.handler
```
------
Cette commande exécute l’image en tant que conteneur et crée un point de terminaison local à `localhost:9000/2015-03-31/functions/function/invocations`.
**Note**
Si vous avez créé l'image Docker pour l'architecture du jeu ARM64 d'instructions, veillez à utiliser l'`--platform linux/arm64`option au lieu de`--platform linux/amd64`.
1. Publiez un événement au point de terminaison local.
------
#### [ Linux/macOS ]
Sous Linux et macOS, exécutez la commande `curl` suivante :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
curl "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{"payload":"hello world!"}'
```
------
#### [ PowerShell ]
Dans PowerShell, exécutez la `Invoke-WebRequest` commande suivante :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{}' -ContentType "application/json"
```
Cette commande invoque la fonction avec un événement vide et renvoie une réponse. Si vous utilisez votre propre code de fonction plutôt que l’exemple de code de fonction, vous pouvez invoquer la fonction avec une charge utile JSON. Exemple :
```
Invoke-WebRequest -Uri "http://localhost:9000/2015-03-31/functions/function/invocations" -Method Post -Body '{"payload":"hello world!"}' -ContentType "application/json"
```
------
1. Obtenez l’ID du conteneur.
```
docker ps
```
1. Utilisez la commande [docker kill](https://docs.docker.com/engine/reference/commandline/kill/) pour arrêter le conteneur. Dans cette commande, remplacez `3766c4ab331c` par l’ID du conteneur de l’étape précédente.
```
docker kill 3766c4ab331c
```
### Déploiement de l’image
**Pour charger l’image sur Amazon RIE et créer la fonction Lambda**
1. Exécutez la [get-login-password](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html)commande pour authentifier la CLI Docker auprès de votre registre Amazon ECR.
+ Définissez la `--region` valeur à l' Région AWS endroit où vous souhaitez créer le référentiel Amazon ECR.
+ `111122223333`Remplacez-le par votre Compte AWS identifiant.
```
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com
```
1. Créez un référentiel dans Amazon ECR à l’aide de la commande [create-repository](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/create-repository.html).
```
aws ecr create-repository --repository-name hello-world --region us-east-1 --image-scanning-configuration scanOnPush=true --image-tag-mutability MUTABLE
```
**Note**
Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda.
En cas de succès, vous obtenez une réponse comme celle-ci :
```
{
"repository": {
"repositoryArn": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world",
"registryId": "111122223333",
"repositoryName": "hello-world",
"repositoryUri": "111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world",
"createdAt": "2023-03-09T10:39:01+00:00",
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": true
},
"encryptionConfiguration": {
"encryptionType": "AES256"
}
}
}
```
1. Copiez le `repositoryUri` à partir de la sortie de l’étape précédente.
1. Exécutez la commande [docker tag](https://docs.docker.com/engine/reference/commandline/tag/) pour étiqueter votre image locale dans votre référentiel Amazon ECR en tant que dernière version. Dans cette commande :
+ `docker-image:test` est le nom et la [balise](https://docs.docker.com/engine/reference/commandline/build/#tag) de votre image Docker. Il s’agit du nom et de la balise de l’image que vous avez spécifiés dans la commande `docker build`.
+ Remplacez `` par l’`repositoryUri` que vous avez copié. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
docker tag docker-image:test :latest
```
Exemple :
```
docker tag docker-image:test 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. Exécutez la commande [docker push](https://docs.docker.com/engine/reference/commandline/push/) pour déployer votre image locale dans le référentiel Amazon ECR. Assurez-vous d’inclure `:latest` à la fin de l’URI du référentiel.
```
docker push 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest
```
1. [Créez un rôle d’exécution](lambda-intro-execution-role.md#permissions-executionrole-api) pour la fonction, si vous n’en avez pas déjà un. Vous aurez besoin de l’Amazon Resource Name (ARN) du rôle à l’étape suivante.
1. Créez la fonction Lambda. Pour `ImageUri`, indiquez l’URI du référentiel mentionné précédemment. Assurez-vous d’inclure `:latest` à la fin de l’URI.
```
aws lambda create-function \
--function-name hello-world \
--package-type Image \
--code ImageUri=111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--role arn:aws:iam::111122223333:role/lambda-ex
```
**Note**
Vous pouvez créer une fonction en utilisant une image d'un autre AWS compte, à condition que l'image se trouve dans la même région que la fonction Lambda. Pour de plus amples informations, veuillez consulter [Autorisations entre comptes Amazon ECR](images-create.md#configuration-images-xaccount-permissions).
1. Invoquer la fonction.
```
aws lambda invoke --function-name hello-world response.json
```
Vous devriez obtenir une réponse comme celle-ci :
```
{
"ExecutedVersion": "$LATEST",
"StatusCode": 200
}
```
1. Pour voir la sortie de la fonction, consultez le fichier `response.json`.
Pour mettre à jour le code de fonction, vous devez créer à nouveau l'image, télécharger la nouvelle image dans le référentiel Amazon ECR, puis utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande pour déployer l'image sur la fonction Lambda.
Lambda résout l’étiquette d’image en hachage d’image spécifique. Cela signifie que si vous pointez la balise d’image qui a été utilisée pour déployer la fonction vers une nouvelle image dans Amazon ECR, Lambda ne met pas automatiquement à jour la fonction pour utiliser la nouvelle image.
Pour déployer la nouvelle image sur la même fonction Lambda, vous devez utiliser la [update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)commande, même si la balise d'image dans Amazon ECR reste la même. Dans l’exemple suivant, l’option `--publish` crée une version de la fonction à l’aide de l’image du conteneur mise à jour.
```
aws lambda update-function-code \
--function-name hello-world \
--image-uri 111122223333.dkr.ecr.us-east-1.amazonaws.com/hello-world:latest \
--publish
```
# Utilisation de couches pour les fonctions Lambda Node.js
Utilisez les [couches Lambda](chapter-layers.md) pour empaqueter le code et les dépendances que vous souhaitez réutiliser dans plusieurs fonctions. Les couches contiennent généralement des dépendances de bibliothèque, une [exécution personnalisée](runtimes-custom.md), ou des fichiers de configuration. La création d’une couche implique trois étapes générales :
1. Empaquetez le contenu de votre couche. Cela signifie créer une archive de fichiers .zip contenant les dépendances que vous souhaitez utiliser dans vos fonctions.
1. Créez la couche dans Lambda.
1. Ajoutez la couche à vos fonctions.
**Topics**
+ [
## Empaqueter le contenu de votre couche
](#nodejs-layers-package)
+ [
## Créer la couche dans Lambda
](#publishing-layer)
+ [
## Ajouter la couche à votre fonction
](#nodejs-layer-adding)
+ [
## Exemple d’application
](#nodejs-layer-sample-app)
## Empaqueter le contenu de votre couche
Pour créer une couche, regroupez vos packages dans une archive (fichier .zip) répondant aux exigences suivantes :
+ Créez la couche à l’aide de la même version de Node.js que celle que vous prévoyez d’utiliser pour la fonction Lambda. Par exemple, si vous créez votre couche à l'aide de Node.js 24, utilisez le runtime Node.js 24 pour votre fonction.
+ Le fichier .zip de votre couche doit utiliser l’une des structures de répertoires suivantes :
+ `nodejs/node_modules`
+ `nodejs/nodeX/node_modules`(où se *X* trouve votre version de Node.js, par exemple`node22`)
Pour de plus amples informations, veuillez consulter [Chemins d’accès de couche pour chaque exécution Lambda](packaging-layers.md#packaging-layers-paths).
+ Les packages de votre couche doivent être compatibles avec Linux. Les fonctions Lambda s’exécutent sur Amazon Linux.
Vous pouvez créer des couches contenant des bibliothèques Node.js tierces installées avec `npm` (telles que `axios` ou`lodash`) ou vos propres JavaScript modules.
### Dépendances tierces
**Créer une couche à l’aide de packages npm**
1. Créez la structure de répertoires requise et installez-y les packages directement :
```
mkdir -p nodejs
npm install --prefix nodejs lodash axios
```
Cette commande installe les packages directement dans le répertoire `nodejs/node_modules`, qui correspond à la structure requise par Lambda.
**Note**
Pour les packages avec des dépendances natives ou des composants binaires (comme [sharp](https://www.npmjs.com/package/sharp) ou [bcrypt](https://www.npmjs.com/package/bcrypt)), assurez-vous qu’ils sont compatibles avec l’environnement Linux Lambda et l’[architecture](foundation-arch.md) de votre fonction. Vous devrez peut-être utiliser l’indicateur `--platform` :
```
npm install --prefix nodejs --platform=linux --arch=x64 sharp
```
Pour les dépendances natives plus complexes, vous devrez peut-être les compiler dans un environnement Linux qui correspond à l’environnement d’exécution Lambda. Vous pouvez utiliser Docker à cette fin.
1. Compressez le contenu de la couche :
------
#### [ Linux/macOS ]
```
zip -r layer.zip nodejs/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\nodejs -DestinationPath .\layer.zip
```
------
La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
nodejs/
├── package.json
├── package-lock.json
└── node_modules/
├── lodash/
├── axios/
└── (dependencies of the other packages)
```
**Note**
Assurez-vous que votre fichier .zip inclut le répertoire `nodejs` au niveau racine avec `node_modules` à l’intérieur. Cette structure garantit que Lambda peut localiser et importer vos packages.
Les fichiers `package.json` et `package-lock.json` du répertoire `nodejs/` sont utilisés par npm pour la gestion des dépendances, mais ne sont pas requis par Lambda pour le fonctionnement des couches. Chaque package installé contient déjà son propre fichier `package.json` qui définit la manière dont Lambda importe le package.
### JavaScript Modules personnalisés
**Créer une couche à l’aide de votre propre code**
1. Créez la structure de répertoires requise pour votre couche :
```
mkdir -p nodejs/node_modules/validator
cd nodejs/node_modules/validator
```
1. Créez un fichier `package.json` pour votre module personnalisé afin de définir comment il doit être importé :
**Example nodejs/node\$1modules/validator/package.json**
```
{
"name": "validator",
"version": "1.0.0",
"type": "module",
"main": "index.mjs"
}
```
1. Créez votre fichier JavaScript de module :
**Example nodejs/node\$1modules/validator/index.mjs**
```
export function validateOrder(orderData) {
// Validates an order and returns formatted data
const requiredFields = ['productId', 'quantity'];
// Check required fields
const missingFields = requiredFields.filter(field => !(field in orderData));
if (missingFields.length > 0) {
throw new Error(`Missing required fields: ${missingFields.join(', ')}`);
}
// Validate quantity
const quantity = orderData.quantity;
if (!Number.isInteger(quantity) || quantity < 1) {
throw new Error('Quantity must be a positive integer');
}
// Format and return the validated data
return {
productId: String(orderData.productId),
quantity: quantity,
shippingPriority: orderData.priority || 'standard'
};
}
export function formatResponse(statusCode, body) {
// Formats the API response
return {
statusCode: statusCode,
body: JSON.stringify(body)
};
}
```
1. Compressez le contenu de la couche :
------
#### [ Linux/macOS ]
```
zip -r layer.zip nodejs/
```
------
#### [ PowerShell ]
```
Compress-Archive -Path .\nodejs -DestinationPath .\layer.zip
```
------
La structure de répertoire de votre fichier .zip devrait se présenter comme suit :
```
nodejs/
└── node_modules/
└── validator/
├── package.json
└── index.mjs
```
1. Dans votre fonction, importez et utilisez les modules. Exemple :
```
import { validateOrder, formatResponse } from 'validator';
export const handler = async (event) => {
try {
// Parse the order data from the event body
const orderData = JSON.parse(event.body || '{}');
// Validate and format the order
const validatedOrder = validateOrder(orderData);
return formatResponse(200, {
message: 'Order validated successfully',
order: validatedOrder
});
} catch (error) {
if (error instanceof Error && error.message.includes('Missing required fields')) {
return formatResponse(400, {
error: error.message
});
}
return formatResponse(500, {
error: 'Internal server error'
});
}
};
```
Vous pouvez utiliser l’[événement de test](testing-functions.md#invoke-with-event) suivant afin d’invoquer la fonction :
```
{
"body": "{\"productId\": \"ABC123\", \"quantity\": 2, \"priority\": \"express\"}"
}
```
Réponse attendue :
```
{
"statusCode": 200,
"body": "{\"message\":\"Order validated successfully\",\"order\":{\"productId\":\"ABC123\",\"quantity\":2,\"shippingPriority\":\"express\"}}"
}
```
## Créer la couche dans Lambda
Vous pouvez publier votre couche à l'aide de la console Lambda AWS CLI ou de la console Lambda.
------
#### [ AWS CLI ]
Exécutez la [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html) AWS CLI commande pour créer la couche Lambda :
```
aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes nodejs24.x
```
Le paramètre [compatible runtimes](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) est facultatif. Lorsqu’il est spécifié, Lambda utilise ce paramètre pour filtrer les couches dans la console Lambda.
------
#### [ Console ]
**Pour créer une couche (console)**
1. Ouvrez la [page Couches](https://console.aws.amazon.com/lambda/home#/layers) de la console Lambda.
1. Sélectionnez **Créer un calque**.
1. Choisissez **Charger un fichier .zip**, puis chargez l’archive .zip que vous avez créée précédemment.
1. (Facultatif) Pour **Environnements d’exécution compatibles**, choisissez l’environnement d’exécution Node.js qui correspond à la version de Node.js que vous avez utilisée pour créer votre couche.
1. Choisissez **Créer**.
------
## Ajouter la couche à votre fonction
------
#### [ AWS CLI ]
Pour associer la couche à votre fonction, exécutez la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) AWS CLI commande. Utilisez l’ARN de la couche pour le paramètre `--layers`. L’ARN doit spécifier la version (par exemple, `arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1`). Pour de plus amples informations, veuillez consulter [Couches et versions de couches](chapter-layers.md#lambda-layer-versions).
```
aws lambda update-function-configuration --function-name my-function --cli-binary-format raw-in-base64-out --layers "arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1"
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
------
#### [ Console ]
**Ajouter une couche à une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la fonction.
1. Faites défiler jusqu’à la section **Couches**, puis choisissez **Ajouter une couche**.
1. Sous **Choisir une couche**, sélectionnez **Couches personnalisées**, puis choisissez votre couche.
**Note**
Si vous n’avez pas ajouté d’[environnement d’exécution compatible](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html#lambda-PublishLayerVersion-request-CompatibleRuntimes) lors de la création de la couche, celle-ci ne sera pas répertoriée ici. Vous pouvez spécifier l’ARN de la couche à la place.
1. Choisissez **Ajouter**.
------
## Exemple d’application
Pour d'autres exemples d'utilisation des couches Lambda, consultez l'exemple d'application [layer-nodejs dans le référentiel du Developer](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/layer-nodejs) Guide. AWS Lambda GitHub Cette application inclut une couche qui contient la bibliothèque [lodash](https://www.npmjs.com/package/lodash). Après avoir créé la couche, vous pouvez déployer et invoquer la fonction correspondante pour confirmer que la couche fonctionne comme prévu.
# Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction Node.js
Lorsque Lambda exécute votre fonction, il transmet un objet contexte au [gestionnaire](nodejs-handler.md). Cet objet fournit des méthodes et des propriétés fournissant des informations sur l’invocation, la fonction et l’environnement d’exécution.
**Méthodes de contexte**
+ `getRemainingTimeInMillis()` – Renvoie le nombre de millisecondes restant avant l’expiration de l’exécution.
**Propriétés du contexte**
+ `functionName` – Nom de la fonction Lambda.
+ `functionVersion` – [Version](configuration-versions.md) de la fonction.
+ `invokedFunctionArn` – Amazon Resource Name (ARN) utilisé pour appeler la fonction. Indique si l’appelant a spécifié un numéro de version ou un alias.
+ `memoryLimitInMB` – Quantité de mémoire allouée à la fonction.
+ `awsRequestId` – Identifiant de la demande d’invocation.
+ `logGroupName` – Groupe de journaux pour la fonction.
+ `logStreamName` – Flux de journal de l’instance de fonction.
+ `identity` – (applications mobiles) Informations sur l’identité Amazon Cognito qui a autorisé la demande.
+ `cognitoIdentityId` – Identité Amazon Cognito authentifiée.
+ `cognitoIdentityPoolId` – Groupe d’identités Amazon Cognito ayant autorisé l’invocation.
+ `clientContext` – (applications mobiles) Contexte client fourni à Lambda par l’application client.
+ `client.installation_id`
+ `client.app_title`
+ `client.app_version_name`
+ `client.app_version_code`
+ `client.app_package_name`
+ `env.platform_version`
+ `env.platform`
+ `env.make`
+ `env.model`
+ `env.locale`
+ `custom` – Personnalisez les valeurs qui sont définies par l’application client.
+ `callbackWaitsForEmptyEventLoop`— Par défaut (`true`), lors de l'utilisation d'un gestionnaire de fonctions basé sur le rappel, Lambda attend que la boucle d'événements soit vide après l'exécution du rappel avant de mettre fin à l'appel de la fonction. Définissez cette valeur `false` sur pour envoyer la réponse et mettre fin à l'appel immédiatement après l'exécution du rappel au lieu d'attendre que la boucle d'événements soit vide. Les événements exceptionnels continuent de se dérouler lors de la prochaine invocation. Notez que Lambda prend en charge les gestionnaires de fonctions basés sur le rappel pour les environnements d'exécution de Node.js 22 et antérieurs uniquement.
Dans l'exemple suivant, la fonction enregistre des informations de contexte et renvoie l'emplacement des journaux.
**Example Fichier index.js**
```
exports.handler = async function(event, context) {
console.log('Remaining time: ', context.getRemainingTimeInMillis())
console.log('Function name: ', context.functionName)
return context.logStreamName
}
```
# Journalisation et surveillance des fonctions Lambda Node.js
AWS Lambda surveille automatiquement les fonctions Lambda en votre nom et envoie les journaux à Amazon. CloudWatch Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs et un flux de journaux pour chaque instance de votre fonction. L’environnement d’exécution Lambda envoie des informations sur chaque invocation au flux de journaux et transmet les journaux et autres sorties provenant du code de votre fonction. Pour de plus amples informations, veuillez consulter [Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md).
Cette page explique comment générer une sortie de journal à partir du code de votre fonction Lambda et comment accéder aux journaux à l'aide de la AWS Command Line Interface console Lambda ou de la console. CloudWatch
**Topics**
+ [
## Création d’une fonction qui renvoie des journaux
](#node-logging-output)
+ [
## Utilisation des contrôles de journalisation avancés de Lambda avec Node.js
](#node-js-logging-advanced)
+ [
## Affichage des journaux dans la console Lambda
](#nodejs-logging-console)
+ [
## Afficher les journaux dans la CloudWatch console
](#nodejs-logging-cwconsole)
+ [
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
](#nodejs-logging-cli)
+ [
## Suppression de journaux
](#nodejs-logging-delete)
## Création d’une fonction qui renvoie des journaux
Pour générer les journaux à partir de votre code de fonction, vous pouvez utiliser des méthodes sur [l’objet console](https://developer.mozilla.org/en-US/docs/Web/API/Console) ou n’importe quelle bibliothèque de journalisation qui écrit dans `stdout` ou `stderr`. L’exemple suivant consigne les valeurs des variables d’environnement et l’objet d’événement.
**Note**
Nous vous recommandons d’utiliser des techniques telles que la validation des entrées et le codage des sorties lors de la journalisation des entrées. Si vous journalisez directement les données d’entrée, un attaquant peut utiliser votre code pour rendre les altérations difficiles à détecter, falsifier des entrées de journal ou contourner les moniteurs de journal. Pour plus d’informations, consultez [Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) dans la *Common Weakness Enumeration*.
**Example Fichier index.js – Journalisation**
```
exports.handler = async function(event, context) {
console.log("ENVIRONMENT VARIABLES\n" + JSON.stringify(process.env, null, 2))
console.info("EVENT\n" + JSON.stringify(event, null, 2))
console.warn("Event not processed.")
return context.logStreamName
}
```
**Example format des journaux**
```
START RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac Version: $LATEST
2019-06-07T19:11:20.562Z c793869b-ee49-115b-a5b6-4fd21e8dedac INFO ENVIRONMENT VARIABLES
{
"AWS_LAMBDA_FUNCTION_VERSION": "$LATEST",
"AWS_LAMBDA_LOG_GROUP_NAME": "/aws/lambda/my-function",
"AWS_LAMBDA_LOG_STREAM_NAME": "2019/06/07/[$LATEST]e6f4a0c4241adcd70c262d34c0bbc85c",
"AWS_EXECUTION_ENV": "AWS_Lambda_nodejs12.x",
"AWS_LAMBDA_FUNCTION_NAME": "my-function",
"PATH": "/var/lang/bin:/usr/local/bin:/usr/bin/:/bin:/opt/bin",
"NODE_PATH": "/opt/nodejs/node10/node_modules:/opt/nodejs/node_modules:/var/runtime/node_modules",
...
}
2019-06-07T19:11:20.563Z c793869b-ee49-115b-a5b6-4fd21e8dedac INFO EVENT
{
"key": "value"
}
2019-06-07T19:11:20.564Z c793869b-ee49-115b-a5b6-4fd21e8dedac WARN Event not processed.
END RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac
REPORT RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac Duration: 128.83 ms Billed Duration: 296 ms Memory Size: 128 MB Max Memory Used: 74 MB Init Duration: 166.62 ms XRAY TraceId: 1-5d9d007f-0a8c7fd02xmpl480aed55ef0 SegmentId: 3d752xmpl1bbe37e Sampled: true
```
Le runtime Node.js enregistre les lignes `START`, `END` et `REPORT` pour chaque invocation. Il ajoute un horodatage, un ID de demande et un niveau de journalisation sur chaque entrée consignée par la fonction. La ligne de rapport fournit les détails suivants.
**Champs de données de la ligne REPORT**
+ **RequestId**— L'identifiant de demande unique pour l'invocation.
+ **Duration** – Temps que la méthode de gestion du gestionnaire de votre fonction a consacré au traitement de l’événement.
+ **Billed Duration** : temps facturé pour l’invocation.
+ **Memory Size** – Quantité de mémoire allouée à la fonction.
+ **Max Memory Used** – Quantité de mémoire utilisée par la fonction. Lorsque les appels partagent un environnement d’exécution, Lambda indique la mémoire maximale utilisée pour toutes les invocations. Ce comportement peut entraîner une valeur signalée plus élevée que prévu.
+ **Init Duration** : pour la première requête servie, temps qu’il a pris à l’exécution charger la fonction et exécuter le code en dehors de la méthode du gestionnaire.
+ **XRAY TraceId** — Pour les demandes suivies, l'[ID de AWS X-Ray trace.](services-xray.md)
+ **SegmentId**— Pour les demandes tracées, l'identifiant du segment X-Ray.
+ **Sampled** – Pour les demandes suivies, résultat de l’échantillonnage.
Vous pouvez consulter les journaux dans la console Lambda, dans la console CloudWatch Logs ou depuis la ligne de commande.
## Utilisation des contrôles de journalisation avancés de Lambda avec Node.js
Pour mieux contrôler la manière dont les journaux de vos fonctions sont capturés, traités et consommés, vous pouvez configurer les options de journalisation suivantes pour les environnements d’exécution Node.js pris en charge :
+ **Format de journal** : choisissez entre le format texte brut et le format JSON structuré pour les journaux de votre fonction
+ **Niveau de journalisation** : pour les journaux au format JSON, choisissez le niveau de détail des journaux que Lambda envoie à Amazon CloudWatch, par exemple ERROR, DEBUG ou INFO
+ **Groupe de journaux** : choisissez le groupe de CloudWatch journaux auquel votre fonction envoie les journaux
Pour plus d’informations sur ces options de journalisation et pour savoir comment configurer votre fonction pour les utiliser, consultez [Configuration de commandes de journalisation avancées pour votre fonction Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
Pour utiliser le format de journal et les options de niveau de journal avec vos fonctions Node.js Lambda, consultez les instructions des sections suivantes.
### Utilisation de journaux JSON structurés avec Node.js
Si vous sélectionnez JSON pour le format de journal de votre fonction, Lambda enverra la sortie des journaux à l'aide des méthodes de console`console.trace`,,,`console.debug`, `console.log` `console.info``console.error`, et `console.warn` vers CloudWatch sous forme de JSON structuré. Chaque objet de journal JSON contient au moins quatre paires clé-valeur avec les clés suivantes :
+ `"timestamp"` - heure à laquelle le message de journal a été généré
+ `"level"` - niveau de journalisation attribué au message
+ `"message"` - contenu du message de journal
+ `"requestId"` - identifiant unique de la demande pour l’invocation de la fonction
Selon la méthode de journalisation utilisée par votre fonction, cet objet JSON peut également contenir des paires de clés supplémentaires. Par exemple, si votre fonction utilise des méthodes `console` pour enregistrer les objets d'erreur à l'aide de plusieurs arguments, l'objet JSON contiendra des paires clé-valeur supplémentaires avec les clés `errorMessage`, `errorType` et `stackTrace`.
Si votre code utilise déjà une autre bibliothèque de journalisation, telle que Powertools for AWS Lambda, pour produire des journaux structurés en JSON, vous n'avez pas besoin d'apporter de modifications. Lambda n’encode pas deux fois les journaux déjà codés en JSON. Les journaux d’application de votre fonction continueront donc d’être capturés comme avant.
Pour plus d'informations sur l'utilisation du package Powertools for AWS Lambda logging afin de créer des journaux structurés JSON dans le runtime Node.js, consultez[Enregistrez et surveillez les fonctions TypeScript Lambda](typescript-logging.md).
#### Exemple de sorties de journal au format JSON
Les exemples suivants montrent comment les différentes sorties de journal générées à l'aide `console` des méthodes avec des arguments uniques et multiples sont capturées dans CloudWatch Logs lorsque vous définissez le format de journal de votre fonction sur JSON.
Le premier exemple utilise la méthode `console.error` pour générer une chaîne simple.
**Example Code de journalisation Node.js**
```
export const handler = async (event) => {
console.error("This is a warning message");
...
}
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp":"2025-11-01T00:21:51.358Z",
"level":"ERROR",
"message":"This is a warning message",
"requestId":"93f25699-2cbf-4976-8f94-336a0aa98c6f"
}
```
Vous pouvez également générer des messages de journal structurés plus complexes en utilisant un ou plusieurs arguments avec les méthodes `console`. Dans l'exemple suivant, vous pouvez utiliser `console.log` pour générer deux paires clé-valeur avec un seul argument. Notez que le `"message"` champ de l'objet JSON envoyé par Lambda à CloudWatch Logs n'est pas stringifié.
**Example Code de journalisation Node.js**
```
export const handler = async (event) => {
console.log({data: 12.3, flag: false});
...
}
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-12-08T23:21:04.664Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": {
"data": 12.3,
"flag": false
}
}
```
Dans l'exemple suivant, vous utilisez à nouveau la méthode `console.log` pour créer une sortie de journal. Cette fois, la méthode prend deux arguments, une carte contenant deux paires clé-valeur et une chaîne d'identification. Notez que dans ce cas, parce que vous avez fourni deux arguments, Lambda stringifie le champ `"message"`.
**Example Code de journalisation Node.js**
```
export const handler = async (event) => {
console.log('Some object - ', {data: 12.3, flag: false});
...
}
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-12-08T23:21:04.664Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": "Some object - { data: 12.3, flag: false }"
}
```
Lambda attribue les sorties générées à l’aide de `console.log` du niveau de journalisation INFO.
Le dernier exemple montre comment les objets d'erreur peuvent être générés dans CloudWatch Logs à l'aide `console` des méthodes. Notez que lorsque vous enregistrez des objets d'erreur à l'aide de plusieurs arguments, Lambda ajoute les champs `errorMessage`, `errorType` et `stackTrace` à la sortie du journal.
**Example Code de journalisation Node.js**
```
export const handler = async (event) => {
let e1 = new ReferenceError("some reference error");
let e2 = new SyntaxError("some syntax error");
console.log(e1);
console.log("errors logged - ", e1, e2);
};
```
**Example Enregistrement de journaux JSON**
```
{
"timestamp": "2025-12-08T23:21:04.632Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": {
"errorType": "ReferenceError",
"errorMessage": "some reference error",
"stackTrace": [
"ReferenceError: some reference error",
" at Runtime.handler (file:///var/task/index.mjs:3:12)",
" at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)"
]
}
}
{
"timestamp": "2025-12-08T23:21:04.646Z",
"level": "INFO",
"requestId": "405a4537-9226-4216-ac59-64381ec8654a",
"message": "errors logged - ReferenceError: some reference error\n at Runtime.handler (file:///var/task/index.mjs:3:12)\n at Runtime.handleOnceNonStreaming
(file:///var/runtime/index.mjs:1173:29) SyntaxError: some syntax error\n at Runtime.handler (file:///var/task/index.mjs:4:12)\n at Runtime.handleOnceNonStreaming
(file:///var/runtime/index.mjs:1173:29)",
"errorType": "ReferenceError",
"errorMessage": "some reference error",
"stackTrace": [
"ReferenceError: some reference error",
" at Runtime.handler (file:///var/task/index.mjs:3:12)",
" at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)"
]
}
```
Lors de la journalisation de plusieurs types d'erreur, les champs supplémentaires `errorMessage`, `errorType`, et `stackTrace` sont extraits du premier type d'erreur fourni à la méthode `console`.
### Utilisation de bibliothèques clientes au format métrique intégré (EMF) avec des journaux JSON structurés
AWS fournit des bibliothèques clientes open source pour Node.js que vous pouvez utiliser pour créer des journaux [au format métrique intégré](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) (EMF). Si vous avez des fonctions existantes qui utilisent ces bibliothèques et que vous modifiez le format de journal de votre fonction en JSON, il est CloudWatch possible que les métriques émises par votre code ne soient plus reconnues.
Si votre code émet actuellement des journaux EMF directement en utilisant `console.log` ou en utilisant Powertools for AWS Lambda (TypeScript), vous ne pourrez pas CloudWatch non plus les analyser si vous modifiez le format de journal de votre fonction en JSON.
**Important**
Pour vous assurer que les journaux EMF de vos fonctions continuent d'être correctement analysés CloudWatch, mettez à jour vos bibliothèques [EMF](https://www.npmjs.com/package/aws-embedded-metrics) et [Powertools pour](https://github.com/aws-powertools/powertools-lambda-typescript) les AWS Lambda bibliothèques avec les dernières versions. Si vous passez au format de journal JSON, nous vous recommandons également d’effectuer des tests pour garantir la compatibilité avec les métriques intégrées de votre fonction. Si votre code émet des journaux EMF directement à l’aide de `console.log`, modifiez votre code pour qu’il affiche directement ces métriques vers `stdout`, comme indiqué dans l’exemple de code suivant.
**Example code émettant des métriques intégrées pour `stdout`**
```
process.stdout.write(JSON.stringify(
{
"_aws": {
"Timestamp": Date.now(),
"CloudWatchMetrics": [{
"Namespace": "lambda-function-metrics",
"Dimensions": [["functionVersion"]],
"Metrics": [{
"Name": "time",
"Unit": "Milliseconds",
"StorageResolution": 60
}]
}]
},
"functionVersion": "$LATEST",
"time": 100,
"requestId": context.awsRequestId
}
) + "\n")
```
### Utilisation du filtrage au niveau du journal avec Node.js
AWS Lambda Pour filtrer les journaux de votre application en fonction de leur niveau de journalisation, votre fonction doit utiliser des journaux au format JSON. Vous pouvez effectuer cette opération de deux façons :
+ Créez des sorties de journal à l'aide des méthodes de console standard et configurez votre fonction pour utiliser le format de journal JSON. AWS Lambda filtre ensuite les sorties de votre journal à l'aide de la paire clé-valeur « niveau » de l'objet JSON décrit dans[Utilisation de journaux JSON structurés avec Node.js](#nodejs-logging-advanced-JSON). Pour savoir comment configurer le format de journal de votre fonction, consultez [Configuration de commandes de journalisation avancées pour votre fonction Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
+ Utilisez une autre bibliothèque ou méthode de journalisation pour créer des journaux structurés JSON dans votre code qui incluent une paire clé-valeur « niveau » définissant le niveau de sortie du journal. Par exemple, vous pouvez utiliser Powertools pour générer des sorties AWS Lambda de journal structurées JSON à partir de votre code. Consultez [Enregistrez et surveillez les fonctions TypeScript Lambda](typescript-logging.md) pour en savoir plus sur l’utilisation de Powertools avec l’exécution Node.js.
Pour que Lambda puisse filtrer les journaux de votre fonction, vous devez également inclure une paire `"timestamp"` clé-valeur dans la sortie de votre journal JSON. L’heure doit être spécifiée dans un format d’horodatage [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) valide. Si vous ne fournissez pas d’horodatage valide, Lambda attribuera au journal le niveau INFO et ajoutera un horodatage pour vous.
Lorsque vous configurez votre fonction pour utiliser le filtrage au niveau des journaux, vous sélectionnez le niveau de journaux que vous souhaitez envoyer AWS Lambda à CloudWatch Logs parmi les options suivantes :
| Niveau de journalisation | Utilisation standard |
| --- | --- |
| TRACE (le plus détaillé) | Les informations les plus précises utilisées pour tracer le chemin d’exécution de votre code |
| DEBUG | Informations détaillées pour le débogage du système |
| INFO | Messages qui enregistrent le fonctionnement normal de votre fonction |
| WARN | Messages relatifs à des erreurs potentielles susceptibles d’entraîner un comportement inattendu si elles ne sont pas traitées |
| ERROR | Messages concernant les problèmes qui empêchent le code de fonctionner comme prévu |
| FATAL (moindre détail) | Messages relatifs à des erreurs graves entraînant l’arrêt du fonctionnement de l’application |
Lambda envoie les journaux du niveau sélectionné et d'un niveau inférieur à. CloudWatch Par exemple, si vous configurez un niveau de journalisation WARN, Lambda envoie des journaux correspondant aux niveaux WARN, ERROR et FATAL.
## Affichage des journaux dans la console Lambda
Vous pouvez utiliser la console Lambda pour afficher la sortie du journal après avoir invoqué une fonction Lambda.
Si votre code peut être testé à partir de l’éditeur **Code** intégré, vous trouverez les journaux dans les **résultats d’exécution**. Lorsque vous utilisez la fonctionnalité de test de console pour invoquer une fonction, vous trouverez **Sortie du journal** dans la section **Détails**.
## Afficher les journaux dans la CloudWatch console
Vous pouvez utiliser la CloudWatch console Amazon pour consulter les journaux de toutes les invocations de fonctions Lambda.
**Pour afficher les journaux sur la CloudWatch console**
1. Ouvrez la [page Groupes de journaux](https://console.aws.amazon.com/cloudwatch/home?#logs:) sur la CloudWatch console.
1. Choisissez le groupe de journaux pour votre fonction (***your-function-name*/aws/lambda/**).
1. Choisissez un flux de journaux.
Chaque flux de journal correspond à une [instance de votre fonction](lambda-runtime-environment.md). Un flux de journal apparaît lorsque vous mettez à jour votre fonction Lambda et lorsque des instances supplémentaires sont créées pour gérer les appels simultanés. Pour trouver les journaux d'un appel spécifique, nous vous recommandons d'instrumenter votre fonction avec. AWS X-Ray X-Ray enregistre des détails sur la demande et le flux de journaux dans le suivi.
## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
AWS CLI Il s'agit d'un outil open source qui vous permet d'interagir avec les AWS services à l'aide de commandes dans votre interface de ligne de commande. Pour effectuer les étapes de cette section, vous devez disposer de la [version 2 de l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
Vous pouvez utiliser [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) pour récupérer les journaux d’une invocation à l’aide de l’option de commande `--log-type`. La réponse inclut un champ `LogResult` qui contient jusqu’à 4 Ko de journaux codés en base64 provenant de l’invocation.
**Example récupérer un ID de journal**
L’exemple suivant montre comment récupérer un *ID de journal* à partir du champ `LogResult` d’une fonction nommée `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example décoder les journaux**
Dans la même invite de commandes, utilisez l’utilitaire `base64` pour décoder les journaux. L’exemple suivant montre comment récupérer les journaux encodés en base64 pour `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
Vous devriez voir la sortie suivante :
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
L’utilitaire `base64` est disponible sous Linux, macOS et [Ubuntu sous Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Les utilisateurs de macOS auront peut-être besoin d’utiliser `base64 -D`.
**Example Script get-logs.sh**
Dans la même invite de commandes, utilisez le script suivant pour télécharger les cinq derniers événements de journalisation. Le script utilise `sed` pour supprimer les guillemets du fichier de sortie et attend 15 secondes pour permettre la mise à disposition des journaux. La sortie comprend la réponse de Lambda, ainsi que la sortie de la commande `get-log-events`.
Copiez le contenu de l’exemple de code suivant et enregistrez-le dans votre répertoire de projet Lambda sous `get-logs.sh`.
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS et Linux (uniquement)**
Dans la même invite de commandes, les utilisateurs macOS et Linux peuvent avoir besoin d’exécuter la commande suivante pour s’assurer que le script est exécutable.
```
chmod -R 755 get-logs.sh
```
**Example récupérer les cinq derniers événements de journal**
Dans la même invite de commande, exécutez le script suivant pour obtenir les cinq derniers événements de journalisation.
```
./get-logs.sh
```
Vous devriez voir la sortie suivante:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Suppression de journaux
Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker des journaux indéfiniment, supprimez le groupe de journaux ou [configurez une période de conservation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) à l’issue de laquelle les journaux sont supprimés automatiquement.
# Instrumentation du code Node.js dans AWS Lambda
Lambda s'intègre pour vous aider AWS X-Ray à suivre, à déboguer et à optimiser les applications Lambda. Vous pouvez utiliser X-Ray pour suivre une demande lorsque celle-ci parcourt les ressources de votre application, qui peuvent inclure des fonctions Lambda et d'autres services AWS .
Pour envoyer des données de suivi à X-Ray, vous pouvez utiliser l'une des deux bibliothèques SDK suivantes :
+ [AWS Distro for OpenTelemetry (ADOT)](https://aws.amazon.com/otel) — Une distribution sécurisée, prête pour la production et AWS prise en charge du SDK (). OpenTelemetry OTel
+ [Kit SDK AWS X-Ray pour Node.js](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs.html) – Un kit SDK permettant de générer et d’envoyer des données de suivi à X-Ray.
Chacune d'entre elles SDKs propose des moyens d'envoyer vos données de télémétrie au service X-Ray. Vous pouvez ensuite utiliser X-Ray pour afficher, filtrer et avoir un aperçu des métriques de performance de votre application, afin d’identifier les problèmes et les occasions d’optimiser votre application.
**Important**
Les outils X-Ray et Powertools pour AWS Lambda SDKs font partie d'une solution d'instrumentation étroitement intégrée proposée par AWS. Les couches ADOT Lambda font partie d’une norme industrielle pour l’instrumentation de traçage qui collecte plus de données en général, mais qui peut ne pas convenir à tous les cas d’utilisation. Vous pouvez implémenter le end-to-end traçage dans X-Ray en utilisant l'une ou l'autre solution. Pour en savoir plus sur le choix entre les deux, consultez [Choosing between the AWS Distro for Open Telemetry and](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-choosing) X-Ray. SDKs
**Topics**
+ [
## Utilisation d'ADOT pour instrumenter vos fonctions Node.js
](#nodejs-adot)
+ [
## Utilisation du kit SDK X-Ray pour instrumenter vos fonctions Node.js
](#nodejs-xray-sdk)
+ [
## Activation du suivi avec la console Lambda
](#nodejs-tracing-console)
+ [
## Activation du suivi avec l’API Lambda
](#nodejs-tracing-api)
+ [
## Activation du traçage avec CloudFormation
](#nodejs-tracing-cloudformation)
+ [
## Interprétation d’un suivi X-Ray
](#nodejs-tracing-interpretation)
+ [
## Stockage des dépendances d’exécution dans une couche (kit SDK X-Ray)
](#nodejs-tracing-layers)
## Utilisation d'ADOT pour instrumenter vos fonctions Node.js
ADOT fournit des couches [Lambda](chapter-layers.md) entièrement gérées qui regroupent tout ce dont vous avez besoin pour collecter des données de télémétrie à l'aide du SDK. OTel En consommant cette couche, vous pouvez instrumenter vos fonctions Lambda sans avoir à modifier le code de fonction. Vous pouvez également configurer votre couche pour effectuer une initialisation personnalisée de OTel. Pour de plus amples informations, veuillez consulter [Configuration personnalisée pour ADOT Collector sur Lambda](https://aws-otel.github.io/docs/getting-started/lambda#custom-configuration-for-the-adot-collector-on-lambda) dans la documentation ADOT.
Pour les exécutions python, vous pouvez ajouter le**AWS couche Lambda gérée pour ADOT Javascript**pour instrumenter automatiquement vos fonctions. Pour obtenir des instructions détaillées sur la façon d'ajouter cette couche, consultez [AWS Distro for OpenTelemetry Lambda JavaScript Support](https://aws-otel.github.io/docs/getting-started/lambda/lambda-js) dans la documentation ADOT.
## Utilisation du kit SDK X-Ray pour instrumenter vos fonctions Node.js
Pour enregistrer des détails sur les appels effectués par votre fonction Lambda à d’autres ressources de votre application, vous pouvez également utiliser le Kit SDK AWS X-Ray pour Node.js. Pour obtenir ce kit SDK, ajoutez le package `aws-xray-sdk-core` aux dépendances de votre application.
**Example [blank-nodejs/package.json](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/package.json)**
```
{
"name": "blank-nodejs",
"version": "1.0.0",
"private": true,
"devDependencies": {
"jest": "29.7.0"
},
"dependencies": {
"@aws-sdk/client-lambda": "3.345.0",
"aws-xray-sdk-core": "3.5.3"
},
"scripts": {
"test": "jest"
}
}
```
Pour instrumenter les clients du AWS SDK dans la [AWS SDK pour JavaScript v3](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/welcome.html), encapsulez l'instance du client avec la `captureAWSv3Client` méthode.
**Example [nodejs/function/indexblank-.js](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/function/index.js) — Suivi d'un client AWS SDK**
```
const AWSXRay = require('aws-xray-sdk-core');
const { LambdaClient, GetAccountSettingsCommand } = require('@aws-sdk/client-lambda');
// Create client outside of handler to reuse
const lambda = AWSXRay.captureAWSv3Client(new LambdaClient());
// Handler
exports.handler = async function(event, context) {
event.Records.forEach(record => {
...
```
Le moteur d'exécution Lambda définit certaines variables d'environnement pour configurer le kit SDK X-Ray. Lambda définit par exemple `AWS_XRAY_CONTEXT_MISSING` à `LOG_ERROR` pour éviter de générer des erreurs d'environnement d'exécution à partir du kit SDK X-Ray. Pour définir une stratégie manquante de contexte personnalisée, remplacez la variable d'environnement dans votre configuration de fonction pour n'avoir aucune valeur, puis vous pouvez définir la stratégie manquante de contexte par programme.
**Example Exemple de code d'initialisation**
```
const AWSXRay = require('aws-xray-sdk-core');
// Configure the context missing strategy to do nothing
AWSXRay.setContextMissingStrategy(() => {});
```
Pour de plus amples informations, veuillez consulter [Utilisation des variables d’environnement Lambda](configuration-envvars.md).
Une fois que vous avez ajouté les bonnes dépendances et effectué les modifications de code nécessaires, activez le suivi dans la configuration de votre fonction via la console Lambda ou l’API.
## Activation du suivi avec la console Lambda
Pour activer/désactiver le traçage actif sur votre fonction Lambda avec la console, procédez comme suit :
**Pour activer le traçage actif**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez **Configuration**, puis choisissez **Outils de surveillance et d’opérations**.
1. Dans **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **Signaux CloudWatch d'application et AWS X-Ray** sélectionnez **Activer les traces** de **service Lambda**.
1. Choisissez **Enregistrer**.
## Activation du suivi avec l’API Lambda
Configurez le suivi sur votre fonction Lambda avec le AWS SDK AWS CLI or, utilisez les opérations d'API suivantes :
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
L'exemple de AWS CLI commande suivant active le suivi actif sur une fonction nommée **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
Le mode de suivi fait partie de la configuration spécifique de la version lorsque vous publiez une version de votre fonction. Vous ne pouvez pas modifier le mode de suivi sur une version publiée.
## Activation du traçage avec CloudFormation
Pour activer le suivi d'une `AWS::Lambda::Function` ressource dans un CloudFormation modèle, utilisez la `TracingConfig` propriété.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Pour une `AWS::Serverless::Function` ressource AWS Serverless Application Model (AWS SAM), utilisez la `Tracing` propriété.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
## Interprétation d’un suivi X-Ray
Votre fonction a besoin d’une autorisation pour charger des données de suivi vers X-Ray. Lorsque vous activez le suivi actif dans la console Lambda, Lambda ajoute les autorisations requises au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Sinon, ajoutez la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)politique au rôle d'exécution.
Une fois que vous avez configuré le suivi actif, vous pouvez observer des demandes spécifiques via votre application. Le [ graphique de services X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html#xray-concepts-servicegraph) affiche des informations sur votre application et tous ses composants. L’exemple suivant montre une application dotée de deux fonctions. La fonction principale traite les événements et renvoie parfois des erreurs. La deuxième fonction située en haut traite les erreurs qui apparaissent dans le groupe de journaux de la première et utilise le AWS SDK pour appeler X-Ray, Amazon Simple Storage Service (Amazon S3) et Amazon Logs. CloudWatch
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sample-errorprocessor-servicemap.png)
X-Ray ne trace pas toutes les requêtes vers votre application. X-Ray applique un algorithme d’échantillonnage pour s’assurer que le suivi est efficace, tout en fournissant un échantillon représentatif de toutes les demandes. Le taux d’échantillonnage est 1 demande par seconde et 5 % de demandes supplémentaires. Vous ne pouvez pas configurer ce taux d’échantillonnage X-Ray pour vos fonctions.
Dans X-Ray, un *suivi* enregistre des informations sur une demande traitée par un ou plusieurs *services*. Lambda enregistre deux segments par suivi, ce qui a pour effet de créer deux nœuds sur le graphique du service. L’image suivante met en évidence ces deux nœuds :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/xray-servicemap-function.png)
Le premier nœud sur la gauche représente le service Lambda qui reçoit la demande d’invocation. Le deuxième nœud représente votre fonction Lambda spécifique. L’exemple suivant illustre une trace avec ces deux segments. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Cet exemple développe le segment `AWS::Lambda::Function` pour afficher ses trois sous-segments.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
L’exemple de suivi présenté ici illustre le segment de fonction à l’ancienne. Les différences entre les segments à l’ancienne et de style moderne sont décrites dans les paragraphes suivants.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
Le segment de fonction à l’ancienne contient les sous-segments suivants :
+ **Initialization (Initialisation)** : représente le temps passé à charger votre fonction et à exécuter le [code d’initialisation](foundation-progmodel.md). Ce sous-segment apparaît pour le premier événement traité par chaque instance de votre fonction.
+ **Invocation** – Représente le temps passé à exécuter votre code de gestionnaire.
+ **Overhead (Travail supplémentaire)** – Représente le temps que le fichier d’exécution Lambda passe à se préparer à gérer l’événement suivant.
Le segment de fonction de style moderne ne contient pas de sous-segment `Invocation`. À la place, les sous-segments du client sont directement rattachés au segment de fonction. Pour plus d’informations sur la structure des segments de fonction à l’ancienne et de style moderne, consultez [Comprendre les suivis X-Ray](services-xray.md#services-xray-traces).
Vous pouvez également utiliser des clients HTTP, enregistrer des requêtes SQL et créer des sous-segments personnalisés avec des annotations et des métadonnées. Pour plus d’informations, consultez [Kit SDK AWS X-Ray pour Node.js](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs.html) dans le *AWS X-Ray Guide du développeur*.
**Tarification**
Vous pouvez utiliser le X-Ray Tracing gratuitement chaque mois jusqu'à une certaine limite dans le cadre du niveau AWS gratuit. Au-delà de ce seuil, X-Ray facture le stockage et la récupération du suivi. Pour en savoir plus, consultez [Pricing AWS X-Ray](https://aws.amazon.com/xray/pricing/) (Tarification).
## Stockage des dépendances d’exécution dans une couche (kit SDK X-Ray)
Si vous utilisez le SDK X-Ray pour instrumenter le code de fonction des clients du AWS SDK, votre package de déploiement peut devenir très volumineux. Pour éviter de charger des dépendances d’environnement d’exécution chaque fois que vous mettez à jour votre code de fonction, empaquetez le kit SDK X-Ray dans une [couche Lambda](chapter-layers.md).
L'exemple suivant montre une ressource `AWS::Serverless::LayerVersion` qui stocke le Kit SDK AWS X-Ray pour Node.js.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) : couche de dépendances**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
CodeUri: function/.
Tracing: Active
Layers:
- !Ref libs
...
libs:
Type: [AWS::Serverless::LayerVersion](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-layerversion.html)
Properties:
LayerName: blank-nodejs-lib
Description: Dependencies for the blank sample app.
ContentUri: lib/.
CompatibleRuntimes:
- nodejs24.x
```
Avec cette configuration, vous ne mettez à jour les fichiers de couche de bibliothèque que si vous modifiez vos dépendances d’exécution. Étant donné que le package de déploiement de la fonction contient uniquement votre code, cela peut contribuer à réduire les temps de chargement.
La création d’une couche de dépendances nécessite des modifications de génération pour créer l’archive des couches avant le déploiement. Pour un exemple fonctionnel, consultez l'exemple d'application [blank-nodejs](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs).