7 min. de lecture

Avec la version GA d’Amazon S3 Files prévue pour avril 2026, les architectes cloud font désormais face à un choix à trois options parmi les systèmes de fichiers AWS. S3 Files permet d’intégrer directement des buckets S3 en tant que point de montage NFS – sans la majoration tarifaire d’EFS, mais avec d’autres compromis. Quand S3 Files constitue le choix le plus rentable, quand EFS tire parti de sa force Multi-AZ et quand FSx for Lustre reste la seule option viable : une matrice de décision pour 2026.

Les points clés en bref

• S3 Files GA depuis avril 2026 : les buckets S3 peuvent être intégrés en tant que point de montage NFS, modèle tarifaire S3 au lieu des frais de débit EFS – attrayant pour les charges de travail analytiques et par lots
• EFS reste leader pour le stockage partagé Multi-AZ : accès en écriture parallèles depuis plusieurs zones de disponibilité, sémantique POSIX robuste, gestion manuelle de la capacité inutile
• FSx for Lustre : indispensable pour le HPC et l’entraînement ML avec des latences sub-millisecondes – protocole Lustre, bandes parallèles sur plusieurs serveurs de stockage, intégration directe à S3 pour l’import de données
• Comparaison des coûts pour 100 TB : S3 Files ~230 USD/mois contre EFS General Purpose ~3.100 USD/mois contre FSx Lustre ~4.500 USD/mois (ScratchFS 2) – hors transfert de données dans chaque cas
• Critère de décision : modèle d’accès (écritures aléatoires contre lectures séquentielles), exigences de latence et nécessité d’une cohérence Multi-AZ

Articles connexesMigration Kubernetes 1.36 : checklist d’entreprise cgroup-v2 + DRA-GA  /  Amazon Bedrock AgentCore : chaîne d’outils CDK pour les agents en production

Qu’est-ce qu’Amazon S3 Files ? Amazon S3 Files est un service AWS rendu Generally Available en avril 2026, qui permet d’intégrer directement des buckets S3 en tant que système de fichiers NFS v4.0 dans des instances EC2 – sans appliance intermédiaire ni service de fichiers séparé. Il complète Amazon EFS et FSx en tant que troisième option de système de fichiers managée sur AWS.

Fichiers S3 : Ce que la version GA signifie réellement

Ne confondez pas Amazon S3 Files avec l’ancien S3 File Gateway (anciennement Storage Gateway NFS). La nouvelle fonctionnalité S3 Files permet de monter directement des compartiments S3 avec S3 Express One Zone ou des compartiments standard comme backend de stockage via NFS. La différence essentielle avec File Gateway : il n’y a plus d’appliance ou de VM sur site – le point de montage fonctionne entièrement dans la région AWS en tant que service géré.

Le modèle de tarification suit la logique de S3 : coûts de stockage selon le tarif S3, frais de requêtes selon les appels d’API. Pour les workloads à forte lecture, cela est moins cher que EFS, qui facture en fonction de la capacité provisionnée ou utilisée, ainsi que des frais de débit. Pour les workloads avec de nombreuses petites écritures aléatoires, la tarification devient rapidement plus chère que prévu – chaque écriture est un PUT S3.

Ce que S3 Files ne peut pas faire : verrouillage POSIX (verrous consultatifs, pas de verrous de plage d’octets appliqués), aucune garantie de cohérence forte en cas d’accès d’écriture parallèles à partir de plusieurs clients. Pour les serveurs Web, les bases de données ou les applications qui dépendent des verrous POSIX, S3 Files est exclu.

En rapport : État de FinOps 2026 : Pourquoi FinOps s’appelle désormais Technology Value Management et ce que cela signifie pour les budgets cloud DACH

EFS : Quand la prime de prix est justifiée

Amazon EFS justifie son supplément de prix par une propriété que S3 Files ne fournit pas : une forte cohérence en cas d’accès d’écriture parallèles à partir de plusieurs zones de disponibilité. Ceux qui écrivent simultanément sur des instances EC2 dans eu-central-1a, 1b et 1c sur le même système de fichiers et ont besoin de la sémantique POSIX n’ont pas d’alternative à EFS.

Le deuxième argument en faveur d’EFS est de nature opérationnelle : pas de planification de capacité. EFS grandit et diminue en fonction du stockage utilisé. Avec S3 Files, les limites de compartiment et les politiques de cycle de vie doivent être activement gérées. Pour les équipes sans ingénierie de stockage dédiée, EFS simplifie considérablement les opérations.

Workloads EFS typiques en 2026 : stockage partagé pour conteneurs ECS et EKS (PVC ReadWriteMany), applications de type « lift-and-shift » qui attendent NFS du centre de données, systèmes de gestion de contenu avec instances de serveur Web parallèles, environnements partagés pour DevTools.

„EFS est le bon choix si la cohérence d’écriture multi-AZ ou le verrouillage POSIX est nécessaire. Pour les workloads d’analyse en lecture seule sur des données S3 existantes, S3 Files est aujourd’hui moins cher que EFS ne le sera jamais.“

FSx for Lustre : Pas de substitut aux autres, mais irremplaçable pour le HPC

FSx for Lustre n’est pas un système de fichiers générique, et ne l’a jamais été. Lustre a été conçu pour des charges de travail parallèles de calcul haute performance : entraînement de modèles d’IA, analyses génomiques, pipelines de rendu vidéo, charges de simulation. Son atout réside dans le modèle de fragmentation : les données sont réparties sur plusieurs serveurs de stockage, permettant à un job d’entraînement ML avec cent instances GPU de lire simultanément à la bande passante maximale.

L’intégration S3 est un détail crucial : FSx for Lustre peut importer directement un bucket S3 comme source de données, traiter les fichiers localement avec les performances de Lustre, puis écrire les résultats de retour dans S3. Cela en fait le choix privilégié pour les pipelines ML où les jeux de données d’entraînement sont stockés dans S3 et doivent être accessibles rapidement.

Le principal inconvénient réside dans son caractère de système de fichiers temporaire : les clusters Scratch sont conçus pour des charges de travail éphémères, tandis que les clusters persistants coûtent nettement plus cher. FSx for Lustre ne remplace pas EFS pour un stockage partagé permanent — les coûts le rendraient prohibitif.

Matrice de décision : Quel service pour quel type de charge ?

Avantages et inconvénients en comparaison directe

Conseils de migration pour les déploiements EFS existants

Pour les équipes qui utilisent actuellement EFS pour les charges de travail d’analyse ou les jobs batch, il est intéressant de vérifier les coûts avec S3 Files. La migration est techniquement simple si : la charge de travail est principalement en lecture séquentielle, aucune écriture multi-AZ n’est nécessaire et le verrouillage POSIX n’est pas utilisé.

Un modèle typique de migration : créer un bucket S3, copier les données EFS existantes vers S3 à l’aide du transfert AWS DataSync, puis changer le point de montage. L’étape critique est l’audit de l’application concernant l’utilisation du verrouillage POSIX – de nombreux frameworks d’analyse n’utilisent pas de verrouillage, mais certains frameworks de traitement en exigent l’utilisation.

Pour les charges de travail conteneurisées sur EKS ou ECS, EFS reste la solution recommandée pour les volumes persistants ReadWriteMany. S3 Files n’est pas encore disponible en tant que pilote CSI pour Kubernetes (état : mai 2026), ce qui limite sa substitution directe dans les environnements conteneurisés.

Questions fréquentes