Optimisation des coûts AWS Lambda : pourquoi le réglage le moins cher n'est pas le plus petit

La facture de ce genre de service cloud est facile à ignorer, jusqu’au jour où elle ne l’est plus. Vous ne payez que lorsque votre code tourne vraiment, quelques centièmes de centime à la fois, et pendant un moment le total reste assez petit pour que personne n’y regarde. Puis le trafic monte, deux ou trois habitudes s’accumulent, et le montant mensuel double sans bruit. C’est tout l’univers d’AWS Lambda, le service d’Amazon qui exécute de petits bouts de code à la demande et ne facture qu’à l’usage : vous confiez votre code à Amazon, il le lance dès que quelque chose le déclenche, et il n’y a aucun serveur à louer au mois. L’intérêt saute aux yeux. Le piège, c’est que la facture se construit à partir d’une poignée de lignes que presque personne ne lit, et l’une d’elles se comporte à l’envers de ce que dicte l’intuition.

La page produit d’AWS Lambda : un calcul facturé à l’usage, uniquement pendant que votre code s’exécute.

D’où part vraiment l’argent

Une facture Lambda ne compte que quelques lignes qui bougent réellement. La plus grosse, c’est le calcul : le temps que passe votre code à tourner, facturé à la fraction de seconde et multiplié par la quantité de mémoire que vous lui avez accordée. L’unité d’Amazon pour ça s’appelle le Go-seconde, c’est-à-dire simplement la mémoire multipliée par la durée, rien de plus mystérieux. La deuxième ligne est un forfait par requête, un péage fixe de quelques centimes par million d’appels que vous ne ferez quasiment jamais baisser sans réduire le trafic lui-même. La troisième est celle qui se cache : les journaux que votre code écrit à chaque exécution, facturés sous un poste à part et, par défaut, conservés indéfiniment.

La page de tarification d’AWS Lambda : les compteurs par appel et par Go-seconde qui forment l’essentiel de la facture.

Bon à savoir avant de s’inquiéter : Amazon offre une tranche d’usage chaque mois. Le premier million de requêtes et une part généreuse de temps de calcul ne coûtent rien, si bien qu’un petit projet peut ne rien devoir tant qu’il n’a pas grandi jusqu’au seuil payant.

Pourquoi un réglage plus gros peut coûter moins cher

Voici le passage qui surprend presque tout le monde. La quantité de mémoire que vous donnez à une fonction, c’est aussi la puissance de calcul qu’elle reçoit. Demandez plus de mémoire et Amazon offre à votre code une part de processeur plus rapide. Comme la facture, c’est la mémoire multipliée par le temps, une fonction réglée trop bas peut tourner si lentement qu’elle finit par coûter plus cher que la même fonction dotée de plus de puissance, qui boucle en une fraction du temps. Affamez-la et elle rampe : le réglage qui semble bon marché gagne sur le papier et perd sur la facture.

Un petit exemple rend la chose concrète. Imaginez une fonction au réglage de mémoire le plus bas, qui met une seconde entière à faire son travail, et la même fonction avec quatre fois plus de mémoire, qui boucle en un quart de seconde. Vous payez désormais quatre fois le tarif, mais pour un quart du temps, si bien que les deux factures tombent à peu près au même endroit — sauf que la plus grosse termine presque instantanément et que l’utilisateur n’attend jamais. Poussez encore le curseur et le calcul bascule souvent franchement de l’autre côté : quelque part au milieu, la vitesse gagnée paie largement le tarif plus élevé, et la facture totale finit par baisser. Le réglage à l’os n’a jamais été la bonne affaire qu’il semblait être.

Il existe un point idéal sur cette courbe, et ce n’est presque jamais le plus petit réglage. Ce n’est pas non plus le plus gros, où vous payez pour une puissance que le code n’arrive pas à exploiter. La seule façon honnête de le trouver, c’est de faire tourner la même fonction à quelques niveaux de mémoire différents et de comparer ce que chacun coûte réellement, plutôt que de deviner — car la bonne réponse dépend de ce que fait le code et change d’une fonction à l’autre. C’est l’idée à emporter d’ici : dans un calcul payé à l’usage, moins cher et plus petit ne sont pas la même chose. Une fois que vous voyez ça, le reste de la facture cesse d’être un mystère et devient une série de choix.

Les leviers qui aident pour de bon

Quelques autres gestes sont rentables, chacun plus modeste que la question de la mémoire mais facile à obtenir gratuitement une fois qu’on sait qu’il existe.

Amazon fait tourner deux types de processeurs sous Lambda, et ses propres puces maison coûtent environ 20 % de moins à mémoire égale, tout en allant souvent un peu plus vite. Le changement tient le plus souvent à un seul réglage. La seule chose qui coince, c’est un logiciel conçu spécifiquement pour l’ancienne puce, qu’il faut recompiler d’abord ; mieux vaut donc tester dans un coin sûr avant de basculer le système en production.

Reviennent ensuite ces journaux, et ils méritent un deuxième regard, car c’est la ligne dont on oublie l’existence. À chaque exécution, une fonction peut écrire une note sur ce qu’elle vient de faire, et ces notes rendent service quand quelque chose casse. L’ennui, c’est le comportement par défaut : la plupart des fonctions écrivent bien plus de détails que personne ne lit, et les enregistrements sont conservés indéfiniment, sauf si vous dites le contraire. Une fonction bavarde qui tient le journal complet de chaque appel, sur des millions d’appels, peut gonfler en silence une facture de journalisation plus lourde que le code qu’elle est censée surveiller. Les enregistrements s’empilent, mois après mois, pour une session de débogage terminée depuis longtemps. Deux corrections tranquilles suffisent : demander au système de supprimer les vieux journaux au bout de deux semaines, et baisser le niveau de détail en production pour qu’il consigne les vrais problèmes au lieu de raconter chaque étape. Aucune des deux ne touche au code, et ensemble elles effacent souvent une ligne devenue plus grosse que le calcul qu’elle côtoyait.

Vient aussi la tentation de payer pour la vitesse. Quand une fonction est restée inactive, son premier appel après la pause est un peu plus lent, le temps que l’environnement se réveille — un délai connu sous le nom de démarrage à froid (cold start). Amazon peut garder pour vous des environnements chauds en permanence pour que ce délai ne survienne jamais, mais il facture cette chaleur jour et nuit, que quelqu’un appelle ou non. Pour la plupart des charges, c’est de l’argent dépensé en capacité inactive à trois heures du matin. Payer pour rester au chaud est un coût, pas une économie, et ça ne se justifie que sur une fonctionnalité face à l’utilisateur où ce temps de réveil se voit vraiment.

Une limite de temps généreuse relève de la même fuite discrète. On laisse souvent à une fonction bien plus de temps pour finir qu’elle n’en aura jamais besoin, ce qui ne coûte rien quand tout va bien, puisque vous ne payez que le temps utilisé. Ça vous coûte sur les mauvaises exécutions : un appel bloqué qui aurait abandonné en quelques secondes facture désormais une minute entière avant de rendre les armes. Régler la limite au plus près du temps réel de travail transforme un emballement en un échec rapide et bon marché.

L’habitude qui fait vraiment économiser

Remarquez ce que tout cela a en commun. Aucune de ces corrections ne commence par couper. Chacune commence par lire la facture et repérer quelle ligne pèse réellement, parce qu’optimiser à l’aveugle, c’est passer un après-midi à gratter quelques pour cent sur une ligne déjà petite. L’optimisation des coûts AWS Lambda se résume vraiment à cette habitude : ouvrir d’abord le détail des coûts, trouver la ligne qui domine, et viser là. Souvent, la fonction qui mange le budget se révèle être une que personne ne surveille, laissée tourner après un test censé être temporaire.

Et comme toute optimisation se dégrade avec le temps, c’est le dernier geste qui compte le plus. Quelqu’un relève une limite, une nouvelle fonction part avec les réglages par défaut, un vieux groupe de journaux retombe en mode « tout garder pour toujours ». Poser une simple alerte de budget qui vous prévient, disons, à 80 % de la dépense prévue pour le mois transforme la prochaine surprise en e-mail plutôt qu’en facture trimestrielle. Le réglage vaut la peine d’être fait une fois. L’alerte, c’est ce qui le maintient en place.

Questions fréquentes

De combien une facture peut-elle réellement baisser ?

Tout dépend de la ligne qui était gonflée au départ. Les deux changements qui se cumulent — trouver le bon réglage de mémoire et passer à la puce moins chère — font couramment fondre de 40 à 60 % la ligne de calcul pour une fonction jamais réglée. Si la journalisation était le vrai coupable, l’élaguer peut retrancher encore davantage en proportion. Le forfait fixe par requête, lui, ne bouge presque pas : les vraies économies viennent du calcul et des journaux, pas des appels eux-mêmes.

Donner plus de mémoire à une fonction coûte-t-il toujours plus cher ?

Non, et c’est le point que la plupart des gens prennent à l’envers. Vous payez la mémoire multipliée par le temps d’exécution, et plus de mémoire achète plus de puissance de calcul, si bien que le travail finit souvent assez vite pour que la durée plus courte annule le tarif plus élevé. C’est exactement pour ça qu’une fonction réglée trop bas peut coûter plus cher que la même dotée de plus d’espace. La façon honnête de trancher, c’est de mesurer quelques réglages et de garder le moins cher, au lieu de supposer que le plus petit gagne.

La puce moins chère est-elle toujours le bon choix ?

Presque toujours, puisque le même travail coûte environ 20 % de moins sur les puces maison d’Amazon et tourne en général au moins aussi vite. L’exception, c’est un logiciel conçu spécifiquement pour l’ancienne puce, qu’il faut recompiler avant qu’il tourne sur la nouvelle. Testez-le dans un coin sûr, vérifiez que le temps d’exécution ne se dégrade pas, et gardez la combinaison qui revient vraiment moins cher en pratique.

Faut-il payer pour garder le code au chaud afin d’économiser ?

En général, non. Garder le code chaud en permanence supprime le délai du premier appel, mais ça ajoute du coût au lieu d’en retrancher, parce que vous payez cette chaleur même quand personne n’appelle. Réservez-la à une fonctionnalité face à l’utilisateur où le délai se remarque vraiment, et programmez son extinction pendant les heures creuses. Pour un usage régulier et prévisible, un engagement de dépense sur la durée auprès d’Amazon fait économiser sans payer de capacité inactive.