Aller au contenu

AWS Mis à jour le 2026-07-04

Concurrence provisionnée : quand ça vaut la peine de payer pour sauter les démarrages à froid Lambda

La concurrence provisionnée élimine les démarrages à froid Lambda en gardant des environnements initialisés en attente — facturés que le trafic arrive ou non. La logique du point d'équilibre, la mise en place, et les cas où c'est de l'argent gaspillé.

La concurrence provisionnée garde un nombre choisi d’environnements d’exécution Lambda initialisés et en attente, si bien que les requêtes qui y atterrissent ne voient jamais de démarrage à froid. Le piège, c’est le modèle de facturation : vous payez la capacité provisionnée au Go-heure pour chaque heure où elle est configurée, qu’il arrive une requête ou un million. Ça en fait une décision économique franche — rentable pour du trafic synchrone sensible à la latence avec un plancher prévisible, du gaspillage pour les fonctions à faible volume et à pointes, et sans objet pour les charges asynchrones où personne ne sent le démarrage à froid.

Ce que vous décidez

Lambda à la demande initialise les environnements de façon réactive : le trafic arrive, les environnements démarrent, la première requête sur chacun mange le temps d’init. La concurrence provisionnée renverse ça en proactif : vous déclarez « garde N environnements chauds », Lambda roule la phase d’init d’avance, et les requêtes routées vers les environnements provisionnés commencent à s’exécuter immédiatement. Les requêtes au-delà de N débordent vers des environnements à la demande ordinaires — elles fonctionnent quand même, elles subissent juste un démarrage à froid, et elles apparaissent dans la métrique ProvisionedConcurrencySpilloverInvocations.

La structure de coût a deux parties. Vous payez un taux par Go-heure pour la capacité configurée, en continu. Les invocations qui roulent sur les environnements provisionnés sont ensuite facturées à la durée, à un taux par Go-seconde plus bas que la demande. La conséquence : à haute utilisation stable, la capacité provisionnée peut coûter à peu près pareil — ou moins — que l’usage à la demande équivalent, si bien que le gain de latence vient presque gratuitement. À basse utilisation, vous louez des chambres chaudes vides. Modélisez vos propres chiffres dans https://calculator.aws/ avant de vous engager; le point de croisement dépend de l’utilisation, de la taille de mémoire et de la région.

Deux détails opérationnels façonnent la décision. La concurrence provisionnée s’attache à une version publiée ou à un alias — jamais à $LATEST — donc elle impose une discipline de déploiement versionné (que vous devriez avoir de toute façon). Et elle peut être planifiée ou auto-ajustée via Application Auto Scaling, ce qui est la façon d’éviter de payer pour le creux de 3 h du matin.

Pesez aussi l’alternative qui n’existait pas au lancement de cette fonctionnalité : SnapStart couvre maintenant Java, Python et .NET, en reprenant d’un instantané plutôt qu’en gardant des environnements chauds. Il ne garantit pas zéro démarrage à froid, mais il coupe l’init à quelques centaines de millisecondes sans frais de capacité à l’heure — pour bien des charges, c’est assez bon et bien moins cher.

Quoi vérifier en premier

  • Si quelqu’un sent réellement les démarrages à froid. Synchrone, face à l’utilisateur, sensible à la latence : candidats. Consommateurs de files et pipelines d’événements : pas candidats, à aucun prix.
  • Le vrai taux de démarrage à froid et la durée d’init. Une init de 300 ms qui touche 0,4 % des requêtes justifie rarement une dépense fixe; une init de 4 s qui touche 5 % des requêtes d’une API de paiement, oui.
  • Le plancher de trafic. La concurrence provisionnée se rentabilise contre la portion stable du trafic. Lisez deux semaines de ConcurrentExecutions pour la fonction et trouvez le creux et le plateau.
  • Si vous déployez via des alias. Si tout roule sur $LATEST, c’est ça qui change en premier.

Comment vérifier

Établissez la base avant de dépenser. Fréquence des démarrages à froid et coût d’init, depuis Logs Insights :

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

La forme de la concurrence, depuis CloudWatch :

aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda --metric-name ConcurrentExecutions \
  --dimensions Name=FunctionName,Value=my-function \
  --start-time 2026-06-20T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 3600 --statistics Maximum Average

Après l’activation, surveillez les deux métriques qui notent le dimensionnement : ProvisionedConcurrencyUtilization (quelle part de ce que vous payez est utilisée) et ProvisionedConcurrencySpilloverInvocations (à quelle fréquence le trafic la dépasse). Les deux sont visibles sous Lambda > Functions > (fonction) > Monitor une fois configurées; la fonctionnalité elle-même est documentée à https://docs.aws.amazon.com/lambda/.

L’approche

  1. Qualifiez la fonction honnêtement. Elle doit être synchrone, sensible à la latence et mesurée — vous connaissez son taux de démarrage à froid, sa durée d’init et son plancher de concurrence. Si vous avez sauté la mesure, faites-la d’abord; la moitié du temps, les données tuent la demande.
  2. Publiez une version et routez par un alias. aws lambda publish-version --function-name my-function, puis pointez un alias comme live dessus. Les appelants invoquent l’alias.
  3. Dimensionnez au plateau, pas au sommet. Réglez la concurrence provisionnée à peu près à la concurrence de régime stable; laissez le débordement absorber les pointes. aws lambda put-provisioned-concurrency-config --function-name my-function --qualifier live --provisioned-concurrent-executions 25. Dimensionner au sommet, c’est comme ça que la facture double pour une latence que personne n’a mesurée.
  4. Planifiez la capacité pour suivre le trafic. Enregistrez l’alias auprès d’Application Auto Scaling et ajoutez des actions planifiées (heures d’affaires en haut, nuits et fins de semaine en bas) ou un suivi de cible à ~70 % de ProvisionedConcurrencyUtilization. Un réglage plat 24/7 n’est presque jamais la bonne forme.
  5. Câblez les déploiements pour déplacer la capacité. Chaque mise en production publie une nouvelle version; l’alias bouge, et la concurrence provisionnée doit le suivre — SAM, CDK et Terraform le soutiennent tous, et le déplacement graduel d’alias se marie naturellement avec les déploiements canaris via les crochets CodeDeploy.
  6. Revoyez l’utilisation après deux semaines. Sous ~40 % d’utilisation moyenne, réduisez ou remettez en question tout l’arrangement; un débordement soutenu pendant la fenêtre que vous payez pour protéger signifie que le plancher était trop bas.

Quand ce n’est pas la bonne approche

Charges asynchrones et pilotées par files : le démarrage à froid est invisible, donc la dépense n’achète rien. Environnements de développement et de pré-production : de la capacité chaude pour zéro utilisateur est un classique des audits de facture. Trafic rare et à pointes (une fonction qui monte à 200 pendant cinq minutes par jour) : la concurrence provisionnée planifiée pour la fenêtre connue peut fonctionner, mais si les pointes sont imprévisibles, les démarrages à froid de débordement domineront de toute façon. Et si la plainte de fond est une init de 4 secondes, couper l’init — paquet plus petit, SnapStart, imports paresseux — coûte moins cher que de louer un contournement.

Erreurs fréquentes

  • Attacher la concurrence provisionnée à une version, déployer une nouvelle version, et payer pour garder le vieux code au chaud pendant que tout le trafic démarre à froid sur le nouveau. Utilisez des alias et déplacez la capacité avec le déploiement.
  • Dimensionner au trafic de pointe et rouler des pourcentages d’utilisation à un chiffre pour toujours.
  • Oublier que la concurrence réservée et provisionnée interagit avec le bassin du compte — la capacité provisionnée compte contre la limite de concurrence régionale.
  • L’activer pour corriger une latence p99 qui s’avère être une dépendance lente, pas des démarrages à froid. La ventilation Logs Insights règle ça en dix minutes.

Garder le contrôle

  • Alarmez sur ProvisionedConcurrencyUtilization sous ~30 % pendant une semaine (payer pour de l’air) et sur un débordement soutenu (sous-provisionné).
  • Étiquetez la dépense de concurrence provisionnée et passez-la en revue dans la passe de coûts mensuelle avec les autres engagements fixes.
  • Refaites la mesure des démarrages à froid chaque trimestre; une cure de paquet ou l’adoption de SnapStart peut discrètement retirer la justification d’origine.
  • Gardez le développement et la pré-production à zéro concurrence provisionnée, par politique.

La concurrence provisionnée est la version honnête de tous les bidouillages de réchauffement : de la vraie capacité réservée, à un vrai prix, pour du trafic où la latence vaut du vrai argent — achetez-en là où cette phrase est vraie et nulle part ailleurs. 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.