Mes factures Cloud sont trop élevées : Ce que je vois maintenant

Salut tout le monde, Jules Martin ici, de retour sur agntmax.com!

Aujourd’hui, je veux parler de quelque chose qui me tracasse, et probablement beaucoup d’entre vous, depuis environ un an : l’augmentation progressive des coûts de l’infrastructure cloud, en particulier en ce qui concerne les fonctions sans serveur. Nous avons tous été convaincus par le rêve du « payez pour ce que vous utilisez », et pendant longtemps, cela semblait être une réalité. Mais récemment, j’ai vu les factures augmenter, parfois de manière inexplicable, même lorsque les modèles de trafic semblent stables. C’est comme si nous étions grignotés par la même flexibilité que nous avions adoptée. Alors, explorons quelque chose de très spécifique et d’actualité : Dominer le Monstre Serverless : Dévoiler et Réduire les Coûts Cachés d’AWS Lambda.

Mon propre parcours dans ce domaine a commencé il y a environ six mois. Nous avons un microservice central qui gère l’authentification des utilisateurs et la gestion des sessions. Il est presque entièrement construit sur AWS Lambda, API Gateway, DynamoDB et Cognito. Pendant longtemps, les coûts étaient parfaitement prévisibles. Puis, l’été dernier, notre facture AWS pour ce service spécifique a augmenté d’environ 15 %. Pas de nouvelles fonctionnalités, pas de pics de trafic significatifs. J’ai d’abord attribué cela à une fluctuation saisonnière ou à un petit bug que je n’avais pas encore trouvé. Mais quand la facture du mois suivant est arrivée encore plus élevée, j’ai su que je devais enquêter. Ce n’était pas qu’un petit incident ; c’était une tendance, et cela nous coûtait de l’argent réel.

L’Illusion des Niveaux « Gratuits » et la Réalité des Invoications « Minuscules »

L’un des plus grands atouts des solutions sans serveur, surtout pour les startups ou les petites équipes, est le généreux niveau gratuit. Et il est généreux ! Un million d’invocations gratuites par mois pour Lambda, plus une quantité significative de temps de calcul. Le problème, c’est qu’à mesure que votre application grandit, ces « invocations » gratuites disparaissent plus vite qu’une part de pizza lors d’une rencontre tech. Ce qui est souvent négligé, ce sont le volume considérable d’invocations minuscules, apparemment insignifiantes, qui s’accumulent. Pensez aux tâches cron, aux vérifications de santé internes, ou même aux mécanismes de réessai d’autres services. Chacune de ces invocations compte.

Mon enquête sur notre service d’authentification a révélé précisément cela. Nous avions une fonction Lambda, appelons-la auth-token-refresher, conçue pour rafraîchir périodiquement les jetons de service internes. Elle était programmée pour s’exécuter toutes les cinq minutes. Ça paraît inoffensif, n’est-ce pas ? 288 invocations par jour. Multipliez cela par 30 jours, et vous obtenez 8 640 invocations par mois. Ajoutez nos environnements de développement, de staging et de production, et soudainement cela fait plus de 25 000 invocations juste pour une toute petite tâche de maintenance. Nous avions une douzaine de telles fonctions. Tout à coup, nos invocations « minuscules » n’étaient plus si petites.

Trouver les Coupables : Les Métriques CloudWatch sont Vos Meilleurs Amis

La première étape pour apprivoiser cette bête est de savoir où va votre argent. AWS CloudWatch est indispensable ici. Ne vous contentez pas de regarder le tableau de bord de facturation de haut niveau ; explorez les métriques spécifiques pour vos fonctions Lambda.

Voici sur quoi je me suis concentré :

1. Invocations : C’est la métrique la plus simple. Des comptes d’invocations élevés pour des fonctions qui ne gèrent pas le trafic utilisateur direct sont des indicateurs immédiats à surveiller.
2. Durée : Combien de temps chaque invocation fonctionne-t-elle ? Des durées plus longues signifient des coûts de calcul plus élevés.
3. Utilisation de la Mémoire : Vous sur-provisionnez-vous de la mémoire pour vos fonctions ? Vous payez pour ce que vous allouez, pas pour ce que vous utilisez.
4. Taux d’Erreur : Des taux d’erreur élevés peuvent conduire à des réessais, ce qui signifie plus d’invocations et des cycles de calcul gaspillés.

Pour notre auth-token-refresher, j’ai examiné sa métrique `Invocations`. Effectivement, elle fonctionnait comme sur des roulettes, toutes les cinq minutes. La durée était minimale, seulement environ 50 ms. Mais le volume énorme contribuait à notre coût global d’invocations.

Exemple Pratique 1 : Consolider et Planifier de Manière Plus Intelligente

La solution pour auth-token-refresher et plusieurs autres fonctions de maintenance similaires était étonnamment simple : la consolidation. Au lieu d’avoir des fonctions Lambda individuelles déclenchées par des événements CloudWatch (ou EventBridge de nos jours) sur des cycles séparés, j’ai créé un seul “Maintenance Runner” Lambda.

Ce “Maintenance Runner” est déclenché par une seule règle d’événement CloudWatch, disons, une fois par heure. À l’intérieur de ce runner, j’ai un simple dispatcher qui vérifie l’heure actuelle et exécute les tâches nécessaires. Par exemple :

import os
import datetime

def lambda_handler(event, context):
 current_hour = datetime.datetime.now().hour
 current_minute = datetime.datetime.now().minute

 # Tâche 1 : Rafraîchir le jeton d'authentification (était exécuté toutes les 5 min)
 if current_minute % 10 == 0: # Exécuter maintenant toutes les 10 minutes
 print("Exécution du rafraîchissement du jeton d'authentification...")
 # Appelez la logique de rafraîchissement de jeton réelle ou une autre fonction interne
 refresh_auth_token()

 # Tâche 2 : Nettoyer les anciens logs (était exécuté toutes les heures)
 if current_hour % 1 == 0 and current_minute == 0: # Exécuter au début de l'heure
 print("Exécution du nettoyage des logs...")
 cleanup_old_logs()

 # Tâche 3 : Vérifier l'état du service externe (était exécuté toutes les 30 min)
 if current_minute == 0 or current_minute == 30:
 print("Vérification de l'état du service externe...")
 check_external_service()

 return {
 'statusCode': 200,
 'body': 'Tâches de maintenance exécutées.'
 }

def refresh_auth_token():
 # ... logique de rafraîchissement de jeton réelle ...
 pass

def cleanup_old_logs():
 # ... logique de nettoyage des logs réelle ...
 pass

def check_external_service():
 # ... logique de vérification du service externe réelle ...
 pass

Ce simple changement a immédiatement réduit le nombre d’invocations pour ces tâches de maintenance de centaines de milliers par mois à quelques milliers. Les économies étaient tangibles, non seulement en ce qui concerne les invocations Lambda, mais aussi en ce qui concerne l’ingestion des logs CloudWatch et les appels API Gateway (si l’une de ces fonctions était exposée via API Gateway).

Le Piège de la Sur-Provision de Mémoire

C’est un autre moteur de coûts subtil qui est souvent négligé. Lorsque vous créez une fonction Lambda, vous allouez une certaine quantité de mémoire (par exemple, 128 Mo, 256 Mo, 512 Mo). Vous payez pour cette mémoire allouée, peu importe combien votre fonction utilise réellement. De plus, la puissance CPU évolue proportionnellement avec l’allocation de mémoire. Donc, si vous allouez 1 Go de mémoire pour un simple script Python qui n’a besoin que de 128 Mo, vous ne payez pas seulement trop pour la mémoire ; vous payez également trop pour les cycles CPU dont elle n’a pas besoin.

J’ai appris cela à mes dépens avec une fonction Lambda de traitement de données qui avait été initialement configurée avec 1 Go de mémoire « juste au cas où ». Lorsque j’ai examiné ses métriques CloudWatch pour l’utilisation de la mémoire, cela restait constamment en dessous de 200 Mo, même lors des charges de pointe. Nous payions essentiellement pour 800 Mo de RAM inutilisée et le surcoût correspondant pour le CPU.

Exemple Pratique 2 : Optimiser l’Allocation de Mémoire avec Lambda Power Tuning

Déterminer manuellement le réglage de mémoire optimal peut être fastidieux. Vous devez déployer, tester, surveiller, ajuster, et recommencer. Heureusement, il existe un excellent outil open-source appelé AWS Lambda Power Tuning (développé par Alex Casalboni chez AWS) qui facilite ce processus.

C’est une application sans serveur elle-même qui vous aide à visualiser et identifier le réglage de mémoire optimal pour vos fonctions Lambda en fonction des coûts et de la performance. Vous la déployez dans votre compte AWS, puis vous pouvez l’utiliser pour tester vos fonctions.

Voici comment cela fonctionne généralement :

1. Vous déployez l’outil Power Tuning via le Serverless Application Repository ou SAM.
2. Vous invoquez une machine d’état (créée par l’outil) avec l’ARN de votre fonction Lambda et un payload.
3. La machine d’état invoque votre Lambda plusieurs fois avec différentes configurations de mémoire (par exemple, 128 Mo, 256 Mo, 512 Mo, 1024 Mo, etc.).
4. Elle analyse ensuite les logs d’exécution et fournit une visualisation montrant les compromis de coûts et de vitesse pour chaque réglage de mémoire.

Pour ma fonction Lambda de traitement de données, le passage par le Power Tuner a montré que 256 Mo était le bon compromis en termes de coût, avec une dégradation de performance négligeable par rapport à 1 Go. Nous avons immédiatement réduit l’allocation de mémoire à 256 Mo, ce qui a entraîné une réduction de 75 % des coûts de calcul pour cette fonction spécifique. Ce n’était pas un cas isolé ; j’ai depuis fait de cette pratique une norme pour passer au crible les nouvelles fonctions ou celles réévaluées avec cet outil.

Pour l’utiliser, après le déploiement, vous commenceriez généralement la machine d’état avec quelque chose comme ceci (en ajustant ARN et payload):

aws stepfunctions start-execution \
 --state-machine-arn "arn:aws:states:REGION:ACCOUNT_ID:stateMachine:powerTuningStateMachine" \
 --input '{ "lambdaARN": "arn:aws:lambda:REGION:ACCOUNT_ID:function:YOUR_FUNCTION_NAME", "num": 100, "payload": {}, "parallel": 5 }'

La sortie fournit un graphique clair, montrant exactement où vos coûts et votre vitesse s’intersectent pour une performance optimale. C’est un changement significatif pour l’optimisation des coûts.

Verbositée des Logs et Démarrages à Froid

Deux autres domaines qui peuvent souvent vous surprendre sont la verbosité des logs et les démarrages à froid. Les logs CloudWatch ne sont pas gratuits. Chaque ligne que votre fonction Lambda imprime est ingérée et stockée, et vous payez pour ça. Bien qu’un bon logging soit crucial pour le débogage, un logging trop verbeux (par exemple, imprimer des objets entiers ou répéter des messages d’état inutilement) peut rapidement gonfler votre facture CloudWatch Logs.

J’ai trouvé quelques fonctions qui enregistraient le corps de la requête HTTP complet à chaque invocation. Bien que cela soit utile pour le développement initial, en production, c’était juste du bruit et un coût. Un rapide ajustement pour ne logger que les métadonnées essentielles (ID de requête, code d’état, point de terminaison) a réduit de manière significative notre ingestion de logs.

Les démarrages à froid, bien qu’ils ne soient pas un “coût” direct de la même manière, impactent l’expérience utilisateur et peuvent indirectement conduire à plus de tentatives ou à des durées de facturation plus longues si votre fonction doit attendre des ressources. Bien qu’AWS ait fait des progrès significatifs pour réduire les temps de démarrage à froid, optimiser la taille du bundle de votre fonction et éviter une logique d’initialisation complexe en dehors du gestionnaire peut toujours faire la différence. Pour les fonctions critiques et sensibles à la latence, la concurrence provisionnée est une option, mais sachez que vous payez pour cette concurrence allouée même lorsque celle-ci est inoccupée.

Exemple Pratique 3 : Journalisation Intelligente et Variables d’Environnement

Pour la journalisation, la solution la plus simple est souvent la meilleure. Utilisez des variables d’environnement pour contrôler les niveaux de journalisation. En Python, par exemple, vous pouvez faire ceci :

import os
import logging

LOG_LEVEL = os.environ.get('LOG_LEVEL', 'INFO').upper()
logging.basicConfig(level=LOG_LEVEL)
logger = logging.getLogger()

def lambda_handler(event, context):
 logger.debug("Ceci est un message de débogage, visible uniquement si LOG_LEVEL est DEBUG")
 logger.info("Traitement de l'événement : %s", event.get('request_id'))
 try:
 # ... logique de la fonction ...
 logger.debug("Traitement terminé pour request_id : %s", event.get('request_id'))
 return {
 'statusCode': 200,
 'body': 'Succès'
 }
 except Exception as e:
 logger.error("Erreur lors du traitement de request_id %s : %s", event.get('request_id'), str(e), exc_info=True)
 return {
 'statusCode': 500,
 'body': 'Erreur'
 }

En définissant LOG_LEVEL à INFO en production et à DEBUG en développement/staging, vous pouvez réduire considérablement votre facture CloudWatch Logs sans sacrifier l’observabilité lorsque vous en avez besoin.

Un autre conseil est de prêter attention à ce qui est initialisé en dehors du gestionnaire. Tout code directement dans le scope global de votre fonction Lambda sera exécuté lors du démarrage à froid. Si vous avez des opérations coûteuses comme le pool de connexions à la base de données ou de grandes importations de bibliothèques, envisagez de les différer jusqu’à ce qu’elles soient réellement nécessaires dans le gestionnaire, ou assurez-vous qu’elles sont efficacement mises en cache pour les invocations chaudes suivantes.

Actions À Entreprendre Pour Votre Lutte Contre les Coûts Serverless

D’accord, nous avons couvert pas mal de choses. Voici un résumé des étapes concrètes que vous pouvez entreprendre dès maintenant pour commencer à réduire ces coûts Lambda sournois :

• Surveillez sans relâche : Ne vous contentez pas de jeter un œil à votre facture AWS globale. Explorez les métriques CloudWatch pour les Invocations, la Durée et l’Utilisation de la Mémoire pour chaque fonction Lambda. Configurez des alarmes pour des pics inattendus.
• Consolidez les tâches cron : Si vous avez de nombreuses petites fonctions Lambda programmées, envisagez de les regrouper en un seul « Maintenance Runner » qui distribue des tâches selon un calendrier moins fréquent. Cela réduit considérablement le nombre d’invocations.
• Optimisez l’allocation de mémoire : Utilisez des outils comme AWS Lambda Power Tuning pour trouver le paramètre de mémoire optimal pour vos fonctions. Ne devinez pas et ne provisionnez pas trop. Rappelez-vous, plus de mémoire signifie plus de CPU, et vous payez pour les deux.
• Contrôlez la verbosité de la journalisation : Implémentez des niveaux de journalisation contrôlés par des variables d’environnement (par exemple, INFO pour la production, DEBUG pour le développement). Évitez de journaliser l’intégralité des corps de requête ou un état interne excessif en production. Votre facture CloudWatch Logs vous remerciera.
• Révisez les fonctions inutilisées : Auditez périodiquement vos fonctions Lambda. Y a-t-il des fonctions anciennes, expérimentales ou obsolètes encore actives et générant des coûts ? Supprimez-les !
• Surveillez la taille des paquets : Des paquets de déploiement plus petits signifient des démarrages à froid plus rapides et moins de coûts de stockage. Incluez uniquement les dépendances nécessaires.
• Comprenez votre modèle de tarification : Relisez la page de tarification Lambda. Comprenez comment les invocations, les GB-secondes et le transfert de données sont facturés. La connaissance est un atout, surtout quand il s’agit de votre portefeuille.

Dominer le monstre serverless ne consiste pas à éviter le serverless ; il s’agit d’être intelligent et intentionnel dans son utilisation. La flexibilité et l’évolutivité sont inestimables, mais sans vigilance appropriée, ces “petits” coûts peuvent s’accumuler et représenter une part importante de votre budget. Allez-y, surveillez, optimisez et économisez !

C’est tout pour moi aujourd’hui. faites-moi savoir dans les commentaires si vous avez d’autres conseils ou astuces pour l’optimisation des coûts Lambda !

🕒 Published: March 27, 2026