Le compromis : démarrage à froid contre capacité en attente
Un démarrage à froid peut dégrader l'expérience utilisateur : la première invocation d'une fonction attend la création de l'environnement d'exécution avant de traiter la demande. À l'inverse, maintenir de la capacité prête en permanence a un coût, y compris pendant qu'elle ne sert pas. C'est le compromis central que décrit la documentation AWS à propos de Provisioned Concurrency.
Provisioned Concurrency préinitialise des environnements d'exécution pour une fonction Lambda. L'objectif est de réduire le temps d'initialisation au moment de l'invocation, en particulier pour les charges sensibles à la latence. Il ne s'agit ni d'un réglage gratuit ni d'une garantie absolue : c'est une capacité réservée et facturée.
Ce que la facturation recouvre
La facturation de Provisioned Concurrency dépend en partie de la mémoire configurée, de la concurrence provisionnée et de la durée pendant laquelle elle est activée. S'y ajoutent les frais de requêtes et d'exécution habituels de Lambda. Autrement dit, le coût ne se limite pas à la capacité en attente : chaque invocation continue d'être facturée selon les règles standard.
Cette structure de coût impose un raisonnement en trois dimensions : combien de mémoire par environnement, combien d'environnements simultanés, et pendant combien de temps. Une capacité provisionnée en continu sur vingt-quatre heures n'a pas le même profil qu'une capacité activée quelques heures par jour. La documentation et la tarification AWS consultées le 24 septembre 2026 constituent la référence à vérifier, car les prix et les modalités peuvent évoluer.
Une garantie de latence partielle, pas de bout en bout
Provisioned Concurrency ne garantit pas la latence de bout en bout. Elle agit sur l'initialisation de l'environnement d'exécution, mais la base de données, le réseau et les dépendances externes restent sur le chemin critique. Une requête peut donc rester lente même avec des environnements préinitialisés, si un appel aval ralentit.
Par ailleurs, les invocations qui dépassent la capacité provisionnée peuvent être servies par la capacité à la demande. Dans ce cas, un démarrage à froid reste possible. La capacité provisionnée n'est donc pas un plafond d'absorption illimité : au-delà du niveau configuré, le comportement revient à celui d'une fonction Lambda classique.
Reserved Concurrency : un autre mécanisme
Il ne faut pas confondre Provisioned Concurrency et Reserved Concurrency. Reserved Concurrency réserve et plafonne la concurrence d'une fonction, sans préinitialiser d'environnements. Elle sert notamment à garantir qu'une fonction dispose d'un quota de concurrence et à l'empêcher de consommer tout le quota partagé du compte. Provisioned Concurrency, elle, vise le temps d'initialisation. Les deux mécanismes répondent à des problèmes différents et peuvent avoir des implications de coût distinctes.
Cinq étapes avant d'activer
Avant d'activer Provisioned Concurrency, plusieurs étapes permettent de fonder la décision. Premièrement, mesurer les latences p95 et p99, et la part de ces latences attribuable à l'initialisation. Deuxièmement, identifier les parcours utilisateurs sensibles à la latence et les heures qui comptent réellement. Troisièmement, dimensionner la capacité à partir de la concurrence observée, et non d'une intuition. Quatrièmement, suivre l'utilisation de la capacité provisionnée et les débordements vers la capacité à la demande. Cinquièmement, comparer le coût supplémentaire au nombre de requêtes qui atteignent effectivement l'objectif de latence.
Cette dernière comparaison est décisive : payer pour de la capacité provisionnée n'a de sens que si un volume suffisant de requêtes en bénéficie. Une capacité largement sous-utilisée ou un débordement fréquent signalent un dimensionnement à revoir.
Tous les traitements ne se valent pas
Un traitement asynchrone qui peut attendre quelques secondes ne se pose pas dans les mêmes termes qu'une interaction client critique. Pour un job de fond, le coût d'une capacité provisionnée permanente est difficile à justifier si l'utilisateur ne perçoit pas la latence. Pour une interaction client, l'arbitrage peut être différent.
Une approche possible, à titre d'illustration et non de recommandation universelle, consiste à activer Provisioned Concurrency uniquement pendant les pics, tout en travaillant sur l'optimisation de l'initialisation. Réduire le temps d'initialisation, par exemple en allégeant les dépendances ou en ajustant la mémoire, peut diminuer le besoin de capacité provisionnée. Ces pistes doivent être validées par des mesures propres à chaque fonction.
Décider sur des mesures avant et après
La décision doit reposer sur des mesures avant et après activation. Sans comparaison, il est difficile de savoir si la latence cible est atteinte, si la capacité est correctement dimensionnée et si le surcoût se traduit par un bénéfice mesurable. Les chiffres à suivre incluent les percentiles de latence, la part d'initialisation, l'utilisation de la capacité provisionnée, les débordements et le coût total.
La question à se poser reste donc : quel supplément est-on prêt à payer pour atteindre l'objectif de latence, et pour quelles heures ? La réponse dépend des parcours concernés, du volume de requêtes et de la tolérance à l'attente. Elle ne se déduit pas d'un réglage par défaut.
Le post à l’origine de cette analyse
Article développé à partir du post LinkedIn. Les liens ci-dessous sont ceux du post d’origine ; leur présence ne constitue pas une vérification indépendante.
LinkedIn ↗