Un warm start est une invocation servie par un environnement d'exécution que Lambda a déjà initialisé : code chargé, variables globales en place, connexions ouvertes, aucune phase d'init sur le chemin de la requête. Garder une fonction chaude revient donc à contrôler combien d'environnements pré-initialisés existent quand le trafic arrive. Un ping planifié en maintient exactement un, la provisioned concurrency en réserve autant que vous en payez, et SnapStart restaure des snapshots sur les runtimes compatibles. Nous mesurons d'abord, allégeons le bundle ensuite, et ne payons que pour les parcours où la latence coûte de l'argent.
Qu'est-ce qui survit réellement entre deux invocations Lambda ?
Tout ce qui est initialisé hors du handler survit : variables globales, clients SDK, connexions base de données ouvertes et le système de fichiers /tmp. Quand Lambda route une requête vers un environnement existant, le handler démarre immédiatement avec cet état intact. Voilà le warm start : la phase d'init, démarrage du runtime plus votre code de niveau module, ne touche jamais la requête.
L'écart de latence justifie l'attention. Une invocation chaude ajoute typiquement quelques millisecondes de surcoût plateforme, quand un cold start va de moins de cent millisecondes pour une fonction Node.js légère à plusieurs secondes pour une fonction Java lourde ou mal bundlée (ordres de grandeur toujours observés en 2026 ; votre runtime et votre graphe de dépendances dominent). La documentation du cycle de vie des environnements d'exécution décrit précisément les phases ; à retenir : un cold start n'est rien d'autre qu'une init qui atterrit sur la requête d'un utilisateur.
Combien de temps AWS garde-t-il un environnement chaud ?
Il n'existe aucune réponse contractuelle, et tout chiffre exact lu en ligne relève du folklore. AWS conserve les environnements inactifs pendant une durée qui se compte en minutes plutôt qu'en heures, ajustée selon la mémoire, le trafic et sa gestion interne de capacité. Planifiez comme si la réutilisation était probable à court terme et jamais garantie.
Deux conséquences. D'abord, les environnements sont aussi recyclés périodiquement, même sous charge continue : la chaleur est une optimisation dont vous bénéficiez, pas un état que vous possédez, et chaque déploiement, montée en charge ou mise à jour de runtime crée des environnements neufs qui feront un cold start. Ensuite, tout ce que vous mettez en cache dans les globales doit tolérer de disparaître à tout moment, et tout ce qui vit longtemps, les connexions base de données en tête, doit être validé ou rétabli dans le handler plutôt que présumé vivant.
Les pings de réchauffage EventBridge fonctionnent-ils vraiment ?
Partiellement, et ce mot porte toute la réponse. Une règle planifiée qui invoque votre fonction toutes les quelques minutes garde exactement un environnement d'exécution chaud. Dès que deux requêtes arrivent en même temps, la seconde fait un cold start, car un environnement ne sert qu'une requête à la fois. Le ping règle la démo mono-utilisateur, pas le p99 de production.
Cela reste un outil raisonnable pour les services internes à faible trafic : un backoffice d'administration, un endpoint de reporting, tout ce dont la concurrence dépasse rarement un et où un cold start occasionnel est acceptable. Faites sortir le handler immédiatement sur le payload de ping pour ne payer que des millisecondes, et suivez le guide des règles planifiées EventBridge pour le câblage :
# Une règle, un ping : exactement un environnement reste chaud
aws events put-rule \
--name warm-reporting-fn \
--schedule-expression "rate(5 minutes)"
aws events put-targets \
--rule warm-reporting-fn \
--targets '[{
"Id": "warm-1",
"Arn": "arn:aws:lambda:eu-west-3:123456789012:function:reporting",
"Input": "{\"warmer\": true}"
}]'Votre p99 est dominé par des cold starts que vous n'avez jamais vraiment mesurés ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Qu'apporte réellement la provisioned concurrency ?
La provisioned concurrency demande à Lambda de maintenir N environnements entièrement initialisés avant l'arrivée des requêtes, configurée sur une version publiée ou un alias, jamais sur $LATEST. Les requêtes dans cette limite sautent l'init ; au-delà, le trafic déborde vers des environnements à la demande qui font un cold start normal. C'est le seul mécanisme qui supprime les cold starts sous vraie concurrence.
Le modèle de coût est la partie à comprendre avant de signer. Vous payez un tarif horaire pour chaque environnement réservé, invoqué ou non, plus un tarif de durée réduit quand ils servent des requêtes ; les chiffres exacts vivent sur la page de tarification Lambda. Payer de la capacité inactive toute la nuit est le gaspillage classique, d'où l'association avec Application Auto Scaling décrite dans la documentation de la provisioned concurrency : des actions planifiées montent le compte avant les heures ouvrées et le redescendent la nuit, et un target tracking autour de 70 % d'utilisation absorbe le reste.
SnapStart est-il l'alternative moins chère ?
Parfois. SnapStart capture un instantané d'un environnement initialisé et le restaure à la demande au lieu de rejouer l'init, ce qui réduit fortement la latence de cold start sur les runtimes compatibles. Java en bénéficie largement sans surcoût ; Python et .NET ont suivi avec des frais de cache et de restauration. Rien d'annoncé pour Node.js à août 2026 : vérifiez la documentation à jour.
Les contraintes comptent autant que le gain. SnapStart ne s'applique qu'aux versions publiées, est mutuellement exclusif avec la provisioned concurrency sur une même fonction, plafonne le stockage éphémère, et réutilise un même snapshot pour de nombreuses restaurations : identifiants uniques, credentials et connexions réseau doivent être créés dans le handler, pas pendant l'init. La restauration est rapide mais pas gratuite ; mesurez avant de la supposer équivalente à un environnement chaud. Les détails sont dans la documentation SnapStart.
Comment forcer un cold start pour vos tests ?
Modifiez la configuration de la fonction ou publiez une nouvelle version : Lambda retire les environnements existants et en crée de nouveaux, donc l'invocation suivante est froide à coup sûr. Mettre à jour une variable d'environnement jetable est le déclencheur le moins cher. C'est ainsi qu'on mesure les cold starts délibérément, au lieu d'attendre qu'un apparaisse en production.
# Chaque changement de configuration crée des environnements neufs
aws lambda update-function-configuration \
--function-name reporting \
--environment "Variables={COLD_MARKER=$(date +%s)}"Invoquez ensuite et lisez la ligne REPORT dans CloudWatch Logs : Init Duration n'apparaît que sur les invocations froides et représente le chiffre que votre budget de latence doit absorber. Répétez le cycle forcer-invoquer assez de fois pour obtenir une distribution, pas un échantillon unique ; cette distribution, pondérée par la fréquence réelle des cold starts en trafic vivant, est votre vérité p99.
Quelle option mérite votre budget ?
Mesurer d'abord, dépenser en dernier. Extrayez Init Duration de vos lignes REPORT, pondérez par la fréquence à laquelle les cold starts touchent réellement des utilisateurs, puis épuisez les corrections gratuites avant les payantes. Le bon premier geste est le plus souvent un bundle plus petit et une initialisation paresseuse, traités dans notre guide de réduction des cold starts, pas une ligne de facture mensuelle.
| Approche | Ce qu'elle corrige | Coût | Limites |
|---|---|---|---|
| Ping de réchauffage (EventBridge) | Les cold starts pour un seul utilisateur concurrent | Quasi nul : quelques invocations par heure | Garde exactement un environnement chaud ; une concurrence de N cold-starte quand même |
| Provisioned concurrency | Les cold starts jusqu'au compte provisionné, tout runtime | Tarif horaire par environnement réservé, utilisé ou non, plus tarif de durée réduit | Versions et alias uniquement ; coût à vide ; exige un auto scaling qui suit le trafic |
| SnapStart | Le temps d'init sur les runtimes compatibles (Java, Python, .NET) | Sans surcoût sur Java ; frais de cache et de restauration sur Python et .NET | Versions publiées uniquement ; exclusif avec la provisioned concurrency ; restauration rapide, pas nulle |
| Optimisation du bundle | La durée d'init elle-même, pour chaque environnement | Du temps d'ingénierie uniquement | Réduit les cold starts, ne les supprime jamais |
Réservez les options payantes aux parcours utilisateurs où la latence est critique : paiement, authentification, recherche instantanée. Les consommateurs de files et les traitements batch se moquent d'une seconde d'init. Pour un second regard sur cet arbitrage, c'est exactement l'objet de notre service d'optimisation des performances.
Checklist warm start
- Lire
Init Durationdans les lignesREPORTavant de changer quoi que ce soit. - Forcer des cold starts par un changement de configuration pour mesurer une distribution, pas une anecdote.
- Réduire le bundle et charger paresseusement les dépendances lourdes en premier.
- N'utiliser les pings de réchauffage que là où la concurrence dépasse rarement un.
- Poser la provisioned concurrency sur des alias, avec auto scaling planifié, sur les parcours utilisateurs seulement.
- Évaluer SnapStart avant la provisioned concurrency sur Java, Python et .NET.
- Revalider les connexions dans le handler : les environnements meurent sans préavis.