Cold starts Lambda et leur impact sur la facture AWS

Hello ! C'est quoi ton runtime ? Java .NET ou Python/Node.js ? Les cold starts sont bien pires avec les JVM. Et tu es en VPC ?

Directement, t'as regardé la Provisioned Concurrency pour tes fonctions critiques ? Ça coûte un bras mais ça élimine quasiment les cold starts.

On est en Python. Et oui toutes nos lambdas sont dans un VPC pour accéder à des ressources internes. C'est ça qui doit faire mal, non ?

Ah oui, VPC + Python, c'est une combo connue pour les cold starts pénibles. Le temps que l'ENI s'attache à l'instance, ça prend du temps. Tu peux activer l'option `VPC Access` pour un démarrage plus rapide (prends quelques secondes pour l'activation)

Pense aussi à optimiser ton package de déploiement. Moins de libs, moins de code, plus rapide le chargement. Tu as une taille de package raisonnable ?

Le package est déjà hyper optimisé, on est sur du 20-30Mo max. `VPC Access` est déjà activé. Pour la Provisioned Concurrency on essaie d'éviter, ça coûte super cher sur la durée.

C'est quoi la mémoire allouée à tes fonctions ? Augmenter la RAM allouée peut aussi booster le CPU de la Lambda et donc accélérer le boot, même si ça augmente le coût par ms.

pour python, si tu as des imports coûteux, essaie de faire du lazy loading, genre n'importe pas tout au niveau global mais à l'intérieur de ta fonction handler quand c'est nécessaire. ça peut aider pas mal.

On est à 512MB de RAM, on a testé 1GB sur certaines fonctions mais sans effet révolutionnaire sur les cold starts. Le lazy loading c'est une bonne piste, faut que je refactorise un peu.

Le problème avec les VPC c'est aussi que si tu as pas mal de security groups ou des règles réseau complexes ça peut impacter le temps de démarrage de l'ENI. Simplifier l'infra réseau si possible.

Tu utilises EFS pour des dépendances partagées ou du code lourd ? Des fois EFS peut rajouter sa propre latence au démarrage, contre-productif pour les cold starts.

non pas d'efs. je vais regarder le lazy loading de plus près. et j'ai pas mal d'accès à rds et sqs dès le début du handler, ptete que les clients sont instanciés trop tôt.

C'est exactement ça, si tes clients RDS ou SQS sont dans le scope global, ils s'initialisent à chaque cold start. Mets-les hors du handler mais assure-toi qu'ils sont réutilisés pour les warm invocations.

Un pattern classique c'est d'initialiser les clients et les connexions DB dans le global scope mais de vérifier si l'objet existe déjà avant de le recréer pour les invocations suivantes.

Ok je vais refactoriser pour que les clients soient instanciés une seule fois au lieu d'à chaque fois. Ça semble être le gros point faible. Merci pour le coup de main !

Et pense à CloudWatch Lambda Insights pour avoir des métriques plus fines sur l'étape d'initialisation de ta fonction, ça t'aidera à identifier les vrais goulots d'étranglement.

j'ai réécrit les init de clients comme suggéré et les `init duration` dans insights ont bien baissé. la facture devrait suivre. pour les gros pics on mettra un peu de provisioned concurrency, ça sera moins cher que de laisser les cold starts s'envoler. thx à tous !