Aller au contenu

AWS Mis à jour le 2026-07-04

Démarrages à froid Lambda : ce qui aide vraiment en 2026 (et ce qui relève du culte du cargo)

La plupart des conseils sur les démarrages à froid Lambda sont dépassés. Ce qui réduit vraiment la latence de démarrage à froid en 2026 — taille du paquet, discipline d'init, SnapStart, concurrence provisionnée — et quels trucs populaires ne font rien.

Un démarrage à froid, c’est le temps que Lambda passe à créer un nouvel environnement d’exécution et à rouler votre code d’initialisation avant que la première invocation puisse être servie. En 2026, ce qui le réduit vraiment : moins de code à charger, moins de travail dans la phase d’init, SnapStart pour Java, Python et .NET, et la concurrence provisionnée quand la latence compte réellement. Ce qui n’aide à peu près pas : les pings de réchauffement, éviter les VPC, et entasser les dépendances dans des layers. La moitié des conseils qui circulent encore datent de 2018 et relèvent maintenant du culte du cargo.

Ce qui se passe

Quand une requête arrive et qu’aucun environnement d’exécution inactif n’existe, Lambda en provisionne un : il télécharge votre paquet de déploiement ou votre image de conteneur, démarre le runtime et exécute tout ce qui est hors de votre handler — imports, construction de clients, code global. C’est la phase d’init, rapportée comme Init Duration dans la ligne REPORT du journal. Ensuite seulement, le handler s’exécute. Les requêtes suivantes réutilisent l’environnement chaud et sautent tout ça.

Deux faits encadrent chaque optimisation. Un, les démarrages à froid touchent un pourcentage des invocations, pas toutes — pour un trafic stable c’est souvent sous 1 %, et pour une fonction à trafic irrégulier ou faible, ça peut être la majorité. Optimiser les démarrages à froid avant de mesurer leur fréquence est prématuré. Deux, l’économie a changé : depuis août 2025, AWS facture la phase d’init pour les runtimes gérés sur les invocations à la demande, donc une init boursouflée n’est plus seulement un problème de latence — elle apparaît aussi sur la facture.

Le vilain historiquement célèbre a disparu. Les fonctions attachées à un VPC ajoutaient jadis des secondes de mise en place d’ENI par démarrage à froid; depuis la refonte des ENI Hyperplane en 2019, l’attachement VPC ajoute une surcharge négligeable. Quiconque vous dit de garder les fonctions hors des VPC « à cause des démarrages à froid » récite un correctif pour un problème qu’AWS a réglé il y a des années.

Quoi vérifier en premier

  • La fréquence réelle des démarrages à froid. Comptez les invocations avec un Init Duration par rapport au total. Si c’est 0,5 % d’un million d’invocations quotidiennes sur un pipeline asynchrone, arrêtez ici — personne n’attend après.
  • La taille réelle de votre init. Une init de 300 ms convient à presque tout. Une init de 4 secondes sur une API destinée aux clients est un vrai problème.
  • La taille du paquet de déploiement. Des centaines de mégaoctets de dépendances prennent du temps à récupérer et charger, et l’essentiel est habituellement du poids transitif inutilisé.
  • Ce qui s’exécute au moment de l’import. Les frameworks qui balaient le système de fichiers, les clients SDK construits d’avance, la configuration récupérée du réseau pendant l’import — tout ça atterrit dans Init Duration.

Comment vérifier

Mesurez avant de toucher à quoi que ce soit. Dans CloudWatch Logs Insights :

filter @type = "REPORT"
| stats count() as invocations,
        sum(strcontains(@message, "Init Duration")) as coldStarts,
        avg(@initDuration) as avgInitMs,
        pct(@initDuration, 95) as p95InitMs
  by bin(1h)

Vérifiez la taille du paquet et le runtime :

aws lambda get-function --function-name my-function \
  --query '{Runtime: Configuration.Runtime, CodeSize: Configuration.CodeSize, Arch: Configuration.Architectures}'

Dans la console, Lambda > Functions > (fonction) > Monitor montre les percentiles de durée; les démarrages à froid apparaissent comme la queue lente. La mécanique du cycle de vie est documentée à https://docs.aws.amazon.com/lambda/.

L’approche

  1. Coupez d’abord dans le paquet de déploiement. Élaguez les dépendances de développement, faites du tree-shaking ou du bundling (esbuild pour Node.js fait un travail spectaculaire ici), et retirez les sous-clients SDK que vous n’appelez jamais. C’est le gain le moins cher et il aide chaque démarrage à froid sur chaque runtime.
  2. Sortez le travail optionnel de l’init — et rentrez-y le travail obligatoire. Importez paresseusement les bibliothèques lourdes utilisées sur des chemins de code rares. À l’inverse, construisez les choses à faire une fois par environnement (clients SDK, mise en place de connexions) dans l’init plutôt qu’à chaque invocation. Vous budgétez où les millisecondes arrivent, vous ne les éliminez pas.
  3. Activez SnapStart si vous roulez Java, Python ou .NET. SnapStart prend un instantané de l’environnement initialisé et reprend à partir de lui, coupant régulièrement des inits de plusieurs secondes à quelques centaines de millisecondes. C’est gratuit pour Java; Python et .NET portent des frais de cache et de restauration, alors pesez-le contre la concurrence provisionnée selon la forme de votre trafic.
  4. Utilisez la concurrence provisionnée pour les chemins synchrones critiques en latence. Elle garde des environnements initialisés en attente, éliminant complètement les démarrages à froid pour la capacité provisionnée — à un coût qui court, trafic ou pas. L’analyse du point d’équilibre est dans Concurrence provisionnée : quand ça vaut la peine de payer.
  5. Considérez arm64. Graviton est d’abord un jeu de rapport prix-performance, pas un jeu de démarrage à froid, mais du calcul plus rapide et moins cher ne nuit jamais, et la migration pour la plupart des charges interprétées est un changement d’une ligne plus une passe de tests.

Quand ce n’est pas la bonne approche

Si la fonction est asynchrone — consommateurs de files, processeurs d’événements, jobs planifiées — personne ne subit le démarrage à froid, et chaque heure passée à le raboter est gaspillée. Si la latence p99 compte au point que même 200 ms d’init sont inacceptables, Lambda est peut-être carrément la mauvaise couche de calcul; un petit conteneur toujours actif derrière un ALB n’a pas de démarrages à froid à combattre. Ne contorsionnez pas votre architecture pour corriger une propriété qu’un autre service n’a tout simplement pas.

Erreurs fréquentes

  • Les pings de réchauffement. Un événement planifié aux 5 minutes garde exactement un environnement chaud. Dès que deux requêtes concurrentes arrivent, la deuxième subit quand même un démarrage à froid. La concurrence provisionnée existe parce que ce truc ne passe pas à l’échelle; en 2026, c’est du pur culte du cargo pour tout ce qui a une concurrence supérieure à un.
  • Déplacer les dépendances dans des layers pour « corriger » les démarrages à froid. Les layers changent comment le code est empaqueté et partagé, pas la quantité qui se charge — les octets décompressés sont identiques et le temps d’init aussi.
  • Monter la mémoire uniquement pour les démarrages à froid. Plus de mémoire achète effectivement plus de CPU pour l’init, et ça aide un peu les initialisations lourdes en CPU — mais c’est un instrument brutal, facturé en permanence, pour ce qui est habituellement un problème de taille de code.
  • Optimiser avant de mesurer. Des équipes brûlent régulièrement un sprint sur une fonction dont le taux de démarrage à froid s’avère être 0,3 %.

Garder le contrôle

  • Suivez le p95 d’Init Duration par fonction dans vos tableaux de bord; alertez quand un déploiement le double, parce que c’est presque toujours une dépendance accidentelle.
  • Faites de la taille du bundle une vérification en CI — échouez le build quand le paquet dépasse un seuil que vous avez choisi délibérément.
  • Relancez la requête de fréquence des démarrages à froid après un changement de patron de trafic; une fonction passée d’un trafic stable à un trafic irrégulier change de catégorie.
  • Revisitez les décisions SnapStart et concurrence provisionnée chaque année; la tarification et le soutien des runtimes ont bougé plus d’une fois.

Les démarrages à froid sont un problème d’ingénierie mesurable et borné, pas une propriété mystique du serverless — mesurez la fréquence, budgétez l’init, et ne payez pour de la capacité préchauffée que là où les utilisateurs peuvent sentir la différence. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.