Résumé

  • AWS annonce un choix explicite de lecture directe pour S3 Files, indépendant du seul réglage mémoire de Lambda.
  • Une exécution réussie ne prouve ni le chemin de lecture utilisé ni l'économie réalisée.

Pourquoi augmenter les ressources de calcul pour exprimer une préférence de stockage ? L'annonce de Lambda du 11 septembre dissocie la sélection explicite des lectures directes S3 Files de la taille mémoire de la fonction. Elle ouvre une possibilité d'optimisation. Elle ne démontre pas un gain financier.

L'API propose AUTO, ENABLED et DISABLED et prévoit un repli vers le système de fichiers si une lecture directe échoue. Ce mécanisme peut préserver l'exécution. Mais un résultat correct ne suffit alors pas à établir que les données ont emprunté le chemin choisi.

Le processeur reste lié à la mémoire

Lambda continue d'allouer le CPU proportionnellement à la mémoire configurée. Réduire celle-ci en profitant du nouveau réglage peut donc modifier deux choses : la préférence de lecture et les ressources disponibles pour calculer. La durée obtenue doit rester dans l'équation.

Un exemple arithmétique suffit à montrer le piège. Diviser la mémoire par deux tout en doublant la durée facturée laisse leur produit inchangé. Ce n'est pas un essai AWS. C'est une conséquence du fait que la tarification standard de Lambda Functions comprend les requêtes et une durée pondérée par la mémoire. Le nombre de mégaoctets, pris isolément, ne tranche rien.

Le stockage se mesure autrement. S3 Files distingue l'accès aux données du système de fichiers des lectures directes, qui conservent des frais de requêtes S3 GET et de lecture des métadonnées. Éviter une catégorie de frais n'efface pas les autres. Le bon dénominateur reste la tâche correctement achevée, avec l'activité de stockage qu'elle provoque.

Observer le chemin, pas seulement le bouton

Les textes publics appellent une autre précaution. L'annonce décrit une répartition selon la taille des fichiers ; la description d'ENABLED dans l'API parle plus largement de toutes les lectures. Il serait imprudent de transformer ces formulations en une règle opérationnelle unique, supposée vérifiée. Aucun test d'exécution n'a été réalisé pour cet article.

Leur point commun demeure clair : une préférence explicite de lecture est désormais disponible indépendamment de la mémoire. En revanche, le réglage seul ne permet pas de conclure au parcours exact de chaque opération d'une charge mixte.

Une application qui lit beaucoup de petits éléments et une autre qui parcourt un gros ensemble de données peuvent faire des choix différents. Ce sont des exemples d'analyse, pas des résultats clients. Il faut déterminer où le temps est dépensé et quels compteurs changent. Sinon, une amélioration du stockage peut masquer un ralentissement du calcul, tandis qu'un repli réussi brouille la comparaison.