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.
# Améliorer les performances de démarrage avec Lambda SnapStart
Lambda SnapStart peut fournir des performances de démarrage inférieures à une seconde, généralement sans modification de votre code de fonction. SnapStart facilite la création d'applications hautement réactives et évolutives sans provisionnement de ressources ni mise en œuvre d'optimisations complexes des performances.
Le principal facteur de latence au démarrage (souvent appelé temps de démarrage à froid) est le temps que Lambda passe à initialiser la fonction, ce qui inclut le chargement du code de la fonction, le démarrage de l’environnement d’exécution et l’initialisation du code de la fonction. Avec SnapStart, Lambda initialise votre fonction lorsque vous publiez une version de fonction. Lambda prend un instantané [Firecracker microVM](https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/) de l’état de la mémoire et du disque de l’[environnement d’exécution](lambda-runtime-environment.md) initialisé, chiffre l’instantané et le met intelligemment en cache pour optimiser la latence de récupération.
Pour garantir la résilience, Lambda conserve plusieurs copies de chaque instantané. Lambda corrige automatiquement les instantanés et leurs copies avec les dernières mises à jour de sécurité et de l’environnement d’exécution. Lorsque vous invoquez la version de la fonction pour la première fois, et au fur et à mesure que les invocations augmentent, Lambda reprend les nouveaux environnements d’exécution à partir de l’instantané mis en cache au lieu de les initialiser à partir de zéro, ce qui améliore la latence au démarrage.
**Important**
Si vos applications dépendent de l’unicité de l’état, vous devez évaluer votre code de fonction et vérifier qu’il est résilient aux opérations instantanées. Pour de plus amples informations, veuillez consulter [Gérer l'unicité avec Lambda SnapStart](snapstart-uniqueness.md).
**Topics**
+ [Quand utiliser SnapStart](#snapstart-use-cases)
+ [Fonctions prises en charge et limitations](#snapstart-runtimes)
+ [Régions prises en charge](#snapstart-supported-regions)
+ [Considérations de compatibilité](#snapstart-compatibility)
+ [SnapStart tarification](#snapstart-pricing)
+ [Activation et gestion de Lambda SnapStart](snapstart-activate.md)
+ [Gérer l'unicité avec Lambda SnapStart](snapstart-uniqueness.md)
+ [Implémentation du code avant ou après les instantanés de fonctions Lambda](snapstart-runtime-hooks.md)
+ [Surveillance pour Lambda SnapStart](snapstart-monitoring.md)
+ [Modèle de sécurité pour Lambda SnapStart](snapstart-security.md)
+ [Maximisez les performances Lambda SnapStart](snapstart-best-practices.md)
+ [Résolution des SnapStart erreurs liées aux fonctions Lambda](snapstart-troubleshooting.md)
## Quand utiliser SnapStart
Lambda SnapStart est conçu pour remédier à la variabilité de latence introduite par un code d'initialisation unique, tel que le chargement de dépendances de modules ou de frameworks. Ces opérations peuvent parfois prendre plusieurs secondes lors de l’invocation initiale. SnapStart À utiliser pour réduire cette latence de quelques secondes à une valeur inférieure à une seconde, dans des scénarios optimaux. SnapStart fonctionne mieux lorsqu'il est utilisé avec des invocations de fonctions à grande échelle. Les fonctions qui sont rarement invoquées peuvent ne pas bénéficier des mêmes améliorations de performance.
SnapStart est particulièrement utile pour deux principaux types d'applications :
+ **Flux utilisateur APIs et sensibles à la latence : les** fonctions faisant partie des points de terminaison critiques des API ou des flux destinés aux utilisateurs peuvent bénéficier de la réduction de la latence et de SnapStart l'amélioration des temps de réponse.
+ **Flux de traitement des données sensibles à la latence :** les flux de traitement des données limités dans le temps qui utilisent des fonctions Lambda peuvent améliorer le débit en réduisant le temps de latence d’initialisation des fonctions anormales.
La [simultanéité allouée](provisioned-concurrency.md) permet aux fonctions d’être initialisées et prêtes à réagir en quelques millisecondes. Utilisez la simultanéité provisionnée si votre application a des exigences strictes en matière de latence de démarrage à froid auxquelles il est impossible de répondre de manière adéquate. SnapStart
## Fonctions prises en charge et limitations
SnapStart est disponible pour les environnements d'exécution [gérés par Lambda](lambda-runtimes.md) suivants :
+ Java 11 et versions ultérieures
+ Python 3.12 et versions ultérieures
+ .NET 8 et versions ultérieures. Si vous utilisez le [framework Lambda Annotations pour .NET](csharp-handler.md#csharp-handler-annotations), passez à [Amazon.Lambda.Annotations version 1.6.0 ou ultérieure pour garantir la compatibilité](https://www.nuget.org/packages/Amazon.Lambda.Annotations) avec. SnapStart
Les autres environnements d'exécution gérés (tels que `nodejs24.x` et `ruby3.4`), [Exécutions uniquement basées sur le système d’exploitation](runtimes-provided.md)et les [images de conteneurs](images-create.md) ne sont pas pris en charge.
SnapStart ne prend pas en charge la [simultanéité provisionnée](provisioned-concurrency.md), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html) ou le stockage éphémère supérieur à 512 Mo.
**Note**
Vous ne pouvez l'utiliser SnapStart que sur des [versions de fonctions publiées](configuration-versions.md#configuration-versions-config) et [des alias](configuration-aliases.md) pointant vers des versions. Vous ne pouvez pas l'utiliser SnapStart sur la version non publiée d'une fonction (\$1LATEST).
## Régions prises en charge
Lambda SnapStart est disponible dans toutes les [régions commerciales](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region), à l'exception de l'Asie-Pacifique (Nouvelle Zélande) et de l'Asie-Pacifique (Taipei).
## Considérations de compatibilité
Avec SnapStart, Lambda utilise un seul instantané comme état initial pour plusieurs environnements d'exécution. Si votre fonction utilise l'un des éléments suivants pendant la [phase d'initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib), vous devrez peut-être apporter quelques modifications avant de l'utiliser SnapStart :
**Unicité**
Si votre code d’initialisation génère un contenu unique qui est inclus dans l’instantané, ce contenu peut ne pas être unique lorsqu’il est réutilisé dans plusieurs environnements d’exécution. Pour conserver l'unicité lors de l'utilisation SnapStart, vous devez générer un contenu unique après l'initialisation. Cela inclut des secrets uniques et uniques IDs, ainsi que l'entropie utilisée pour générer du pseudo-hasard. Pour savoir comment restaurer l’unicité, consultez [Gérer l'unicité avec Lambda SnapStart](snapstart-uniqueness.md).
**Connexions réseau**
L’état des connexions que votre fonction établit pendant la phase d’initialisation n’est pas garanti lorsque Lambda reprend votre fonction à partir d’un instantané. Validez l’état de vos connexions réseau et rétablissez-les si nécessaire. Dans la plupart des cas, les connexions réseau établies par un AWS SDK reprennent automatiquement. Pour les autres connexions, consultez les [bonnes pratiques](snapstart-best-practices.md).
**Données temporaires**
Certaines fonctions téléchargent ou initialisent des données éphémères, telles que des informations d’identification temporaires ou des horodatages mis en cache, pendant la phase d’initialisation. Actualisez les données éphémères dans le gestionnaire de fonctions avant de les utiliser, même lorsque vous ne les utilisez pas. SnapStart
## SnapStart tarification
**Note**
Pour les environnements d'exécution gérés par Java, il n'y a aucun coût supplémentaire pour SnapStart. Vous êtes facturé en fonction du nombre de demandes pour vos fonctions, de la durée d’exécution de votre code et de la mémoire configurée pour votre fonction.
Le coût d'utilisation SnapStart inclut les éléments suivants :
+ **Mise en cache :** pour chaque version de fonction que vous publiez avec cette SnapStart option activée, vous payez les frais de mise en cache et de maintenance de l'instantané. Le prix dépend de la quantité de [mémoire](configuration-memory.md) que vous allouez à votre fonction. Vous êtes facturé pour un minimum de 3 heures. Vous continuerez à payer des frais tant que votre fonction restera [active](snapstart-activate.md#snapstart-active). Utilisez l'action [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)API pour identifier les versions des fonctions, puis utilisez-la [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)pour supprimer les versions inutilisées. Pour supprimer automatiquement les versions de fonction inutilisées, consultez le modèle [Lambda Version Cleanup](https://serverlessland.com/workflows/step-functions-lambda-version-cleanup) sur Serverless Land.
+ **Restauration :** chaque fois qu’une instance de fonction est restaurée à partir d’un instantané, vous payez des frais de restauration. Le prix dépend de la quantité de mémoire que vous allouez à votre fonction.
Comme pour toutes les fonctions Lambda, des frais de durée s’appliquent au code exécuté dans le gestionnaire de fonctions. Pour les SnapStart fonctions, les frais de durée s'appliquent également au code d'initialisation déclaré en dehors du gestionnaire, au temps nécessaire au chargement de l'exécution et à tout code exécuté dans un hook [d'exécution](snapstart-runtime-hooks.md). La durée est calculée à partir du moment où votre code commence à s’exécuter jusqu’à son retour ou sa fin, arrondie à la milliseconde la plus proche. Lambda conserve des copies en cache de votre instantané pour des raisons de résilience et leur applique automatiquement les mises à jour logicielles, telles que les mises à niveau de l’environnement d’exécution et les correctifs de sécurité. Des frais s’appliquent chaque fois que Lambda réexécute votre code d’initialisation pour appliquer des mises à jour logicielles.
Pour plus d'informations sur le coût d'utilisation SnapStart, consultez la section [AWS Lambda Tarification](https://aws.amazon.com/lambda/pricing/#SnapStart_Pricing).
# Activation et gestion de Lambda SnapStart
Pour l'utiliser SnapStart, activez-la SnapStart sur une fonction Lambda nouvelle ou existante. Ensuite, publiez et invoquez une version de la fonction.
**Topics**
+ [Activation SnapStart (console)](#snapshot-console)
+ [Activation SnapStart (AWS CLI)](#snapshot-cli)
+ [Activation SnapStart (API)](#snapshot-api)
+ [Lambda SnapStart et états des fonctions](#snapstart-function-states)
+ [Mise à jour d’un instantané](#update-snapshot)
+ [Utilisation SnapStart avec AWS SDKs](#snapstart-credentials)
+ [Utilisation SnapStart avec CloudFormation AWS SAM, et AWS CDK](#snapstart-cfn-sam)
+ [Suppression d’instantanés](#snapshot-delete)
## Activation SnapStart (console)
**SnapStart Pour activer une fonction**
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. Choisissez **Configuration**, puis **General configuration** (Configuration générale).
1. Dans le volet **General configuration** (Configuration générale), choisissez **Edit** (Modifier).
1. Sur la page **Modifier les paramètres de base**, pour **SnapStart**, choisissez **Versions publiées**.
1. Choisissez **Enregistrer**.
1. [Publiez une version de la fonction](configuration-versions.md#configuration-versions-config). Lambda initialise votre code, crée un instantané de l’environnement d’exécution initialisé, puis met en cache l’instantané pour un accès à faible latence.
1. [Invoquez la version de la fonction.](configuration-versions.md#versioning-versions-using).
## Activation SnapStart (AWS CLI)
**SnapStart Pour activer une fonction existante**
1. Mettez à jour la configuration de la fonction en exécutant la [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)commande avec l'**--snap-start**option.
```
aws lambda update-function-configuration \
--function-name my-function \
--snap-start ApplyOn=PublishedVersions
```
1. Publiez une version de la fonction avec la commande [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html).
```
aws lambda publish-version \
--function-name my-function
```
1. Vérifiez qu'elle SnapStart est activée pour la version de la fonction en exécutant la [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html)commande et en spécifiant le numéro de version. L’exemple suivant spécifie la version 1.
```
aws lambda get-function-configuration \
--function-name my-function:1
```
Si la réponse indique que [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)c'est le cas `On` et que [l'état l'](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) SnapStart est`Active`, alors il est activé et un instantané est disponible pour la version de fonction spécifiée.
```
"SnapStart": {
"ApplyOn": "PublishedVersions",
"OptimizationStatus": "On"
},
"State": "Active",
```
1. Invoquez la version de la fonction en exécutant la commande [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) et en spécifiant la version. L’exemple suivant invoque la version 1.
```
aws lambda invoke \
--cli-binary-format raw-in-base64-out \
--function-name my-function:1 \
--payload '{ "name": "Bob" }' \
response.json
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
**À activer SnapStart lorsque vous créez une nouvelle fonction**
1. Créez une fonction en exécutant la commande [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) avec l’option **--snap-start**. Pour **--role**, spécifiez le Amazon Resource Name (ARN) de votre [rôle d’exécution](lambda-intro-execution-role.md).
```
aws lambda create-function \
--function-name my-function \
--runtime "java25" \
--zip-file fileb://my-function.zip \
--handler my-function.handler \
--role arn:aws:iam::111122223333:role/lambda-ex \
--snap-start ApplyOn=PublishedVersions
```
1. Créez une version avec la commande [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html).
```
aws lambda publish-version \
--function-name my-function
```
1. Vérifiez qu'elle SnapStart est activée pour la version de la fonction en exécutant la [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html)commande et en spécifiant le numéro de version. L’exemple suivant spécifie la version 1.
```
aws lambda get-function-configuration \
--function-name my-function:1
```
Si la réponse indique que [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)c'est le cas `On` et que [l'état l'](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) SnapStart est`Active`, alors il est activé et un instantané est disponible pour la version de fonction spécifiée.
```
"SnapStart": {
"ApplyOn": "PublishedVersions",
"OptimizationStatus": "On"
},
"State": "Active",
```
1. Invoquez la version de la fonction en exécutant la commande [invoke](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) et en spécifiant la version. L’exemple suivant invoque la version 1.
```
aws lambda invoke \
--cli-binary-format raw-in-base64-out \
--function-name my-function:1 \
--payload '{ "name": "Bob" }' \
response.json
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
## Activation SnapStart (API)
**Pour activer SnapStart**
1. Effectuez l’une des actions suivantes :
+ Créez une nouvelle fonction SnapStart activée en utilisant l'action [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)API avec le [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html)paramètre.
+ SnapStart Activez une fonction existante en utilisant l'[UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)action associée au [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html)paramètre.
1. Publiez une version de fonction avec l'[PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)action. Lambda initialise votre code, crée un instantané de l’environnement d’exécution initialisé, puis met en cache l’instantané pour un accès à faible latence.
1. Vérifiez qu'elle SnapStart est activée pour la version de la fonction en utilisant l'[GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)action. Spécifiez un numéro de version pour confirmer qu' SnapStart il est activé pour cette version. Si la réponse indique que [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)c'est le cas `On` et que [l'état l'](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) SnapStart est`Active`, alors il est activé et un instantané est disponible pour la version de fonction spécifiée.
```
"SnapStart": {
"ApplyOn": "PublishedVersions",
"OptimizationStatus": "On"
},
"State": "Active",
```
1. Invoquez la version de la fonction avec l’action [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html).
## Lambda SnapStart et états des fonctions
Les états de fonction suivants peuvent se produire lorsque vous utilisez SnapStart.
**En attente**
Lambda initialise votre code et prend un instantané de l’environnement d’exécution initialisé. Les invocations ou autres actions d’API qui agissent sur la version de fonction échoueront.
**Actif**
La création de l’instantané est terminée et vous pouvez invoquer la fonction. Pour l'utiliser SnapStart, vous devez invoquer la version publiée de la fonction, et non la version non publiée (\$1LATEST).
** Inactif**
L’état `Inactive` peut se produire lorsque Lambda régénère périodiquement des instantanés de fonction pour appliquer des mises à jour logicielles. Dans ce cas, si votre fonction ne parvient pas à s’initialiser, elle peut entrer dans un état `Inactive`.
Pour les fonctions utilisant un environnement d’exécution Java, Lambda supprime les instantanés au bout de 14 jours sans invocation. Si vous invoquez la version de la fonction après 14 jours, Lambda renvoie une réponse `SnapStartNotReadyException` et commence à initialiser un nouvel instantané. Attendez que la fonction version atteigne l’état `Active`, puis invoquez-la à nouveau.
**Échec**
Lambda a rencontré une erreur lors de l’exécution du code d’initialisation ou de la création de l’instantané.
## Mise à jour d’un instantané
Lambda crée un instantané pour chaque version de fonction publiée. Pour mettre à jour un instantané, publiez une nouvelle version de la fonction.
## Utilisation SnapStart avec AWS SDKs
Pour effectuer des appels au AWS SDK depuis votre fonction, Lambda génère un ensemble éphémère d'informations d'identification en assumant le rôle d'exécution de votre fonction. Ces informations d’identification sont disponibles en tant que variables d’environnement lors de l’invocation de votre fonction. Vous n’avez pas besoin de fournir des informations d’identification pour le kit SDK directement dans le code. Par défaut, la chaîne de fournisseurs d’informations d’identification vérifie séquentiellement chaque endroit où vous pouvez définir des informations d’identification et sélectionne le premier disponible, généralement les variables d’environnement (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` et `AWS_SESSION_TOKEN`).
**Note**
Lorsqu'il SnapStart est activé, le moteur d'exécution Lambda utilise automatiquement les informations d'identification du conteneur (`AWS_CONTAINER_CREDENTIALS_FULL_URI`et`AWS_CONTAINER_AUTHORIZATION_TOKEN`) au lieu des variables d'environnement de la clé d'accès. Cela évite que les informations d’identification n’expirent avant la restauration de la fonction.
## Utilisation SnapStart avec CloudFormation AWS SAM, et AWS CDK
+ **AWS CloudFormation:** Déclarez l'[SnapStart](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-snapstart.html)entité dans votre modèle.
+ **AWS Serverless Application Model (AWS SAM) :** Déclarez la [SnapStart](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-snapstart)propriété dans votre modèle.
+ **AWS Cloud Development Kit (AWS CDK):** Utilisez le [SnapStartProperty](https://docs.aws.amazon.com/cdk/api/v2/java/software/amazon/awscdk/services/lambda/CfnFunction.SnapStartProperty.html)type.
## Suppression d’instantanés
Lambda supprime les instantanés lorsque :
+ Vous supprimez la fonction ou la version de la fonction.
+ **Exécutions Java uniquement** : vous n’invoquez pas la version de la fonction pendant 14 jours. Après 14 jours sans invocation, la version de fonction passe à l’état [Inactif](#snapstart-function-states). Si vous invoquez la version de la fonction après 14 jours, Lambda renvoie une réponse `SnapStartNotReadyException` et commence à initialiser un nouvel instantané. Attendez que la version de la fonction atteigne l’état [Actif](#snapstart-function-states), puis invoquez-la à nouveau.
Lambda supprime toutes les ressources associées aux instantanés supprimés, conformément au Règlement général sur la protection des données (RGPD).
# Gérer l'unicité avec Lambda SnapStart
Lorsque les invocations augmentent sur une SnapStart fonction, Lambda utilise un seul instantané initialisé pour reprendre plusieurs environnements d'exécution. Si votre code d’initialisation génère un contenu unique qui est inclus dans l’instantané, ce contenu peut ne pas être unique lorsqu’il est réutilisé dans plusieurs environnements d’exécution. Pour conserver l'unicité lors de l'utilisation SnapStart, vous devez générer un contenu unique après l'initialisation. Cela inclut des secrets uniques et uniques IDs, ainsi que l'entropie utilisée pour générer du pseudo-hasard.
Nous vous recommandons les bonnes pratiques suivantes pour vous aider à maintenir l’unicité de votre code. Pour les fonctions Java, Lambda fournit également un [outil d'SnapStart analyse](#snapstart-scanning) open source pour aider à vérifier le code qui suppose un caractère unique. Si vous générez des données uniques pendant la phase d’initialisation, vous pouvez utiliser un [hook d’exécution](snapstart-runtime-hooks.md) pour rétablir l’unicité. Avec les hooks d’exécution, vous pouvez exécuter un code spécifique immédiatement avant que Lambda ne prenne un instantané ou immédiatement après que Lambda ait repris une fonction à partir d’un instantané.
## Évitez de sauvegarder un état qui dépend de l’unicité pendant l’initialisation
Pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib) de votre fonction, évitez de mettre en cache des données qui sont censées être uniques, comme la génération d’un ID unique pour la journalisation ou la configuration de seeds pour les fonctions random. Nous vous recommandons plutôt de générer des données uniques ou de configurer des seeds pour des fonctions random dans votre gestionnaire de fonction ou d’utiliser un [hook d’exécution](snapstart-runtime-hooks.md).
Les exemples suivants montrent comment générer un UUID dans le gestionnaire de fonctions.
------
#### [ Java ]
**Example – Génération d’un ID unique dans le gestionnaire de fonctions**
```
import java.util.UUID;
public class Handler implements RequestHandler {
private static UUID uniqueSandboxId = null;
@Override
public String handleRequest(String event, Context context) {
if (uniqueSandboxId == null)
uniqueSandboxId = UUID.randomUUID();
System.out.println("Unique Sandbox Id: " + uniqueSandboxId);
return "Hello, World!";
}
}
```
------
#### [ Python ]
**Example – Génération d’un ID unique dans le gestionnaire de fonctions**
```
import json
import random
import time
unique_number = None
def lambda_handler(event, context):
seed = int(time.time() * 1000)
random.seed(seed)
global unique_number
if not unique_number:
unique_number = random.randint(1, 10000)
print("Unique number: ", unique_number)
return "Hello, World!"
```
------
#### [ .NET ]
**Example – Génération d’un ID unique dans le gestionnaire de fonctions**
```
namespace Example;
public class SnapstartExample
{
private Guid _myExecutionEnvironmentGuid;
public SnapstartExample()
{
// This GUID is set for non-restore use cases, such as testing or if SnapStart is turned off
_myExecutionEnvironmentGuid = new Guid();
// Register the method which will run after each restore. You may need to update Amazon.Lambda.Core to see this
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(MyAfterRestore);
}
private ValueTask MyAfterRestore()
{
// After restoring this snapshot to a new execution environment, update the GUID
_myExecutionEnvironmentGuid = new Guid();
return ValueTask.CompletedTask;
}
public string Handler()
{
return $"Hello World! My Execution Environment GUID is {_myExecutionEnvironmentGuid}";
}
}
```
------
## Utiliser des générateurs de nombres pseudo-aléatoires sécurisés par cryptographie () CSPRNGs
Si votre application repose sur le caractère aléatoire, nous vous recommandons d'utiliser des générateurs de nombres aléatoires sécurisés par cryptographie ()CSPRNGs. Outre OpenSSL 1.0.2, les environnements d'exécution gérés par Lambda incluent également les fonctionnalités intégrées suivantes : CSPRNGs
+ **Java :** `java.security.SecureRandom`
+ **Python :** `random.SystemRandom`
+ **.NET :** `System.Security.Cryptography.RandomNumberGenerator`
Logiciel qui obtient toujours des nombres aléatoires `/dev/random` ou qui `/dev/urandom` maintient le caractère aléatoire avec SnapStart.
AWS les bibliothèques de cryptographie conservent automatiquement le caractère aléatoire en SnapStart commençant par les versions minimales spécifiées dans le tableau suivant. Si vous utilisez ces bibliothèques avec vos fonctions Lambda, assurez-vous d’utiliser les versions minimales ou ultérieures suivantes :
****
| Bibliothèque | Version minimale prise en charge (x86) | Version minimale prise en charge (ARM) |
| --- | --- | --- |
| AWS libcrypto (AWS-LC) | 1.16.0 | 1.30.0 |
| AWS libcrypto FIPS | 2.0.13 | 2.0.13 |
Si vous empaquetez les bibliothèques de chiffrement ci-dessus avec vos fonctions Lambda sous forme de dépendances transitives via les bibliothèques suivantes, assurez-vous d’utiliser les versions minimales suivantes ou des versions ultérieures :
****
| Bibliothèque | Version minimale prise en charge (x86) | Version minimale prise en charge (ARM) |
| --- | --- | --- |
| AWS SDK for Java 2.x | 2,23,20 | 2,26,12 |
| AWS Common Runtime pour Java | 0,29,8 | 0,29,25 |
| Amazon Corretto Crypto Provider | 2.4.1 | 2.4.1 |
| Amazon Corretto Crypto Provider FIPS | 2.4.1 | 2.4.1 |
Les exemples suivants montrent comment garantir des séquences CSPRNGs de numéros uniques même lorsque la fonction est restaurée à partir d'un instantané.
------
#### [ Java ]
**Example — java.security. SecureRandom**
```
import java.security.SecureRandom;
public class Handler implements RequestHandler {
private static SecureRandom rng = new SecureRandom();
@Override
public String handleRequest(String event, Context context) {
for (int i = 0; i < 10; i++) {
System.out.println(rng.next());
}
return "Hello, World!";
}
}
```
------
#### [ Python ]
**Example — aléatoire. SystemRandom**
```
import json
import random
secure_rng = random.SystemRandom()
def lambda_handler(event, context):
random_numbers = [secure_rng.random() for _ in range(10)]
for number in random_numbers:
print(number)
return "Hello, World!"
```
------
#### [ .NET ]
**Example – RandomNumberGenerator**
```
using Amazon.Lambda.Core;
using System.Security.Cryptography;
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace DotnetSecureRandom;
public class Function
{
public string FunctionHandler()
{
using (RandomNumberGenerator rng = RandomNumberGenerator.Create())
{
byte[] randomUnsignedInteger32Bytes = new byte[4];
for (int i = 0; i < 10; i++)
{
rng.GetBytes(randomUnsignedInteger32Bytes);
int randomInt32 = BitConverter.ToInt32(randomUnsignedInteger32Bytes, 0);
Console.WriteLine("{0:G}", randomInt32);
}
}
return "Hello World!";
}
}
```
------
## SnapStart outil de numérisation (Java uniquement)
Lambda fournit un outil d’analyse pour Java pour vous aider à vérifier le code qui suppose l’unicité. L'outil de SnapStart numérisation est un [SpotBugs](https://spotbugs.github.io/)plugin open source qui exécute une analyse statique par rapport à un ensemble de règles. L’outil d’analyse aide à identifier les implémentations de code potentielles qui pourraient enfreindre les suppositions concernant l’unicité. Pour les instructions d'installation et la liste des vérifications effectuées par l'outil d'analyse, consultez le référentiel [aws-lambda-snapstart-java-rules](https://github.com/aws/aws-lambda-snapstart-java-rules) sur GitHub.
Pour en savoir plus sur la gestion de l'unicité avec SnapStart, consultez [Starting up faster with AWS Lambda SnapStart](https://aws.amazon.com/blogs/compute/starting-up-faster-with-aws-lambda-snapstart/) sur le blog AWS Compute.
# Implémentation du code avant ou après les instantanés de fonctions Lambda
Vous pouvez utiliser des hooks d’exécution pour implémenter du code avant que Lambda ne crée un instantané ou après que Lambda ait repris une fonction à partir d’un instantané. Les hooks d’exécution sont utiles à diverses fins, telles que :
+ **Le nettoyage et l’initialisation :** avant de créer un instantané, vous pouvez utiliser un hook d’exécution pour effectuer des opérations de nettoyage ou de libération de ressources. Après la restauration d’un instantané, vous pouvez utiliser un hook d’exécution pour réinitialiser les ressources ou les états qui n’ont pas été capturés dans l’instantané.
+ **La configuration dynamique :** vous pouvez utiliser des hooks d’exécution pour mettre à jour dynamiquement la configuration ou d’autres métadonnées avant la création d’un instantané ou après sa restauration. Cela peut être utile si votre fonction doit s’adapter aux modifications de l’environnement d’exécution.
+ **Les intégrations externes :** vous pouvez utiliser des hooks d’exécution pour intégrer des services ou des systèmes externes, tels que l’envoi de notifications ou la mise à jour de l’état externe, dans le cadre du processus de point de contrôle et de restauration.
+ **L’optimisation des performances :** vous pouvez utiliser des hooks d’exécution pour optimiser la séquence de démarrage de votre fonction, par exemple en préchargeant les dépendances. Pour de plus amples informations, consultez [Personnalisation de performances](snapstart-best-practices.md#snapstart-tuning).
Les pages suivantes expliquent comment implémenter des hooks d’exécution pour votre environnement d’exécution préféré.
**Topics**
+ [Java](snapstart-runtime-hooks-java.md)
+ [Python](snapstart-runtime-hooks-python.md)
+ [.NET](snapstart-runtime-hooks-dotnet.md)
# Hooks d' SnapStart exécution Lambda pour Java
Vous pouvez utiliser des hooks d’exécution pour implémenter du code avant que Lambda ne crée un instantané ou après que Lambda ait repris une fonction à partir d’un instantané. Les hooks d'exécution sont disponibles dans le cadre du projet open source Coordinated Restore at Checkpoint (CRaC). CRaC est en cours de développement pour le [kit de développement Open Java (OpenJDK](https://wiki.openjdk.org/display/crac)). Pour un exemple d'utilisation de CRa C avec une application de référence, consultez le référentiel [CRaC](https://github.com/CRaC/docs/blob/master/STEP-BY-STEP.md) sur GitHub. CRaC utilise trois éléments principaux :
+ `Resource` – Une interface avec deux méthodes, `beforeCheckpoint()` et `afterRestore()`. Utilisez ces méthodes pour implémenter le code que vous voulez exécuter avant un instantané et après une restauration.
+ `Context ` – Pour recevoir des notifications pour les points de contrôle et les restaurations, une `Resource` doit être enregistrée avec un `Context`.
+ `Core` – Le service de coordination, qui fournit le `Context` global par défaut via la méthode statique `Core.getGlobalContext()`.
Pour plus d'informations sur `Context` et`Resource`, consultez [Package org.crac dans la CRa documentation C.](https://javadoc.io/doc/io.github.crac/org-crac/latest/index.html)
Suivez les étapes suivantes pour implémenter des hooks d’exécution avec le [package org.crac](https://github.com/CRaC/org.crac). Le moteur d'exécution Lambda contient une implémentation de contexte CRa C personnalisée qui appelle vos hooks d'exécution avant le point de contrôle et après la restauration.
## Enregistrement et exécution du hook d’exécution
L’ordre dans lequel Lambda exécute vos hooks d’exécution est déterminé par l’ordre d’enregistrement. L’ordre d’enregistrement suit l’ordre d’importation, de définition ou d’exécution dans votre code.
+ `beforeCheckpoint()` : exécutés dans l’ordre inverse de l’enregistrement
+ `afterRestore()` : exécutés dans l’ordre d’enregistrement
Assurez-vous que tous les hooks enregistrés sont correctement importés et inclus dans le code de votre fonction. Si vous enregistrez les hooks d’exécution dans un fichier ou un module distinct, vous devez vous assurer que le module est importé, soit directement, soit dans le cadre d’un package plus large, dans le fichier de gestionnaire de votre fonction. Si le fichier ou le module n’est pas importé dans le gestionnaire de fonctions, Lambda ignore les hooks d’exécution.
**Note**
Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le [délai d’expiration de la fonction configurée](configuration-timeout.md) (900 secondes au maximum), la valeur la plus élevée étant retenue. Vos hooks d’exécution `beforeCheckpoint()` sont comptabilisés dans le délai d’attente du code d’initialisation. Lorsque Lambda restaure un instantané, l’exécution doit se charger et les hooks d’exécution `afterRestore()` doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException.
## Étape 1 : mettre à jour de configuration de création
Ajoutez la dépendance `org.crac` à la configuration de compilation. L’exemple suivant utilise Gradle. Pour des exemples concernant d’autres systèmes de compilation, consultez la [documentation Apache Maven](https://search.maven.org/artifact/io.github.crac/org-crac/0.1.3/jar).
```
dependencies {
compile group: 'com.amazonaws', name: 'aws-lambda-java-core', version: '1.2.1'
# All other project dependecies go here:
# ...
# Then, add the org.crac dependency:
implementation group: 'org.crac', name: 'crac', version: '1.4.0'
}
```
## Étape 2 : mettre à jour le gestionnaire Lambda
Le *gestionnaire* de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.
Pour de plus amples informations, veuillez consulter [Définition du gestionnaire de fonction Lambda dans Java](java-handler.md).
L’exemple de gestionnaire suivant montre comment exécuter le code avant le point de contrôle (`beforeCheckpoint()`) et après la restauration (`afterRestore()`). Ce gestionnaire enregistre également la `Resource` dans le `Context` global géré par l’environnement d’exécution.
**Note**
Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le [délai d’expiration de la fonction configurée](configuration-timeout.md) (900 secondes au maximum), la valeur la plus élevée étant retenue. Vos hooks d’exécution `beforeCheckpoint()` sont comptabilisés dans le délai d’attente du code d’initialisation. Lorsque Lambda restaure un instantané, l’exécution (JVM) doit se charger et les hooks d’exécution `afterRestore()` doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException.
```
...
import org.crac.Resource;
import org.crac.Core;
...
public class CRaCDemo implements RequestStreamHandler, Resource {
public CRaCDemo() {
Core.getGlobalContext().register(this);
}
public String handleRequest(String name, Context context) throws IOException {
System.out.println("Handler execution");
return "Hello " + name;
}
@Override
public void beforeCheckpoint(org.crac.Context context)
throws Exception {
System.out.println("Before checkpoint");
}
@Override
public void afterRestore(org.crac.Context context)
throws Exception {
System.out.println("After restore");
```
`Context` maintient uniquement une [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html) à l’objet enregistré. Si une [https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html](https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html) est récupérée par le récupérateur de mémoire, les hooks d’exécution ne s’exécutent pas. Votre code doit maintenir une référence forte à la `Resource` pour garantir l’exécution du hook d’exécution.
Voici deux exemples de modèles à éviter :
**Example – Objet sans référence forte**
```
Core.getGlobalContext().register( new MyResource() );
```
**Example – Objets de classes anonymes**
```
Core.getGlobalContext().register( new Resource() {
@Override
public void afterRestore(Context context) throws Exception {
// ...
}
@Override
public void beforeCheckpoint(Context context) throws Exception {
// ...
}
} );
```
Au lieu de cela, maintenez une référence forte. Dans l’exemple suivant, la ressource enregistrée n’est pas récupérée par le récupérateur de mémoire et les hooks d’exécution s’exécutent de manière cohérente.
**Example – Objet avec une référence forte**
```
Resource myResource = new MyResource(); // This reference must be maintained to prevent the registered resource from being garbage collected
Core.getGlobalContext().register( myResource );
```
# Hooks d’exécution Lambda SnapStart pour Python
Vous pouvez utiliser des hooks d’exécution pour implémenter du code avant que Lambda ne crée un instantané ou après que Lambda ait repris une fonction à partir d’un instantané. Les hooks d’exécution Python sont disponibles dans le cadre de la [bibliothèque Snapshot Restore for Python](https://pypi.org/project/snapshot-restore-py/) open source, qui est incluse dans les environnements d’exécution gérés par Python. Cette bibliothèque fournit deux décorateurs que vous pouvez utiliser pour définir vos hooks d’exécution :
+ `@register_before_snapshot` : pour les fonctions que vous souhaitez exécuter avant que Lambda ne crée un instantané.
+ `@register_after_restore` : pour les fonctions que vous souhaitez exécuter lorsque Lambda reprend une fonction à partir d’un instantané.
Vous pouvez également utiliser les méthodes suivantes afin d’enregistrer des fonctions pouvant être appelées pour des hooks d’exécution :
+ `register_before_snapshot(func, *args, **kwargs)`
+ `register_after_restore(func, *args, **kwargs)`
## Enregistrement et exécution du hook d’exécution
L’ordre dans lequel Lambda exécute vos hooks d’exécution est déterminé par l’ordre d’enregistrement :
+ Avant l’instantané : exécutés dans l’ordre inverse de l’enregistrement
+ Après l’instantané : exécutés dans l’ordre d’enregistrement
L’ordre d’enregistrement des hooks d’exécution dépend de la façon dont vous définissez les hooks. Lorsque vous utilisez des décorateurs (`@register_before_snapshot` et `@register_after_restore`), l’ordre d’enregistrement suit l’ordre d’importation, de définition ou d’exécution dans votre code. Si vous avez besoin de plus de contrôle sur l’ordre d’enregistrement, utilisez les méthodes `register_before_snapshot()` et `register_after_restore()` au lieu des décorateurs.
Assurez-vous que tous les hooks enregistrés sont correctement importés et inclus dans le code de votre fonction. Si vous enregistrez les hooks d’exécution dans un fichier ou un module distinct, vous devez vous assurer que le module est importé, soit directement, soit dans le cadre d’un package plus large, dans le fichier de gestionnaire de votre fonction. Si le fichier ou le module n’est pas importé dans le gestionnaire de fonctions, Lambda ignore les hooks d’exécution.
**Note**
Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le [délai d’expiration de la fonction configurée](configuration-timeout.md) (900 secondes au maximum), la valeur la plus élevée étant retenue. Vos hooks d’exécution `@register_before_snapshot` sont comptabilisés dans le délai d’attente du code d’initialisation. Lorsque Lambda restaure un instantané, l’exécution doit se charger et les hooks d’exécution `@register_after_restore` doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez une SnapStartTimeoutException.
## Exemple
L’exemple de gestionnaire suivant montre comment exécuter le code avant le point de contrôle (`@register_before_snapshot`) et après la restauration (`@register_after_restore`).
```
from snapshot_restore_py import register_before_snapshot, register_after_restore
def lambda_handler(event, context):
# Handler code
@register_before_snapshot
def before_checkpoint():
# Logic to be executed before taking snapshots
@register_after_restore
def after_restore():
# Logic to be executed after restore
```
Pour plus d’exemples, consultez [Snapshot Restore pour Python](https://github.com/aws/snapshot-restore-py/tree/main/examples) dans le référentiel GitHub AWS.
# Hooks d’exécution Lambda SnapStart pour .NET
Vous pouvez utiliser des hooks d’exécution pour implémenter du code avant que Lambda ne crée un instantané ou après que Lambda ait repris une fonction à partir d’un instantané. Les hooks d’exécution .NET sont disponibles dans le cadre du package [Amazon.Lambda.Core](https://www.nuget.org/packages/Amazon.Lambda.Core) (version 2.5.0 ou ultérieure). Cette bibliothèque fournit deux méthodes que vous pouvez utiliser pour définir vos hooks d’exécution :
+ `RegisterBeforeSnapshot()` : code à exécuter avant la création de l’instantané
+ `RegisterAfterSnapshot()` : code à exécuter après la reprise d’une fonction à partir d’un instantané
**Note**
Si vous utilisez le [cadre Lambda Annotations pour .NET](csharp-handler.md#csharp-handler-annotations), passez à [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations) version 1.6.0 ou ultérieure pour garantir la compatibilité avec SnapStart.
## Enregistrement et exécution du hook d’exécution
Enregistrez vos hooks dans votre code d’initialisation. Tenez compte des directives suivantes en fonction du [modèle d’exécution](csharp-handler.md#csharp-handler-setup) de votre fonction Lambda :
+ Pour l’[approche de l’assemblage exécutable](csharp-handler.md#csharp-executable-assembly-handlers), enregistrez vos hooks avant de démarrer l’amorçage Lambda avec `RunAsync`.
+ Pour l’[approche de la bibliothèque de classes](csharp-handler.md#csharp-class-library-handlers), enregistrez vos hooks dans le constructeur de classe du gestionnaire.
+ Pour les [applications ASP.NET Core](csharp-package-asp.md), enregistrez vos hooks avant d’appeler la méthode `WebApplications.Run`.
Pour enregistrer des hooks d’exécution pour SnapStart dans .NET, utilisez les méthodes suivantes :
```
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint);
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint);
```
Lorsque plusieurs types de hooks sont enregistrés, l’ordre dans lequel Lambda exécute vos hooks d’exécution est déterminé par l’ordre d’enregistrement :
+ `RegisterBeforeSnapshot()` : exécutés dans l’ordre inverse de l’enregistrement
+ `RegisterAfterSnapshot()` : exécutés dans l’ordre d’enregistrement
**Note**
Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le [délai d’expiration de la fonction configurée](configuration-timeout.md) (900 secondes au maximum), la valeur la plus élevée étant retenue. Vos hooks d’exécution `RegisterBeforeSnapshot()` sont comptabilisés dans le délai d’attente du code d’initialisation. Lorsque Lambda restaure un instantané, l’exécution doit se charger et les hooks d’exécution `RegisterAfterSnapshot()` doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez une SnapStartTimeoutException.
## Exemple
L’exemple de fonction suivant montre comment exécuter le code avant le point de contrôle (`RegisterBeforeSnapshot`) et après la restauration (`RegisterAfterRestore`).
```
public class SampleClass
{
public SampleClass()
{
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint);
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint);
}
private ValueTask BeforeCheckpoint()
{
// Add logic to be executed before taking the snapshot
return ValueTask.CompletedTask;
}
private ValueTask AfterCheckpoint()
{
// Add logic to be executed after restoring the snapshot
return ValueTask.CompletedTask;
}
public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
// Add business logic
return new APIGatewayProxyResponse
{
StatusCode = 200
};
}
}
```
# Surveillance pour Lambda SnapStart
Vous pouvez surveiller vos fonctions Lambda SnapStart en utilisant Amazon CloudWatch, AWS X-Ray et l’API [Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie](telemetry-api.md).
**Note**
Les [variables d'environnement](configuration-envvars.md#configuration-envvars-runtime) `AWS_LAMBDA_LOG_GROUP_NAME` et `AWS_LAMBDA_LOG_STREAM_NAME` ne sont pas disponibles dans les fonctions SnapStart Lambda.
## Comprendre le comportement de journalisation et de facturation avec SnapStart
Il existe quelques différences avec le format du [flux de journal CloudWatch](monitoring-cloudwatchlogs.md) pour les fonctions SnapStart :
+ **Journaux d’initialisation** – Lorsqu’un nouvel environnement d’exécution est créé, le `REPORT` n’inclut pas le champ `Init Duration`. C’est parce que Lambda initialise les fonctions SnapStart lorsque vous créez une version au lieu de le faire pendant l’invocation de la fonction. Pour les fonctions SnapStart, le champ `Init Duration` se trouve dans l’enregistrement `INIT_REPORT`. Cet enregistrement indique les détails de la durée du [Phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib), y compris la durée de tout [hook d’exécution](snapstart-runtime-hooks.md) `beforeCheckpoint`.
+ **Journaux d’invocation** – Lorsqu’un nouvel environnement d’exécution est créé, le `REPORT` inclut les champs `Restore Duration` et `Billed Restore Duration` :
+ `Restore Duration` : le temps nécessaire à Lambda pour restaurer un instantané, charger l’exécution et exécuter les éventuels [hooks d’exécution](snapstart-runtime-hooks.md) après restauration. Le processus de restauration des instantanés peut inclure du temps consacré à des activités en dehors de la MicroVM. Ce temps est indiqué dans `Restore Duration`.
+ `Billed Restore Duration` : le temps nécessaire à Lambda pour charger l’exécution et exécuter les éventuels [hooks d’exécution](snapstart-runtime-hooks.md) après restauration.
**Note**
Comme pour toutes les fonctions Lambda, des frais de durée s’appliquent au code exécuté dans le gestionnaire de fonctions. Pour les fonctions SnapStart, les frais de durée s’appliquent également au code d’initialisation déclaré en dehors du gestionnaire, au temps de chargement de l’environnement d’exécution et à tout code s’exécutant dans un [hook d’exécution](snapstart-runtime-hooks.md).
La durée du démarrage à froid est la somme de `Restore Duration` \$1 `Duration`.
L’exemple suivant est une demande Lambda Insights qui renvoie les percentiles de latence pour les fonctions SnapStart. Pour plus d’informations sur les demandes Lambda Insights, consultez [Exemple de flux de travail utilisant des demandes pour dépanner une fonction](monitoring-insights.md#monitoring-insights-queries).
```
filter @type = "REPORT"
| parse @log /\d+:\/aws\/lambda\/(?.*)/
| parse @message /Restore Duration: (?.*?) ms/
| stats
count(*) as invocations,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as p50,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as p90,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99) as p99,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99.9) as p99.9
group by function, (ispresent(@initDuration) or ispresent(restoreDuration)) as coldstart
| sort by coldstart desc
```
## Suivi actif de X-Ray pour SnapStart
Vous pouvez utiliser [X-Ray](services-xray.md) pour suivre les demandes adressées aux fonctions Lambda SnapStart. Il existe quelques différences avec les sous-segments X-Ray pour les fonctions SnapStart :
+ Il n’existe aucun sous-segment `Initialization` pour les fonctions SnapStart.
+ Le sous-segment `Restore` indique le temps nécessaire à Lambda pour restaurer un instantané, charger l’exécution et exécuter les éventuels [hooks d’exécution](snapstart-runtime-hooks.md) après restauration. Le processus de restauration des instantanés peut inclure du temps consacré à des activités en dehors de la MicroVM. Cette heure est indiquée dans le sous-segment `Restore`. Le temps passé en dehors de la microVM pour restaurer un instantané ne vous est pas facturé.
## Événements de l’API de télémétrie pour SnapStart
Lambda envoie les événements SnapStart suivants à [API de télémétrie](telemetry-api.md) :
+ [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart) – Indique l’heure à laquelle la [phase `Restore` a commencé](lambda-runtime-environment.md#runtimes-lifecycle-restore).
+ [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone) – Indique si la phase `Restore` a réussi. Lambda envoie ce message lorsque l’environnement d’exécution envoie une demande d’API d’exécution `restore/next`. Il existe trois statuts possibles : succès, échec et dépassement de délai.
+ [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport) – Indique la durée de la phase `Restore` et le nombre de millisecondes pour lesquelles vous avez été facturé pendant cette phase.
## Métriques de l’URL de la fonction et de l’Amazon API Gateway
Si vous créez une API Web [à l’aide d’API Gateway](services-apigateway.md), vous pouvez utiliser la métrique [IntegrationLatency](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html) pour mesurer la latence de bout en bout (le temps entre le moment où API Gateway relaie une demande au backend et celui où il reçoit une réponse du backend).
Si vous utilisez une [URL de la fonction Lambda](urls-configuration.md), vous pouvez utiliser la métrique [UrlRequestLatency](urls-monitoring.md) pour mesurer la latence de bout en bout (le temps entre le moment où l’URL de la fonction reçoit une demande et celui où l’URL de la fonction renvoie une réponse).
# Modèle de sécurité pour Lambda SnapStart
Lambda SnapStart prend en charge le chiffrement au repos. Lambda chiffre les instantanés avec un AWS KMS key. Par défaut, Lambda utilise une Clé gérée par AWS. Si ce comportement par défaut convient à votre flux, vous n'avez pas besoin de configurer autre chose. Sinon, vous pouvez utiliser l'option `--kms-key-arn` dans la commande [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) ou [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) pour fournir une clé AWS KMS gérée par le 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. Les clés gérés par le client entraînent des frais AWS KMS standard. Pour plus d’informations, consultez [Tarification d’AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
Lorsque vous supprimez une fonction ou une version de fonction SnapStart, toutes les demandes `Invoke` à cette fonction ou version de fonction échouent. Lambda supprime toutes les ressources associées aux instantanés supprimés, conformément au Règlement général sur la protection des données (RGPD).
# Maximisez les performances Lambda SnapStart
**Topics**
+ [Personnalisation de performances](#snapstart-tuning)
+ [Bonnes pratiques concernant le réseau](#snapstart-networking)
## Personnalisation de performances
Pour optimiser les avantages de SnapStart, tenez compte des recommandations d'optimisation du code suivantes pour votre environnement d'exécution.
**Note**
SnapStart fonctionne mieux lorsqu'il est utilisé avec des invocations de fonctions à grande échelle. Les fonctions qui sont rarement invoquées peuvent ne pas bénéficier des mêmes améliorations de performance.
### Java
Pour optimiser les avantages de SnapStart, nous vous recommandons de précharger les dépendances et d'initialiser les ressources qui contribuent à la latence de démarrage dans votre code d'initialisation plutôt que dans le gestionnaire de fonctions. Cela permet de déplacer la latence associée au chargement intensif de classes hors du chemin d'invocation, optimisant ainsi les performances de démarrage avec SnapStart.
Si vous ne pouvez pas précharger les dépendances ou les ressources pendant l’initialisation, nous vous recommandons de les précharger avec des invocations fictives. Pour ce faire, mettez à jour le code du gestionnaire de fonctions, comme indiqué dans l'exemple suivant, à partir de la [fonction pet store](https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/spring/pet-store) du GitHub référentiel AWS Labs.
```
private static SpringLambdaContainerHandler handler;
static {
try {
handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class);
// Use the onStartup method of the handler to register the custom filter
handler.onStartup(servletContext -> {
FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class);
registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*");
});
// Send a fake Amazon API Gateway request to the handler to load classes ahead of time
ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity();
identity.setApiKey("foo");
identity.setAccountId("foo");
identity.setAccessKey("foo");
AwsProxyRequestContext reqCtx = new AwsProxyRequestContext();
reqCtx.setPath("/pets");
reqCtx.setStage("default");
reqCtx.setAuthorizer(null);
reqCtx.setIdentity(identity);
AwsProxyRequest req = new AwsProxyRequest();
req.setHttpMethod("GET");
req.setPath("/pets");
req.setBody("");
req.setRequestContext(reqCtx);
Context ctx = new TestContext();
handler.proxy(req, ctx);
} catch (ContainerInitializationException e) {
// if we fail here. We re-throw the exception to force another cold start
e.printStackTrace();
throw new RuntimeException("Could not initialize Spring framework", e);
}
}
```
### Python
Pour en tirer le meilleur parti SnapStart, concentrez-vous sur l'organisation efficace du code et la gestion des ressources au sein de vos fonctions Python. De manière générale, effectuez les tâches de calcul intensives pendant la [phase d’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib). Cette approche élimine les opérations fastidieuses du processus d’invocation, améliorant ainsi les performances globales des fonctions. Pour implémenter cette stratégie de manière efficace, nous vous recommandons les bonnes pratiques suivantes :
+ Importez les dépendances en dehors du gestionnaire de fonction.
+ Créez des instances `boto3` en dehors du gestionnaire.
+ Initialisez les ressources ou les configurations statiques avant que le gestionnaire ne soit invoqué.
+ Envisagez d’utiliser un [hook d’exécution](snapstart-runtime-hooks-python.md) avant l’instantané pour les tâches gourmandes en ressources, comme le téléchargement de fichiers externes, le préchargement de frameworks tels que Django ou le chargement de modèles de machine learning.
**Example — Optimise la fonction Python pour SnapStart**
```
# Import all dependencies outside of Lambda handler
from snapshot_restore_py import register_before_snapshot
import boto3
import pandas
import pydantic
# Create S3 and SSM clients outside of Lambda handler
s3_client = boto3.client("s3")
# Register the function to be called before snapshot
@register_before_snapshot
def download_llm_models():
# Download an object from S3 and save to tmp
# This files will persist in this snapshot
with open('/tmp/FILE_NAME', 'wb') as f:
s3_client.download_fileobj('amzn-s3-demo-bucket', 'OBJECT_NAME', f)
...
def lambda_handler(event, context):
...
```
### .NET
Pour réduire le temps de compilation just-in-time (JIT) et de chargement de l'assemblage, pensez à appeler votre gestionnaire de fonctions à partir `RegisterBeforeCheckpoint` [d'un hook d'exécution](snapstart-runtime-hooks-dotnet.md). En raison du fonctionnement de la compilation par niveau .NET, vous obtiendrez des résultats optimaux en invoquant le gestionnaire plusieurs fois, comme dans l’exemple suivant.
**Important**
Assurez-vous que l’invocation de votre fonction fictive ne produit pas d’effets secondaires imprévus, tels que le lancement de transactions commerciales.
**Example**
```
public class Function
{
public Function()
{
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(FunctionWarmup);
}
// Warmup method that calls the function handler before snapshot to warm up the .NET code and runtime.
// This speeds up future cold starts after restoring from a snapshot.
private async ValueTask FunctionWarmup()
{
var request = new APIGatewayProxyRequest
{
Path = "/heathcheck",
HttpMethod = "GET"
};
for (var i = 0; i < 10; i++)
{
await FunctionHandler(request, null);
}
}
public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
//
// Process HTTP request
//
var response = new APIGatewayProxyResponse
{
StatusCode = 200
};
return await Task.FromResult(response);
}
}
```
## Bonnes pratiques concernant le réseau
L’état des connexions que votre fonction établit pendant la phase d’initialisation n’est pas garanti lorsque Lambda reprend votre fonction à partir d’un instantané. Dans la plupart des cas, les connexions réseau établies par un AWS SDK reprennent automatiquement. Pour les autres connexions, nous vous recommandons les bonnes pratiques suivantes.
**Rétablissez les connexions réseau**
Rétablissez toujours vos connexions réseau lorsque votre fonction reprend à partir d’un instantané. Nous vous recommandons de rétablir les connexions réseau dans le gestionnaire de fonction. Vous pouvez également utiliser un [hook d’exécution](snapstart-runtime-hooks.md) après la restauration.
**N’utilisez pas le nom d’hôte comme identifiant unique d’environnement d’exécution**
Nous vous déconseillons d’utiliser `hostname` pour identifier votre environnement d’exécution comme un nœud ou un conteneur unique dans vos applications. Avec SnapStart, un seul instantané est utilisé comme état initial pour plusieurs environnements d'exécution. Tous les environnements d’exécution renvoient la même valeur `hostname` pour `InetAddress.getLocalHost()` (Java), `socket.gethostname()` (Python) et `Dns.GetHostName()` (.NET). Pour les applications qui nécessitent une identité ou une valeur `hostname` d’environnement d’exécution unique, nous vous recommandons de générer un identifiant unique dans le gestionnaire de fonction. Ou bien, utilisez un [hook d’exécution](snapstart-runtime-hooks.md) après la restauration pour générer un ID unique, puis utilisez cet ID unique comme identifiant de l’environnement d’exécution.
**Évitez de lier les connexions à des ports source fixes**
Nous vous recommandons d’éviter de lier les connexions réseau à des ports source fixes. Les connexions sont rétablies lorsqu’une fonction reprend à partir d’un instantané, et les connexions réseau qui sont liées à un port source fixe peuvent échouer.
**Évitez d’utiliser le cache DNS de Java**
Les fonctions Lambda mettent déjà en cache les réponses DNS. Si vous utilisez un autre cache DNS avec SnapStart, vous risquez de rencontrer des délais de connexion lorsque la fonction reprend à partir d'un instantané.
La classe `java.util.logging.Logger` peut activer indirectement le cache DNS de la JVM. Pour remplacer les paramètres par défaut, définissez [networkaddress.cache.ttl](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/InetAddress.html#inetaddress-caching-heading) sur 0 avant de procéder à l’initialisation de `logger`. Exemple :
```
public class MyHandler {
// first set TTL property
static{
java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
}
// then instantiate logger
var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class);
}
```
Pour éviter les échecs `UnknownHostException` de l’environnement d’exécution de Java 11, nous vous recommandons de définir la valeur de `networkaddress.cache.negative.ttl` sur 0. Dans les environnements d’exécution de Java 17 et versions ultérieures, cette étape n’est pas nécessaire. Vous pouvez définir cette propriété pour une fonction Lambda à l’aide de la variable d’environnement `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0`.
La désactivation du cache DNS de la JVM ne désactive pas la mise en cache DNS gérée par Lambda.
# Résolution des SnapStart erreurs liées aux fonctions Lambda
Cette page aborde les problèmes courants qui se produisent lors de l'utilisation de Lambda SnapStart, notamment les erreurs de création de snapshots, les erreurs de délai d'expiration et les erreurs de service internes.
## SnapStartNotReadyException
**Erreur :** une erreur s'est produite (SnapStartNotReadyException) lors de l'appel de l'opération Invoke20150331 : Lambda initialise votre fonction. L’invocation sera possible une fois que l’état de votre fonction deviendra ACTIVE.
### Causes courantes
Cette erreur se produit lorsque vous essayez d’invoquer une version de fonction qui se trouve à l’[état](snapstart-activate.md#snapstart-function-states) `Inactive`. La version de votre fonction devient `Inactive` lorsqu’elle n’a pas été invoquée depuis 14 jours ou lorsque Lambda recycle périodiquement l’environnement d’exécution.
### Résolution
Attendez que la fonction version atteigne l’état `Active`, puis invoquez-la à nouveau.
## SnapStartTimeoutException
**Problème :** vous recevez un `SnapStartTimeoutException` lorsque vous essayez d'invoquer une version de SnapStart fonction.
### Cause courante
Pendant la phase de [restauration](lambda-runtime-environment.md#runtimes-lifecycle-restore), Lambda restaure l’environnement d’exécution Java et exécute tous les [hooks d’exécution](snapstart-runtime-hooks.md) après la restauration. Si un hook d’exécution après la restauration s’exécute pendant plus de 10 secondes, la phase `Restore` expire et vous obtenez une erreur lorsque vous essayez d’invoquer la fonction. Les problèmes de connexion réseau et d’identification peuvent également entraîner des délais d’attente de la phase `Restore`.
### Résolution
Consultez les CloudWatch journaux de la fonction pour détecter les erreurs de temporisation survenues pendant la phase de [restauration](lambda-runtime-environment.md#runtimes-lifecycle-restore). Assurez-vous que tous les hooks après restauration se terminent en moins de 10 secondes.
**Example CloudWatch journal**
```
{ "cause": "Lambda couldn't restore the snapshot within the timeout limit. (Service: Lambda, Status Code: 408, Request ID: 11a222c3-410f-427c-ab22-931d6bcbf4f2)", "error": "Lambda.SnapStartTimeoutException"}
```
## Erreur interne du service 500
**Erreur :** Lambda n’a pas pu créer de nouvel instantané car vous avez atteint votre limite de création d’instantanés simultanés.
### Cause courante
Une erreur 500 est une erreur interne au sein du service Lambda lui-même, plutôt qu’un problème lié à votre fonction ou à votre code. Ces erreurs sont souvent intermittentes.
### Résolution
Réessayez de publier la version de la fonction.
## 401 Accès non autorisé
**Erreur :** jeton de session ou clé d’en-tête incorrect
### Cause courante
Cette erreur se produit lors de l'utilisation du [AWS Systems Manager Parameter Store et de AWS Secrets Manager l'extension](with-secrets-manager.md) avec Lambda SnapStart.
### Résolution
Le AWS Systems Manager Parameter Store et AWS Secrets Manager son extension ne sont pas compatibles avec SnapStart. L'extension génère des informations d'identification avec lesquelles communiquer AWS Secrets Manager lors de l'initialisation de la fonction, ce qui provoque des erreurs d'identification expirées lorsqu'elle est utilisée avec. SnapStart
## UnknownHostException (Java)
**Erreur :** impossible d’exécuter la requête HTTP : le certificat pour `abc.us-east-1.amazonaws.com` ne correspond à aucun des noms alternatifs d’objet.
### Cause courante
Les fonctions Lambda mettent déjà en cache les réponses DNS. Si vous utilisez un autre cache DNS avec SnapStart, vous risquez de rencontrer des délais de connexion lorsque la fonction reprend à partir d'un instantané.
### Résolution
Pour éviter les échecs `UnknownHostException` de l’environnement d’exécution de Java 11, nous vous recommandons de définir la valeur de `networkaddress.cache.negative.ttl` sur 0. Dans les environnements d’exécution de Java 17 et versions ultérieures, cette étape n’est pas nécessaire. Vous pouvez définir cette propriété pour une fonction Lambda à l’aide de la variable d’environnement `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0`.
## Échecs de création d’instantanés
**Erreur :** AWS Lambda impossible d'appeler votre SnapStart fonction. Si cette erreur persiste, consultez les CloudWatch journaux de votre fonction pour détecter les erreurs d'initialisation.
### Résolution
Consultez les CloudWatch journaux Amazon de votre fonction pour connaître les délais d'expiration du hook [d'exécution](snapstart-runtime-hooks.md) avant le point de contrôle. Vous pouvez également essayer de publier une nouvelle version de fonction, ce qui peut parfois résoudre le problème.
## Latence de création d’instantanés
**Problème :** lorsque vous publiez une nouvelle version de fonction, celle-ci reste à l’[état](snapstart-activate.md#snapstart-function-states) `Pending` pendant une longue période.
### Cause courante
Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le [délai d’expiration de la fonction configurée](configuration-timeout.md) (900 secondes au maximum), la valeur la plus élevée étant retenue.
Si votre fonction est [attachée à un VPC](configuration-vpc.md#configuration-vpc-attaching), Lambda devra peut-être également créer des interfaces réseau avant que la fonction ne devienne `Active`. Si vous essayez d’invoquer la version de la fonction alors que la fonction est `Pending`, vous pourriez obtenir une erreur 409 `ResourceConflictException`. Si la fonction est invoquée à l’aide d’un point de terminaison Amazon API Gateway, une erreur 500 peut s’afficher dans API Gateway.
### Résolution
Attendez au moins 15 minutes que la version de la fonction soit initialisée avant de l’invoquer.