Aller au contenu

AWS Mis à jour le 2026-07-04

Dimensionner la mémoire Lambda : le lien mémoire-CPU et le point d'équilibre des coûts

La mémoire Lambda contrôle aussi le CPU, donc plus de mémoire signifie souvent plus rapide et parfois moins cher. Comment trouver le réglage de mémoire où coût et durée s'équilibrent, avec de vraies mesures plutôt que des devinettes.

Le réglage de mémoire de Lambda est en réalité un cadran de calcul : le CPU est alloué en proportion de la mémoire, d’une fraction de vCPU à 128 Mo jusqu’à 6 vCPU à 10 240 Mo, avec environ 1 769 Mo correspondant à un vCPU complet. Comme vous êtes facturé en Go-millisecondes — mémoire multipliée par durée — doubler la mémoire en divisant la durée par deux coûte pareil et finit deux fois plus vite, et souvent la chute de durée est assez grande pour que plus de mémoire soit en fait moins cher. Le point d’équilibre se trouve par la mesure, pas l’intuition, et la mesure prend environ une heure.

Ce qui se passe

Vous configurez exactement un bouton de performance sur une fonction Lambda : la mémoire, de 128 Mo à 10 240 Mo. Le CPU, et dans une certaine mesure le débit réseau, montent avec elle linéairement. Il n’y a pas de réglage CPU séparé.

Le calcul de facturation est simple : coût par invocation = frais de requête + (mémoire en Go) x (durée facturée en ms) x (taux par Go-ms). Le coût est donc le produit de deux facteurs que vous influencez en directions opposées. Donnez plus de mémoire à une fonction limitée par le CPU et la durée tombe; que le coût monte ou baisse dépend de quel effet gagne. Pour une fonction qui fait de l’analyse JSON, du redimensionnement d’images, de la compression ou de la cryptographie, la courbe de durée chute typiquement à pic entre 128 Mo et environ 1 769 Mo (où la fonction a pour la première fois un vCPU complet), puis s’aplatit. Passé le plateau, vous payez plus cher la milliseconde pour des millisecondes qui ne rétrécissent plus.

Les fonctions qui passent leur vie à attendre — une réponse HTTP, une requête de base de données, un service en aval — se comportent tout autrement. Attendre coûte pareil à n’importe quelle taille de mémoire et ne va pas plus vite avec plus de CPU, donc les fonctions limitées par les E/S appartiennent aux petits réglages de mémoire, avec juste assez de marge pour que le runtime et vos structures de données tiennent.

Les runtimes multi-fils et multi-processus compliquent un cas limite : sous un vCPU complet, les fils d’arrière-plan (rinceurs de métriques, connexions maintenues) volent des cycles à votre travail principal; au-dessus d’environ 1 769 Mo, les vCPU supplémentaires n’aident que si le code utilise réellement plus d’un cœur, ce que la plupart du code de handler ne fait pas.

Quoi vérifier en premier

  • Max Memory Used contre Memory Size. La ligne REPORT imprime les deux. Une fonction configurée à 1 024 Mo qui ne dépasse jamais 190 Mo n’est pas forcément surdimensionnée — le surplus achète peut-être du CPU utile — mais ça vous dit que la pression mémoire n’est pas la contrainte.
  • Si la fonction est limitée par le CPU ou par les E/S. Si la durée bouge à peine quand vous changez la mémoire, elle est limitée par les E/S et la plus petite taille viable gagne.
  • Si quelqu’un attend. Pour les pipelines asynchrones, raboter 400 ms ne vaut rien sauf si ça change le coût. Pour les API synchrones, c’est de la latence visible pour l’utilisateur.
  • Les morts par manque de mémoire. Runtime exited with error: signal: killed ou des erreurs juste quand Max Memory Used approche Memory Size signifient que vous êtes sous-dimensionné, point final.

Comment vérifier

Tirez l’usage réel des journaux. Dans CloudWatch Logs Insights :

filter @type = "REPORT"
| stats count() as invocations,
        avg(@duration) as avgMs,
        pct(@duration, 95) as p95Ms,
        max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
        max(@memorySize / 1024 / 1024) as memConfiguredMB

Vérifiez le réglage actuel :

aws lambda get-function-configuration \
  --function-name my-function \
  --query '{Memory: MemorySize, Timeout: Timeout, Arch: Architectures}'

Pour le vrai point d’équilibre, roulez AWS Lambda Power Tuning — la machine à états Step Functions à code ouvert qui invoque votre fonction à une gamme de tailles de mémoire avec de vraies charges utiles et trace le coût contre la durée. Elle transforme les devinettes en image. AWS Compute Optimizer produit aussi des recommandations de mémoire Lambda à partir de votre historique de production une fois qu’il a assez de données; nous avons couvert son comportement dans Le redimensionnement avec Compute Optimizer. Les dimensions de facturation elles-mêmes sont documentées à https://docs.aws.amazon.com/lambda/.

L’approche

  1. Classez d’abord la fonction. Dix minutes à lire le code vous disent si le temps va au calcul ou à l’attente. Limitée par les E/S : réglez la mémoire à environ 1,5-2x le Max Memory Used observé et arrêtez. Limitée par le CPU : continuez.
  2. Faites le tuning avec des charges utiles à l’image de la production. Une passe de tuning avec un événement de test trivial vous ment — une charge utile de 100 octets s’analyse vite à n’importe quelle taille de mémoire. Utilisez de vrais événements capturés, et ajustez pour la charge utile p95, pas la moyenne.
  3. Lisez la courbe coût-durée, pas seulement le point le moins cher. Power Tuning montre les deux. Il y a fréquemment un réglage qui coûte 5 % de plus que le minimum et coupe la durée de 40 % — pour une API synchrone, ce compromis est habituellement le bon.
  4. Attention à la ligne des 1 769 Mo pour le code mono-fil. Au-delà d’un vCPU complet, les handlers mono-fil gagnent peu. Si la courbe continue de s’améliorer passé ce point, votre runtime utilise le deuxième cœur (JIT, GC, déchargement crypto) — très bien, mais vérifiez au lieu de supposer.
  5. Appliquez, puis re-mesurez en production. Posez la nouvelle valeur avec aws lambda update-function-configuration --function-name my-function --memory-size 1024 et comparez une semaine de statistiques REPORT à la semaine précédente. Le tuning synthétique et le trafic de production sont parfois en désaccord.

Quand ce n’est pas la bonne approche

Le réglage de la mémoire est une optimisation de second ordre. Si la durée d’une fonction est dominée par une requête sans index, un patron d’appels N+1 ou une cache manquante, corrigez ça d’abord — aucun réglage de mémoire ne sauve de mauvaises E/S. Et si une fonction roule quelques milliers de fois par mois, la dépense totale est de la petite monnaie à n’importe quel réglage; investissez l’heure là où il y a plus de levier. Le tuning compte quand le volume d’invocations est élevé, la durée est significative, ou un utilisateur synchrone attend.

Erreurs fréquentes

  • Mettre chaque fonction à 128 Mo « pour économiser » — pour le travail limité par le CPU, c’est fréquemment le réglage le plus lent et le plus cher à la fois, parce que la durée gonfle plus vite que le taux de mémoire ne rétrécit.
  • Faire le tuning une fois au lancement et plus jamais. Les dépendances grossissent, les charges utiles grossissent, et le point d’équilibre de l’an passé dérive.
  • Oublier que la durée facturée est ce que vous payez, et que depuis 2025 la phase d’init des runtimes gérés est facturée aussi sur les invocations à la demande — une init lourde à haute mémoire est un vrai poste de dépense.
  • Copier le réglage de mémoire d’une fonction à tout un service. Les charges de travail des handlers diffèrent; ajustez par fonction, au moins pour les plus gros postes de dépense.

Garder le contrôle

  • Ajoutez la requête Logs Insights mémoire/durée à une revue mensuelle de vos dix fonctions les plus coûteuses.
  • Alarmez quand Max Memory Used dépasse ~90 % de Memory Size pour attraper les charges utiles qui rampent avant que les morts par manque de mémoire commencent.
  • Relancez Power Tuning après toute mise à niveau de dépendance qui touche la sérialisation, la crypto ou la compression.
  • Consignez la taille de mémoire choisie et la date du tuning dans un commentaire de l’IaC pour que le prochain ingénieur sache que c’était délibéré, pas du folklore.

Le cadran de mémoire est le seul levier que Lambda vous donne sur la vitesse et le coût à la fois, et il récompense une heure de mesure honnête bien plus que n’importe quelle quantité de folklore de forum. 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.