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.
# Configuration des AWS Lambda fonctions
Découvrez comment configurer les capacités et options de base de votre fonction Lambda à l'aide de l'API ou de la console Lambda.
**[archives de fichiers .zip](configuration-function-zip.md) **
Créez un package de déploiement de fonctions Lambda lorsque vous souhaitez inclure des dépendances, des couches d'exécution personnalisées ou des fichiers autres que le code de votre fonction. Le package de déploiement est une archive de fichier .zip contenant le code de votre fonction et ses dépendances.
**[Images de conteneur](images-create.md) **
Utilisez des images de conteneur pour empaqueter le code de votre fonction et ses dépendances lorsque vous avez besoin de mieux contrôler le processus de génération ou si votre fonction nécessite des configurations d'exécution personnalisées. Vous pouvez créer, tester et déployer des fonctions Lambda sous forme d'images de conteneur à l'aide d'outils tels que Docker CLI.
**[Mémoire](configuration-memory.md)**
Découvrez comment et quand augmenter la mémoire des fonctions.
**[Stockage éphémère](configuration-ephemeral-storage.md) **
Découvrez comment et quand augmenter la capacité de stockage temporaire de votre fonction.
**[Expiration](configuration-timeout.md) **
Découvrez comment et quand augmenter le délai d’expiration de votre fonction.
**[Configuration durable](durable-configuration.md) **
Permettez à vos fonctions Lambda de s'exécuter pendant de longues périodes (jusqu'à un an) tout en conservant leur état entre les appels. Configurez les délais d'exécution, la rétention des états et le comportement de gestion des versions pour les flux de travail dynamiques de longue durée. Les fonctions durables vous permettent de créer des processus complexes en plusieurs étapes capables de suspendre, de reprendre et de gérer automatiquement les interruptions.
** [Variables d'environnement](configuration-envvars.md)**
Vous pouvez rendre le code de votre fonction portable et garder les secrets de votre code en les stockant dans la configuration de votre fonction à l'aide de variables d'environnement.
**[Réseaux sortants](configuration-vpc.md) **
Vous pouvez utiliser votre fonction Lambda avec les AWS ressources d'un Amazon VPC. La connexion de votre fonction à un VPC vous permet d'accéder aux ressources d'un sous-réseau privé, telles que les bases de données relationnelles et les caches.
** [Réseaux entrants](configuration-vpc-endpoints.md)**
Vous pouvez utiliser un point de terminaison d'un VPC d'interface pour invoquer vos fonctions Lambda sans traverser l'Internet public.
**[Système de fichiers](configuration-filesystem.md)**
Vous pouvez utiliser votre fonction Lambda pour monter un Amazon EFS dans un répertoire local. Un système de fichiers permet à votre code de fonction d'accéder à des ressources partagées et de les modifier en toute sécurité et avec une simultanéité élevée.
**[Alias](configuration-aliases.md)**
Vous pouvez configurer vos clients pour qu'ils invoquent une version spécifique de la fonction Lambda en utilisant un alias, au lieu de mettre à jour le client.
**[Versions](configuration-versions.md)**
En publiant une version de votre fonction, vous pouvez stocker votre code et votre configuration comme une ressource séparée qui ne peut pas être modifiée.
**[Balises](configuration-tags.md)**
Utilisez des balises pour activer le contrôle d'accès basé sur les attributs (ABAC), pour organiser vos fonctions Lambda et pour filtrer et générer des rapports sur vos fonctions à l'aide des services ou AWS Billing and AWS Cost Explorer Cost Management.
**[Streaming des réponses](configuration-response-streaming.md)**
Vous pouvez configurer votre fonction Lambda URLs pour transmettre les charges utiles de réponse aux clients. Le streaming de réponses peut profiter aux applications sensibles à la latence en améliorant les performances de temps au premier octet (TTFB). En effet, vous pouvez renvoyer des réponses partielles au client dès qu'elles sont disponibles. En outre, vous pouvez utiliser le streaming de réponses pour créer des fonctions qui renvoient des charges utiles plus importantes.
**[Point final de métadonnées](configuration-metadata-endpoint.md)**
Utilisez le point de terminaison de métadonnées Lambda pour découvrir dans quelle zone de disponibilité s'exécute votre fonction, ce qui vous permet d'optimiser la latence en acheminant vers des ressources de même zone de zone de disponibilité et de mettre en œuvre des modèles de résilience compatibles avec l'AZ.
# Déploiement des fonctions Lambda comme des archives de fichiers .zip
Lorsque vous créez une fonction Lambda, vous empaquetez le code de votre fonction dans un package de déploiement. Lambda prend en charge deux types de packages de déploiement : les images conteneurs et les archives de fichier .zip. Le flux de travail de création d'une fonction dépend du type de package de déploiement. Pour configurer une fonction définie en tant qu'image de conteneur, consultez [Création d’une fonction Lambda à l’aide d’une image de conteneur](images-create.md).
Vous pouvez utiliser la console Lambda et l'API Lambda pour créer une fonction définie avec une archive de fichiers .zip. Vous pouvez également charger un fichier .zip mis à jour pour modifier le code de la fonction.
**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.
**Topics**
+ [
## Création de la fonction
](#configuration-function-create)
+ [
## Utilisation de l'éditeur de code de la console
](#configuration-functions-console-update)
+ [
## Mise à jour du code de fonction
](#configuration-function-update)
+ [
## Modification de l'environnement d'exécution
](#configuration-function-runtime)
+ [
## Modification de l'architecture
](#configuration-function-arch)
+ [
## Utilisation de l'API Lambda
](#configuration-function-api)
+ [
## Téléchargement du code de votre fonction
](#configuration-function-download)
+ [
## CloudFormation
](#configuration-function-cloudformation)
+ [
# Chiffrement des packages de déploiement Lambda au format .zip
](encrypt-zip-package.md)
## Création de la fonction
Lorsque vous créez une fonction définie avec une archive de fichiers .zip, vous choisissez un modèle de code, la version du langage et le rôle d'exécution pour la fonction. Vous ajoutez votre code de fonction après que Lambda a créé la fonction.
**Pour créer la fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez **Create function** (Créer une fonction).
1. Choisissez **Créer à partir de zéro** ou **Utiliser un plan** pour créer votre fonction.
1. Sous **Informations de base**, procédez comme suit :
1. Pour **Function name** (Nom de la fonction), saisissez le nom de la fonction. Les noms de fonctions sont limités à 64 caractères.
1. Pour **Runtime**, sélectionnez la version du langage à utiliser pour votre fonction.
1. (Facultatif) Pour **Architecture**, choisissez l'architecture de l'ensemble des instructions pour utiliser la fonction. L'architecture par défaut est x86\$164. Lorsque vous créez le package de déploiement de la fonction, assurez-vous qu'il est compatible avec cette [architecture de l'ensemble des instructions](foundation-arch.md).
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 utiliser un rôle existant.
1. (Facultatif) Développez **Advanced settings (Paramètres avancés)**. Vous pouvez choisir une **Configuration de signature de code** pour la fonction. Vous pouvez également configurer un (VPC Amazon) auquel la fonction puisse accéder.
1. Sélectionnez **Créer une fonction**.
Lambda crée la nouvelle fonction. Vous pouvez désormais utiliser la console pour ajouter le code de fonction et configurer d'autres paramètres et caractéristiques de la fonction. Pour obtenir des instructions de déploiement de code, consultez la page du gestionnaire pour l'exécution utilisée par votre fonction.
------
#### [ Node.js ]
[Déployer des fonctions Lambda en Node.js avec des archives de fichiers .zip](nodejs-package.md)
------
#### [ Python ]
[Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python](python-package.md)
------
#### [ Ruby ]
[Déployer des fonctions Lambda en Ruby avec des archives de fichiers .zip](ruby-package.md)
------
#### [ Java ]
[Déployer des fonctions Lambda en Java avec des archives de fichiers .zip ou JAR](java-package.md)
------
#### [ Go ]
[Déployer des fonctions Lambda Go avec des archives de fichiers .zip](golang-package.md)
------
#### [ C\$1 ]
[Créez et déployez des fonctions Lambda C\$1 à l’aide des archives de fichiers .zip](csharp-package.md)
------
#### [ PowerShell ]
[Déployer des fonctions Lambda PowerShell avec des archives de fichiers .zip](powershell-package.md)
------
## Utilisation de l'éditeur de code de la console
La console crée une fonction Lambda avec un seul fichier source. Pour le scripting, vous pouvez modifier ce fichier et ajouter des fichiers à l'aide de l'éditeur de code intégré. Choisissez **Save** pour enregistrer les changements. Ensuite, pour exécuter votre code, choisissez **Test**.
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.
## Mise à jour du code de fonction
Pour le scripting (Node.js, Python et Ruby), vous pouvez modifier votre code de fonction dans l'éditeur intégré. Si ce code est d'une taille supérieure à 3 Mo, si vous devez ajouter des bibliothèques ou dans le cas des langages que l'éditeur ne prend pas en charge (Java, Go, C\$1), vous devez charger le code de votre fonction en tant qu'archive .zip. Si l'archive de fichier .zip est d'une taille inférieure à 50 Mo, vous pouvez charger l'archive de fichier .zip à partir de votre machine locale. Si le fichier est d'une taille supérieure à 50 Mo, chargez le fichier dans la fonction à partir d'un compartiment Amazon S3.
**Pour charger le code de fonction en tant qu'archive .zip**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction à mettre à jour, puis choisissez l'onglet **Code**.
1. Sous **Code source** (Source du code), sélectionnez **Upload from** (Charger depuis).
1. Choisissez **.zip file (fichier .zip)**, puis **Upload (Charger)**.
1. Dans le sélecteur de fichiers, sélectionnez la nouvelle version de l'image et choisissez **Open (Ouvrir)**, puis **Save (Enregistrer)**.
1. (Alternative à l'étape 4) Choisissez **Emplacement Amazon S3**.
1. Dans la zone de texte, saisissez l'URL du lien S3 de l'archive de fichiers .zip, puis choisissez **Enregistrer**.
## Modification de l'environnement d'exécution
Si vous mettez à jour la configuration de la fonction pour utiliser un nouvel environnement d'exécution, vous devrez peut-être mettre à jour le code de la fonction pour qu'il soit compatible avec la nouvelle version. Si vous mettez à jour la configuration de la fonction pour utiliser une autre exécution, vous **devez** fournir un nouveau code de fonction compatible avec l'exécution et l'architecture. Pour obtenir des instructions sur comment créer un package de déploiement pour le code de la fonction, consultez la page du gestionnaire de l'exécution utilisé par la fonction.
Les images de base de Node.js 20, Python 3.12, Java 21, .NET 8, Ruby 3.3 et versions ultérieures sont basées sur l’image de conteneur minimale Amazon Linux 2023. 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`. Pour plus d’informations, consultez [Présentation de l’environnement d’exécution Amazon Linux 2023 pour AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/) sur le blog AWS Compute.
**Pour modifier l'environnement d'exécution**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction à mettre à jour, puis choisissez l'onglet **Code**.
1. Faites défiler jusqu'à la section **Runtime settings (Paramètres d'exécution)**, qui se trouve sous l'éditeur de code.
1. Choisissez **Modifier**.
1. Pour **Runtime** (Environnement d'exécution), sélectionnez l'identifiant de l'environnement d'exécution.
1. Pour **Gestionnaire**, spécifiez le nom de fichier et gestionnaire de votre fonction.
1. Pour **Architecture**, choisissez l'architecture de l'ensemble des instructions pour utiliser votre fonction.
1. Choisissez **Enregistrer**.
## Modification de l'architecture
Avant de pouvoir modifier l'architecture de l'ensemble des instructions, vous devez vous assurer que le code de la fonction est compatible avec l'architecture cible.
Si vous utilisez Node.js, Python ou Ruby et que vous modifiez le code de fonction dans l'éditeur, le code existant peut s'exécuter sans modification.
Toutefois, si vous fournissez le code de fonction en utilisant un package de déploiement d'archives de fichiers .zip, vous devez préparer une nouvelle archive de fichiers .zip compilée et créée correctement pour l'exécution cible et l'architecture de l'ensemble des instructions. Pour obtenir des instructions, veuillez consulter la page du gestionnaire d'exécution de la fonction.
**Pour modifier l'architecture de l'ensemble des instructions**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction à mettre à jour, puis choisissez l'onglet **Code**.
1. Sous **Paramètres du runtime**, choisissez **Modifier**.
1. Pour **Architecture**, choisissez l'architecture de l'ensemble des instructions pour utiliser votre fonction.
1. Choisissez **Enregistrer**.
## Utilisation de l'API Lambda
Pour créer et configurer une fonction qui utilise 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)
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
## Téléchargement du code de votre fonction
Vous pouvez télécharger la version non publiée actuelle (`$LATEST`) de l’archive .zip du code de votre fonction via la console Lambda. Avant de démarrer, vérifiez que vous disposez des autorisations IAM suivantes :
+ `iam:GetPolicy`
+ `iam:GetPolicyVersion`
+ `iam:GetRole`
+ `iam:GetRolePolicy`
+ `iam:ListAttachedRolePolicies`
+ `iam:ListRolePolicies`
+ `iam:ListRoles`
**Pour télécharger l’archive .zip du code de fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction pour laquelle vous souhaitez télécharger l’archive .zip du code de la fonction.
1. Dans **Aperçu de la fonction**, cliquez sur le bouton **Télécharger**, puis choisissez **Télécharger l’archive .zip du code de fonction**
1. Vous pouvez également choisir **Télécharger AWS SAM le fichier** pour générer et télécharger un modèle SAM en fonction de la configuration de votre fonction. Vous pouvez aussi choisir **Télécharger les deux** pour télécharger à la fois l’archive .zip et le modèle SAM.
## CloudFormation
Vous pouvez l'utiliser CloudFormation pour créer une fonction Lambda qui utilise une archive de fichiers .zip. Dans votre CloudFormation modèle, la `AWS::Lambda::Function` ressource spécifie la fonction Lambda. Pour une description des propriétés de la `AWS::Lambda::Function` ressource, reportez-vous [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)au *guide de l'AWS CloudFormation utilisateur*.
Dans la ressource `AWS::Lambda::Function`, définissez les propriétés suivantes pour créer une fonction définie en tant qu'archive de fichiers .zip :
+ AWS::Lambda::Function
+ PackageType — Réglez sur`Zip`.
+ Code – Saisissez le nom du compartiment Amazon S3 et le nom du fichier .zip dans les champs `S3Bucket` et `S3Key`. Pour Node.js ou Python, vous pouvez fournir le code source inclus de votre fonction Lambda.
+ Runtime – Définissez la valeur du runtime.
+ Architecture — Définissez la valeur de l'architecture `arm64` pour utiliser le processeur AWS Graviton2. La valeur de l'architecture par défaut est `x86_64`.
# Chiffrement des packages de déploiement Lambda au format .zip
Lambda fournit toujours le chiffrement côté serveur au repos pour les packages de déploiement .zip et les détails de configuration des fonctions avec une AWS KMS key. Par défaut, Lambda utilise une [Clé détenue par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). Si ce comportement par défaut convient à votre flux de travail, vous n'avez rien d'autre à configurer. AWS l'utilisation de cette clé ne vous est pas facturée.
Si vous préférez, vous pouvez plutôt fournir une clé gérée par le AWS KMS client. Vous pouvez procéder ainsi pour contrôler la rotation de la clé KMS ou pour répondre aux exigences de votre organisation en matière de gestion des clés KMS. Lorsque vous utilisez une clé gérée par le client, seuls les utilisateurs de votre compte ayant accès à la clé KMS peuvent visualiser ou gérer le code ou la configuration de la fonction.
Les clés gérées par le client entraînent des AWS KMS frais standard. Pour en savoir plus, consultez [Pricing AWS Key Management Service](https://aws.amazon.com/kms/pricing/) (Tarification).
## Création d’une clé gérée par le client
Vous pouvez créer une clé symétrique gérée par le client en utilisant le AWS Management Console, ou le AWS KMS APIs.
**Pour créer une clé symétrique gérée par le client**
Suivez les étapes de la rubrique [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) dans le *Guide du développeur AWS Key Management Service *.
### Permissions
**Stratégie de clé**
Les [stratégies de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) contrôlent l’accès à votre clé gérée par le client. Chaque clé gérée par le client doit avoir exactement une stratégie de clé, qui contient des instructions qui déterminent les personnes pouvant utiliser la clé et comment elles peuvent l’utiliser. Pour plus d’informations, consultez [How to change a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-how-to) dans le *Guide du développeur AWS Key Management Service *.
Lorsque vous utilisez une clé gérée par le client pour chiffrer un package de déploiement .zip, Lambda n’ajoute aucun [octroi](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) à la clé. Au lieu de cela, votre politique AWS KMS clé doit autoriser Lambda à appeler les opérations d' AWS KMS API suivantes en votre nom :
+ [km : GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
L'exemple de politique de clé suivant permet à toutes les fonctions Lambda du compte 111122223333 d'appeler les AWS KMS opérations requises pour la clé gérée par le client spécifiée :
**Example AWS KMS politique clé**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:lambda:FunctionArn": "arn:aws:lambda:us-east-1:111122223333:function:*"
}
}
}
]
}
```
Pour plus d'informations sur le [dépannage des clés d’accès](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html#example-no-iam), consultez le *Guide du développeur AWS Key Management Service *.
**Autorisations de principal**
Lorsque vous utilisez une clé gérée par le client pour chiffrer un package de déploiement .zip, seuls les [principaux](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html) ayant accès à cette clé peuvent accéder au package de déploiement .zip. Par exemple, les principaux qui n'ont pas accès à la clé gérée par le client ne peuvent pas télécharger le package .zip à l'aide de l'URL S3 présignée incluse dans la réponse. [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html) Une `AccessDeniedException` est renvoyée dans la section `Code` de la réponse.
**Example AWS KMS AccessDeniedException**
```
{
"Code": {
"RepositoryType": "S3",
"Error": {
"ErrorCode": "AccessDeniedException",
"Message": "KMS access is denied. Check your KMS permissions. KMS Exception: AccessDeniedException KMS Message: User: arn:aws:sts::111122223333:assumed-role/LambdaTestRole/session is not authorized to perform: kms:Decrypt on resource: arn:aws:kms:us-east-1:111122223333:key/key-id with an explicit deny in a resource-based policy"
},
"SourceKMSKeyArn": "arn:aws:kms:us-east-1:111122223333:key/key-id"
},
...
```
Pour plus d'informations sur les autorisations relatives aux AWS KMS clés, consultez [Authentification et contrôle d'accès pour AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html).
## Utilisation d’une clé gérée par le client pour votre package de déploiement .zip
Utilisez les paramètres d’API suivants pour configurer les clés gérées par le client pour les packages de déploiement .zip :
+ [Source KMSKey Arn](https://docs.aws.amazon.com/lambda/latest/api/API_FunctionCode.html#lambda-Type-FunctionCode-SourceKMSKeyArn) : chiffre le package de déploiement .zip source (le fichier que vous chargez).
+ [KMSKeyArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-KMSKeyArn) : chiffre les [variables d'environnement et les instantanés SnapStart](configuration-envvars-encryption.md) [Lambda](snapstart.md).
Lorsque `SourceKMSKeyArn` et `KMSKeyArn` sont tous deux spécifiés, Lambda utilise la clé `KMSKeyArn` pour chiffrer la version décompressée du package que Lambda utilise pour invoquer la fonction. Lorsque `SourceKMSKeyArn` est spécifié mais que `KMSKeyArn` ne l’est pas, Lambda utilise une [Clé gérée par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)pour chiffrer la version décompressée du package.
------
#### [ Lambda console ]
**Pour ajouter le chiffrement par clé gérée par le client lors de la création d’une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Choisissez **Author from scratch** (Créer à partir de zéro) ou **Container image** (Image de conteneur).
1. Sous **Basic information** (Informations de base), procédez comme suit :
1. Pour **Function name (Nom de la fonction)**, saisissez le nom de la fonction.
1. Pour **Runtime**, sélectionnez la version du langage à utiliser pour votre fonction.
1. Développez **les paramètres avancés**, puis sélectionnez **Activer le chiffrement avec une clé gérée par AWS KMS le client**.
1. Choisissez une clé gérée par le client.
1. Choisissez **Créer une fonction**.
Pour supprimer le chiffrement par clé gérée par le client ou pour utiliser une autre clé, vous devez télécharger à nouveau le package de déploiement .zip.
**Pour ajouter le chiffrement par clé gérée par le client à une fonction existante**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Dans le volet **Source du code**, choisissez **Charger à partir de**.
1. Choisissez un **fichier .zip** ou un **emplacement Amazon S3**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/upload-zip.png)
1. Importez le fichier ou saisissez l’emplacement Amazon S3.
1. Choisissez **Activer le chiffrement avec une clé gérée par le AWS KMS client**.
1. Choisissez une clé gérée par le client.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
**Pour ajouter un chiffrement par clé gérée par le client lors de la création d’une fonction**
Dans l’exemple [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) suivant :
+ `--code`: Spécifie le chemin local vers le package de déploiement .zip (`ZipFile`) et la clé gérée par le client pour le chiffrer ()`SourceKMSKeyArn`.
+ `--kms-key-arn` : spécifie la clé gérée par le client pour chiffrer les variables d’environnement et la version décompressée du package de déploiement.
```
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 ZipFile=fileb://myFunction.zip,SourceKMSKeyArn=arn:aws:kms:us-east-1:111122223333:key/key-id \
--kms-key-arn arn:aws:kms:us-east-1:111122223333:key/key2-id
```
Dans l’exemple [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) suivant :
+ `--code`: Spécifie l'emplacement du fichier .zip dans un compartiment Amazon S3 (`S3Bucket`,`S3Key`,`S3ObjectVersion`) et la clé gérée par le client pour le chiffrer (`SourceKMSKeyArn`).
+ `--kms-key-arn` : spécifie la clé gérée par le client pour chiffrer les variables d’environnement et la version décompressée du package de déploiement.
```
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,SourceKMSKeyArn=arn:aws:kms:us-east-1:111122223333:key/key-id \
--kms-key-arn arn:aws:kms:us-east-1:111122223333:key/key2-id
```
**Pour ajouter un chiffrement par clé gérée par le client à une fonction existante**
Dans l'[update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)exemple suivant :
+ `--zip-file` : spécifie le chemin local du package de déploiement .zip.
+ `--source-kms-key-arn` : spécifie la clé gérée par le client pour chiffrer la version compressée du package de déploiement. Lambda utilise une clé AWS détenue pour chiffrer le package décompressé pour les invocations de fonctions. Si vous souhaitez utiliser une clé gérée par le client pour chiffrer la version décompressée du package, exécutez la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande avec l'option. `--kms-key-arn`
```
aws lambda update-function-code \
--function-name myFunction \
--zip-file fileb://myFunction.zip \
--source-kms-key-arn arn:aws:kms:us-east-1:111122223333:key/key-id
```
Dans l'[update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)exemple suivant :
+ `--s3-bucket` : spécifie l’emplacement du fichier .zip dans un compartiment Amazon S3.
+ `--s3-key` : spécifie la clé Amazon S3 du package de déploiement.
+ `--s3-object-version` : pour les objets versionnés, la version de l’objet de package de déploiement à utiliser.
+ `--source-kms-key-arn` : spécifie la clé gérée par le client pour chiffrer la version compressée du package de déploiement. Lambda utilise une clé AWS détenue pour chiffrer le package décompressé pour les invocations de fonctions. Si vous souhaitez utiliser une clé gérée par le client pour chiffrer la version décompressée du package, exécutez la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande avec l'option. `--kms-key-arn`
```
aws lambda update-function-code \
--function-name myFunction \
--s3-bucket amzn-s3-demo-bucket \
--s3-key myFileName.zip \
--s3-object-version myObject Version
--source-kms-key-arn arn:aws:kms:us-east-1:111122223333:key/key-id
```
**Pour supprimer le chiffrement par clé gérée par le client d’une fonction existante**
Dans l'[update-function-code](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)exemple suivant, `--zip-file` indique le chemin local vers le package de déploiement .zip. Lorsque vous exécutez cette commande sans `--source-kms-key-arn` option, Lambda utilise une clé AWS détenue pour chiffrer la version compressée du package de déploiement.
```
aws lambda update-function-code \
--function-name myFunction \
--zip-file fileb://myFunction.zip
```
------
# Création d’une fonction Lambda à l’aide d’une image de conteneur
Le code de votre AWS Lambda fonction se compose de scripts ou de programmes compilés et de leurs dépendances. Pour déployer votre code de fonction vers Lambda, vous utilisez un *package de déploiement*. Lambda prend en charge deux types de packages de déploiement : les images conteneurs et les archives de fichiers .zip.
Il existe trois méthodes pour créer une image de conteneur pour une fonction Lambda :
+ [Utilisation d'une image AWS de base pour Lambda](#runtimes-images-lp)
Les [images de base AWS](#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](#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 un [client d’interface d’exécution](#images-ric) pour votre langage dans l’image.
+ [Utilisation d'une image non AWS basique](#images-types)
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 un [client d’interface d’exécution](#images-ric) pour votre langage 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).
Pour créer une fonction Lambda à partir d’une image de conteneur, créez votre image localement et chargez-la dans un référentiel Amazon Elastic Container Registry (Amazon ECR). Si vous utilisez une image de conteneur fournie par un vendeur [AWS Marketplace](https://docs.aws.amazon.com/marketplace/latest/userguide/container-based-products.html), vous devez d’abord cloner l’image dans votre référentiel Amazon ECR privé. Indiquez ensuite l’URI du référentiel lorsque vous créez la fonction. Le référentiel Amazon ECR doit être Région AWS identique à la fonction Lambda. 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](#configuration-images-xaccount-permissions).
**Note**
Lambda ne prend pas en charge les points de terminaison Amazon ECR FIPS pour les images de conteneurs. Si l’URI de votre dépôt contient `ecr-fips`, vous utilisez un point de terminaison FIPS. Exemple: `111122223333.dkr.ecr-fips.us-east-1.amazonaws.com`.
Cette page explique les types d’images de base et les exigences requises pour créer des images de conteneur compatibles avec Lambda.
**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.
**Topics**
+ [
## Exigences
](#images-reqs)
+ [
## Utilisation d'une image AWS de base pour Lambda
](#runtimes-images-lp)
+ [
## Utilisation d'une image de base AWS uniquement pour le système d'exploitation
](#runtimes-images-provided)
+ [
## Utilisation d'une image non AWS basique
](#images-types)
+ [
## Clients d’interface d’exécution
](#images-ric)
+ [
## Autorisations Amazon ECR
](#gettingstarted-images-permissions)
+ [
## Cycle de vie des fonctions
](#images-lifecycle)
## Exigences
Installez l’[AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et la [CLI Docker](https://docs.docker.com/get-docker). En outre, notez les exigences suivantes :
+ L’image de conteneur doit implémenter l’[Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés](runtimes-api.md). Les [clients d’interface de runtime](#images-ric) open source AWS implémentent l’API. Vous pouvez ajouter un client d’interface de runtime à votre image de base préférée pour la rendre compatible avec Lambda.
+ L’image de conteneur doit pouvoir s’exécuter sur un système de fichiers en lecture seule. Votre code de fonction peut accéder à un répertoire `/tmp` inscriptible entre 512 Mo et 10 240 Mo de stockage, par incréments de 1 Mo.
+ L’utilisateur Lambda par défaut doit pouvoir lire tous les fichiers requis pour exécuter votre code de fonction. Lambda suit les bonnes pratiques de sécurité en définissant un utilisateur Linux par défaut avec des autorisations assortie d’un privilège minimum. Cela signifie que vous n’avez pas besoin de spécifier un [UTILISATEUR](https://docs.docker.com/reference/dockerfile/#user) dans votre Dockerfile. Vérifiez que votre code d’application ne repose pas sur des fichiers dont l’exécution n’est pas autorisée à d’autres utilisateurs Linux.
+ Lambda prend uniquement en charge les images de conteneur basées sur Linux.
+ Lambda fournit des images de base multi-architecture. Toutefois, l’image que vous créez pour la fonction ne doit avoir que l’une des architectures pour cible. Lambda ne prend pas en charge les fonctions qui utilisent les images de conteneur multi-architecture.
## Utilisation d'une image AWS de base pour Lambda
Vous pouvez utiliser l’une des [images de base AWS](https://gallery.ecr.aws/lambda/) pour Lambda afin de créer l’image de conteneur pour votre code de fonction. Les images de base sont préchargées avec une exécution de langage et d’autres composants requis pour exécuter une image conteneur sur Lambda. Vous ajoutez votre code de fonction et vos dépendances à l’image de base, puis vous l’empaquetez en tant qu’image de conteneur.
AWS fournit régulièrement des mises à jour des images AWS de base pour Lambda. Si votre Dockerfile inclut le nom de l’image dans la propriété FROM, votre client Docker extrait la dernière version de l’image du [référentiel Amazon ECR](https://gallery.ecr.aws/lambda/). Afin d’utiliser l’image de base mise à jour, vous devez reconstruire votre image de conteneur et [mettre à jour le code de la fonction](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html).
Les images de base de Node.js 20, Python 3.12, Java 21, .NET 8, Ruby 3.3 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.
Pour créer une image de conteneur à l'aide d'une image de AWS base, choisissez les instructions correspondant à votre langue préférée :
+ [Node.js](nodejs-image.md#nodejs-image-instructions)
+ [TypeScript](typescript-image.md#base-image-typescript)(utilise une image de base Node.js)
+ [Python](python-image.md#python-image-instructions)
+ [Java](java-image.md#java-image-instructions)
+ [Go](go-image.md#go-image-provided)
+ [.NET](csharp-image.md#csharp-image-instructions)
+ [Ruby](ruby-image.md#ruby-image-instructions)
## Utilisation d'une image de base AWS uniquement pour le système d'exploitation
[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 un [client d’interface d’exécution](#images-ric) pour votre langage dans l’image.
| Étiquettes | Environnement d’exécution | Système d’exploitation | Dockerfile | Obsolescence |
| --- | --- | --- | --- | --- |
| al2023 | Exécution uniquement basée sur le système d'exploitation | Amazon Linux 2023 | [Dockerfile pour OS uniquement Runtime sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2023/Dockerfile.provided.al2023) | 30 juin 2029 |
| al2 | Exécution uniquement basée sur le système d'exploitation | Amazon Linux 2 | [Dockerfile pour OS uniquement Runtime sur GitHub](https://github.com/aws/aws-lambda-base-images/blob/provided.al2/Dockerfile.provided.al2) | 31 juillet 2026 |
Galerie publique d'Amazon Elastic Container Registry : [gallery.ecr. aws/lambda/provided](https://gallery.ecr.aws/lambda/provided)
## Utilisation d'une image non AWS basique
Lambda prend en charge toute image conforme à l’un des formats de manifeste d’image suivants :
+ Manifeste d’images Docker V2, schéma 2 (utilisé avec la version 1.10 de Docker et les versions les plus récentes)
+ Spécifications OCI (Open Container initiative, soit initiative de conteneur ouvert) (v1.0.0 et versions ultérieures)
Lambda prend en charge une taille maximale d’image non compressée de 10 Go, comprenant toutes les couches.
**Note**
Pour rendre l’image compatible avec Lambda, vous devez inclure un [client d’interface d’exécution](#images-ric) pour votre langage dans l’image.
Pour des performances optimales, maintenez la taille de votre manifeste d’image inférieure à 25 400 octets. Pour réduire la taille du manifeste d’image, réduisez le nombre de couches de votre image et réduisez le nombre d’annotations.
## Clients d’interface d’exécution
Si vous utilisez une [image de base uniquement pour le système d’exploitation](#runtimes-images-provided) ou une autre image de base, vous devez inclure un client d'interface d'exécution dans votre image. Le client de l'interface d'exécution doit étendre le[Utilisation de l’API de l’environnement d’exécution Lambda pour des environnements d’exécution personnalisés](runtimes-api.md), qui gère l'interaction entre Lambda et votre code de fonction. AWS fournit des clients d'interface d'exécution open source pour les langages suivants :
+ [Node.js](nodejs-image.md#nodejs-image-clients)
+ [Python](python-image.md#python-image-clients)
+ [Java](java-image.md#java-image-clients)
+ [.NET](csharp-image.md#csharp-image-clients)
+ [Go](go-image.md#go-image-clients)
+ [Ruby](ruby-image.md#ruby-image-clients)
+ [Rouille](lambda-rust.md) —
Si vous utilisez un langage qui ne possède pas de client d'interface d'exécution AWS fourni, vous devez créer le vôtre.
## Autorisations Amazon ECR
Avant de créer une fonction Lambda à partir d’une image de conteneur, vous devez créer l’image localement et la charger dans un référentiel Amazon ECR. Lorsque vous créez la fonction, indiquez l’URI du référentiel Amazon ECR.
Assurez-vous que les autorisations accordées à l'utilisateur ou au rôle qui crée la fonction incluent `GetRepositoryPolicy``SetRepositoryPolicy`,`BatchGetImage`, et`GetDownloadUrlForLayer`.
Par exemple, utilisez la console IAM pour créer un rôle avec la stratégie suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecr:SetRepositoryPolicy",
"ecr:GetRepositoryPolicy",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Resource": "arn:aws:ecr:us-east-1:111122223333:repository/hello-world"
}
]
}
```
------
### Politiques de référentiel Amazon ECR
Pour qu’une fonction dans le même compte accède à l’image conteneur dans Amazon ECR, vous pouvez ajouter des autorisations `ecr:BatchGetImage` et `ecr:GetDownloadUrlForLayer` à votre politique de référentiel Amazon ECR. L’exemple suivant présente la stratégie minimum :
```
{
"Sid": "LambdaECRImageRetrievalPolicy",
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
]
}
```
Pour plus d’informations sur les autorisations des référentiels Amazon ECR, consultez [Politiques des référentiels privés](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html) dans le *Guide de l’utilisateur Amazon Elastic Container Registry*.
Si le référentiel Amazon ECR n’inclut pas ces autorisations, Lambda tente de les ajouter automatiquement. Lambda ne peut ajouter ces autorisations que si le principal appelant Lambda dispose des autorisations `ecr:getRepositoryPolicy` et `ecr:setRepositoryPolicy`.
Pour afficher ou modifier les autorisations de votre référentiel Amazon ECR, suivez les instructions de la section [Définition d’une déclaration de politique de référentiel privé](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) dans le *Guide de l’utilisateur Amazon Elastic Container Registry*.
#### Autorisations entre comptes Amazon ECR
Un autre compte dans la même région peut créer une fonction qui utilise une image conteneur appartenant à votre compte. Dans l’exemple suivant, votre [politique d’autorisations de référentiel Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html) a besoin des instructions suivantes pour accorder l’accès au numéro de compte 123456789012.
+ **CrossAccountPermission**— Permet au compte 123456789012 de créer et de mettre à jour des fonctions Lambda qui utilisent des images provenant de ce référentiel ECR.
+ **Lambda — ECRImage CrossAccountRetrievalPolicy** Lambda finira par définir l'état d'une fonction sur inactif si elle n'est pas invoquée pendant une période prolongée. Cette instruction est requise pour que Lambda puisse récupérer l’image conteneur à des fins d’optimisation et de mise en cache pour le compte de la fonction détenue par 123456789012.
**Example – Ajouter une autorisation entre comptes à votre référentiel**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CrossAccountPermission",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
},
{
"Sid": "LambdaECRImageCrossAccountRetrievalPolicy",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Condition": {
"ArnLike": {
"aws:sourceARN": "arn:aws:lambda:us-east-1:123456789012:function:*"
}
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
}
]
}
```
Pour donner accès à plusieurs comptes, vous ajoutez le compte IDs à la liste Principal de la `CrossAccountPermission` politique et à la liste d'évaluation des conditions dans le`LambdaECRImageCrossAccountRetrievalPolicy`.
Si vous travaillez avec plusieurs comptes au AWS sein d'une organisation, nous vous recommandons d'énumérer chaque ID de compte dans la politique d'autorisation ECR. Cette approche est conforme aux meilleures pratiques de AWS sécurité qui consistent à définir des autorisations restreintes dans les politiques IAM.
Outre les autorisations Lambda, l’utilisateur ou le rôle qui crée la fonction doit également disposer des autorisations `BatchGetImage` et `GetDownloadUrlForLayer`.
## Cycle de vie des fonctions
Après avoir chargé une nouvelle image de conteneur ou une image de conteneur mise à jour, Lambda optimise l'image avant que la fonction ne puisse traiter les appels. Le processus d'optimisation peut prendre quelques secondes. La fonction reste dans l’état `Pending` jusqu’à ce que le processus se termine, l’état passant alors à `Active`. Vous ne pouvez pas invoquer la fonction jusqu’à ce qu’elle atteigne l’état `Active`.
Si une fonction n'est pas appelée pendant plusieurs semaines, Lambda récupère sa version optimisée, et la fonction passe à l'état `Inactive`. Pour réactiver la fonction, vous devez l'appeler. Lambda rejette la première invocation et la fonction passe à l'état `Pending` jusqu'à ce que Lambda réoptimise l'image. La fonction revient ensuite à l'état `Active`.
Lambda récupère périodiquement l’image de conteneur associée à partir du référentiel Amazon ECR. Si l'image de conteneur correspondante n'existe plus sur Amazon ECR ou si les autorisations ont été révoquées, la fonction passera à l'état `Failed`, et Lambda renverra un message d'échec à tout appel de la fonction.
Vous pouvez utiliser l'API Lambda pour obtenir des informations sur l'état d'une fonction. Pour de plus amples informations, veuillez consulter [États de la fonction Lambda](functions-states.md).
# Configuration de la mémoire d’une fonction Lambda
Lambda alloue de la puissance d’UC en fonction de la quantité de mémoire configurée. La *mémoire* est la quantité de mémoire disponible pour une fonction Lambda lors de l’exécution. Vous pouvez augmenter ou réduire la mémoire et la puissance d’UC allouées à votre fonction à l’aide du paramètre **Mémoire**. Vous pouvez configurer la mémoire comprise entre 128 et 10 240 Mo, par incréments de 1 Mo. A 1 769 Mo, une fonction dispose de l’équivalent d’1 vCPU (un vCPU-seconde de crédits par seconde).
Cette page explique comment et quand mettre à jour le paramètre de mémoire pour une fonction Lambda.
**Topics**
+ [
## Évaluation du paramètre de mémoire approprié pour une fonction Lambda
](#configuration-memory-use-cases)
+ [
## Configuration de la mémoire d’une fonction (console)
](#configuration-memory-console)
+ [
## Configuration de la mémoire d’une fonction (AWS CLI)
](#configuration-memory-cli)
+ [
## Configuration de la mémoire d’une fonction (AWS SAM)
](#configuration-memory-sam)
+ [
## Acceptation des recommandations relatives à la mémoire d’une fonction (console)
](#configuration-memory-optimization-accept)
## Évaluation du paramètre de mémoire approprié pour une fonction Lambda
La mémoire est le principal instrument de contrôle de l’exécution d’une fonction. Le réglage par défaut, 128 Mo, est le plus bas possible. Nous vous recommandons de n’utiliser que 128 Mo pour les fonctions Lambda simples, telles que celles qui transforment et acheminent des événements vers d’autres services AWS . Une allocation de mémoire plus élevée peut améliorer les performances pour les fonctions qui utilisent des bibliothèques importées, des [couches Lambda](chapter-layers.md), Amazon Simple Storage Service (Amazon S3) ou Amazon Elastic File System (Amazon EFS). L’ajout de mémoire augmente proportionnellement la quantité de processeur, augmentant ainsi la puissance de calcul globale disponible. Si une fonction est liée au processeur, au réseau ou à la mémoire, l’augmentation du paramètre de mémoire peut améliorer considérablement ses performances.
Pour trouver la bonne configuration de mémoire, surveillez vos fonctions avec Amazon CloudWatch et définissez des alarmes si la consommation de mémoire approche les valeurs maximales configurées. Cela peut aider à identifier les fonctions liées à la mémoire. Pour les fonctions liées au processeur et aux E/S, le suivi de la durée apporte souvent des informations intéressantes. Dans ces cas, l’augmentation de la mémoire peut aider à résoudre les goulets d’étranglement de calcul ou de réseau.
Vous pouvez également envisager d’utiliser l’outil open source [AWS Lambda Power Tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning). Cet outil permet AWS Step Functions d'exécuter plusieurs versions simultanées d'une fonction Lambda avec différentes allocations de mémoire et de mesurer les performances. La fonction de saisie s'exécute dans votre AWS compte et effectue des appels HTTP en direct et une interaction avec le SDK, afin de mesurer les performances probables dans un scénario de production en direct. Vous pouvez également implémenter un CI/CD processus permettant d'utiliser cet outil pour mesurer automatiquement les performances des nouvelles fonctions que vous déployez.
## Configuration de la mémoire d’une fonction (console)
Vous pouvez configurer la mémoire de votre fonction dans la console Lambda.
**Pour mettre à jour la mémoire d’une fonction**
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 **Configuration générale**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/configuration-tab.png)
1. Sous **Configuration générale**, choisissez **Modifier**.
1. Pour **Mémoire**, définissez une valeur comprise entre 128 et 10 240 Mo.
1. Choisissez **Enregistrer**.
## Configuration de la mémoire d’une fonction (AWS CLI)
Vous pouvez utiliser la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande pour configurer la mémoire de votre fonction.
**Example**
```
aws lambda update-function-configuration \
--function-name my-function \
--memory-size 1024
```
## Configuration de la mémoire d’une fonction (AWS SAM)
Vous pouvez utiliser [AWS Serverless Application Model](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-getting-started.html ) pour configurer la mémoire de votre fonction. Mettez à jour la [MemorySize](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-memorysize)propriété dans votre `template.yaml` fichier, puis exécutez [sam deploy](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html).
**Example template.yaml**
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Application Model template describing your function.
Resources:
my-function:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Description: ''
MemorySize: 1024
# Other function properties...
```
## Acceptation des recommandations relatives à la mémoire d’une fonction (console)
Si vous disposez d'autorisations d'administrateur dans Gestion des identités et des accès AWS (IAM), vous pouvez choisir de recevoir des recommandations de configuration de la mémoire des fonctions Lambda de la part de. Optimiseur de calcul AWS Pour obtenir des instructions sur la manière de choisir de recevoir des recommandations relatives à la mémoire pour votre compte ou votre organisation, consultez [Inscription à votre compte](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html#account-opt-in) dans le *Guide de l’utilisateur Optimiseur de calcul AWS *.
**Note**
Compute Optimizer prend en charge uniquement les fonctions qui utilisent l’architecture x86\$164.
Si vous avez choisi cette option et si votre [fonction Lambda répond aux exigences de Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-lambda-functions), vous pouvez afficher et accepter les recommandations de Compute Optimizer relatives à la mémoire de la fonction dans la console Lambda dans **Configuration générale**.
# Configuration d’un stockage éphémère pour les fonctions Lambda
Lambda fournit un stockage éphémère pour les fonctions du répertoire `/tmp`. Ce stockage est temporaire et propre à chaque environnement d’exécution. Vous pouvez contrôler la quantité de stockage éphémère allouée à votre fonction à l’aide du paramètre **Stockage éphémère**. Vous pouvez configurer le stockage éphémère comprise entre 512 et 10 240 Mo, par incréments de 1 Mo. Toutes les données stockées dans `/tmp` sont chiffrées au repos à l’aide d’une clé gérée par AWS.
Cette page décrit les cas d’utilisation courants et explique comment mettre à jour le stockage éphémère pour une fonction Lambda.
**Topics**
+ [
## Cas d’utilisation courants pour un stockage éphémère augmenté
](#configuration-ephemeral-storage-use-cases)
+ [
## Configuration du magasin éphémère (console)
](#configuration-ephemeral-storage-console)
+ [
## Configuration du stockage éphémère (AWS CLI)
](#configuration-ephemeral-storage-cli)
+ [
## Configuration du stockage éphémère (AWS SAM)
](#configuration-ephemeral-storage-sam)
## Cas d’utilisation courants pour un stockage éphémère augmenté
Voici plusieurs cas d’utilisation courants qui bénéficient d’un stockage éphémère augmenté :
+ **Extract-transform-load Tâches (ETL) :** augmentez le stockage éphémère lorsque votre code effectue des calculs intermédiaires ou télécharge d'autres ressources pour terminer le traitement. Un espace temporaire plus important permet d’exécuter des tâches ETL plus complexes dans des fonctions Lambda.
+ **Inférence de machine learning (ML) :** de nombreuses tâches d’inférence reposent sur des fichiers de données de référence volumineux, notamment des bibliothèques et des modèles. Avec un stockage éphémère plus important, vous pouvez télécharger des modèles plus grands depuis Amazon Simple Storage Service (Amazon S3) vers `/tmp` et les utiliser pour votre traitement.
+ **Traitement des données :** pour les charges de travail qui téléchargent des objets depuis Amazon S3 en réponse à des événements S3, un espace `/tmp` plus important permet de gérer des objets plus volumineux sans recourir au traitement en mémoire. Les charges de travail qui créent PDFs ou traitent des médias bénéficient également d'un stockage plus éphémère.
+ **Traitement graphique :** le traitement d’image est un cas d’utilisation courant pour les applications basées sur Lambda. Pour les charges de travail qui traitent de gros fichiers TIFF ou des images satellites, un stockage éphémère plus important facilite l’utilisation des bibliothèques et l’exécution des calculs dans Lambda.
## Configuration du magasin éphémère (console)
Vous pouvez configurer le stockage éphémère dans la console Lambda.
**Pour modifier le stockage éphémère d’une fonction**
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 **Configuration générale**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/configuration-tab.png)
1. Sous **Configuration générale**, choisissez **Modifier**.
1. Pour **Stockage éphémère,** définissez une valeur comprise entre 512 et 10 240 Mo, par incréments de 1 Mo.
1. Choisissez **Enregistrer**.
## Configuration du stockage éphémère (AWS CLI)
Vous pouvez utiliser la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande pour configurer le stockage éphémère.
**Example**
```
aws lambda update-function-configuration \
--function-name my-function \
--ephemeral-storage '{"Size": 1024}'
```
## Configuration du stockage éphémère (AWS SAM)
Vous pouvez utiliser [AWS Serverless Application Model](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-getting-started.html ) pour configurer le stockage éphémère pour votre fonction. Mettez à jour la [EphemeralStorage](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-ephemeralstorage)propriété dans votre `template.yaml` fichier, puis exécutez [sam deploy](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html).
**Example template.yaml**
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Application Model template describing your function.
Resources:
my-function:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Description: ''
MemorySize: 128
Timeout: 120
Handler: index.handler
Runtime: nodejs22.x
Architectures:
- x86_64
EphemeralStorage:
Size: 10240
# Other function properties...
```
# Sélection et configuration d’une architecture de jeu d’instructions pour votre fonction Lambda
L'*architecture de l'ensemble des instructions* d'une fonction Lambda détermine le type de processeur d'ordinateur que Lambda utilise pour exécuter la fonction. Lambda permet de choisir parmi plusieurs architectures de l'ensemble des instructions :
+ arm64 — Architecture ARM 64 bits, pour le processeur AWS Graviton2.
+ x86\$164 : architecture 64 bits x86, pour les processeurs x86.
**Note**
L'architecture arm64 est disponible dans la plupart des Régions AWS cas. Pour plus d’informations, consultez [Tarification d’AWS Lambda](https://aws.amazon.com//lambda/pricing/#aws-element-9ccd9262-b656-4d9c-8a72-34ee6b662135). Dans le tableau des prix de la mémoire, choisissez l'onglet **Arm Price**, puis ouvrez la liste déroulante des **régions** pour voir qui Régions AWS prend en charge arm64 avec Lambda.
Pour un exemple de création d'une fonction avec l'architecture arm64, voir [AWS Lambda Fonctions alimentées par le processeur AWS Graviton2](https://aws.amazon.com/blogs/aws/aws-lambda-functions-powered-by-aws-graviton2-processor-run-your-functions-on-arm-and-get-up-to-34-better-price-performance/).
**Topics**
+ [
## Avantages liés à l'utilisation de l'architecture arm64
](#foundation-arch-adv)
+ [
## Exigences pour la migration vers l'architecture arm64
](#foundation-arch-consider)
+ [
## Compatibilité des codes de fonction avec l'architecture arm64
](#foundation-arch-considerations)
+ [
## Comment migrer vers l'architecture arm64
](#foundation-arch-steps)
+ [
## Configuration de l'architecture de l'ensemble des instructions
](#foundation-arch-config)
## Avantages liés à l'utilisation de l'architecture arm64
Les fonctions Lambda qui utilisent l'architecture arm64 (processeur AWS Graviton2) peuvent atteindre un prix et des performances nettement supérieurs à ceux des fonctions équivalentes exécutées sur l'architecture x86\$164. Envisagez d'utiliser arm64 pour les applications de calcul intensif telles que le calcul haute performance, le codage vidéo et les applications de simulation.
Le processeur Graviton2 utilise le cœur Neoverse N1 et prend en charge Armv8.2 (y compris les extensions CRC et cryptographiques), ainsi que plusieurs autres extensions architecturales.
Graviton2 réduit le temps de lecture de la mémoire en fournissant un cache L2 plus important par vCPU, ce qui permet d'obtenir une meilleure performance de latence des backends Web et mobiles, des microservices et des systèmes de traitement de données. Graviton2 offre également des performances de chiffrement améliorées et prend en charge les ensembles des instructions qui améliorent la latence de l'inférence Machine Learning basée sur CPU.
Pour plus d'informations sur AWS Graviton2, consultez la section Processeur [AWS Graviton](https://aws.amazon.com/ec2/graviton).
## Exigences pour la migration vers l'architecture arm64
Lorsque vous sélectionnez une fonction Lambda à migrer vers l'architecture arm64, pour que la migration soit fluide, assurez-vous que la fonction répond aux exigences suivantes :
+ Le package de déploiement ne contient que des composants open source et le code source que vous contrôlez, ce qui vous permet d'effectuer les mises à jour nécessaires à la migration.
+ Si le code de la fonction inclut des dépendances tierces, chaque bibliothèque ou package fournit une version arm64.
## Compatibilité des codes de fonction avec l'architecture arm64
Le code de la fonction Lambda doit être compatible avec l'architecture de l'ensemble des instructions de la fonction. Avant de migrer une fonction vers l'architecture arm64, veuillez noter les points suivants concernant le code de fonction actuel :
+ Si vous avez ajouté le code de la fonction à l'aide de l'éditeur de code intégré, le code s'exécute probablement sur l'une des architectures sans modification.
+ Si vous avez chargé le code de la fonction, vous devez charger un nouveau code compatible avec l'architecture cible.
+ Si la fonction utilise des couches, vous devez [vérifier chaque couche](adding-layers.md#finding-layer-information) afin de vous assurer qu'elle est compatible avec la nouvelle architecture. Si une couche n'est pas compatible, modifiez la fonction, afin de remplacer la version actuelle de la couche par une version de couche compatible.
+ Si la fonction utilise des extensions Lambda, vous devez vérifier chaque extension, afin de vous assurer de sa compatibilité avec la nouvelle architecture.
+ Si votre fonction utilise un type de package de déploiement de l'image de conteneur, vous devez créer une nouvelle image de conteneur compatible avec l'architecture de la fonction.
## Comment migrer vers l'architecture arm64
Pour migrer une fonction Lambda vers l'architecture arm64, nous recommandons de procéder comme suit :
1. Créez la liste des dépendances de l'application ou de la charge de travail. Les dépendances courantes comprennent :
+ Toutes les bibliothèques et les packages utilisés par la fonction.
+ Les outils que vous utilisez pour créer, déployer et tester la fonction, tels que les compilateurs, les suites de tests, les pipelines d'intégration continue et de livraison continue (CI/CD), les outils d'approvisionnement et les scripts.
+ Les extensions Lambda et les outils tiers que vous utilisez pour contrôler la fonction en production.
1. Pour chacune des dépendances, vérifiez la version, puis vérifiez si les versions arm64 sont disponibles.
1. Créez un environnement pour migrer l'application.
1. Amorcez l'application.
1. Testez et déboguez l'application.
1. Testez la performance de la fonction arm64. Comparez la performance avec celle de la version x86\$164.
1. Mettez à jour le pipeline d'infrastructure pour prendre en charge les fonctions Lambda arm64.
1. Établissez le déploiement vers la production.
Par exemple, utilisez la [configuration du routage d'alias](configuring-alias-routing.md) pour fractionner le trafic entre les versions x86 et arm64 de la fonction et comparez les performances et la latence.
Pour plus d'informations sur la création d'un environnement de code pour l'architecture arm64, y compris des informations spécifiques au langage pour Java, Go, .NET et Python, consultez le référentiel [Getting started with AWS](https://github.com/aws/aws-graviton-getting-started) Graviton. GitHub
## Configuration de l'architecture de l'ensemble des instructions
Vous pouvez configurer l'architecture du jeu d'instructions pour les fonctions Lambda nouvelles et existantes à l'aide de la console Lambda, AWS SDKs, AWS Command Line Interface ()AWS CLI ou. CloudFormation Procédez comme suit pour modifier l'architecture de l'ensemble des instructions d'une fonction Lambda existante à partir de la console.
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de la fonction pour laquelle vous voulez configurer l'architecture de l'ensemble des instructions.
1. Dans l'onglet principal **Code**, pour la section **Paramètres d'exécution**, choisissez **Modifier**.
1. Sous **Architecture**, choisissez l'architecture de l'ensemble des instructions que votre fonction doit utiliser.
1. Choisissez **Enregistrer**.
# Configuration du délai d’expiration d’une fonction Lambda
Lambda exécute votre code pendant une durée définie avant l’expiration du délai. Le *délai d’expiration* est la durée maximale, en secondes, pendant laquelle une fonction Lambda peut être exécutée. La valeur par défaut de ce paramètre est de 3 secondes, mais vous pouvez l’ajuster par incréments d’1 seconde jusqu’à une valeur maximale de 900 secondes (15 minutes).
Cette page explique comment et quand mettre à jour le paramètre de délai d’expiration pour une fonction Lambda.
**Topics**
+ [
## Évaluation de la valeur de délai d’expiration appropriée pour une fonction Lambda
](#configuration-timeout-use-cases)
+ [
## Configuration du délai d’expiration (console)
](#configuration-timeout-console)
+ [
## Configuration du délai d’expiration (AWS CLI)
](#configuration-timeout-cli)
+ [
## Configuration du délai d’expiration (AWS SAM)
](#configuration-timeout-sam)
## Évaluation de la valeur de délai d’expiration appropriée pour une fonction Lambda
Si la valeur du délai d’expiration est proche de la durée moyenne d’une fonction, il y a un risque plus élevé que la fonction s’arrête de manière inattendue. La durée d’exécution d’une fonction peut varier en fonction de la quantité de données transférées et traitées, ainsi que de la latence des services avec lesquels la fonction interagit. Parmi les causes courantes de délai d’expiration, citons les suivantes :
+ Les téléchargements à partir d’Amazon Simple Storage Service (Amazon S3) sont plus importants ou prennent plus de temps que d’habitude.
+ Une fonction adresse une requête à un autre service, lequel met plus de temps à répondre.
+ Les paramètres fournis à une fonction exigent une plus grande complexité de calcul dans la fonction, ce qui allonge la durée de l’invocation.
Lors des tests de votre application, veillez à ce que ceux-ci reflètent fidèlement la taille et la quantité des données, et à ce que les valeurs des paramètres soient réalistes. Les tests utilisent souvent de petits échantillons pour des raisons de commodité. Cependant, les jeux de données utilisés devraient se rapprocher des limites supérieures de ce que l’on peut raisonnablement attendre de votre charge de travail.
## Configuration du délai d’expiration (console)
Vous pouvez configurer le délai d’expiration d’une fonction dans la console Lambda.
**Pour modifier le délai d’expiration d’une fonction**
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 **Configuration générale**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/configuration-tab.png)
1. Sous **Configuration générale**, choisissez **Modifier**.
1. Pour **Expiration**, définissez une valeur comprise entre 1 et 900 secondes (15 minutes).
1. Choisissez **Enregistrer**.
## Configuration du délai d’expiration (AWS CLI)
Vous pouvez utiliser la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande pour configurer la valeur du délai d'expiration, en secondes. L’exemple de commande suivant augmente le délai d’expiration de la fonction à 120 secondes (2 minutes).
**Example**
```
aws lambda update-function-configuration \
--function-name my-function \
--timeout 120
```
## Configuration du délai d’expiration (AWS SAM)
Vous pouvez utiliser [AWS Serverless Application Model](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-getting-started.html ) pour configurer la valeur du délai d’expiration de votre fonction. Mettez à jour la propriété [Timeout](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-timeout) dans votre fichier `template.yaml`, puis exécutez [sam deploy](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html).
**Example template.yaml**
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Application Model template describing your function.
Resources:
my-function:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Description: ''
MemorySize: 128
Timeout: 120
# Other function properties...
```
# Configurer les fonctions durables de Lambda
Pour permettre une exécution durable de votre fonction Lambda, vous devez configurer des paramètres spécifiques qui contrôlent la durée d'exécution de votre fonction, la durée de conservation des données d'état et les autorisations requises.
## Permettre une exécution durable
Pour permettre une exécution durable de votre fonction Lambda, configurez-la `DurableConfig` dans la configuration de votre fonction. Ce paramètre contrôle le délai d'exécution, la conservation des états et le comportement de gestion des versions.
------
#### [ AWS CLI ]
```
aws lambda update-function-configuration \
--function-name my-durable-function \
--durable-config '{
"ExecutionTimeout": 3600,
"RetentionPeriodInDays": 30,
"AllowInvokeLatest": true
}'
```
------
#### [ CloudFormation ]
```
Resources:
MyDurableFunction:
Type: AWS::Lambda::Function
Properties:
FunctionName: my-durable-function
Runtime: nodejs18.x
Handler: index.handler
Code:
ZipFile: |
// Your durable function code
DurableConfig:
ExecutionTimeout: 3600
RetentionPeriodInDays: 30
AllowInvokeLatest: true
```
------
**Paramètres de configuration :**
+ `ExecutionTimeout`- Temps d'exécution maximal en secondes (jusqu'à 31 536 000 pour un an)
+ `RetentionPeriodInDays`- Combien de temps faut-il conserver l'état et l'historique d'exécution (1 à 365 jours)
+ `AllowInvokeLatest`- Autoriser ou non l'invocation de la version \$1LATEST pour une exécution durable
## Autorisations IAM pour des fonctions durables
Les fonctions durables nécessitent des autorisations IAM supplémentaires au-delà des rôles d'exécution Lambda standard. Le rôle d'exécution de votre fonction doit inclure des autorisations pour la gestion des états et l'exécution durable APIs.
**Autorisations minimales requises :**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction",
"lambda:GetFunction",
"lambda:ManageDurableState",
"lambda:GetDurableExecution",
"lambda:ListDurableExecutions"
],
"Resource": "arn:aws:lambda:*:*:function:*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
}
]
}
```
**CloudFormation exemple de rôle d'exécution :**
```
DurableFunctionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
Policies:
- PolicyName: DurableFunctionPolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- lambda:ManageDurableState
- lambda:GetDurableExecution
- lambda:ListDurableExecutions
Resource: '*'
```
## Bonnes pratiques en matière de configuration
Suivez les meilleures pratiques suivantes lors de la configuration de fonctions durables pour une utilisation en production :
+ **Définissez des délais d'exécution appropriés - Configurez** `ExecutionTimeout` en fonction de la durée maximale prévue de votre flux de travail. Ne fixez pas de délais d'attente inutilement longs, car ils affectent les coûts et l'allocation des ressources.
+ **Équilibrez la rétention avec les coûts de stockage** : définissez les `RetentionPeriodInDays` paramètres en fonction de vos exigences en matière de débogage et d'audit. Des périodes de conservation plus longues augmentent les coûts de stockage.
+ **Utiliser le versionnement en production** : configurez-le sur `false` dans `AllowInvokeLatest` les environnements de production et utilisez des versions de fonctions ou des alias spécifiques pour des exécutions durables.
+ **Taille de l'état du moniteur** : les objets à état volumineux augmentent les coûts de stockage et peuvent avoir un impact sur les performances. Maintenez l'état minimal et utilisez un stockage externe pour les données volumineuses.
+ **Configurer une journalisation appropriée** - Activez la journalisation détaillée pour résoudre les problèmes liés aux flux de travail de longue durée, tout en tenant compte du volume des journaux et des coûts.
**Exemple de configuration de production :**
```
{
"ExecutionTimeout": 86400,
"RetentionPeriodInDays": 7,
"AllowInvokeLatest": false
}
```
# Utilisation des variables d’environnement Lambda
Vous pouvez utiliser des variables d’environnement pour ajuster le comportement de votre fonction sans mettre à jour le code. Une variable d’environnement est une paire de chaînes stockées dans la configuration spécifique à la version d’une fonction. L’environnement d’exécution de Lambda met les variables d’environnement à la disposition de votre code et définit les variables d’environnement supplémentaires qui contiennent des informations sur la fonction et la demande d’invocation.
**Note**
Pour renforcer la sécurité, nous vous recommandons d'utiliser à la AWS Secrets Manager place des variables d'environnement pour stocker les informations d'identification de la base de données et d'autres informations sensibles telles que les clés d'API ou les jetons d'autorisation. Pour de plus amples informations, veuillez consulter [Utiliser des secrets Secrets Manager dans des fonctions Lambda](with-secrets-manager.md).
Les variables d’environnement ne sont pas évaluées avant l’invocation de la fonction. Toute valeur que vous définissez est considérée comme une chaîne littérale et non développée. Effectuez l’évaluation de la variable dans le code de votre fonction.
## Création de variables d’environnement Lambda
Vous pouvez configurer les variables d'environnement dans Lambda à l'aide de la console Lambda, du AWS Command Line Interface (AWS CLI), AWS Serverless Application Model (AWS SAM) ou d'un SDK. AWS
------
#### [ Console ]
Vous définissez des variables d’environnement sur la version non publiée de votre fonction. Lorsque vous publiez une version, les variables d’environnement sont verrouillées pour cette version ainsi que d’autres [paramètres de configuration spécifiques à la version](configuration-versions.md).
Vous créez une variable d’environnement pour votre fonction en définissant une clé et une valeur. Votre fonction utilise le nom de la clé pour récupérer la valeur de la variable d’environnement.
**Pour définir des variables d’environnement dans la console Lambda**
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 **Variables d’environnement**.
1. Sous **Variables d’environnement**, choisissez **Modifier**.
1. Choisissez **Ajouter une variable d’environnement**.
1. Entrez une clé et une valeur.
**Exigences**
+ Les clés commencent par une lettre et comportent au moins deux caractères.
+ Les clés contiennent uniquement des lettres, des chiffres et le caractère de soulignement (`_`).
+ Les clés ne sont pas [réservées par Lambda](#configuration-envvars-runtime).
+ La taille totale de toutes les variables d’environnement ne dépasse pas 4 Ko.
1. Choisissez **Enregistrer**.
**Pour générer une liste de variables d’environnement dans l’éditeur de code de la console**
Vous pouvez générer une liste de variables d’environnement dans l’éditeur de code Lambda. Il s’agit d’un moyen rapide de référencer vos variables d’environnement pendant que vous codez.
1. Cliquez sur l’onglet **Code**.
1. Faites défiler l’écran jusqu’à la section **VARIABLES D’ENVIRONNEMENT** de l’éditeur de code. Les variables d’environnement existantes sont répertoriées ici :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/env-var.png)
1. Pour créer de nouvelles variables d’environnement, choisissez le signe plus (![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-plus.png)) :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-env-var.png)
Les variables d’environnement restent chiffrées lorsqu’elles sont répertoriées dans l’éditeur de code de la console. Si vous avez activé les assistants de chiffrement pour le chiffrement en transit, ces paramètres restent inchangés. Pour de plus amples informations, veuillez consulter [Sécurisation de variables d’environnement Lambda](configuration-envvars-encryption.md).
La liste des variables d’environnement est en lecture seule et n’est disponible que sur la console Lambda. Ce fichier n’est pas inclus lorsque vous téléchargez l’archive .zip de la fonction et vous ne pouvez pas ajouter de variables d’environnement en chargeant ce fichier.
------
#### [ AWS CLI ]
L’exemple suivant définit deux variables d’environnement sur une fonction nommée `my-function`.
```
aws lambda update-function-configuration \
--function-name my-function \
--environment "Variables={BUCKET=amzn-s3-demo-bucket,KEY=file.txt}"
```
Lorsque vous appliquez des variables d’environnement avec la commande `update-function-configuration`, l’ensemble du contenu de la structure `Variables` est remplacé. Pour conserver les variables d’environnement existantes lorsque vous en ajoutez une nouvelle, incluez toutes les valeurs existantes dans votre demande.
Pour obtenir la configuration actuelle, utilisez la commande `get-function-configuration`.
```
aws lambda get-function-configuration \
--function-name my-function
```
Vous devriez voir la sortie suivante :
```
{
"FunctionName": "my-function",
"FunctionArn": "arn:aws:lambda:us-east-2:111122223333:function:my-function",
"Runtime": "nodejs24.x",
"Role": "arn:aws:iam::111122223333:role/lambda-role",
"Environment": {
"Variables": {
"BUCKET": "amzn-s3-demo-bucket",
"KEY": "file.txt"
}
},
"RevisionId": "0894d3c1-2a3d-4d48-bf7f-abade99f3c15",
...
}
```
Vous pouvez transmettre l’identifiant de révision depuis la sortie de `get-function-configuration` en tant que paramètre à `update-function-configuration`. Cela garantit que les valeurs ne changent pas entre le moment où vous lisez la configuration et celui où vous la mettez à jour.
Pour configurer la clé de chiffrement d’une fonction, définissez l’option `KMSKeyARN`.
```
aws lambda update-function-configuration \
--function-name my-function \
--kms-key-arn arn:aws:kms:us-east-2:111122223333:key/055efbb4-xmpl-4336-ba9c-538c7d31f599
```
------
#### [ AWS SAM ]
Vous pouvez utiliser [AWS Serverless Application Model](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/serverless-getting-started.html ) pour configurer les variables d’environnement de votre fonction. Mettez à jour les propriétés [Environnement](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-environment) et [Variables](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-environment.html#cfn-lambda-function-environment-variables) dans votre fichier `template.yaml`, puis exécutez [sam deploy](https://docs.aws.amazon.com//serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html).
**Example template.yaml**
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Application Model template describing your function.
Resources:
my-function:
Type: AWS::Serverless::Function
Properties:
CodeUri: .
Description: ''
MemorySize: 128
Timeout: 120
Handler: index.handler
Runtime: nodejs24.x
Architectures:
- x86_64
EphemeralStorage:
Size: 10240
Environment:
Variables:
BUCKET: amzn-s3-demo-bucket
KEY: file.txt
# Other function properties...
```
------
#### [ AWS SDKs ]
Pour gérer les variables d'environnement à l'aide d'un AWS SDK, 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)
Pour en savoir plus, référez-vous à la [documentation du kit SDK AWS](https://aws.amazon.com/developer/tools/) correspondant à votre langage de programmation préféré.
------
## Exemple de scénario pour les variables d’environnement
Vous pouvez utiliser des variables d’environnement pour personnaliser le comportement des fonctions dans vos environnements de test et de production. Vous pouvez par exemple créer deux fonctions avec le même code mais une configuration différente. Une fonction se connecte à une base de données de test et l’autre à une base de données de production. Dans ce cas, vous utilisez des variables d’environnement pour transmettre à la fonction le nom d’hôte, ainsi que d’autres détails de connexion pour la base de données.
L’exemple suivant montre comment définir l’hôte de la base de données et le nom de base de données en tant que variables d’environnement.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/console-env.png)
Si vous souhaitez que votre environnement de test génère plus d’informations de débogage que l’environnement de production, vous pouvez définir une variable d’environnement pour configurer votre environnement de test de manière à utiliser une journalisation plus approfondie ou un suivi plus détaillé.
Par exemple, dans votre environnement de test, vous pouvez définir une variable d’environnement avec la clé `LOG_LEVEL` et une valeur indiquant le niveau de journalisation du débogage ou du suivi. Dans le code de votre fonction Lambda, vous pouvez ensuite utiliser cette variable d’environnement pour définir le niveau de journalisation.
Les exemples de code suivants en Python et Node.js illustrent la façon dont vous pouvez y parvenir. Ces exemples supposent que la valeur de votre variable d’environnement est `DEBUG` en Python, ou `debug` en Node.js.
------
#### [ Python ]
**Example Code Python pour définir le niveau de journalisation**
```
import os
import logging
# Initialize the logger
logger = logging.getLogger()
# Get the log level from the environment variable and default to INFO if not set
log_level = os.environ.get('LOG_LEVEL', 'INFO')
# Set the log level
logger.setLevel(log_level)
def lambda_handler(event, context):
# Produce some example log outputs
logger.debug('This is a log with detailed debug information - shown only in test environment')
logger.info('This is a log with standard information - shown in production and test environments')
```
------
#### [ Node.js (ES module format) ]
**Example Code Node.js pour définir le niveau de journalisation**
Cet exemple utilise la bibliothèque de journalisation `winston`. Utilisez npm pour ajouter cette bibliothèque au package de déploiement de votre fonction. Pour de plus amples informations, veuillez consulter [Création d’un package de déploiement .zip avec dépendances](nodejs-package.md#nodejs-package-create-dependencies).
```
import winston from 'winston';
// Initialize the logger using the log level from environment variables, defaulting to INFO if not set
const logger = winston.createLogger({
level: process.env.LOG_LEVEL || 'info',
format: winston.format.json(),
transports: [new winston.transports.Console()]
});
export const handler = async (event) => {
// Produce some example log outputs
logger.debug('This is a log with detailed debug information - shown only in test environment');
logger.info('This is a log with standard information - shown in production and test environment');
};
```
------
## Récupération de variables d’environnement Lambda
Pour récupérer les variables d’environnement dans le code de votre fonction, utilisez la méthode standard pour votre langage de programmation.
------
#### [ Node.js ]
```
let region = process.env.AWS_REGION
```
------
#### [ Python ]
```
import os
region = os.environ['AWS_REGION']
```
**Note**
Dans certains cas, vous devrez peut-être utiliser le format suivant :
```
region = os.environ.get('AWS_REGION')
```
------
#### [ Ruby ]
```
region = ENV["AWS_REGION"]
```
------
#### [ Java ]
```
String region = System.getenv("AWS_REGION");
```
------
#### [ Go ]
```
var region = os.Getenv("AWS_REGION")
```
------
#### [ C\$1 ]
```
string region = Environment.GetEnvironmentVariable("AWS_REGION");
```
------
#### [ PowerShell ]
```
$region = $env:AWS_REGION
```
------
Lambda stocke les variables d’environnement en toute sécurité en les chiffrant au repos. Vous pouvez [configurer Lambda pour utiliser une clé de chiffrement différente](configuration-envvars-encryption.md), chiffrer les valeurs des variables d'environnement côté client ou définir des variables d'environnement dans un CloudFormation modèle avec. AWS Secrets Manager
## Variables d’environnement d’exécution définies
Les [runtimes](lambda-runtimes.md) Lambda définissent plusieurs variables d’environnement lors de l’initialisation. La plupart des variables d’environnement fournissent des informations sur la fonction ou l’exécution. Les clés de ces variables d’environnement sont *réservées* et ne peuvent pas être définies dans la configuration de la fonction.
**Variables d’environnement réservées**
+ `_HANDLER` – Emplacement de gestionnaire configuré sur la fonction.
+ `_X_AMZN_TRACE_ID` – [En-tête de suivi X-Ray](services-xray.md). Cette variable d'environnement change à chaque invocation.
+ Cette variable d'environnement n'est pas définie pour les environnements d'exécution uniquement basés sur le système d'exploitation (famille des environnements d'exécution `provided`). Vous pouvez définir `_X_AMZN_TRACE_ID` pour les environnements d’exécution personnalisés à l’aide de l’en-tête de réponse `Lambda-Runtime-Trace-Id` de l’[Invocation suivante](runtimes-api.md#runtimes-api-next).
+ Pour les versions 17 et ultérieures du runtime Java, cette variable d'environnement n'est pas utilisée. Lambda stocke plutôt les informations de suivi dans la propriété du système `com.amazonaws.xray.traceHeader`.
+ `AWS_DEFAULT_REGION`— L' Région AWS endroit par défaut où la fonction Lambda est exécutée.
+ `AWS_REGION`— L' Région AWS endroit où la fonction Lambda est exécutée. Si elle est définie, cette valeur remplace `AWS_DEFAULT_REGION`.
+ Pour plus d'informations sur l'utilisation des variables d' Région AWS environnement avec AWS SDKs, consultez [AWS la section Région](https://docs.aws.amazon.com/sdkref/latest/guide/feature-region.html#feature-region-sdk-compat) dans le *guide de référence des outils AWS SDKs et*.
+ `AWS_EXECUTION_ENV` – [Identifiant d’exécution](lambda-runtimes.md), doté du préfixe `AWS_Lambda_` (par exemple, `AWS_Lambda_java8`). Cette variable d'environnement n'est pas définie pour les environnements d'exécution uniquement basés sur le système d'exploitation (famille des environnements d'exécution `provided`).
+ `AWS_LAMBDA_FUNCTION_NAME` – Nom de la fonction.
+ `AWS_LAMBDA_FUNCTION_MEMORY_SIZE` – Quantité de mémoire disponible pour la fonction en Mo.
+ `AWS_LAMBDA_FUNCTION_VERSION` – Version de la fonction en cours d’exécution.
+ `AWS_LAMBDA_INITIALIZATION_TYPE`— Le type d'initialisation de la fonction, qui est `on-demand` `provisioned-concurrency``snap-start`, ou`lambda-managed-instances`. Pour plus d'informations, consultez [Configuration de la simultanéité provisionnée](provisioned-concurrency.md)[Améliorer les performances de démarrage avec Lambda SnapStart](snapstart.md), ou. [Instances gérées par Lambda](lambda-managed-instances.md)
+ `AWS_LAMBDA_LOG_GROUP_NAME`, `AWS_LAMBDA_LOG_STREAM_NAME` — Le nom du groupe Amazon CloudWatch Logs et du flux associés à la fonction. Les [variables `AWS_LAMBDA_LOG_GROUP_NAME` d'`AWS_LAMBDA_LOG_STREAM_NAME`environnement](#configuration-envvars-runtime) et ne sont pas disponibles dans les fonctions Lambda SnapStart .
+ `AWS_ACCESS_KEY`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN` – Clés d’accès obtenues du [rôle d’exécution](lambda-intro-execution-role.md) de la fonction.
+ `AWS_LAMBDA_RUNTIME_API` – ([exécution personnalisée](runtimes-custom.md)) Hôte et port de l’[API d’exécution.](runtimes-api.md).
+ `LAMBDA_TASK_ROOT` – Chemin d’accès du code de la fonction Lambda.
+ `LAMBDA_RUNTIME_DIR` – Chemin d’accès des bibliothèques de l’environnement d’exécution.
+ `AWS_LAMBDA_MAX_CONCURRENCY`— (Instances gérées par Lambda uniquement) Le nombre maximum d'appels simultanés que Lambda enverra à un environnement d'exécution.
+ `AWS_LAMBDA_METADATA_API`— L'adresse du serveur de point de [terminaison de métadonnées](configuration-metadata-endpoint.md) au format `{ipv4_address}:{port}` (par exemple,`169.254.100.1:9001`).
+ `AWS_LAMBDA_METADATA_TOKEN`— Un jeton d'authentification unique pour l'environnement d'exécution actuel utilisé pour authentifier les demandes adressées au point de [terminaison des métadonnées](configuration-metadata-endpoint.md). Lambda génère ce jeton automatiquement lors de l'initialisation.
Les variables d’environnement supplémentaires suivantes ne sont pas réservées et peuvent être étendues dans la configuration de la fonction.
**Variables d’environnement non réservées**
+ `LANG` – Paramètres régionaux de l’environnement d’exécution (`en_US.UTF-8`).
+ `PATH` – Chemin d’exécution (`/usr/local/bin:/usr/bin/:/bin:/opt/bin`).
+ `LD_LIBRARY_PATH` – Chemin de la bibliothèque système (`/var/lang/lib:/lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib`).
+ `NODE_PATH` – ([Node.js](lambda-nodejs.md)) Chemin d’accès de la bibliothèque Node.js (`/opt/nodejs/node12/node_modules/:/opt/nodejs/node_modules:$LAMBDA_RUNTIME_DIR/node_modules`).
+ `NODE_OPTIONS` – ([Node.js](lambda-nodejs.md)) Pour les environnements d’exécution Node.js, vous pouvez utiliser `NODE_OPTIONS` pour réactiver les fonctionnalités expérimentales que Lambda désactive par défaut.
+ `PYTHONPATH` : ([Python](lambda-python.md)) le chemin de la bibliothèque Python (`$LAMBDA_RUNTIME_DIR`).
+ `GEM_PATH` – ([Ruby](lambda-ruby.md)) Chemin d’accès de la bibliothèque Ruby (`$LAMBDA_TASK_ROOT/vendor/bundle/ruby/3.3.0:/opt/ruby/gems/3.3.0`).
+ `AWS_XRAY_CONTEXT_MISSING` – Pour le suivi X-Ray, Lambda définit cette valeur sur `LOG_ERROR` pour éviter de générer des erreurs d’environnement d’exécution à partir du kit SDK X-Ray.
+ `AWS_XRAY_DAEMON_ADDRESS` – Pour le suivi X-Ray, adresse IP et le port du démon X-Ray.
+ `AWS_LAMBDA_DOTNET_PREJIT` : ([.NET](lambda-csharp.md)) définissez cette variable pour activer ou désactiver les optimisations d’environnement d’exécution spécifiques à .NET. Les valeurs incluent `always`, `never` et `provisioned-concurrency`. Pour de plus amples informations, veuillez consulter [Configuration de la simultanéité provisionnée pour une fonction](provisioned-concurrency.md).
+ `TZ` – Fuseau horaire de l’environnement (`:UTC`). L’environnement d’exécution utilise NTP pour synchroniser l’horloge système.
Les valeurs d’exemple affichées reflètent les derniers moteurs d’exécution. La présence de variables spécifiques ou leurs valeurs peuvent varier dans les anciens environnements d’exécution.
# Sécurisation de variables d’environnement Lambda
Pour sécuriser vos variables d’environnement, vous pouvez utiliser le chiffrement côté serveur pour protéger vos données au repos, et le chiffrement côté client pour protéger vos données en transit.
**Note**
Pour renforcer la sécurité de la base de données, nous vous recommandons d'utiliser à la AWS Secrets Manager place des variables d'environnement pour stocker les informations d'identification de la base de données. Pour de plus amples informations, veuillez consulter [Utiliser des secrets Secrets Manager dans des fonctions Lambda](with-secrets-manager.md).
**Sécurité au repos**
Lambda fournit toujours le chiffrement côté serveur au repos grâce à une AWS KMS key. Par défaut, Lambda utilise une Clé gérée par AWS. Si ce comportement par défaut convient à votre flux de travail, vous n’avez pas besoin de configurer quoi que ce soit d’autre. Lambda les crée Clé gérée par AWS dans votre compte et gère les autorisations pour vous. AWS l'utilisation de cette clé ne vous est pas facturée.
Si vous préférez, vous pouvez plutôt fournir une clé gérée par le AWS KMS client. Vous pouvez procéder ainsi pour contrôler la rotation de la clé KMS ou pour répondre aux exigences de votre organisation en matière de gestion des clés KMS. Si vous utilisez une clé gérée par le client, seuls les utilisateurs de votre compte ayant accès à la clé KMS peuvent afficher ou gérer les variables d’environnement sur la fonction.
Les clés gérées par le client entraînent des AWS KMS frais standard. Pour en savoir plus, consultez [Pricing AWS Key Management Service](https://aws.amazon.com/kms/pricing/) (Tarification).
**Sécurité pendant le transit**
Pour plus de sécurité, vous pouvez activer les assistants pour le chiffrement en transit, ce qui garantit que vos variables d’environnement sont chiffrées côté client pour une meilleure protection pendant le transit.
**Pour configurer le chiffrement de vos variables d’environnement**
1. Utilisez le AWS Key Management Service (AWS KMS) pour créer des clés gérées par le client que Lambda utilisera pour le chiffrement côté serveur et côté client. Pour en savoir plus, consultez [Création des clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *AWS Key Management Service Guide du développeur *.
1. À l’aide de la console Lambda, accédez à la page **Modifier les variables d’environnement**.
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 **Variables d’environnement** dans la barre de navigation de gauche.
1. Dans la section **Variables d’environnement)**, choisissez **Modifier**.
1. Développez **Configuration du chiffrement**.
1. (Facultatif) Activez les assistants de chiffrement de la console afin qu’ils utilisent le chiffrement côté client pour protéger vos données en transit.
1. Sous **Encryption in transit** (Chiffrement pendant le transit), choisissez **Enable helpers for encryption in transit** (Activer les assistants pour le chiffrement pendant le transit).
1. Pour chaque variable d’environnement pour laquelle vous souhaitez activer les assistants de chiffrement de la console, choisissez **Encrypt** (Chiffrer) en regard de la variable d’environnement.
1. Sous AWS KMS key Pour chiffrer en cours de transfert, choisissez une clé gérée par le client que vous avez créée au début de cette procédure.
1. Choisissez **Politique de rôle d’exécution** et copiez la politique. Cette politique octroie au rôle d’exécution de votre fonction l’autorisation de déchiffrer les variables d’environnement.
Enregistrez cette politique, car vous l’utiliserez à la dernière étape de cette procédure.
1. Ajoutez le code à votre fonction qui déchiffre les variables d’environnement . Pour obtenir un exemple, choisissez **Déchiffrer l’extrait de secrets**.
1. (Facultatif) Spécifiez votre clé gérée par le client pour le chiffrement au repos.
1. Choisissez **Utiliser une clé principale client**.
1. Choisissez une clé gérée par le client que vous avez créée au début de cette procédure.
1. Choisissez **Enregistrer**.
1. Configurez des autorisations.
Si vous utilisez une clé gérée par le client avec chiffrement côté serveur, octroyez des autorisations à tous les utilisateurs ou rôles que vous voulez pouvoir afficher ou pour gérer des variables d’environnement sur la fonction. Pour de plus amples informations, veuillez consulter [Gestion des autorisations sur votre clé de chiffrement KMS côté serveur](#managing-permissions-to-your-server-side-encryption-key).
Si vous activez le chiffrement côté client pour la sécurité pendant le transit, votre fonction doit disposer d’une autorisation pour appeler l’opération d’API `kms:Decrypt`. Ajoutez la politique que vous avez précédemment enregistrée dans cette procédure au [rôle d’exécution](lambda-intro-execution-role.md) de la fonction.
## Gestion des autorisations sur votre clé de chiffrement KMS côté serveur
Aucune AWS KMS autorisation n'est requise pour que votre utilisateur ou le rôle d'exécution de la fonction utilise la clé de chiffrement par défaut. Pour utiliser une clé gérée par le client, vous devez disposer des autorisations appropriées pour utiliser la clé. Lambda utilise vos autorisations pour créer un octroi sur la clé. Cela permet à Lambda de l’utiliser pour le chiffrement.
+ `kms:ListAliases` – Pour afficher les clés dans la console Lambda.
+ `kms:CreateGrant`, `kms:Encrypt` – Pour configurer une clé gérée par le client sur une fonction.
+ `kms:Decrypt` – Pour afficher et gérer des variables d’environnement chiffrées à l’aide d’une clé gérée par le client.
Vous pouvez obtenir ces autorisations à partir de votre politique d'autorisation basée sur les ressources Compte AWS ou de celle d'une clé. `ListAliases`est fourni par les [politiques gérées pour Lambda](access-control-identity-based.md). Les stratégies de clé accordent les autorisations restantes aux utilisateurs du groupe **Key users (Utilisateurs de clés)**.
Les utilisateurs sans autorisation `Decrypt` peuvent gérer les fonctions, mais ils ne peuvent pas afficher les variables d’environnement ni les gérer dans la console Lambda. Pour empêcher un utilisateur d’afficher des variables d’environnement, ajoutez une instruction aux autorisations de cet utilisateur afin de refuser l’accès à la clé par défaut, à une clé gérée par le client ou à toutes les clés.
**Example Politique IAM – Refuser l’accès en fonction de l’ARN de la clé**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-2:111122223333:key/3be10e2d-xmpl-4be4-bc9d-0405a71945cc"
}
]
}
```
Pour en savoir plus sur la gestion des autorisations de clés, consultez [Stratégies de clé dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) que vous trouverez dans le *Guide du développeur AWS Key Management Service *.
# Octroi aux fonctions Lambda d’un accès aux ressources d’un Amazon VPC
Avec Amazon Virtual Private Cloud (Amazon VPC), vous pouvez créer des réseaux privés Compte AWS pour héberger des ressources telles que les instances Amazon Elastic Compute Cloud (Amazon EC2), les instances Amazon Relational Database Service (Amazon RDS) et les instances Amazon. ElastiCache Vous pouvez donner à votre fonction Lambda l’accès aux ressources hébergées dans un Amazon VPC en attachant votre fonction au VPC via les sous-réseaux privés qui contiennent les ressources. Suivez les instructions des sections suivantes pour associer une fonction Lambda à un Amazon VPC à l'aide de la console Lambda, du () ou. AWS Command Line Interface AWS CLI AWS SAM
**Note**
Chaque fonction Lambda s’exécute au sein d’un VPC détenu et géré par le service Lambda. Ils VPCs sont gérés automatiquement par Lambda et ne sont pas visibles pour les clients. La configuration de votre fonction pour accéder à d'autres AWS ressources d'un Amazon VPC n'a aucun effet sur le VPC géré par Lambda dans lequel votre fonction exécute.
**Topics**
+ [
## Autorisations IAM requises
](#configuration-vpc-permissions)
+ [
## Associer des fonctions Lambda à un Amazon VPC dans votre Compte AWS
](#configuration-vpc-attaching)
+ [
## Accès à Internet en cas d’attachement à un VPC
](#configuration-vpc-internet-access)
+ [
## IPv6 soutien
](#configuration-vpc-ipv6)
+ [
## Bonnes pratiques d'utilisation de Lambda avec Amazon VPCs
](#configuration-vpc-best-practice)
+ [
## Comprendre les interfaces réseau élastiques Hyperplane () ENIs
](#configuration-vpc-enis)
+ [
## Utilisation des clés de condition IAM pour les paramètres du VPC
](#vpc-conditions)
+ [
## Didacticiels de VPC
](#vpc-tutorials)
## Autorisations IAM requises
Pour associer une fonction Lambda à un Amazon VPC dans votre VPC, Compte AWS Lambda a besoin d'autorisations pour créer et gérer les interfaces réseau qu'il utilise pour permettre à votre fonction d'accéder aux ressources du VPC.
Les interfaces réseau créées par Lambda sont appelées Hyperplane Elastic Network Interfaces ou Hyperplane. ENIs Pour en savoir plus sur ces interfaces réseau, consultez [Comprendre les interfaces réseau élastiques Hyperplane () ENIs](#configuration-vpc-enis).
Vous pouvez accorder à votre fonction les autorisations dont elle a besoin en associant la politique AWS gérée [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)au rôle d'exécution de votre fonction. Lorsque vous créez une fonction dans la console Lambda et que vous l’associez à un VPC, Lambda ajoute automatiquement cette politique d’autorisations pour vous.
Si vous préférez créer votre propre politique d’autorisations IAM, veillez à inclure toutes les autorisations suivantes et à les autoriser sur toutes les ressources (`"Resource": "*"`) :
+ EC2 : CreateNetworkInterface
+ EC2 : DescribeNetworkInterfaces
+ EC2 : DescribeSubnets
+ EC2 : DeleteNetworkInterface
+ EC2 : AssignPrivateIpAddresses
+ EC2 : UnassignPrivateIpAddresses
Notez que le rôle de votre fonction n’a besoin de ces autorisations que pour créer les interfaces réseau, et non pour invoquer votre fonction. Votre fonction peut toujours être invoquée avec succès lorsqu’elle est attachée à un VPC Amazon, même si vous supprimez ces autorisations du rôle d’exécution de votre fonction.
Pour associer votre fonction à un VPC, Lambda doit également vérifier les ressources réseau à l’aide de votre rôle d’utilisateur IAM. Veillez à ce que votre rôle d’utilisateur dispose des autorisations IAM suivantes :
+ **EC2 : DescribeSecurityGroups**
+ **EC2 : DescribeSubnets**
+ **EC2 : DescribeVpcs**
+ **EC2 : GetSecurityGroupsForVpc**
**Note**
Les autorisations Amazon EC2 que vous accordez au rôle d’exécution de votre fonction sont utilisées par le service Lambda pour associer votre fonction à un VPC. Cependant, ces autorisations sont également accordées implicitement au code de votre fonction. Cela signifie que le code de votre fonction est capable d’effectuer ces appels d’API Amazon EC2. Pour obtenir des conseils sur le respect des pratiques exemplaires en matière de sécurité, consultez [Bonnes pratiques de sécurité](#configuration-vpc-best-practice-security).
## Associer des fonctions Lambda à un Amazon VPC dans votre Compte AWS
Associez votre fonction à un Amazon VPC dans votre ordinateur à l'aide Compte AWS de la console Lambda, du ou. AWS CLI AWS SAM Si vous utilisez le AWS CLI ou AWS SAM, ou si vous attachez une fonction existante à un VPC à l'aide de la console Lambda, assurez-vous que le rôle d'exécution de votre fonction dispose des autorisations nécessaires répertoriées dans la section précédente.
Les fonctions Lambda ne peuvent pas se connecter directement à un VPC avec la [location d’instance dédiée](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html). Pour vous connecter à des ressources dans un VPC dédié, [associez-les à un deuxième VPC avec une location par défaut](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-dedicated-vpc/).
------
#### [ Lambda console ]
**Pour attacher une fonction lors de sa création à un Amazon VPC**
1. Ouvrez la page [Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez **Créer une fonction**.
1. Sous **Informations de base**, dans **Nom de fonction**, entrez un nom pour votre fonction.
1. Configurez les paramètres VPC pour la fonction en procédant comme suit :
1. Développez **Advanced settings** (Paramètres avancés).
1. Sélectionnez **Activer le VPC**, puis choisissez le VPC auquel vous souhaitez associer la fonction.
1. (Facultatif) Pour autoriser le [ IPv6 trafic sortant, sélectionnez Autoriser le IPv6 trafic](#configuration-vpc-ipv6) **pour les sous-réseaux à double pile**.
1. Choisissez les sous-réseaux et les groupes de sécurité pour lesquels créer l’interface réseau. Si vous avez sélectionné **Autoriser IPv6 le trafic pour les sous-réseaux à double pile**, tous les sous-réseaux sélectionnés doivent comporter un bloc IPv4 CIDR et un bloc CIDR. IPv6
**Note**
Pour accéder aux ressources privées, connectez votre fonction à des sous-réseaux privés. Si votre fonction a besoin d’un accès Internet, utilisez [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md). La connexion d’une fonction à un sous-réseau public ne lui donne pas accès à Internet ou à une adresse IP publique.
1. Sélectionnez **Create function** (Créer une fonction).
**Pour associer une fonction existante à un Amazon VPC**
1. Ouvrez la [page Fonctions](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda et choisissez votre fonction.
1. Choisissez l’onglet **Configuration**, puis **VPC**.
1. Choisissez **Modifier**.
1. Sous **VPC**, sélectionnez l’Amazon VPC auquel vous souhaitez associer votre fonction.
1. (Facultatif) Pour autoriser le [ IPv6 trafic sortant, sélectionnez Autoriser le IPv6 trafic](#configuration-vpc-ipv6) **pour les sous-réseaux à double pile**.
1. Choisissez les sous-réseaux et les groupes de sécurité pour lesquels créer l’interface réseau. Si vous avez sélectionné **Autoriser IPv6 le trafic pour les sous-réseaux à double pile**, tous les sous-réseaux sélectionnés doivent comporter un bloc IPv4 CIDR et un bloc CIDR. IPv6
**Note**
Pour accéder aux ressources privées, connectez votre fonction à des sous-réseaux privés. Si votre fonction a besoin d’un accès Internet, utilisez [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md). La connexion d’une fonction à un sous-réseau public ne lui donne pas accès à Internet ou à une adresse IP publique.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
**Pour attacher une fonction lors de sa création à un Amazon VPC**
+ Pour créer une fonction Lambda et l’attacher à un VPC, exécutez la commande `create-function` de la CLI suivante.
```
aws lambda create-function --function-name my-function \
--runtime nodejs24.x --handler index.js --zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/lambda-role \
--vpc-config Ipv6AllowedForDualStack=true,SubnetIds=subnet-071f712345678e7c8,subnet-07fd123456788a036,SecurityGroupIds=sg-085912345678492fb
```
Spécifiez vos propres sous-réseaux et groupes de sécurité et configurez `Ipv6AllowedForDualStack` sur `true` ou `false` en fonction de votre cas d’utilisation.
**Pour associer une fonction existante à un Amazon VPC**
+ Pour attacher une fonction existante à un VPC, exécutez la commande `update-function-configuration` de la CLI suivante.
```
aws lambda update-function-configuration --function-name my-function \
--vpc-config Ipv6AllowedForDualStack=true, SubnetIds=subnet-071f712345678e7c8,subnet-07fd123456788a036,SecurityGroupIds=sg-085912345678492fb
```
**Pour dissocier votre fonction d’un VPC**
+ Pour dissocier votre fonction d’un VPC, exécutez la commande `update-function-configuration` de la CLI suivante avec une liste vide de sous-réseaux et de groupes de sécurité VPC.
```
aws lambda update-function-configuration --function-name my-function \
--vpc-config SubnetIds=[],SecurityGroupIds=[]
```
------
#### [ AWS SAM ]
**Pour attacher votre fonction à un VPC**
+ Pour associer une fonction Lambda à un Amazon VPC, ajoutez la propriété `VpcConfig` à votre définition de fonction, comme illustré par l’exemple de modèle suivant. Pour plus d'informations sur cette propriété, voir [AWS: :Lambda : :Function VpcConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-vpcconfig.html) dans le *guide de CloudFormation l'utilisateur* (la AWS SAM `VpcConfig` propriété est transmise directement à la `VpcConfig` propriété d'une CloudFormation `AWS::Lambda::Function` ressource).
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./lambda_function/
Handler: lambda_function.handler
Runtime: python3.12
VpcConfig:
SecurityGroupIds:
- !Ref MySecurityGroup
SubnetIds:
- !Ref MySubnet1
- !Ref MySubnet2
Policies:
- AWSLambdaVPCAccessExecutionRole
MySecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Security group for Lambda function
VpcId: !Ref MyVPC
MySubnet1:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MyVPC
CidrBlock: 10.0.1.0/24
MySubnet2:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MyVPC
CidrBlock: 10.0.2.0/24
MyVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
```
*Pour plus d'informations sur la configuration de votre VPC dans AWS SAM, consultez [AWS: :EC2 : :VPC](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpc.html) dans le guide de l'utilisateur.CloudFormation *
------
## Accès à Internet en cas d’attachement à un VPC
Par défaut, les fonctions Lambda ont accès à l’Internet public. Lorsque vous attachez votre fonction à un VPC, son accès est limité aux ressources disponibles au sein de ce VPC. Pour accorder à votre fonction l’accès à Internet, vous devez également configurer le VPC pour qu’il dispose d’un accès à Internet. Pour en savoir plus, veuillez consulter la section [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md).
## IPv6 soutien
Votre fonction peut se connecter à des ressources dans des sous-réseaux VPC à double pile via. IPv6 Cette option est désactivée par défaut. Pour autoriser le IPv6 trafic sortant, utilisez la console ou l'`--vpc-config Ipv6AllowedForDualStack=true`option associée à la [fonction ou à la commande de création](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)
**Note**
Pour autoriser le IPv6 trafic sortant dans un VPC, tous les sous-réseaux connectés à la fonction doivent être des sous-réseaux à double pile. Lambda ne prend pas en charge les IPv6 connexions IPv6 sortantes pour les sous-réseaux uniquement d'un VPC ni les connexions IPv6 sortantes pour les fonctions qui ne sont pas connectées à un VPC.
Vous pouvez mettre à jour votre code de fonction pour vous connecter explicitement aux ressources du sous-réseau. IPv6 L'exemple Python suivant ouvre un socket et se connecte à un IPv6 serveur.
**Example — Se connecter au IPv6 serveur**
```
def connect_to_server(event, context):
server_address = event['host']
server_port = event['port']
message = event['message']
run_connect_to_server(server_address, server_port, message)
def run_connect_to_server(server_address, server_port, message):
sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM, 0)
try:
# Send data
sock.connect((server_address, int(server_port), 0, 0))
sock.sendall(message.encode())
BUFF_SIZE = 4096
data = b''
while True:
segment = sock.recv(BUFF_SIZE)
data += segment
# Either 0 or end of data
if len(segment) < BUFF_SIZE:
break
return data
finally:
sock.close()
```
## Bonnes pratiques d'utilisation de Lambda avec Amazon VPCs
Pour vous assurer que votre configuration VPC Lambda est conforme aux pratiques exemplaires en la matière, suivez les conseils des sections suivantes.
### Bonnes pratiques de sécurité
Pour associer votre fonction Lambda à un VPC, vous devez octroyer au rôle d’exécution de votre fonction un certain nombre d’autorisations Amazon EC2. Ces autorisations sont nécessaires pour créer les interfaces réseau que votre fonction utilise pour accéder aux ressources du VPC. Cependant, ces autorisations sont également octroyées implicitement au code de votre fonction. Cela signifie que le code de votre fonction dispose de l’autorisation d’effectuer ces appels d’API Amazon EC2.
Pour respecter le principe de l’accès au moindre privilège, ajoutez une politique de rejet au rôle d’exécution de votre fonction, comme dans l’exemple suivant. Cette politique empêche votre code de fonction d'appeler Amazon EC2 APIs, tout en permettant au service Lambda de gérer les ressources VPC en votre nom. La politique utilise la clé de condition `lambda:SourceFunctionArn`, qui s’applique uniquement aux appels d’API effectués par le code de votre fonction lors de l’exécution. Pour de plus amples informations, veuillez consulter [Utilisation de l’ARN de la fonction source pour contrôler le comportement d’accès aux fonctions](permissions-source-function-arn.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSubnets",
"ec2:DetachNetworkInterface",
"ec2:AssignPrivateIpAddresses",
"ec2:UnassignPrivateIpAddresses"
],
"Resource": [ "*" ],
"Condition": {
"ArnEquals": {
"lambda:SourceFunctionArn": [
"arn:aws:lambda:us-west-2:123456789012:function:my_function"
]
}
}
}
]
}
```
------
AWS fournit des *[groupes de sécurité et des](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)* *[listes de contrôle d'accès réseau (ACLs)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)* pour renforcer la sécurité de votre VPC. Les groupes de sécurité contrôlent le trafic entrant et sortant pour vos ressources, et le réseau ACLs contrôlent le trafic entrant et sortant pour vos sous-réseaux. Les groupes de sécurité offrent un contrôle d’accès suffisant pour la plupart des sous-réseaux. Vous pouvez utiliser le réseau ACLs si vous souhaitez ajouter une couche de sécurité supplémentaire à votre VPC. Pour obtenir des directives générales sur les meilleures pratiques de sécurité lors de l'utilisation d'Amazon VPCs, consultez [les meilleures pratiques de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) dans le guide de l'*utilisateur d'Amazon Virtual Private Cloud*.
### Bonnes pratiques en matière de performances
Lorsque vous attachez votre fonction à un VPC, Lambda vérifie s’il existe une ressource réseau disponible (ENI Hyperplane) à laquelle elle peut se connecter. Les hyperplans ENIs sont associés à une combinaison particulière de groupes de sécurité et de sous-réseaux VPC. Si vous avez déjà attaché une fonction à un VPC, le fait de spécifier les mêmes sous-réseaux et groupes de sécurité lorsque vous attachez une autre fonction signifie que Lambda peut partager les ressources du réseau et éviter d’avoir à créer une ENI Hyperplane. Pour plus d'informations sur Hyperplane ENIs et son cycle de vie, consultez[Comprendre les interfaces réseau élastiques Hyperplane () ENIs](#configuration-vpc-enis).
## Comprendre les interfaces réseau élastiques Hyperplane () ENIs
Une ENI Hyperplane est une ressource gérée qui agit comme une interface réseau entre votre fonction Lambda et les ressources auxquelles vous souhaitez que votre fonction se connecte. Le service Lambda les crée et les gère ENIs automatiquement lorsque vous attachez votre fonction à un VPC.
Les hyperplans ne ENIs sont pas directement visibles pour vous, et vous n'avez pas besoin de les configurer ou de les gérer. Cependant, être au fait de leur fonctionnement peut vous aider à comprendre le comportement de votre fonction lorsque vous l’attachez à un VPC.
La première fois que vous attachez une fonction à un VPC à l’aide d’une combinaison particulière de sous-réseau et de groupe de sécurité, Lambda crée une ENI Hyperplane. D’autres fonctions de votre compte qui utilisent la même combinaison de sous-réseau et de groupe de sécurité peuvent également utiliser cette ENI. Dans la mesure du possible, Lambda réutilise les ressources existantes ENIs pour optimiser l'utilisation des ressources et minimiser la création de nouvelles ressources. ENIs Cependant, chaque ENI Hyperplane prend en charge jusqu’à 65 000 connexions/ports. Si le nombre de connexions dépasse cette limite, Lambda adapte le nombre de connexions ENIs automatiquement en fonction du trafic réseau et des exigences de simultanéité.
Pour les nouvelles fonctions, pendant que Lambda crée une ENI Hyperplane, votre fonction reste à l’état En attente et vous ne pouvez pas l’invoquer. Votre fonction passe à l’état Actif uniquement lorsque l’ENI Hyperplane est prête, ce qui peut prendre plusieurs minutes. Pour les fonctions existantes, aucune opération supplémentaire ciblant la fonction ne peut être effectuée, comme la création de versions ou la mise à jour du code de la fonction, mais vous pouvez continuer à invoquer les versions antérieures de la fonction.
Dans le cadre de la gestion du cycle de vie d'ENI, Lambda peut supprimer et recréer pour équilibrer la charge du trafic réseau ENIs ou ENIs pour résoudre les problèmes détectés lors des bilans de santé d'ENI. De plus, si une fonction Lambda reste inactive pendant 14 jours, Lambda récupère tout hyperplan inutilisé ENIs et définit l'état de la fonction sur. `Inactive` La prochaine tentative d’invocation échouera et la fonction entrera à nouveau dans l’état En attente jusqu’à ce que Lambda termine la création ou l’allocation d’une ENI Hyperplane. Nous recommandons que votre design ne repose pas sur la persistance de ENIs.
Lorsque vous mettez à jour une fonction pour supprimer sa configuration VPC, Lambda a besoin de 20 minutes au maximum pour supprimer l'ENI Hyperplane attaché. Lambda ne supprime l’ENI que si aucune autre fonction (ou version de fonction publiée) n’utilise cette ENI Hyperplane.
Lambda s’appuie sur les permissions du [rôle d’exécution](lambda-intro-execution-role.md) de la fonction pour supprimer l’ENI Hyperplane. Si vous supprimez le rôle d’exécution avant que Lambda ne supprime l’ENI Hyperplane, Lambda ne pourra pas la supprimer. Vous pouvez effectuer la suppression manuellement.
## Utilisation des clés de condition IAM pour les paramètres du VPC
Vous pouvez utiliser des clés de condition spécifiques de Lambda pour les paramètres du VPC afin de fournir des contrôles d’autorisation supplémentaires pour vos fonctions Lambda. Par exemple, vous pouvez exiger que toutes les fonctions de votre organisation soient connectées à un VPC. Vous pouvez également spécifier les sous-réseaux et les groupes de sécurité que les utilisateurs de la fonction peuvent et ne peuvent pas utiliser.
Lambda prend également en charge les clés de condition suivantes dans les stratégies IAM :
+ **lambda : VpcIds** — Autoriser ou refuser un ou plusieurs VPCs.
+ **lambda : SubnetIds** — Autoriser ou refuser un ou plusieurs sous-réseaux.
+ **lambda : SecurityGroupIds** — Autoriser ou refuser un ou plusieurs groupes de sécurité.
L'API Lambda fonctionne [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)et [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)prend en charge ces clés de condition. Pour de plus amples informations sur l’utilisation de clés de condition dans des stratégies IAM, consultez [Éléments de politique JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
**Astuce**
Si votre fonction inclut déjà une configuration VPC à partir d’une demande d’API précédente, vous pouvez envoyer une demande `UpdateFunctionConfiguration` sans la configuration du VPC.
### Exemple de stratégies avec des clés de condition pour les paramètres du VPC
Les exemples suivants montrent comment utiliser les clés de condition pour les paramètres du VPC. Après avoir créé une instruction de politique avec les restrictions souhaitées, ajoutez l’instruction de politique pour l’utilisateur ou le rôle cible.
#### Assurez-vous que les utilisateurs déploient uniquement les fonctions connectées au VPC
Pour vous assurer que tous les utilisateurs déploient uniquement des fonctions connectées au VPC, vous pouvez refuser les opérations de création et de mise à jour de fonctions qui n’incluent pas d’ID de VPC valide.
Notez que l’ID de VPC n’est pas un paramètre d’entrée pour la demande `CreateFunction` ou `UpdateFunctionConfiguration`. Lambda récupère la valeur de l’ID de VPC en fonction des paramètres du sous-réseau et du groupe de sécurité.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnforceVPCFunction",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"Null": {
"lambda:VpcIds": "true"
}
}
}
]
}
```
------
#### Refuser aux utilisateurs l'accès à VPCs des sous-réseaux ou à des groupes de sécurité spécifiques
Pour refuser aux utilisateurs l'accès à une condition spécifique VPCs, utilisez cette option `StringEquals` pour vérifier la valeur de la `lambda:VpcIds` condition. L’exemple suivant refuse aux utilisateurs l’accès à `vpc-1` et `vpc-2`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnforceOutOfVPC",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:VpcIds": [
"vpc-1",
"vpc-2"
]
}
}
}
]
}
```
------
Pour refuser aux utilisateurs l’accès à des sous-réseaux spécifiques, utilisez `StringEquals` pour vérifier la valeur de la condition `lambda:SubnetIds`. L’exemple suivant refuse aux utilisateurs l’accès à `subnet-1` et `subnet-2`.
```
{
"Sid": "EnforceOutOfSubnet",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"lambda:SubnetIds": ["subnet-1", "subnet-2"]
}
}
}
```
Pour refuser aux utilisateurs l’accès à des groupes de sécurité spécifiques, utilisez `StringEquals` pour vérifier la valeur de la condition `lambda:SecurityGroupIds`. L’exemple suivant refuse aux utilisateurs l’accès à `sg-1` et `sg-2`.
```
{
"Sid": "EnforceOutOfSecurityGroups",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"lambda:SecurityGroupIds": ["sg-1", "sg-2"]
}
}
}
]
}
```
#### Autoriser les utilisateurs à créer et à mettre à jour des fonctions avec des paramètres VPC spécifiques
Pour autoriser les utilisateurs à accéder à une condition spécifique VPCs, utilisez cette option `StringEquals` pour vérifier la valeur de la `lambda:VpcIds` condition. L’exemple suivant permet aux utilisateurs d’accéder à `vpc-1` et `vpc-2`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnforceStayInSpecificVpc",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:VpcIds": [
"vpc-1",
"vpc-2"
]
}
}
}
]
}
```
------
Pour permettre aux utilisateurs d’accéder à des sous-réseaux spécifiques, utilisez `StringEquals` pour vérifier la valeur de la condition `lambda:SubnetIds`. L’exemple suivant permet aux utilisateurs d’accéder à `subnet-1` et `subnet-2`.
```
{
"Sid": "EnforceStayInSpecificSubnets",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"lambda:SubnetIds": ["subnet-1", "subnet-2"]
}
}
}
```
Pour permettre aux utilisateurs d’accéder à des groupes de sécurité spécifiques, utilisez `StringEquals` pour vérifier la valeur de la condition `lambda:SecurityGroupIds`. L’exemple suivant permet aux utilisateurs d’accéder à `sg-1` et `sg-2`.
```
{
"Sid": "EnforceStayInSpecificSecurityGroup",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"lambda:SecurityGroupIds": ["sg-1", "sg-2"]
}
}
}
]
}
```
## Didacticiels de VPC
Dans les didacticiels suivants, vous connectez une fonction Lambda à des ressources dans votre VPC.
+ [Tutoriel : Utilisation d’une fonction Lambda pour accéder à Amazon RDS dans un Amazon VPC](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-lambda-tutorial.html)
+ [Tutoriel : Configuration d'une fonction Lambda pour accéder à Amazon ElastiCache dans un Amazon VPC](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/LambdaRedis.html)
# Octroi aux fonctions Lambda d’un accès à une ressource dans un Amazon VPC d’un autre compte
Vous pouvez donner à votre AWS Lambda fonction l'accès à une ressource d'un Amazon VPC dans Amazon Virtual Private Cloud géré par un autre compte, sans exposer l'un ou l'autre VPC à Internet. Ce modèle d'accès vous permet de partager des données avec d'autres organisations utilisant AWS. Grâce à ce modèle d'accès, vous pouvez partager des données VPCs avec un niveau de sécurité et de performance supérieur à celui d'Internet. Configurez votre fonction Lambda pour utiliser une connexion d’appairage d’Amazon VPC pour accéder à ces ressources.
**Avertissement**
Lorsque vous autorisez l'accès entre les comptes ou VPCs que vous vérifiez que votre plan répond aux exigences de sécurité des organisations respectives qui gèrent ces comptes. Le respect des instructions de ce document aura une incidence sur le niveau de sécurité de vos ressources.
Dans ce didacticiel, vous connectez deux comptes à l'aide d'une connexion d'appairage à l'aide IPv4 de. Vous configurez une fonction Lambda qui n’est pas déjà connectée à un Amazon VPC. Vous configurez la résolution DNS pour connecter votre fonction à des ressources qui ne fournissent pas de données statiques IPs. Pour adapter ces instructions à d’autres scénarios d’appairage, consultez le [Guide d’appairage de VPC](https://docs.aws.amazon.com//vpc/latest/peering/what-is-vpc-peering.html).
## Conditions préalables
Pour permettre à une fonction Lambda d’accéder à une ressource d’un autre compte, vous devez avoir :
+ une fonction Lambda, configurée pour s’authentifier auprès de votre ressource puis lire à partir de celle-ci ;
+ une ressource d’un autre compte, tel qu’un cluster Amazon RDS, disponible via Amazon VPC ;
+ les informations d’identification du compte de votre fonction Lambda et du compte de votre ressource. Si vous n’êtes pas autorisé à utiliser le compte de votre ressource, contactez un utilisateur autorisé pour préparer ce compte ;
+ l’autorisation de créer et de mettre à jour un VPC (et de prendre en charge les ressources Amazon VPC) à associer à votre fonction Lambda ;
+ l’autorisation de mettre à jour le rôle d’exécution et la configuration VPC de votre fonction Lambda ;
+ l’autorisation de créer une connexion d’appairage de VPC dans le compte de votre fonction Lambda ;
+ l’autorisation d’accepter une connexion d’appairage de VPC dans le compte de votre ressource ;
+ l’autorisation de mettre à jour la configuration du VPC de votre ressource (et de prendre en charge les ressources Amazon VPC) ;
+ l’autorisation d’invoquer votre fonction Lambda.
## Création d’un Amazon VPC dans le compte de votre fonction
Créez un Amazon VPC, des sous-réseaux, des tables de routage et un groupe de sécurité dans le compte de votre fonction Lambda.
**Pour créer un VPC, des sous-réseaux et d'autres ressources VPC à l'aide de la console**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Sur le tableau de bord, choisissez **Créer un VPC**.
1. Pour le **bloc IPv4 CIDR**, fournissez un bloc CIDR privé. Votre bloc d’adresse CIDR ne doit chevaucher aucun bloc utilisé dans le VPC de votre ressource. Ne choisissez pas un bloc que le VPC de vos ressources utilise pour l'attribuer IPs aux ressources ou un bloc déjà défini dans les tables de routage de votre VPC de ressources. Pour plus d’informations sur la définition des blocs d’adresse CIDR appropriés, consultez [VPC CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html).
1. Choisissez **Personnaliser AZs**.
1. Sélectionnez la même ressource AZs que votre ressource.
1. Pour **Nombre de sous-réseaux publics**, choisissez **0**.
1. Pour **VPC endpoints** (Points de terminaison d'un VPC), choisissez **None** (Aucun).
1. Sélectionnez **Create VPC** (Créer un VPC).
## Octroi d’autorisations VPC au rôle d’exécution de votre fonction
[AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)Attachez-vous au rôle d'exécution de votre fonction pour lui permettre de se connecter à VPCs.
**Pour octroyer des autorisations VPC au rôle d’exécution de votre fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de votre fonction .
1. Choisissez **Configuration**.
1. Choisissez **Autorisations**.
1. Sous **Nom du rôle**, choisissez le rôle d’exécution.
1. Dans la section **Politiques d’autorisations**, choisissez **Ajouter des autorisations**.
1. Dans la liste déroulante, choisissez **Attacher des politiques**.
1. Dans la zone de recherche, saisissez `AWSLambdaVPCAccessExecutionRole`.
1. À gauche du nom de politique, cochez la case.
1. Choisissez **Ajouter des autorisations**.
**Pour attacher votre fonction à votre Amazon VPC**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de votre fonction .
1. Choisissez l’onglet **Configuration**, puis **VPC**.
1. Choisissez **Modifier**.
1. Sous **VPC**, sélectionnez votre VPC.
1. Sous **Sous-réseaux**, choisissez vos sous-réseaux.
1. Sous **Groupe de sécurité**, sélectionnez le groupe de sécurité par défaut de votre VPC.
1. Choisissez **Enregistrer**.
## Création d’une requête de connexion d’appairage de VPC
Créez une requête de connexion d’appairage de VPC entre le VPC de votre fonction (le VPC demandeur) et le VPC de votre ressource (le VPC accepteur).
**Pour demander une connexion d’appairage de VPC depuis le VPC de votre fonction**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le volet de navigation, choisissez **Peering connections** (Connexions d'appairage).
1. Choisissez **Create peering connection** (Créer une connexion d'appairage).
1. Pour **ID VPC (demandeur)**, sélectionnez le VPC de votre fonction.
1. Pour **ID de compte**, saisissez l’ID du compte de votre ressource.
1. Pour **VPC ID (Accepter)**, saisissez le VPC de votre ressource.
## Préparation du compte de votre ressource
Pour créer votre connexion d’appairage et préparer le VPC de votre ressource à utiliser la connexion, connectez-vous au compte de votre ressource avec un rôle doté des autorisations répertoriées dans les conditions requises. Les étapes de connexion peuvent être différentes en fonction de la manière dont le compte est sécurisé. Pour plus d'informations sur la façon de se connecter à un AWS compte, consultez le [Guide de l'utilisateur de AWS connexion](https://docs.aws.amazon.com//signin/latest/userguide/what-is-sign-in.html). Au sein du compte de votre ressource, effectuez les procédures suivantes.
**Pour accepter une requête de connexion d’appairage de VPC**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le volet de navigation, choisissez **Peering connections** (Connexions d'appairage).
1. Sélectionnez la connexion d’appairage de VPC en attente (statut pending-acceptance).
1. Choisissez **Actions**.
1. Dans la liste déroulante Actions, choisissez **Accepter la demande**.
1. Lorsque vous êtes invité à confirmer l'opération, choisissez **Accepter la demande**.
1. Choisissez **Modifier mes tables de routage maintenant** pour ajouter une route à la table de routage principale de votre VPC afin de pouvoir envoyer et recevoir du trafic via la connexion d’appairage.
Inspectez les tables de routage du VPC de la ressource. La route générée par Amazon VPC peut ne pas établir de connectivité, en fonction de la configuration du VPC de votre ressource. Vérifiez les conflits entre la nouvelle route et la configuration existante du VPC. Pour plus d’informations sur le dépannage, consultez [Troubleshoot a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/troubleshoot-vpc-peering-connections.html) dans le *Guide d’appairage de VPC Amazon Virtual Private Cloud*.
**Pour mettre à jour le groupe de sécurité de votre ressource**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le panneau de navigation, choisissez **Groupes de sécurité**.
1. Sélectionnez le groupe de sécurité pour votre ressource.
1. Choisissez **Actions**.
1. Dans la liste déroulante, choisissez **Modifier les règles entrantes**.
1. Choisissez **Ajouter une règle**.
1. Pour **Source**, saisissez l’ID de compte et de groupe de sécurité de votre fonction, séparés par une barre oblique (par exemple, 111122223333/sg-1a2b3c4d).
1. Choisissez **Edit outbound rules** (Modifier les règles sortantes).
1. Vérifiez si le trafic sortant est restreint. Les paramètres de VPC par défaut autorisent tout le trafic sortant. Si le trafic sortant est restreint, passez à l’étape suivante.
1. Choisissez **Ajouter une règle**.
1. Pour **Destination**, saisissez l’ID de compte et de groupe de sécurité de votre fonction, séparés par une barre oblique (par exemple, 111122223333/sg-1a2b3c4d).
1. Sélectionnez **Enregistrer les règles**.
**Pour activer la résolution DNS pour votre connexion d’appairage**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le volet de navigation, choisissez **Peering connections** (Connexions d'appairage).
1. Sélectionnez votre connexion d’appairage.
1. Choisissez **Actions**.
1. Choisissez **Modifier les paramètres DNS**.
1. En-dessous de **Résolution DNS acceptée**, sélectionnez **Autoriser le VPC demandeur à convertir le DNS des hôtes VPC accepteurs** en IP privée.
1. Sélectionnez **Enregistrer les modifications**.
## Mise à jour de la configuration VPC dans le compte de votre fonction
Connectez-vous au compte de votre fonction, puis mettez à jour la configuration du VPC.
**Pour ajouter une route pour une connexion d’appairage de VPC**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le volet de navigation, choisissez **Route tables** (Tables de routage).
1. Cochez la case en regard du nom de la table de routage pour le sous-réseau que vous avez associé à votre fonction.
1. Choisissez **Actions**.
1. Choisissez **Edit routes (Modifier des routes)**.
1. Choisissez **Ajouter une route**.
1. Pour **Destination**, saisissez le bloc CIDR du VPC de votre ressource.
1. Pour **Cible**, sélectionnez la connexion d’appairage de VPC.
1. Sélectionnez **Enregistrer les modifications**.
Pour de plus amples informations relatives aux éléments que vous pouvez rencontrer lors de la mise à jour de vos tables de routage, consultez [Update your route tables for a VPC peering connection](https://docs.aws.amazon.com//vpc/latest/peering/vpc-peering-routing.html).
**Pour mettre à jour le groupe de sécurité de votre fonction Lambda**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le panneau de navigation, choisissez **Groupes de sécurité**.
1. Choisissez **Actions**.
1. Choisissez **Modifier les règles entrantes**.
1. Choisissez **Ajouter une règle**.
1. Pour **Source**, saisissez l’ID de compte et de groupe de sécurité de votre ressource, séparés par une barre oblique (par exemple, 111122223333/sg-1a2b3c4d).
1. Sélectionnez **Enregistrer les règles**.
**Pour activer la résolution DNS pour votre connexion d’appairage**
1. Ouvrez la [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le volet de navigation, choisissez **Peering connections** (Connexions d'appairage).
1. Sélectionnez votre connexion d’appairage.
1. Choisissez **Actions**.
1. Choisissez **Modifier les paramètres DNS**.
1. Sous **Résolution DNS du demandeur**, sélectionnez **Autoriser le VPC accepteur à convertir le DNS des hôtes VPC demandeur** en IP privée.
1. Sélectionnez **Enregistrer les modifications**.
## Test de votre fonction
**Pour créer un événement de test et inspecter la sortie de votre fonction**
1. Dans le volet **Source du code**, choisissez **Test**.
1. Sélectionnez **Créer un événement**.
1. Dans le panneau **JSON d’événement**, remplacez les valeurs par défaut par une entrée adaptée à votre fonction Lambda.
1. Sélectionnez **Invoquer **.
1. Dans l’onglet **Résultats de l’exécution**, vérifiez que **Response** contient le résultat attendu.
En outre, vous pouvez consulter les journaux de votre fonction pour vérifier qu’ils correspondent à vos attentes.
**Pour consulter les enregistrements d'invocation de votre fonction dans Logs CloudWatch**
1. Choisissez l’onglet **Surveiller**.
1. Choisissez **Afficher CloudWatch les journaux**.
1. Dans l'onglet **Flux de journaux**, choisissez le flux de journaux pour l'invocation de votre fonction.
1. Vérifiez que vos journaux sont conformes à vos attentes.
# Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC
Par défaut, les fonctions Lambda s’exécutent dans un VPC géré par Lambda disposant d’un accès à Internet. Pour accéder aux ressources d’un VPC dans votre compte, vous pouvez ajouter une configuration VPC à une fonction. Cela limite la fonction aux ressources de ce VPC, sauf si le VPC dispose d’un accès à Internet. Cette page explique comment fournir un accès Internet aux fonctions Lambda connectées au VPC.
## Je n’ai pas encore de VPC
### Créer le VPC
Le **flux de travail de création de VPC** crée toutes les ressources VPC requises pour qu’une fonction Lambda accède à l’Internet public à partir d’un sous-réseau privé, y compris les sous-réseaux, la passerelle NAT, la passerelle Internet et les entrées de table de routage.
**Pour créer le VPC**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Sur le tableau de bord, choisissez **Créer un VPC**.
1. Sous **Ressources à créer**, choisissez **VPC et plus encore**.
1. **Configurer le VPC**
1. Pour **Name tag auto-generation** (Génération automatique de balises de nom), saisissez un nom pour le VPC.
1. Pour le **bloc IPv4 CIDR**, vous pouvez conserver la suggestion par défaut ou saisir le bloc CIDR requis par votre application ou votre réseau.
1. Si votre application communique à l'aide d' IPv6 adresses, choisissez le bloc **IPv6CIDR, le bloc** CIDR **fourni par Amazon IPv6 **.
1. **Configurer les sous-réseaux**
1. Pour **Nombre de zones de disponibilité**, choisissez **2**. Nous en recommandons au moins deux AZs pour une haute disponibilité.
1. Pour **Number of public subnets** (Nombre de sous-réseaux publics), choisissez **2**.
1. Pour **Number of private subnets** (Nombre de sous-réseaux privés), choisissez **2**.
1. Vous pouvez conserver le bloc d'adresse CIDR par défaut pour le sous-réseau public ou développer **Personnaliser les blocs d'adresse CIDR du sous-réseau** et saisir un bloc d'adresse CIDR. Pour plus d’informations, consultez [Subnet CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html).
1. Pour **Passerelles NAT**, choisissez **1 par zone de disponibilité** afin d'améliorer la résilience.
1. Pour la **passerelle Internet de sortie uniquement**, choisissez **Oui** si vous avez choisi d'inclure un bloc IPv6 CIDR.
1. Pour **Points de terminaison de VPC**, conservez la valeur par défaut (**Passerelle S3**). Cette option n’entraîne pas de frais. Pour plus d’informations, consultez [Types of VPC endpoints for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3).
1. Pour **Options DNS**, conservez les paramètres par défaut.
1. Sélectionnez **Create VPC** (Créer un VPC).
### Configurer la fonction Lambda
**Pour configurer un VPC lorsque vous créez une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Sous **Informations de base**, dans **Nom de fonction**, entrez un nom pour votre fonction.
1. Développez **Advanced settings (Paramètres avancés)**.
1. Sélectionnez **Activer le VPC**, puis choisissez un VPC.
1. (Facultatif) Pour autoriser le [ IPv6 trafic sortant, sélectionnez Autoriser le IPv6 trafic](configuration-vpc.md#configuration-vpc-ipv6) **pour les sous-réseaux à double pile**.
1. Pour **Sous-réseaux**, sélectionnez tous les sous-réseaux privés. Les sous-réseaux privés peuvent accéder à Internet via une passerelle NAT. La connexion d’une fonction à un sous-réseau public ne lui donne pas accès à Internet.
**Note**
Si vous avez sélectionné **Autoriser IPv6 le trafic pour les sous-réseaux à double pile**, tous les sous-réseaux sélectionnés doivent comporter un bloc IPv4 CIDR et un bloc CIDR. IPv6
1. Pour les **groupes de sécurité**, sélectionnez un groupe de sécurité qui autorise le trafic sortant.
1. Choisissez **Créer une fonction**.
Lambda crée automatiquement un rôle d'exécution avec la politique [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) AWS gérée. Les autorisations de cette politique ne sont nécessaires que pour créer des interfaces réseau élastiques pour la configuration VPC, et non pour invoquer votre fonction. Pour appliquer les autorisations de moindre privilège, vous pouvez supprimer la **AWSLambdaVPCAccessExecutionRole**politique de votre rôle d'exécution après avoir créé la fonction et la configuration VPC. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises](configuration-vpc.md#configuration-vpc-permissions).
**Pour configurer un VPC pour une fonction existante**
Pour ajouter une configuration VPC à une fonction existante, le rôle d’exécution de la fonction doit être [autorisé à créer et à gérer des interfaces réseau élastiques](configuration-vpc.md#configuration-vpc-permissions). La politique [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) AWS gérée inclut les autorisations requises. Pour appliquer les autorisations de moindre privilège, vous pouvez supprimer la **AWSLambdaVPCAccessExecutionRole**politique de votre rôle d'exécution après avoir créé la configuration VPC.
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez l’onglet **Configuration** puis choisissez **VPC**.
1. Sous **VPC**, choisissez **Modifier**.
1. Sélectionnez le VPC.
1. (Facultatif) Pour autoriser le [ IPv6 trafic sortant, sélectionnez Autoriser le IPv6 trafic](configuration-vpc.md#configuration-vpc-ipv6) **pour les sous-réseaux à double pile**.
1. Pour **Sous-réseaux**, sélectionnez tous les sous-réseaux privés. Les sous-réseaux privés peuvent accéder à Internet via une passerelle NAT. La connexion d’une fonction à un sous-réseau public ne lui donne pas accès à Internet.
**Note**
Si vous avez sélectionné **Autoriser IPv6 le trafic pour les sous-réseaux à double pile**, tous les sous-réseaux sélectionnés doivent comporter un bloc IPv4 CIDR et un bloc CIDR. IPv6
1. Pour les **groupes de sécurité**, sélectionnez un groupe de sécurité qui autorise le trafic sortant.
1. Choisissez **Enregistrer**.
### Tester la fonction
Utilisez l’exemple de code suivant pour vérifier que votre fonction connectée au VPC peut accéder à l’Internet public. En cas de succès, le code renvoie un code d’état `200`. En cas d’échec, la fonction expire.
------
#### [ Node.js ]
1. Dans le volet **Source du code** de la console Lambda, collez le code suivant dans le fichier **index.mjs**. La fonction envoie une requête HTTP GET à un point de terminaison public et renvoie le code de réponse HTTP pour tester si la fonction a accès à l’Internet public.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/code-source-nodejs.png)
**Example – Requête HTTP avec async/await**
```
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;
}
};
```
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)
1. Choisissez l’onglet **Test**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-tab.png)
1. Sélectionnez **Tester)**.
1. La fonction renvoie un code d’état `200`. Cela signifie que la fonction dispose d’un accès Internet sortant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-successful-200.png)
Si la fonction ne parvient pas à accéder à l’Internet public, un message d’erreur de ce type s’affiche :
```
{
"errorMessage": "2024-04-11T17:22:20.857Z abe12jlc-640a-8157-0249-9be825c2y110 Task timed out after 3.01 seconds"
}
```
------
#### [ Python ]
1. Dans le volet **Source du code** de la console Lambda, collez le code suivant dans le fichier **lambda\$1function.py**. La fonction envoie une requête HTTP GET à un point de terminaison public et renvoie le code de réponse HTTP pour tester si la fonction a accès à l’Internet public.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/code-source-python.png)
```
import urllib.request
def lambda_handler(event, context):
try:
response = urllib.request.urlopen('https://aws.amazon.com')
status_code = response.getcode()
print('Response Code:', status_code)
return status_code
except Exception as e:
print('Error:', e)
raise e
```
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)
1. Choisissez l’onglet **Test**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-tab.png)
1. Sélectionnez **Tester)**.
1. La fonction renvoie un code d’état `200`. Cela signifie que la fonction dispose d’un accès Internet sortant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-successful-200.png)
Si la fonction ne parvient pas à accéder à l’Internet public, un message d’erreur de ce type s’affiche :
```
{
"errorMessage": "2024-04-11T17:22:20.857Z abe12jlc-640a-8157-0249-9be825c2y110 Task timed out after 3.01 seconds"
}
```
------
## J’ai déjà un VPC
Si vous possédez déjà un VPC mais que vous devez configurer un accès Internet public pour une fonction Lambda, procédez comme suit. Cette procédure suppose que votre VPC possède au moins deux sous-réseaux. Si vous n’avez pas deux sous-réseaux, consultez [Create a subnet](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) dans le *Guide de l’utilisateur Amazon VPC*.
### Vérification de la configuration de la table de routage
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez l’**ID de VPC**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/vpc-id.png)
1. Faites défiler la page jusqu’à la section **Carte des ressources**. Notez les mappages des tables de routage. Ouvrez chaque table de routage mappée à un sous-réseau.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/route-table-associations.png)
1. Faites défiler jusqu’à l’onglet **Routes**. Passez en revue les itinéraires pour déterminer si votre VPC possède les deux tables de routage suivantes. Chacune de ces exigences doit être satisfaite par une table de routage distincte.
+ Le trafic Internet (`0.0.0.0/0`pour IPv4, `::/0` pour IPv6) est acheminé vers une passerelle Internet (). `igw-xxxxxxxxxx` Cela signifie que le sous-réseau associé à la table de routage est un sous-réseau public.
**Note**
Si votre sous-réseau ne possède pas de bloc IPv6 CIDR, vous ne verrez que la IPv4 route ()`0.0.0.0/0`.
**Example Table de routage de sous-réseau public**
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/routes-public.png)
+ Le trafic Internet pour IPv4 (`0.0.0.0/0`) est acheminé vers une passerelle NAT (`nat-xxxxxxxxxx`) associée à un sous-réseau public. Cela signifie que le sous-réseau est un sous-réseau privé qui peut accéder à l’Internet via la passerelle NAT.
**Note**
Si votre sous-réseau comporte un bloc IPv6 CIDR, la table de routage doit également acheminer le IPv6 trafic Internet (`::/0`) vers une passerelle Internet de sortie uniquement (). `eigw-xxxxxxxxxx` Si votre sous-réseau ne possède pas de bloc IPv6 CIDR, vous ne verrez que la IPv4 route ()`0.0.0.0/0`.
**Example table de routage de sous-réseau privé**
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/routes-private.png)
1. Répétez l’étape précédente jusqu’à ce que vous ayez examiné chaque table de routage associée à un sous-réseau de votre VPC et confirmé que vous disposez d’une table de routage avec une passerelle Internet et d’une table de routage avec une passerelle NAT.
Si vous n’avez pas deux tables de routage, l’une avec une route vers une passerelle Internet et l’autre avec une route vers une passerelle NAT, suivez ces étapes pour créer les ressources manquantes et les entrées de table de routage.
### Création d’une table de routage
Suivez les étapes ci-dessous pour créer une table de routage et l’associer à un sous-réseau.
**Pour créer une table de routage personnalisée à l’aide de la console Amazon VPC**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le volet de navigation, choisissez **Route tables** (Tables de routage).
1. Choisissez **Créer une table de routage**.
1. (Facultatif) Pour **Nom**, entrez un nom pour votre table de routage.
1. Pour **VPC**, choisissez votre VPC.
1. (Facultatif) Pour ajouter une identification, choisissez **Add new tag** (Ajouter une identification) et saisissez la clé et la valeur de l'identification.
1. Choisissez **Créer une table de routage**.
1. Sur l'onglet **Associations de sous-réseau**, choisissez **Modifier les associations de sous-réseau**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/route-table-subnet.png)
1. Sélectionnez la case à cocher pour le sous-réseau à associer à la table de routage.
1. Choisissez **Save associations (Enregistrer les associations)**.
### Création d'une passerelle Internet
Procédez comme suit pour créer une passerelle Internet, l’associer à votre VPC et l’ajouter à la table de routage de votre sous-réseau public.
**Pour créer une passerelle Internet**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le panneau de navigation, choisissez **Passerelles Internet**.
1. Choisissez **Créer une passerelle Internet**.
1. (Facultatif) Saisissez un nom pour votre passerelle Internet.
1. (Facultatif) Pour ajouter une identification, choisissez **Add new tag** (Ajouter une identification) et saisissez la clé et la valeur de l’identification.
1. Choisissez **Créer une passerelle Internet**.
1. Choisissez **Attacher à un VPC** dans la bannière en haut de l’écran, sélectionnez un VPC disponible, puis choisissez **Attacher une passerelle Internet**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/igw-attach-vpc.png)
1. Choisissez l’**ID de VPC**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/igw-subnet-1.png)
1. Sélectionnez à nouveau l’**ID de VPC** pour ouvrir la page des détails.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/igw-your-vpcs.png)
1. Faites défiler vers le bas jusqu’à la section **Carte des ressources** et choisissez un sous-réseau. Les détails du sous-réseau s’affichent dans un nouvel onglet.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/vpc-subnets.png)
1. Cliquez sur le lien sous **Table de routage**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/subnet-route-table.png)
1. Choisissez l’**ID de la table de routage** pour ouvrir la page de détails de la table de routage.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/route-table-id.png)
1. Sous **Routes**, choisissez la **Modifier des routes**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/edit-routes.png)
1. Choisissez **Ajouter une route**, puis saisissez `0.0.0.0/0` dans la zone **Destination**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-route-1.png)
1. Pour **Cible**, sélectionnez **Passerelle Internet**, puis choisissez la passerelle Internet que vous avez créée précédemment. Si votre sous-réseau possède un bloc IPv6 CIDR, vous devez également ajouter une route `::/0` vers la même passerelle Internet.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-route-2.png)
1. Sélectionnez **Enregistrer les modifications**.
### Créer une passerelle NAT
Suivez ces étapes pour créer une passerelle NAT, l’associer à un sous-réseau public, puis l’ajouter à la table de routage de votre sous-réseau privé.
**Pour créer une passerelle NAT et l’associer à un sous-réseau public**
1. Dans le volet de navigation, sélectionnez **Passerelles NAT**.
1. Sélectionnez **Créer une passerelle NAT**.
1. (Facultatif) Saisissez un nom pour votre passerelle NAT.
1. Pour **Sous-réseau**, sélectionnez le sous-réseau public dans votre VPC. (Un sous-réseau public est un sous-réseau qui a une entrée de table de routage comportant une route vers une passerelle Internet)
**Note**
Les passerelles NAT sont associées à un sous-réseau public, mais l’entrée de la table de routage se trouve dans le sous-réseau privé.
1. Pour **ID d’allocation IP élastique**, sélectionnez une adresse IP élastique ou choisissez **Allouer une adresse IP élastique**.
1. Sélectionnez **Créer une passerelle NAT**.
**Pour ajouter une route vers la passerelle NAT dans la table de routage du sous-réseau privé**
1. Dans le panneau de navigation, choisissez **Subnets** (Sous-réseaux).
1. Sélectionnez un sous-réseau privé dans votre VPC. (Un sous-réseau privé est un sous-réseau qui ne comporte pas de route vers une passerelle Internet dans sa table de routage)
1. Cliquez sur le lien sous **Table de routage**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/subnet-route-table.png)
1. Choisissez l’**ID de la table de routage** pour ouvrir la page de détails de la table de routage.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/route-table-id.png)
1. Choisissez l’onglet **Routes**, puis **Modifier des routes**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/route-table-edit-routes.png)
1. Choisissez **Ajouter une route**, puis saisissez `0.0.0.0/0` dans la zone **Destination**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-route-1.png)
1. Pour **Cible**, choisissez **Passerelle NAT**, puis sélectionnez la passerelle NAT que vous avez créée.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-route-nat.png)
1. Sélectionnez **Enregistrer les modifications**.
### Créer une passerelle Internet de sortie uniquement (uniquement) IPv6
Procédez comme suit pour créer une passerelle Internet de sortie uniquement et l’ajouter à la table de routage de votre sous-réseau privé.
**Pour créer une passerelle Internet de sortie uniquement**
1. Dans le volet de navigation, choisissez **Passerelles Internet de sortie uniquement**.
1. Choisissez **Créer une passerelle Internet de sortie uniquement**.
1. (Facultatif) Saisissez un nom.
1. Sélectionnez le VPC dans lequel créer la passerelle Internet de sortie uniquement.
1. Choisissez **Créer une passerelle Internet de sortie uniquement**.
1. Choisissez le lien sous **ID du VPC attaché**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/eigw-details.png)
1. Sélectionnez le lien sous l’**ID de VPC** pour ouvrir la page des détails.
1. Faites défiler vers le bas jusqu’à la section **Carte des ressources** et choisissez un sous-réseau privé. (Un sous-réseau privé est un sous-réseau qui ne comporte pas de route vers une passerelle Internet dans sa table de routage) Les détails du sous-réseau s’affichent dans un nouvel onglet.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/vpc-subnet-private.png)
1. Cliquez sur le lien sous **Table de routage**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/private-subnet-route-table.png)
1. Choisissez l’**ID de la table de routage** pour ouvrir la page de détails de la table de routage.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/route-table-id.png)
1. Sous **Routes**, choisissez la **Modifier des routes**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/edit-routes.png)
1. Choisissez **Ajouter une route**, puis saisissez `::/0` dans la zone **Destination**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/create-route-1.png)
1. Pour **Cible**, sélectionnez **Passerelle Internet de sortie uniquement**, puis choisissez la passerelle que vous avez créée précédemment.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/eigw-route.png)
1. Sélectionnez **Enregistrer les modifications**.
### Configurer la fonction Lambda
**Pour configurer un VPC lorsque vous créez une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Sous **Informations de base**, dans **Nom de fonction**, entrez un nom pour votre fonction.
1. Développez **Advanced settings (Paramètres avancés)**.
1. Sélectionnez **Activer le VPC**, puis choisissez un VPC.
1. (Facultatif) Pour autoriser le [ IPv6 trafic sortant, sélectionnez Autoriser le IPv6 trafic](configuration-vpc.md#configuration-vpc-ipv6) **pour les sous-réseaux à double pile**.
1. Pour **Sous-réseaux**, sélectionnez tous les sous-réseaux privés. Les sous-réseaux privés peuvent accéder à Internet via une passerelle NAT. La connexion d’une fonction à un sous-réseau public ne lui donne pas accès à Internet.
**Note**
Si vous avez sélectionné **Autoriser IPv6 le trafic pour les sous-réseaux à double pile**, tous les sous-réseaux sélectionnés doivent comporter un bloc IPv4 CIDR et un bloc CIDR. IPv6
1. Pour les **groupes de sécurité**, sélectionnez un groupe de sécurité qui autorise le trafic sortant.
1. Choisissez **Créer une fonction**.
Lambda crée automatiquement un rôle d'exécution avec la politique [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) AWS gérée. Les autorisations de cette politique ne sont nécessaires que pour créer des interfaces réseau élastiques pour la configuration VPC, et non pour invoquer votre fonction. Pour appliquer les autorisations de moindre privilège, vous pouvez supprimer la **AWSLambdaVPCAccessExecutionRole**politique de votre rôle d'exécution après avoir créé la fonction et la configuration VPC. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises](configuration-vpc.md#configuration-vpc-permissions).
**Pour configurer un VPC pour une fonction existante**
Pour ajouter une configuration VPC à une fonction existante, le rôle d’exécution de la fonction doit être [autorisé à créer et à gérer des interfaces réseau élastiques](configuration-vpc.md#configuration-vpc-permissions). La politique [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) AWS gérée inclut les autorisations requises. Pour appliquer les autorisations de moindre privilège, vous pouvez supprimer la **AWSLambdaVPCAccessExecutionRole**politique de votre rôle d'exécution après avoir créé la configuration VPC.
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez l’onglet **Configuration** puis choisissez **VPC**.
1. Sous **VPC**, choisissez **Modifier**.
1. Sélectionnez le VPC.
1. (Facultatif) Pour autoriser le [ IPv6 trafic sortant, sélectionnez Autoriser le IPv6 trafic](configuration-vpc.md#configuration-vpc-ipv6) **pour les sous-réseaux à double pile**.
1. Pour **Sous-réseaux**, sélectionnez tous les sous-réseaux privés. Les sous-réseaux privés peuvent accéder à Internet via une passerelle NAT. La connexion d’une fonction à un sous-réseau public ne lui donne pas accès à Internet.
**Note**
Si vous avez sélectionné **Autoriser IPv6 le trafic pour les sous-réseaux à double pile**, tous les sous-réseaux sélectionnés doivent comporter un bloc IPv4 CIDR et un bloc CIDR. IPv6
1. Pour les **groupes de sécurité**, sélectionnez un groupe de sécurité qui autorise le trafic sortant.
1. Choisissez **Enregistrer**.
### Tester la fonction
Utilisez l’exemple de code suivant pour vérifier que votre fonction connectée au VPC peut accéder à l’Internet public. En cas de succès, le code renvoie un code d’état `200`. En cas d’échec, la fonction expire.
------
#### [ Node.js ]
1. Dans le volet **Source du code** de la console Lambda, collez le code suivant dans le fichier **index.mjs**. La fonction envoie une requête HTTP GET à un point de terminaison public et renvoie le code de réponse HTTP pour tester si la fonction a accès à l’Internet public.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/code-source-nodejs.png)
**Example – Requête HTTP avec async/await**
```
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;
}
};
```
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)
1. Choisissez l’onglet **Test**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-tab.png)
1. Sélectionnez **Tester)**.
1. La fonction renvoie un code d’état `200`. Cela signifie que la fonction dispose d’un accès Internet sortant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-successful-200.png)
Si la fonction ne parvient pas à accéder à l’Internet public, un message d’erreur de ce type s’affiche :
```
{
"errorMessage": "2024-04-11T17:22:20.857Z abe12jlc-640a-8157-0249-9be825c2y110 Task timed out after 3.01 seconds"
}
```
------
#### [ Python ]
1. Dans le volet **Source du code** de la console Lambda, collez le code suivant dans le fichier **lambda\$1function.py**. La fonction envoie une requête HTTP GET à un point de terminaison public et renvoie le code de réponse HTTP pour tester si la fonction a accès à l’Internet public.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/code-source-python.png)
```
import urllib.request
def lambda_handler(event, context):
try:
response = urllib.request.urlopen('https://aws.amazon.com')
status_code = response.getcode()
print('Response Code:', status_code)
return status_code
except Exception as e:
print('Error:', e)
raise e
```
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)
1. Choisissez l’onglet **Test**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-tab.png)
1. Sélectionnez **Tester)**.
1. La fonction renvoie un code d’état `200`. Cela signifie que la fonction dispose d’un accès Internet sortant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/test-successful-200.png)
Si la fonction ne parvient pas à accéder à l’Internet public, un message d’erreur de ce type s’affiche :
```
{
"errorMessage": "2024-04-11T17:22:20.857Z abe12jlc-640a-8157-0249-9be825c2y110 Task timed out after 3.01 seconds"
}
```
------
# Connexion des points de terminaison d'un VPC de l'interface entrante pour Lambda
Si vous utilisez Amazon Virtual Private Cloud (Amazon VPC) pour héberger vos ressources AWS, vous pouvez établir une connexion entre votre VPC et Lambda. Vous pouvez utiliser cette connexion pour invoquer votre fonction Lambda sans traverser l'Internet public.
Pour établir une connexion privée entre votre VPC et Lambda, créez un [point de terminaison de VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html). Les points de terminaison d'interface étant alimentés par [AWS PrivateLink](https://aws.amazon.com/privatelink), vous pouvez accéder en privé aux API Lambda sans passerelle Internet, périphérique NAT, connexion VPN ou connexion AWS Direct Connect. Les instances dans votre VPC n'ont pas besoin d'adresses IP publiques pour communiquer avec des API Lambda. Le trafic entre votre VPC et Lambda ne quitte pas le réseau AWS.
Chaque point de terminaison d'interface est représenté par une ou plusieurs [interfaces réseau Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans vos sous-réseaux. Une interface réseau fournit une adresse IP privée qui sert de point d'entrée au trafic vers Lambda.
**Topics**
+ [
## Considérations relatives aux points de terminaison d'interface Lambda
](#vpc-endpoint-considerations)
+ [
## Création d'un point de terminaison d'interface pour Lambda
](#vpc-endpoint-create)
+ [
## Création d'une stratégie de point de terminaison d'interface pour Lambda
](#vpc-endpoint-policy)
## Considérations relatives aux points de terminaison d'interface Lambda
Avant de configurer un point de terminaison d'interface pour Lambda, consulter [Propriétés et limites des points de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations) dans le *Guide de l'utilisateur Amazon VPC*.
Vous pouvez appeler n'importe quelle opération d'API Lambda à partir de votre VPC. Par exemple, vous pouvez invoquer la fonction Lambda en appelant l'API `Invoke` à partir de votre VPC. Pour obtenir la liste complète des API Lambda, consultez [Actions](https://docs.aws.amazon.com/lambda/latest/dg/API_Operations.html) dans la Référence API Lambda.
`use1-az3` est une région à capacité limitée pour les fonctions Lambda VPC. Vous ne devez pas utiliser de sous-réseaux dans cette zone de disponibilité avec vos fonctions Lambda, car cela peut réduire la redondance zonale en cas de panne.
### Keep-alive pour les connexions persistantes
Lambda purgeant les connexions inactives au fil du temps, vous devez utiliser une directive keep-alive pour maintenir les connexions persistantes. 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, voir [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) dans le *Guide du développeur AWS SDK pour JavaScript*.
### Considérations sur la facturation
L'accès à une fonction Lambda via un point de terminaison d'interface n'occasionne aucun coût supplémentaire. Pour plus d'informations sur la tarification de Lambda, consultez [Tarification AWS Lambda](https://aws.amazon.com/lambda/pricing/).
La tarification standard pour AWS PrivateLink s'applique aux points de terminaison d'interface pour Lambda. Votre compte AWS est facturé pour chaque heure d'approvisionnement de point de terminaison d'interface dans chaque zone de disponibilité, et pour les données traitées via le point de terminaison d'interface. Pour plus d'informations sur la tarification des points de terminaison d'interface, consultez [Tarification AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/).
### Considérations sur l'appairage de VPC
Vous pouvez connecter d'autres VPC au VPC avec des points de terminaison d'interface à l'aide d'un [Appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html). L'appairage de VPC est une connexion réseau entre deux VPC. Vous pouvez aussi établir une connexion d'appairage de VPC entre vos deux VPC, ou avec un VPC situé dans un autre compte AWS. Les VPC peuvent également se trouver dans deux régions AWS différentes.
Le trafic entre des VPC appairés reste sur le réseau AWS et ne traverse pas l'Internet public. Une fois les VPC appairés, des ressources telles que des instances Amazon Elastic Compute Cloud (Amazon EC2), des instances Amazon Relational Database Service (Amazon RDS) ou des fonctions Lambda API basées sur un VPC dans les deux VPC peuvent accéder à l'API Lambda via des points de terminaison d'interface créés dans l'un des VPC.
## Création d'un point de terminaison d'interface pour Lambda
Vous pouvez créer un point de terminaison d'interface pour Lambda à l'aide de la console Amazon VPC ou de l'AWS Command Line Interface (AWS CLI). Pour de plus amples informations, veuillez consulter [Création d'un point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) dans le *Amazon VPC Guide de l'utilisateur*.
**Pour créer un point de terminaison d'interface pour Lambda (console)**
1. Ouvrez la [page Points de terminaison](https://console.aws.amazon.com/vpc/home?#Endpoints) de la console Amazon VPC.
1. Choisissez **Créer un point de terminaison**.
1. Pour **Catégorie de service**, assurez-vous que **Services AWS** est sélectionné.
1. Pour **Nom du service**, choisissez **com.amazonaws.*région*.lambda**. Vérifiez que le **Type** est **Interface**.
1. Choisissez un VPC et des sous-réseaux
1. Pour activer un DNS privé pour le point de terminaison d'interface, sélectionnez la case à cocher **Enable DNS Name (Activer le nom de DNS)**. Nous vous recommandons d’activer des noms d’hôtes DNS privés pour votre point de terminaison de VPC pour les Services AWS. Cela garantit que les requêtes qui utilisent les points de terminaison du service public, telles que les requêtes effectuées via un kit SDK AWS, sont résolues vers votre point de terminaison de VPC.
1. Pour **Groupes de sécurité**, choisissez un ou plusieurs groupes de sécurité.
1. Choisissez **Créer un point de terminaison**.
Pour utiliser l'option de DNS privée, vous devez définir les `enableDnsHostnames` et `enableDnsSupportattributes` de votre VPC. Pour plus d'informations, consultez [Affichage et mise à jour de la prise en charge de DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) dans le *Guide de l'utilisateur Amazon VPC*. Si vous activez le DNS privé pour le point de terminaison d'interface, vous pouvez adresser des demandes d'API à Lambda en utilisant son nom DNS par défaut pour la région, par exemple, `lambda.us-east-1.amazonaws.com`. Pour plus de points de terminaison de service, consultez [Points de terminaison de service et quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) dans le *Références générales AWS*.
Pour de plus amples informations, veuillez consulter [Accès à un service via un point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint) dans le *Amazon VPC Guide de l'utilisateur*.
Pour plus d'informations sur la création et la configuration d'un point de terminaison avec CloudFormation, consultez la ressource [AWS::EC2::VPCEndpoint](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html) dans le *Guide de l'utilisateur AWS CloudFormation*.
**Pour créer un point de terminaison d'interface pour Lambda (AWS CLI)**
Utilisez la commande [create-vpc-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-vpc-endpoint.html) et spécifiez l’ID du VPC, le type du point de terminaison de VPC (interface), le nom du service, les sous-réseaux qui utiliseront le point de terminaison et les groupes de sécurité à associer aux interfaces réseau du point de terminaison. Par exemple :
```
aws ec2 create-vpc-endpoint
--vpc-id vpc-ec43eb89
--vpc-endpoint-type Interface
--service-name com.amazonaws.us-east-1.lambda
--subnet-id subnet-abababab
--security-group-id sg-1a2b3c4d
```
## Création d'une stratégie de point de terminaison d'interface pour Lambda
Pour contrôler qui peut utiliser votre point de terminaison d'interface, ainsi que les fonctions Lambda auxquelles l'utilisateur peut accéder, vous pouvez attacher une stratégie de point de terminaison à votre point de terminaison. La stratégie spécifie les informations suivantes :
+ Le principal qui peut exécuter des actions.
+ Les actions que le principal peut effectuer.
+ Ressources sur lesquelles le principal peut effectuer des actions.
Pour de plus amples informations, veuillez consulter [Contrôle de l'accès aux services avec points de terminaison d'un VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) dans le *Amazon VPC Guide de l'utilisateur*.
**Exemple : stratégie de point de terminaison d'interface pour des actions Lambda**
Voici un exemple de stratégie de point de terminaison pour Lambda. Lorsqu'elle est attachée à un point de terminaison, cette stratégie permet à l'utilisateur `MyUser` d'invoquer la fonction `my-function`.
**Note**
Vous devez inclure les ARN de la fonction qualifiée et de celle non qualifiée dans la ressource.
```
{
"Statement":[
{
"Principal":
{
"AWS": "arn:aws:iam::111122223333:user/MyUser"
},
"Effect":"Allow",
"Action":[
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:us-east-2:123456789012:function:my-function",
"arn:aws:lambda:us-east-2:123456789012:function:my-function:*"
]
}
]
}
```
# Configuration de l'accès au système de fichiers pour les fonctions Lambda
Vous pouvez configurer une fonction pour monter un système de fichiers Amazon Elastic File System (Amazon EFS) dans un répertoire local. Avec Amazon EFS, votre code de fonction peut accéder aux ressources partagées et les modifier en toute sécurité et avec une haute simultanéité.
## Régions prises en charge
Amazon EFS pour Lambda est disponible dans toutes les [régions commerciales](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region), à l’exception des régions Asie-Pacifique (Nouvelle-Zélande), Asie-Pacifique (Taipei), Asie-Pacifique (Malaisie), Mexique (Centre), Asie-Pacifique (Thaïlande) et Canada Ouest (Calgary).
**Topics**
+ [
## Régions prises en charge
](#configuration-filesystem-supported-regions)
+ [
## Rôle d'exécution et autorisations utilisateur
](#configuration-filesystem-permissions)
+ [
## Configuration d'un système de fichiers et d'un point d'accès
](#configuration-filesystem-setup)
+ [
## Connexion à un système de fichiers (console)
](#configuration-filesystem-config)
## Rôle d'exécution et autorisations utilisateur
Si le système de fichiers ne possède pas de politique Gestion des identités et des accès AWS (IAM) configurée par l'utilisateur, EFS utilise une politique par défaut qui accorde un accès complet à tout client pouvant se connecter au système de fichiers à l'aide d'une cible de montage du système de fichiers. Si le système de fichiers dispose d'une stratégie IAM configurée par l'utilisateur, le rôle d'exécution de votre fonction doit avoir le bon.`elasticfilesystem`Autorisations.
**Autorisations du rôle d’exécution**
+ **elasticfilesystem:ClientMount**
+ **elasticfilesystem:ClientWrite (non requis pour les connexions en lecture seule)**
Ces autorisations sont incluses dans la stratégie gérée **AmazonElasticFileSystemClientReadWriteAccess** . En outre, votre rôle d'exécution doit posséder le[autorisations requises pour se connecter au VPC du système de fichiers](configuration-vpc.md#configuration-vpc-permissions).
Lorsque vous configurez un système de fichiers, Lambda utilise vos autorisations pour vérifier les cibles de montage. Pour configurer une fonction pour vous connecter à un système de fichiers, votre utilisateur a besoin des autorisations suivantes :
**Autorisations des utilisateurs**
+ **elasticfilesystem:DescribeMountTargets**
## Configuration d'un système de fichiers et d'un point d'accès
Créez un système de fichiers Amazon EFS avec une cible de montage dans chaque zone de disponibilité à laquelle votre fonction se connecte. Pour les performances et une résilience, utilisez au moins deux zones de disponibilité. Par exemple, dans une configuration simple, vous pouvez avoir un VPC avec deux sous-réseaux privés dans des zones de disponibilité distinctes. La fonction se connecte aux deux sous-réseaux et une cible de montage est disponible dans chacun. Assurez-vous que le trafic NFS (port 2049) est autorisé par les groupes de sécurité utilisés par la fonction et les cibles de montage.
**Note**
Lorsque vous créez un système de fichiers, vous choisissez un mode de performances qui ne peut pas être modifié ultérieurement. Le mode **Usage général** a une latence plus faible, et le mode **I/O max** prend en charge un débit maximal et des I/O par seconde plus élevées. Pour orienter votre choix, consultez [Performances d'Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html) dans le *Guide de l'utilisateur Amazon Elastic File System*.
Un point d'accès relie chaque instance de la fonction à la cible de montage droite pour la zone de disponibilité à laquelle elle se connecte. Pour des performances optimales, créez un point d'accès avec un chemin non racine et limitez le nombre de fichiers que vous créez dans chaque répertoire. L'exemple suivant crée un répertoire nommé `my-function` sur le système de fichiers et définit l'ID propriétaire sur 1001 avec les autorisations d'annuaire standard (755).
**Example configuration du point d'accès**
+ **Nom** – `files`
+ **ID de l'utilisateur** – `1001`
+ **ID du groupe** – `1001`
+ **Chemin** – `/my-function`
+ **Permissions (Autorisations** – `755`
+ **ID d'utilisateur du propriétaire** – `1001`
+ **ID d'utilisateur du groupe** – `1001`
Lorsqu'une fonction utilise le point d'accès, elle reçoit l'ID utilisateur 1001 et dispose d'un accès complet au répertoire.
Pour plus d'informations, consultez les rubriques suivantes dans le *Guide de l'utilisateur Amazon Elastic File System User*.
+ [Création de ressources pour Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/creating-using.html)
+ [Collaboration avec des utilisateurs, des groupes et des autorisations](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html)
## Connexion à un système de fichiers (console)
Une fonction se connecte à un système de fichiers sur le réseau local dans un VPC. Les sous-réseaux auquel votre fonction se connecte peuvent être les mêmes sous-réseaux qui contiennent des points de montage pour votre système de fichiers, ou des sous-réseaux de la même zone de disponibilité qui peuvent acheminer le trafic NFS (port 2049) vers le système de fichiers.
**Note**
Si votre fonction n'est pas déjà connectée à un VPC, veuillez consulter [Octroi aux fonctions Lambda d’un accès aux ressources d’un Amazon VPC](configuration-vpc.md).
**Pour configurer l'accès au système de fichiers**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez **Configuration**, puis **File systems (Systèmes de fichiers)**.
1. Sous **Système de fichiers**, choisissez **Ajouter un système de fichiers**.
1. Configurez les propriétés suivantes :
+ **Système de fichiers EFS** – Point d'accès d'un système de fichiers dans le même VPC.
+ **Chemin de montage local** – Emplacement où le système de fichiers est monté sur la fonction Lambda, commençant par `/mnt/`.
**Tarification**
Amazon EFS facture le stockage et le débit, avec des tarifs qui varient selon la classe de stockage. Pour plus d'informations, consultez [Tarification Amazon EFS](https://aws.amazon.com/efs/pricing).
Lambda facture le transfert de données entre VPC. Cela ne s'applique que si le VPC de votre fonction est appairé à un autre VPC avec un système de fichiers. Les tarifs sont les mêmes que pour le transfert de données Amazon EC2 entre VPC dans une même région. Pour plus d’informations, consultez [Tarification ambda](https://aws.amazon.com/lambda/pricing).
# Création d’un alias de fonction Lambda
Vous pouvez créer des alias pour votre fonction Lambda. Un alias Lambda est un pointeur vers une version de la fonction que vous pouvez mettre à jour. Les utilisateurs de la fonction peuvent accéder à la version de la fonction en utilisant l'alias Amazon Resource Name (ARN). Lorsque vous déployez une nouvelle version, vous pouvez mettre à jour l'alias pour utiliser la nouvelle version, ou diviser le trafic entre deux versions.
------
#### [ Console ]
**Pour créer un alias à l’aide de la console**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez **Alias**, puis **Create alias (Créer un alias)**.
1. Sur la page **Create alias (Créer un alias)**, procédez de la manière suivante :
1. Renseignez le champ **Name (Nom)** pour l'alias.
1. (Facultatif) Renseignez le champ **Description** de l'alias.
1. Pour **Version**, choisissez une version de fonction vers laquelle vous souhaitez que l'alias pointe.
1. (Facultatif) Pour configurer le routage sur l'alias, développez **Weighted alias (Alias pondéré)**. Pour de plus amples informations, veuillez consulter [Mise en œuvre de déploiements canary Lambda à l’aide d’un alias pondéré](configuring-alias-routing.md).
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
Pour créer un alias à l’aide de l’AWS Command Line Interface (AWS CLI), utilisez la commande [create-alias](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-alias.html).
```
aws lambda create-alias \
--function-name my-function \
--name alias-name \
--function-version version-number \
--description " "
```
Pour modifier un alias afin qu’il pointe vers une nouvelle version de la fonction, utilisez la commande [update-alias](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-alias.html).
```
aws lambda update-alias \
--function-name my-function \
--name alias-name \
--function-version version-number
```
Pour créer un alias, utilisez la commande [delete-alias](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-alias.html).
```
aws lambda delete-alias \
--function-name my-function \
--name alias-name
```
Les commandes AWS CLI dans les étapes précédentes correspondent aux opérations d'API Lambda suivantes :
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)
------
# Utilisation d’alias Lambda dans les sources d’événements et les politiques d’autorisation
Chaque alias a un ARN unique. Un alias peut uniquement pointer vers une version de fonction, et non vers un autre alias. Vous pouvez mettre à jour un alias de sorte qu’il pointe vers une nouvelle version de la fonction.
Des sources d'événements telles qu'Amazon Simple Storage Service (Amazon S3) appellent votre fonction Lambda. Ces sources d'événements gèrent un mappage qui identifie la fonction à appeler lorsque des événements se produisent. Si vous spécifiez un alias de fonction Lambda dans la configuration du mappage, vous n'avez pas besoin de mettre à jour le mappage lorsque la version de la fonction change. Pour de plus amples informations, veuillez consulter [Procédure de traitement par Lambda des enregistrements provenant de sources d’événements basées sur des flux et des files d’attente](invocation-eventsourcemapping.md).
Dans une stratégie de ressources, vous pouvez accorder des autorisations en lien avec des sources d'événements à utiliser votre fonction Lambda. Si vous spécifiez un ARN d'alias dans la stratégie, vous n'avez pas besoin de mettre à jour la stratégie lorsque la version de la fonction change.
## Stratégies basées sur une ressource
Vous pouvez utiliser une [stratégie basée sur les ressources](access-control-resource-based.md) pour accorder l'accès à votre fonction à un service, à une ressource ou à un compte. La portée de cette autorisation est dépendante du fait que vous appliquiez l'autorisation à un alias, à une version ou à la fonction entière. Par exemple, si vous utilisez un nom d'alias (tel que `helloworld:PROD`), l'autorisation vous permet d'appeler la fonction `helloworld` à l'aide de l'ARN d'alias (`helloworld:PROD`).
Si vous essayez d'appeler la fonction sans alias ou version spécifique, vous obtenez une erreur d'autorisation. Cette erreur d'autorisation continue de se produire même si vous tentez d'appeler directement la version de fonction associée à l'alias.
Par exemple, la commande AWS CLI suivante accorde des autorisations Amazon S3 pour appeler l'alias PROD de la fonction `helloworld` quand Amazon S3 agit pour le compte de `amzn-s3-demo-bucket`.
```
aws lambda add-permission \
--function-name helloworld \
--qualifier PROD \
--statement-id 1 \
--principal s3.amazonaws.com \
--action lambda:InvokeFunction \
--source-arn arn:aws:s3:::amzn-s3-demo-bucket \
--source-account 123456789012
```
Pour de plus amples informations sur l'utilisation des noms de ressources dans les stratégies, veuillez consulter [Optimisation des sections relatives aux stratégies de Ressources et Conditions](lambda-api-permissions-ref.md).
# Mise en œuvre de déploiements canary Lambda à l’aide d’un alias pondéré
Vous pouvez utiliser un alias pondéré pour répartir le trafic entre deux [versions](configuration-versions.md) différentes de la même fonction. Cette approche vous permet de tester de nouvelles versions de vos fonctions avec un faible pourcentage de trafic et de revenir rapidement en arrière si nécessaire. C’est ce que l’on appelle un [déploiement canary](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/canary-deployments.html). Les déploiements Canary diffèrent blue/green des déploiements en exposant la nouvelle version à une partie seulement des demandes plutôt que de changer tout le trafic en une seule fois.
Vous pouvez faire pointer un alias vers au maximum deux versions de fonction Lambda. Les versions doivent répondre aux critères suivants :
+ Les deux versions doivent avoir le même [rôle d'exécution](lambda-intro-execution-role.md).
+ Les deux versions doivent avoir la même configuration de [file d'attente de lettres mortes](invocation-async-retain-records.md#invocation-dlq) ou aucune configuration de file d'attente de lettres mortes.
+ Les deux versions doivent être publiées. L'alias ne peut pas pointer vers `$LATEST`.
**Note**
Lambda utilise un modèle probabiliste simple pour distribuer le trafic entre les deux versions de la fonction. Quand le niveau de trafic est faible, il se peut que vous observiez une variance élevée entre les pourcentages de trafic configuré et réel sur chaque version. Si votre fonction utilise une simultanéité approvisionnée, vous pouvez éviter des [invocations de débordement](monitoring-metrics-types.md#invocation-metrics) en configurant un plus grand nombre d’instances de simultanéité approvisionnées pendant que le routage d’alias est actif.
## Création d’un alias pondéré
------
#### [ Console ]
**Pour configurer le routage sur un alias à l’aide de la console**
**Note**
Vérifiez que la fonction a au moins deux versions publiées. Pour créer des versions supplémentaires, suivez les instructions de la section [Création de versions de fonction](configuration-versions.md#configuration-versions-config).
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez **Alias**, puis **Create alias (Créer un alias)**.
1. Sur la page **Create alias (Créer un alias)**, procédez de la manière suivante :
1. Renseignez le champ **Name (Nom)** pour l'alias.
1. (Facultatif) Renseignez le champ **Description** de l'alias.
1. Pour **Version**, choisissez la première version de fonction vers laquelle vous souhaitez que l'alias pointe.
1. Développez **Weighted alias (Alias pondéré)**.
1. Pour **Additional version (Version supplémentaire)**, choisissez la deuxième version de fonction vers laquelle vous souhaitez que l'alias pointe.
1. Pour **Weight (%) (Pondération (%))**, entrez une valeur de pondération pour la fonction. La *pondération* est le pourcentage de trafic qui est affecté à cette version lorsque l'alias est appelé. La première version reçoit le reste du trafic. Par exemple, si vous spécifiez 10 % pour **Additional version (Version supplémentaire)**, 90 % du trafic est automatiquement affecté à la première version.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
Utilisez les AWS CLI commandes [create-alias](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-alias.html) et [update-alias](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-alias.html) pour configurer les pondérations du trafic entre deux versions de fonction. Lorsque vous créez ou mettez à jour l'alias, vous spécifiez la pondération du trafic dans le paramètre `routing-config`.
L'exemple suivant crée un alias de fonction Lambda nommé **routing-alias** qui pointe vers la version 1 de la fonction. La version 2 de la fonction reçoit 3 % du trafic. Les 97 % restants du trafic sont acheminés vers la version 1.
```
aws lambda create-alias \
--name routing-alias \
--function-name my-function \
--function-version 1 \
--routing-config AdditionalVersionWeights={"2"=0.03}
```
Utilisez la commande `update-alias` pour augmenter le pourcentage de trafic entrant vers la version 2. Dans l'exemple suivant, vous augmentez le trafic à 5 %.
```
aws lambda update-alias \
--name routing-alias \
--function-name my-function \
--routing-config AdditionalVersionWeights={"2"=0.05}
```
Pour acheminer l'ensemble du trafic vers la version 2, utilisez la commande `update-alias` pour modifier la propriété `function-version` afin que l'alias pointe vers la version 2. La commande réinitialise également la configuration de routage.
```
aws lambda update-alias \
--name routing-alias \
--function-name my-function \
--function-version 2 \
--routing-config AdditionalVersionWeights={}
```
Les AWS CLI commandes des étapes précédentes correspondent aux opérations d'API Lambda suivantes :
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)
------
## Détermination de la version invoquée
Lorsque vous configurez des pondérations de trafic entre deux versions de fonction, vous pouvez déterminer la version de fonction Lambda appelée de deux manières :
+ **CloudWatch Journaux** — Lambda émet automatiquement une entrée de `START` journal contenant l'ID de version invoqué pour chaque appel de fonction. Exemple :
`START RequestId: 1dh194d3759ed-4v8b-a7b4-1e541f60235f Version: 2`
Pour les appels d'alias, Lambda utilise la dimension `ExecutedVersion` pour filtrer les métriques en fonction de la version appelée. Pour de plus amples informations, veuillez consulter [Affichage des métriques pour une fonction Lambda](monitoring-metrics-view.md).
+ **Charge utile de réponse (appels synchrones)** – Les réponses aux appels de fonction synchrones incluent un en-tête `x-amz-executed-version` indiquant la version de fonction appelée.
## Création d’un déploiement continu avec des alias pondérés
Utilisez AWS CodeDeploy and AWS Serverless Application Model (AWS SAM) pour créer un déploiement continu qui détecte automatiquement les modifications apportées à votre code de fonction, déploie une nouvelle version de votre fonction et augmente progressivement le volume de trafic vers la nouvelle version. La quantité de trafic et le taux d'augmentation sont des paramètres que vous pouvez configurer.
Dans le cadre d'un déploiement continu, AWS SAM exécute les tâches suivantes :
+ Il configure votre fonction Lambda et crée un alias. La configuration de routage d’alias pondéré est la capacité sous-jacente qui implémente le déploiement propagé.
+ Crée une CodeDeploy application et un groupe de déploiement. Le groupe de déploiement gère le déploiement propagé et la restauration, si nécessaire.
+ Il détecte le moment où vous créez une nouvelle version de votre fonction Lambda.
+ Déclencheurs CodeDeploy permettant de démarrer le déploiement de la nouvelle version.
### Exemple de AWS SAM modèle
L'exemple suivant présente un [modèle AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template-basics.html) pour un déploiement propagé simple.
```
AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: A sample SAM template for deploying Lambda functions
Resources:
# Details about the myDateTimeFunction Lambda function
myDateTimeFunction:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Handler: myDateTimeFunction.handler
Runtime: nodejs24.x
# Creates an alias named "live" for the function, and automatically publishes when you update the function.
AutoPublishAlias: live
DeploymentPreference:
# Specifies the deployment configuration
Type: Linear10PercentEvery2Minutes
```
Ce modèle définit une fonction Lambda nommée `myDateTimeFunction` avec les propriétés suivantes.
**AutoPublishAlias **
La propriété `AutoPublishAlias` crée un alias nommé `live`. De plus, l'infrastructure AWS SAM détecte automatiquement le moment où vous enregistrez du code nouveau pour la fonction. L'infrastructure publie ensuite une nouvelle version de fonction et met à jour l'alias `live` de sorte qu'il pointe vers la nouvelle version.
**DeploymentPreference**
La `DeploymentPreference` propriété détermine la vitesse à laquelle l' CodeDeploy application déplace le trafic de la version d'origine de la fonction Lambda vers la nouvelle version. La valeur `Linear10PercentEvery2Minutes` déplace 10 % du trafic toutes les deux minutes vers la nouvelle version.
Pour obtenir la liste des configurations de déploiement prédéfinies, consultez [Configurations de déploiement](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html).
Pour plus d'informations sur la façon de créer des déploiements progressifs avec CodeDeploy et AWS SAM, consultez les rubriques suivantes :
+ [Tutoriel : Déployer une fonction Lambda mise à jour avec et CodeDeploy AWS Serverless Application Model](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-lambda-sam.html)
+ [Déploiement progressif d'applications sans serveur avec AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
# Gestion des versions d’une fonction Lambda
Vous pouvez utiliser des versions pour gérer le déploiement de vos fonctions. Par exemple, vous pouvez publier une nouvelle version d’une fonction à des fins de test bêta sans affecter les utilisateurs de la version de production stable. Lambda crée une nouvelle version de votre fonction chaque fois que vous la publiez. La nouvelle version est une copie de la version non publiée de la fonction. La version non publiée est nommée `$LATEST`.
Il est important de noter que chaque fois que vous déployez le code de votre fonction, vous remplacez le code actuel dans `$LATEST`. Pour enregistrer l’itération `$LATEST` actuelle, créez une nouvelle version de la fonction. Si `$LATEST` est identique à une version publiée précédemment, aucune nouvelle version ne pourra être créée tant que les modifications n’auront pas été déployées dans `$LATEST`. Ces modifications peuvent inclure la mise à jour du code ou la modification des paramètres de configuration de la fonction.
Une fois que vous avez publié une version de fonction, son code, son environnement d’exécution, son architecture, sa mémoire, ses couches et la plupart des autres paramètres de configuration sont immuables. Cela signifie que vous ne pouvez pas modifier ces paramètres sans publier une nouvelle version à partir de `$LATEST`. Vous pouvez configurer les éléments suivants pour une version de fonction publiée :
+ [Déclencheurs](lambda-services.md#lambda-invocation-trigger)
+ [Destinations](invocation-async-retain-records.md#create-destination)
+ [Simultanéité allouée](provisioned-concurrency.md)
+ [invocation asynchrone](invocation-async.md)
+ [Connexions aux bases de données et proxys](services-rds.md#rds-configuration)
**Note**
Lorsque vous utilisez les [contrôles de gestion de l’environnement d’exécution](runtimes-update.md#runtime-management-controls) avec le mode **Auto**, la version de l’environnement d’exécution utilisée par la version de la fonction est mise à jour automatiquement. Lorsque vous utilisez le mode **Function update** (Mise à jour de fonction) ou **Manual** (Manuel), la version de l’environnement d’exécution n’est pas mise à jour. Pour de plus amples informations, veuillez consulter [Comprendre comment Lambda gère les mises à jour de version de l’environnement d’exécution](runtimes-update.md).
**Topics**
+ [
## Création de versions de fonction
](#configuration-versions-config)
+ [
## Utilisation des versions
](#versioning-versions-using)
+ [
## Octroi d’autorisations
](#versioning-permissions)
## Création de versions de fonction
Vous pouvez modifier le code et les paramètres de la fonction uniquement sur la version non publiée d’une fonction. Lorsque vous publiez une version, Lambda verrouille le code et la plupart des paramètres afin de préserver une expérience cohérente pour les utilisateurs de cette version.
Vous pouvez créer une version de fonction à l’aide de la console Lambda.
**Pour créer une version de fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction, puis choisissez l’onglet **Versions**.
1. Sur la page de configuration des versions, sélectionnez **Publish new version (Publier une nouvelle version)**.
1. (Facultatif) Entrez une description de la version.
1. Choisissez **Publier**.
Vous pouvez également publier une version d'une fonction à l'aide de l'opération [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)API.
La AWS CLI commande suivante publie une nouvelle version d'une fonction. La réponse renvoie les informations de configuration relatives à la nouvelle version, y compris le numéro de version et l’ARN de la fonction avec le suffixe de version.
```
aws lambda publish-version --function-name my-function
```
Vous devriez voir la sortie suivante :
```
{
"FunctionName": "my-function",
"FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function:1",
"Version": "1",
"Role": "arn:aws:iam::123456789012:role/lambda-role",
"Handler": "function.handler",
"Runtime": "nodejs24.x",
...
}
```
**Note**
Lambda attribue des numéros de séquence à croissance monotone pour la gestion des versions. Lambda ne réutilise jamais les numéros de version, même après avoir supprimé et recréé une fonction.
## Utilisation des versions
Vous pouvez référencer votre fonction Lambda à l’aide d’un ARN qualifié ou d’un ARN non qualifié.
+ **ARN qualifié** – ARN de la fonction avec suffixe de version. L’exemple suivant fait référence à la version 42 de la fonction `helloworld`.
```
arn:aws:lambda:aws-region:acct-id:function:helloworld:42
```
+ **ARN non qualifié** – ARN de la fonction sans suffixe de version.
```
arn:aws:lambda:aws-region:acct-id:function:helloworld
```
Vous pouvez utiliser un ARN qualifié ou non qualifié dans toutes les opérations d’API pertinentes. Cependant, vous ne pouvez pas utiliser un ARN non qualifié pour créer un alias.
Si vous décidez de ne pas publier de versions de fonction, vous pouvez invoquer la fonction à l’aide de l’ARN qualifié ou non qualifié dans votre [mappage source d’événement](invocation-eventsourcemapping.md). Lorsque vous invoquez une fonction à l’aide d’un ARN non qualifié, Lambda invoque implicitement `$LATEST`.
L’ARN qualifié pour chaque version de fonction Lambda est unique. Après avoir publié une version, vous ne pouvez pas modifier l’ARN ou le code de fonction.
Lambda ne publie une nouvelle version de fonction que si le code n’a jamais été publié ou si le code a changé par rapport à la version publiée la plus récente. S’il n’y a pas de changement, la version de fonction publiée la plus récente reste active.
Lorsque vous publiez une version, Lambda crée un instantané immuable du code et de la configuration de votre fonction. Les modifications de configuration ne déclenchent pas toutes la publication d’une nouvelle version. Les modifications de configuration suivantes rendent une fonction éligible à la publication d’une nouvelle version :
+ Code de fonction
+ Variables d’environnement
+ Environnement d’exécution
+ Handler (Gestionnaire)
+ Layers
+ Taille de la mémoire
+ Timeout
+ Configuration VPC
+ Configuration de file d’attente de lettres mortes (DLQ)
+ Rôle IAM
+ Description
+ Architecture (x86\$164 ou arm64)
+ Taille du stockage éphémère
+ Type de package
+ Configuration de la journalisation
+ Configuration du système de fichiers
+ SnapStart
+ Configuration du suivi
Les paramètres opérationnels, comme la [simultanéité réservée](configuration-concurrency.md), ne déclenchent pas la publication d’une nouvelle version lorsqu’ils sont modifiés.
## Octroi d’autorisations
Vous pouvez utiliser une [stratégie basée sur les ressources](access-control-resource-based.md) ou une [stratégie basée sur l’identité](access-control-identity-based.md) pour accorder l’accès à votre fonction. La portée de l’autorisation est dépendante du fait que vous appliquiez la stratégie à une fonction ou à une version d’une fonction. Pour de plus amples informations sur les noms de ressource de fonction dans les stratégies, veuillez consulter [Optimisation des sections relatives aux stratégies de Ressources et Conditions](lambda-api-permissions-ref.md).
Vous pouvez simplifier la gestion des sources d'événements et des politiques Gestion des identités et des accès AWS (IAM) en utilisant des alias de fonction. Pour de plus amples informations, veuillez consulter [Création d’un alias de fonction Lambda](configuration-aliases.md).
# Utilisation de balises sur les fonctions Lambda
Vous pouvez étiqueter les fonctions pour organiser et gérer vos ressources. Les balises sont des paires clé-valeur de forme libre associées à vos ressources prises en charge par l’ensemble des ressources Services AWS. Pour plus d'informations sur les cas d'utilisation des balises, consultez la section [Stratégies de balisage courantes dans le guide des AWS](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) *ressources de balisage et de l'éditeur de balises*.
Les balises s’appliquent au niveau de la fonction, pas aux versions ni aux alias. Les balises ne font pas partie de la configuration spécifique à la version qui AWS Lambda crée un instantané du moment où vous publiez une version. Vous pouvez utiliser l’API Lambda pour afficher et mettre à jour les balises. Vous pouvez également afficher et mettre à jour les balises tout en gérant une fonction spécifique dans la console Lambda.
**Topics**
+ [
## Autorisations requises pour l’utilisation des balises
](#fxn-tags-required-permissions)
+ [
## Utilisation des balises avec la console Lambda
](#using-tags-with-the-console)
+ [
## Utilisation de balises avec AWS CLI
](#configuration-tags-cli)
## Autorisations requises pour l’utilisation des balises
Pour autoriser une identité Gestion des identités et des accès AWS (IAM) – utilisateur, groupe ou rôle – à afficher ou marquer les ressources, accordez-lui les autorisations correspondantes :
+ **lambda : ListTags** —Lorsqu' une ressource possède des balises, accordez cette autorisation à tous ceux qui ont besoin de `ListTags` l'utiliser. Pour les fonctions balisées, cette autorisation est également nécessaire pour `GetFunction`.
+ **lambda : TagResource** —Accordez cette autorisation à toute personne ayant besoin d'appeler `TagResource` ou d'exécuter un tag lors de la création.
Vous pouvez éventuellement envisager d'accorder également l'UntagResourceautorisation **lambda :** pour autoriser les `UntagResource` appels à la ressource.
Pour de plus amples informations, veuillez consulter [Politiques IAM basées sur l’identité pour Lambda](access-control-identity-based.md).
## Utilisation des balises avec la console Lambda
Vous pouvez utiliser la console Lambda pour créer des fonctions qui comportent des balises, pour ajouter des balises aux fonctions existantes et pour filtrer des fonctions selon les balises ajoutées.
**Ajout de balises lors de la création d’une fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Choisissez **Author from scratch** (Créer à partir de zéro) ou **Container image** (Image de conteneur).
1. Sous **Informations de base**, configurez votre fonction. Pour de plus amples informations sur la configuration des fonctions, consultez [Configuration des AWS Lambda fonctions](lambda-functions.md).
1. Développez **Advanced settings** (Paramètres avancés) et sélectionnez **Enable tags** (Activer les balises).
1. Pour cela, choisissez **Ajouter une balise**, puis saisissez une **clé** et éventuellement une **valeur**. Répétez cette étape pour ajouter d’autres balises.
1. Choisissez **Créer une fonction**.
**Pour ajouter des balises à une fonction existante**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Sélectionnez **Configuration**, puis **Tags (Balises)**.
1. Sous **Balises**, choisissez **Gérer les balises**.
1. Pour cela, choisissez **Ajouter une balise**, puis saisissez une **clé** et éventuellement une **valeur**. Répétez cette étape pour ajouter d’autres balises.
1. Choisissez **Enregistrer**.
**Pour filtrer des fonctions avec des balises**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Cliquez dans la zone de recherche pour afficher la liste des propriétés de fonction et des clés de balise.
1. Choisissez une clé de balise pour afficher la liste des valeurs utilisées dans la AWS région actuelle.
1. Sélectionnez **Utiliser : « tag-name »** pour afficher toutes les fonctions étiquetées avec cette touche, ou choisissez un **Opérateur** pour affiner le filtrage en fonction de la valeur.
1. Sélectionnez votre valeur de balise pour appliquer un filtre combinant la clé et la valeur de la balise.
La barre de recherche prend également en charge la recherche de clés de balise. Saisissez `tag` pour afficher uniquement une liste de clés de balise ou entrez le nom d’une clé pour la rechercher dans la liste.
## Utilisation de balises avec AWS CLI
Vous pouvez ajouter et supprimer des balises sur les ressources Lambda existantes, fonctions incluses, avec l’API Lambda. Il est également possible d’ajouter des balises lors de la création d’une fonction, vous permettant ainsi de conserver une ressource balisée tout au long de son cycle de vie.
### Mise à jour des balises avec la balise Lambda APIs
Vous pouvez ajouter et supprimer des balises pour les ressources Lambda prises en charge par le biais des opérations [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)et de l'[UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API.
Vous pouvez appeler ces opérations par l’intermédiaire de l’ AWS CLI. Pour ajouter des balises à une ressource existante, utilisez la commande `tag-resource`. Cet exemple ajoute deux balises, l'une avec la clé *Department* et l'autre avec la clé*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Pour supprimer des balises, utilisez la commande `untag-resource`. Cet exemple supprime la balise contenant la clé*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Ajout de balises lors de la création d’une fonction
Pour créer une nouvelle fonction Lambda avec des balises, utilisez l'opération [CreateFunction](https://docs.aws.amazon.com//lambda/latest/api/API_CreateFunction.html)API. Spécifiez le paramètre `Tags`. Vous pouvez appeler cette opération à l’aide de la commande `create-function` de la CLI associée à l’option --tags. Avant d’utiliser le paramètre tags avec `CreateFunction`, vérifiez que votre rôle dispose de l’autorisation de baliser les ressources en plus des autorisations habituelles nécessaires à cette opération. Pour plus d’informations sur les autorisations requises pour l’étiquetage, consultez [Autorisations requises pour l’utilisation des balises](#fxn-tags-required-permissions). Cet exemple ajoute deux balises, l'une avec la clé *Department* et l'autre avec la clé*CostCenter*.
```
aws lambda create-function --function-name my-function
--handler index.js --runtime nodejs24.x \
--role arn:aws:iam::123456789012:role/lambda-role \
--tags Department=Marketing,CostCenter=1234ABCD
```
### Affichage des balises d’une fonction
Pour afficher les balises associées à une ressource Lambda spécifique, utilisez l’opération d’API `ListTags`. Pour de plus amples informations, veuillez consulter [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Vous pouvez appeler cette opération à l'aide de la `list-tags` AWS CLI commande en fournissant un ARN (Amazon Resource Name).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
Vous pouvez afficher les balises appliquées à une ressource spécifique à l'aide de l'opération [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)d'API. Aucune fonctionnalité comparable n’est disponible pour les autres types de ressources.
Vous pouvez appeler cette opération à l’aide de la commande `get-function` de la CLI :
```
aws lambda get-function --function-name my-function
```
### Filtrage de ressources par balise
Vous pouvez utiliser le fonctionnement de l' AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API pour filtrer vos ressources par balises. L’opération `GetResources` reçoit jusqu’à 10 filtres, chaque filtre contenant une clé de balise et jusqu’à 10 valeurs de balise. Vous fournissez `GetResources`avec un `ResourceType` pour filtrer par certains types de ressources.
Vous pouvez appeler cette opération à l'aide de la `get-resources` AWS CLI commande. Pour des exemples d’utilisation de `get-resources`, consultez [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) dans la *Référence des commandes de l’AWS CLI*.
# Streaming de réponses pour les fonctions Lambda
Les fonctions Lambda peuvent renvoyer nativement les charges utiles de réponse aux clients via la [fonction Lambda](urls-configuration.md) ou à l'aide de l'[InvokeWithResponseStream](https://docs.aws.amazon.com/lambda/latest/api/API_InvokeWithResponseStream.html)API (via le AWS SDK URLs ou des appels d'API directs). Votre fonction Lambda peut également diffuser des charges utiles de réponse via l'[intégration du proxy Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/response-transfer-mode-lambda.html), qui utilise l'[InvokeWithResponseStream](https://docs.aws.amazon.com/lambda/latest/api/API_InvokeWithResponseStream.html)API pour appeler votre fonction. Le streaming de réponses peut profiter aux applications sensibles à la latence en améliorant les performances de temps au premier octet (TTFB). En effet, vous pouvez renvoyer des réponses partielles au client dès qu'elles sont disponibles. En outre, les fonctions de diffusion des réponses peuvent renvoyer des données utiles allant jusqu’à 200 Mo, contre un maximum de 6 Mo pour les réponses mises en mémoire tampon. La diffusion d'une réponse signifie également que votre fonction n'a pas besoin de stocker l'intégralité de la réponse en mémoire. Pour les réponses très volumineuses, cela peut réduire la quantité de mémoire que vous devez configurer pour votre fonction.
**Note**
Le streaming des réponses Lambda n'est pas encore entièrement disponible. Régions AWS Consultez la section [AWS Capacités par région](https://builder.aws.com/build/capabilities) du Builder Center pour connaître la disponibilité des fonctionnalités par région.
La vitesse à laquelle Lambda diffuse vos réponses dépend de la taille de la réponse. Le débit de diffusion pour les 6 premiers Mo de réponse de votre fonction n’est pas plafonné. Pour les réponses supérieures à 6 Mo, le reste de la réponse est soumis à une limite de bande passante. Pour plus d'informations sur la bande passante de diffusion, consultez [Limitation de la bande passante pour la diffusion des réponses](#config-rs-bandwidth-cap).
Les réponses en streaming entraînent des coûts et les réponses diffusées en continu ne sont ni interrompues ni arrêtées lorsque la connexion du client appelant est interrompue. Les clients seront facturés pour la durée complète des fonctions. Les clients doivent donc faire preuve de prudence lorsqu'ils configurent des délais d'expiration de fonction prolongés.
Lambda prend en charge le streaming des réponses sur les exécutions gérées par Node.js. Pour les autres langages, y compris Python, vous pouvez [utiliser un environnement d'exécution personnalisé avec une intégration d'API d'exécution personnalisée](runtimes-custom.md#runtimes-custom-response-streaming) pour diffuser les réponses ou utiliser l'adaptateur [Web Lambda](https://github.com/awslabs/aws-lambda-web-adapter).
**Note**
Lorsque vous testez votre fonction via la console Lambda, vous verrez toujours les réponses comme étant mises en mémoire tampon.
**Topics**
+ [
## Limitation de la bande passante pour la diffusion des réponses
](#config-rs-bandwidth-cap)
+ [
## Compatibilité du VPC avec la diffusion en continu de réponses
](#config-rs-vpc-compatibility)
+ [
# Écriture de fonctions Lambda compatibles avec le streaming de réponses
](config-rs-write-functions.md)
+ [
# Invocation d'une fonction activée pour le streaming de réponses à l'aide de la fonction Lambda URLs
](config-rs-invoke-furls.md)
+ [
# Tutoriel : création d’une fonction Lambda de streaming de réponses avec une URL de la fonction
](response-streaming-tutorial.md)
## Limitation de la bande passante pour la diffusion des réponses
Les 6 premiers Mo des données utiles de la réponse de votre fonction disposent d’une bande passante non plafonnée. Après cette première rafale, Lambda diffuse votre réponse à un débit maximum de 2. MBps Si les réponses de votre fonction ne dépassent jamais 6 Mo, cette limite de bande passante ne s’applique pas.
**Note**
Les limites de bande passante s'appliquent uniquement à la charge utile de la réponse de votre fonction, et non à l'accès au réseau par votre fonction.
Le débit de bande passante non plafonnée varie en fonction d'un certain nombre de facteurs, notamment la vitesse de traitement de votre fonction. Vous pouvez normalement vous attendre à un débit supérieur à 2 MBps pour les 6 premiers Mo de réponse de votre fonction. Si votre fonction diffuse une réponse vers une destination située à l'extérieur AWS, le débit de diffusion dépend également de la vitesse de la connexion Internet externe.
## Compatibilité du VPC avec la diffusion en continu de réponses
Lorsque vous utilisez des fonctions Lambda dans un environnement VPC, la diffusion en continu des réponses doit tenir compte de certaines considérations importantes :
+ La fonction Lambda ne prend URLs pas en charge le streaming des réponses dans un environnement VPC.
+ Vous pouvez utiliser le streaming de réponses au sein d'un VPC en appelant votre fonction Lambda via le SDK à l'aide de l' AWS API. `InvokeWithResponseStream` Pour cela, vous devez configurer les points de terminaison VPC appropriés pour Lambda.
+ Pour les environnements VPC, vous devez créer un point de terminaison de VPC d’interface pour Lambda afin de permettre la communication entre vos ressources dans le VPC et dans le service Lambda.
Une architecture typique pour la diffusion en continu des réponses dans un VPC peut inclure :
```
Client in VPC -> Interface VPC endpoint for Lambda -> Lambda function -> Response streaming back through the same path
```
# Écriture de fonctions Lambda compatibles avec le streaming de réponses
L'écriture du gestionnaire pour les fonctions de streaming de réponses est différente des modèles de gestionnaire typiques. Lorsque vous écrivez des fonctions de streaming, assurez-vous de faire ce qui suit :
+ Encapsulez votre événement avec le décorateur `awslambda.streamifyResponse()`. L’objet global `awslambda` est fourni par l’environnement d’exécution Node.js de Lambda.
+ Terminez la diffusion de manière élégante afin de vous assurer que le traitement des données est terminé.
## Configuration d'une fonction gestionnaire pour diffuser les réponses
Pour indiquer à l'exécution que Lambda doit diffuser les réponses de votre fonction, vous devez envelopper votre fonction avec le décorateur `streamifyResponse()`. Cela indique à l'exécution d'utiliser le chemin logique approprié pour le streaming des réponses et permet à la fonction de diffuser les réponses.
Le décorateur `streamifyResponse()` accepte une fonction qui accepte les paramètres suivants :
+ `event` : fournit des informations sur l'événement d'invocation de l'URL de la fonction, telles que la méthode HTTP, les paramètres de la requête et le corps de la requête.
+ `responseStream` : fournit un flux inscriptible.
+ `context` : fournit des méthodes et des propriétés avec des informations sur l'invocation, la fonction et l'environnement d'exécution.
L'objet `responseStream` est un [`writableStream` Node.js](https://nodesource.com/blog/understanding-streams-in-nodejs/). Comme pour tout flux de ce type, vous devez utiliser la méthode `pipeline()`.
**Note**
L’objet global `awslambda` est automatiquement fourni par l’environnement d’exécution Node.js de Lambda et aucune importation n’est requise.
**Example gestionnaire compatible avec le streaming de réponses**
```
import { pipeline } from 'node:stream/promises';
import { Readable } from 'node:stream';
export const echo = awslambda.streamifyResponse(async (event, responseStream, _context) => {
// As an example, convert event to a readable stream.
const requestStream = Readable.from(Buffer.from(JSON.stringify(event)));
await pipeline(requestStream, responseStream);
});
```
Bien que `responseStream` propose la méthode `write()` pour écrire dans le flux, nous vous recommandons d'utiliser [https://nodejs.org/api/stream.html#streampipelinesource-transforms-destination-callback](https://nodejs.org/api/stream.html#streampipelinesource-transforms-destination-callback) dans la mesure du possible. L'utilisation de `pipeline()` permet de s'assurer que le flux accessible en écriture n'est pas submergé par un flux accessible en lecture plus rapide.
## Fin du flux
Assurez-vous de terminer correctement le flux avant le retour du gestionnaire. La méthode `pipeline()` s'en charge automatiquement.
Pour les autres cas d'utilisation, appelez la méthode `responseStream.end()` pour terminer correctement un flux. Cette méthode signale que plus aucune donnée ne doit être écrite dans le flux. Cette méthode n'est pas nécessaire si vous écrivez dans le flux avec `pipeline()` ou `pipe()`.
À partir de Node.js 24, Lambda n'attend plus que les promesses non résolues se terminent après le retour de votre gestionnaire ou la fin du flux de réponses. Si votre fonction dépend d'opérations asynchrones supplémentaires, telles que des temporisations ou des extractions, vous devez `await` les inclure dans votre gestionnaire.
**Example Exemple de fin d'un flux avec pipeline()**
```
import { pipeline } from 'node:stream/promises';
export const handler = awslambda.streamifyResponse(async (event, responseStream, _context) => {
await pipeline(requestStream, responseStream);
});
```
**Example Exemple de fin d'un flux sans pipeline()**
```
export const handler = awslambda.streamifyResponse(async (event, responseStream, _context) => {
responseStream.write("Hello ");
responseStream.write("world ");
responseStream.write("from ");
responseStream.write("Lambda!");
responseStream.end();
});
```
# Invocation d'une fonction activée pour le streaming de réponses à l'aide de la fonction Lambda URLs
**Note**
Votre fonction Lambda peut désormais diffuser les charges utiles des réponses via l'intégration du proxy [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/response-transfer-mode-lambda.html).
Vous pouvez invoquer des fonctions compatibles avec le streaming de réponses en modifiant le mode d'invocation de l'URL de votre fonction. Le mode d'invocation détermine l'opération d'API que Lambda utilise pour invoquer votre fonction. Les modes d'invocation disponibles sont les suivants :
+ `BUFFERED` : il s'agit de l'option par défaut. Lambda invoque votre fonction en utilisant l’opération d’API `Invoke`. Les résultats de l’invocation sont disponibles lorsque la charge utile est complète. La taille de la charge utile maximale est de 6 Mo.
+ `RESPONSE_STREAM` : permet à votre fonction de diffuser les résultats de la charge utile au fur et à mesure qu'ils sont disponibles. Lambda invoque votre fonction en utilisant l'opération d'API `InvokeWithResponseStream`. La taille maximale de la charge utile de réponse est de 200 Mo.
Vous pouvez toujours invoquer votre fonction sans streaming de réponses en appelant directement l'opération d'API `Invoke`. Cependant, Lambda diffuse toutes les charges utiles de réponse pour les invocations qui passent par l'URL de la fonction jusqu'à ce que vous changiez le mode d'invocation en `BUFFERED`.
------
#### [ Console ]
**Pour définir le mode d'invocation d'une URL de la fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez le nom de la fonction pour laquelle vous voulez définir le mode d'invocation.
1. Choisissez l'onglet **Configuration**, puis **Function URL** (URL de fonction).
1. Sélectionnez **Modifier**, puis **Paramètres supplémentaires**.
1. Sous **Mode d'invocation**, sélectionnez le mode d'invocation de votre choix.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
**Pour définir le mode d’invocation d’une URL de fonction (AWS CLI)**
```
aws lambda update-function-url-config \
--function-name my-function \
--invoke-mode RESPONSE_STREAM
```
------
#### [ CloudFormation ]
**Pour définir le mode d’invocation d’une URL de fonction (CloudFormation)**
```
MyFunctionUrl:
Type: AWS::Lambda::Url
Properties:
AuthType: AWS_IAM
InvokeMode: RESPONSE_STREAM
```
------
Pour plus d'informations sur la configuration de la fonction URLs, consultez la section Fonction [Lambda](urls-configuration.md). URLs
# Tutoriel : création d’une fonction Lambda de streaming de réponses avec une URL de la fonction
Dans ce didacticiel, vous créez une fonction Lambda définie comme archive de fichier ZIP avec un point de terminaison d’URL de la fonction qui renvoie un flux de réponses. Pour plus d'informations sur la configuration de la fonction URLs, consultez[Fonction URLs](urls-configuration.md).
## Conditions préalables
Ce didacticiel suppose que vous avez quelques connaissances des opérations Lambda de base et de la console Lambda. Si ce n’est déjà fait, suivez les instructions fournies dans [Créer une fonction Lambda à l'aide de la console](getting-started.md#getting-started-create-function) pour créer votre première fonction Lambda.
Pour effectuer les étapes suivantes, vous avez besoin de l’[AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). Les commandes et la sortie attendue sont répertoriées dans des blocs distincts :
```
aws --version
```
Vous devriez voir la sortie suivante:
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
Pour les commandes longues, un caractère d’échappement (`\`) est utilisé pour les fractionner en plusieurs lignes.
Sur Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez 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 Bash. Les exemples de commandes CLI de ce guide utilisent le formatage Linux. Les commandes qui incluent des documents JSON en ligne doivent être reformatées si vous utilisez la CLI Windows.
## Créer un rôle d’exécution
Créez le [rôle d’exécution](lambda-intro-execution-role.md) qui donne à votre fonction Lambda l’autorisation d’accéder aux ressources AWS .
**Pour créer un rôle d’exécution**
1. Accédez à la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la Gestion des identités et des accès AWS console (IAM).
1. Sélectionnez **Créer un rôle**.
1. Créez un rôle avec les propriétés suivantes :
+ **Type d’entité sécurisée** – **Service AWS **
+ **Cas d’utilisation** – **Lambda**
+ **Permissions (Autorisations** – **AWSLambdaBasicExecutionRole**
+ **Nom de rôle** – **response-streaming-role**
La **AWSLambdaBasicExecutionRole**politique dispose des autorisations dont la fonction a besoin pour écrire des CloudWatch journaux sur Amazon Logs. Après avoir créé le rôle, notez son Amazon Resource Name (ARN). Vous en aurez besoin à l’étape suivante.
## Création d’une fonction de streaming de réponses (AWS CLI)
Créez une fonction Lambda de streaming de réponses avec un point de terminaison d’URL de la fonction à l’aide de l’ AWS Command Line Interface (AWS CLI).
**Pour créer une fonction capable de diffuser des réponses**
1. Copiez l’exemple de code suivant dans un fichier nommé `index.js`. Cette fonction diffuse trois réponses, séparées de 1 seconde.
```
exports.handler = awslambda.streamifyResponse(
async (event, responseStream, _context) => {
// Metadata is a JSON serializable JS object. Its shape is not defined here.
const metadata = {
statusCode: 200,
headers: {
"Content-Type": "application/json",
"CustomHeader": "outerspace"
}
};
// Assign to the responseStream parameter to prevent accidental reuse of the non-wrapped stream.
responseStream = awslambda.HttpResponseStream.from(responseStream, metadata);
responseStream.write("Streaming with Helper \n");
await new Promise(r => setTimeout(r, 1000));
responseStream.write("Hello 0 \n");
await new Promise(r => setTimeout(r, 1000));
responseStream.write("Hello 1 \n");
await new Promise(r => setTimeout(r, 1000));
responseStream.write("Hello 2 \n");
await new Promise(r => setTimeout(r, 1000));
responseStream.end();
await responseStream.finished();
}
);
```
1. Créez un package de déploiement.
```
zip function.zip index.js
```
1. Créez une fonction Lambda à l’aide de la commande `create-function`. Remplacez la valeur de `--role` par l’ARN de rôle de l’étape précédente. Cette commande définit le délai d’expiration de la fonction à 10 secondes, ce qui permet à la fonction de diffuser trois réponses.
```
aws lambda create-function \
--function-name my-streaming-function \
--runtime nodejs24.x \
--zip-file fileb://function.zip \
--handler index.handler \
--timeout 10 \
--role arn:aws:iam::123456789012:role/response-streaming-role
```
**Pour créer une URL de la fonction**
1. Ajoutez une stratégie basée sur les ressources à votre fonction en accordant les autorisations `lambda:InvokeFunctionUrl` et `lambda:InvokeFunction`. Chaque instruction doit être ajoutée dans une commande distincte. Remplacez la valeur de `--principal` par votre Compte AWS identifiant.
```
aws lambda add-permission \
--function-name my-streaming-function \
--action lambda:InvokeFunctionUrl \
--statement-id UrlPolicyInvokeURL \
--principal 123456789012 \
--function-url-auth-type AWS_IAM
```
```
aws lambda add-permission \
--function-name my-streaming-function \
--action lambda:InvokeFunction \
--statement-id UrlPolicyInvokeFunction \
--principal 123456789012
```
1. Créez un point de terminaison d’URL pour la fonction avec la commande `create-function-url-config`.
```
aws lambda create-function-url-config \
--function-name my-streaming-function \
--auth-type AWS_IAM \
--invoke-mode RESPONSE_STREAM
```
**Note**
Si un message d’erreur concernant `--invoke-mode` s’affiche, il se peut que vous deviez effectuer une mise à niveau vers une [version plus récente d’ AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
## Test du point de terminaison d’URL de fonction
Testez votre intégration en invoquant votre fonction. Vous pouvez ouvrir l’URL de votre fonction dans un navigateur ou utiliser curl.
```
curl --request GET "https://abcdefghijklm7nop7qrs740abcd.lambda-url.us-east-1.on.aws/" --user "AKIAIOSFODNN7EXAMPLE" --aws-sigv4 "aws:amz:us-east-1:lambda" --no-buffer
```
Notre URL de la fonction utilise le type d’authentification `IAM_AUTH`. Cela signifie que vous devez signer les demandes à la fois avec [votre clé d’accès AWS et votre clé secrète](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). Dans la commande précédente, remplacez par `AKIAIOSFODNN7EXAMPLE` l'ID de la clé d' AWS accès. Entrez votre clé AWS secrète lorsque vous y êtes invité. Si vous n'avez pas votre clé AWS secrète, vous pouvez [utiliser des AWS informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html) à la place.
Vous devriez obtenir une réponse comme celle-ci :
```
Streaming with Helper
Hello 0
Hello 1
Hello 2
```
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
# Utilisation du point de terminaison de métadonnées Lambda
Le point de terminaison de métadonnées Lambda permet à vos fonctions de découvrir dans quelle zone de disponibilité (AZ) elles s'exécutent, ce qui vous permet d'optimiser la latence en les acheminant vers des ressources de même zone, telles que les points de terminaison Amazon et ElastiCache Amazon RDS, et de mettre en œuvre des modèles de résilience compatibles avec l'AZ.
Le point de terminaison renvoie les métadonnées dans un format JSON simple via une API HTTP localhost au sein de l'environnement d'exécution et est accessible à la fois aux environnements d'exécution et aux extensions.
**Topics**
+ [
## Prise en main
](#metadata-endpoint-getting-started)
+ [
## Comprendre la zone de disponibilité IDs
](#metadata-endpoint-az-ids)
+ [
## Référence des API
](#metadata-endpoint-api-reference)
## Prise en main
[Powertools for AWS Lambda](https://docs.aws.amazon.com/powertools/) fournit un utilitaire permettant d'accéder au point de terminaison des métadonnées Lambda en Python TypeScript, Java et .NET. L'utilitaire met en cache la réponse après le premier appel et gère automatiquement l'invalidation SnapStart du cache.
Utilisez l'utilitaire de métadonnées Powertools for AWS Lambda ou appelez directement le point de terminaison des métadonnées
------
#### [ Python ]
Installez le package Powertools :
```
pip install "aws-lambda-powertools"
```
Utilisez l'utilitaire de métadonnées de votre gestionnaire :
**Example Récupération d'un identifiant AZ avec Powertools (Python)**
```
from aws_lambda_powertools.utilities.lambda_metadata import get_lambda_metadata
def handler(event, context):
metadata = get_lambda_metadata()
az_id = metadata.availability_zone_id # e.g., "use1-az1"
return {"az_id": az_id}
```
------
#### [ TypeScript ]
Installez le package Powertools :
```
npm install @aws-lambda-powertools/commons
```
Utilisez l'utilitaire de métadonnées de votre gestionnaire :
**Example Récupération d'un identifiant AZ avec Powertools () TypeScript**
```
import { getMetadata } from '@aws-lambda-powertools/commons/utils/metadata';
const metadata = await getMetadata();
export const handler = async () => {
const { AvailabilityZoneID: azId } = metadata;
return azId;
};
```
------
#### [ Java ]
Ajoutez la dépendance Powertools à votre `pom.xml` :
```
software.amazon.lambda
powertools-lambda-metadata
2.10.0
```
Utilisez le client de métadonnées dans votre gestionnaire :
**Example Récupération d'un identifiant AZ avec Powertools (Java)**
```
import software.amazon.lambda.powertools.metadata.LambdaMetadata;
import software.amazon.lambda.powertools.metadata.LambdaMetadataClient;
public class App implements RequestHandler {
@Override
public String handleRequest(Object input, Context context) {
LambdaMetadata metadata = LambdaMetadataClient.get();
String azId = metadata.getAvailabilityZoneId(); // e.g., "use1-az1"
return "{\"azId\": \"" + azId + "\"}";
}
}
```
------
#### [ .NET ]
Installez le package Powertools :
```
dotnet add package AWS.Lambda.Powertools.Metadata
```
Utilisez la classe de métadonnées dans votre gestionnaire :
**Example Récupération d'un identifiant AZ avec Powertools (.NET)**
```
using AWS.Lambda.Powertools.Metadata;
public class Function
{
public string Handler(object input, ILambdaContext context)
{
var azId = LambdaMetadata.AvailabilityZoneId;
return $"Running in AZ: {azId}";
}
}
```
------
#### [ All Runtimes ]
Tous les environnements d'exécution Lambda prennent en charge le point de terminaison des métadonnées, y compris les environnements d'exécution personnalisés et les images de conteneur. Utilisez l'exemple suivant pour accéder à l'API de métadonnées directement depuis votre fonction à l'aide des variables d'environnement que Lambda définit automatiquement dans l'environnement d'exécution.
**Example Accès direct au point de terminaison des métadonnées**
```
# Variables are automatically set by Lambda
METADATA_ENDPOINT="http://${AWS_LAMBDA_METADATA_API}/2026-01-15/metadata/execution-environment"
# Make the request
RESPONSE=$(curl -s -H "Authorization: Bearer ${AWS_LAMBDA_METADATA_TOKEN}" "$METADATA_ENDPOINT")
# Parse the AZ ID
AZ_ID=$(echo "$RESPONSE" | jq -r '.AvailabilityZoneID')
echo "Function is running in AZ ID: $AZ_ID"
```
------
## Comprendre la zone de disponibilité IDs
AZ IDs (par exemple`use1-az1`) fait toujours référence au même emplacement physique sur tous les AWS comptes, tandis que les noms AZ (par exemple,`us-east-1a`) peuvent correspondre à différentes infrastructures physiques de chaque AWS compte dans certaines régions. Pour plus d'informations, voir [AZ IDs pour la cohérence entre comptes](https://docs.aws.amazon.com/global-infrastructure/latest/regions/az-ids.html).
**Conversion d'un ID AZ en nom AZ :**
Pour convertir un ID AZ en nom AZ, utilisez l'API Amazon EC2. [DescribeAvailabilityZones](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeAvailabilityZones.html) Pour utiliser cette API, ajoutez l'`ec2:DescribeAvailabilityZones`autorisation au rôle d'exécution de votre fonction.
## Référence des API
### Variables d’environnement
Lambda définit automatiquement les variables d'environnement suivantes dans chaque environnement d'exécution :
+ `AWS_LAMBDA_METADATA_API`— L'adresse du serveur de métadonnées au format `{ipv4_address}:{port}` (par exemple,`169.254.100.1:9001`).
+ `AWS_LAMBDA_METADATA_TOKEN`— Un jeton d'authentification unique pour l'environnement d'exécution actuel. Lambda génère ce jeton automatiquement lors de l'initialisation. Incluez-le dans toutes les demandes d'API de métadonnées.
### Endpoint
`GET http://${AWS_LAMBDA_METADATA_API}/2026-01-15/metadata/execution-environment`
### Demande
**En-têtes obligatoires :**
+ `Authorization`— La valeur du jeton de la variable d'`AWS_LAMBDA_METADATA_TOKEN`environnement avec le schéma Bearer :`Bearer `. Cette authentification basée sur des jetons fournit une protection approfondie contre les vulnérabilités SSRF (Server-Side Request Forgery). Chaque environnement d'exécution reçoit un jeton unique généré aléatoirement lors de l'initialisation.
### Réponse
**État :** `200 OK`
**Type de contenu :** `application/json`
**Contrôle du cache :** `private, max-age=43200, immutable`
La réponse est immuable dans un environnement d'exécution. Les clients doivent mettre en cache la réponse et respecter le `Cache-Control` TTL. Pour les SnapStart fonctions, le TTL est réduit lors de l'initialisation afin que les clients actualisent les métadonnées après la restauration lorsque l'environnement d'exécution peut se trouver dans une zone de disponibilité différente. Si vous utilisez Powertools, la mise en cache et l' SnapStart invalidation sont gérées automatiquement.
**Corps de texte:**
```
{
"AvailabilityZoneID": "use1-az1"
}
```
Le `AvailabilityZoneID` champ contient l'identifiant unique de la zone de disponibilité dans laquelle s'exécute l'environnement d'exécution.
**Note**
Des champs supplémentaires peuvent être ajoutés à la réponse lors de futures mises à jour. Les clients doivent ignorer les champs inconnus et ne pas échouer si de nouveaux champs apparaissent.
### Réponses d'erreur
+ **401 Non autorisé** — L'`Authorization`en-tête est manquant ou contient un jeton non valide. Vérifiez que vous êtes en train de réussir`Bearer ${AWS_LAMBDA_METADATA_TOKEN}`.
+ **405 Méthode non autorisée** — La méthode de demande ne l'est pas`GET`.
+ **500 Erreur interne du serveur — Erreur** de traitement côté serveur.