6 Min. de lecture
Amazon S3 Files est désormais disponible depuis le 7 avril 2026. Cette fonctionnalité permet de monter des compartiments S3 directement en tant que système de fichiers compatible NFS dans EC2, EKS et Lambda – sans modifier le code des applications existantes. Pour les équipes DACH ayant des workloads legacy, des pipelines ML et des besoins de stockage partagé, cela change fondamentalement les options d’architecture.
Les points clés en bref
- Montage NFS sans modification de l’application : S3 Files fournit un point de montage compatible POSIX. Les applications existantes qui utilisent open(), read() et write() peuvent accéder à S3 sans refactoring.
- 34 régions, différence de prix significative avec EFS : Le stockage S3 coûte 0,023 USD/Go/mois en standard, tandis qu’EFS coûte 0,30 USD/Go/mois en mode standard. Pour les grands ensembles de données ML et les points de contrôle de modèle, le facteur coût est pertinent.
- La latence est le compromis : Les opérations de métadonnées avec S3 Files se situent entre 10 et 50 ms, tandis qu’EFS est inférieur à 1 ms. Les workloads avec de nombreuses petites opérations de fichiers (DB transactionnelles, petits fichiers de configuration à haute fréquence) ne sont pas le scénario cible.
- Intégration EKS via le pilote CSI : Le pilote CSI AWS S3 est mis à jour et prend en charge S3 Files en tant que volume persistant. L’accès multi-pod au même compartiment est possible, ce qui est important pour les configurations de formation distribuée.
En relationBSI-KRITIS, NIS2 et C5 : vérification de la conformité multi-cloud en pratique pour 2026 / BYOD dans l’entreprise allemande en 2026
Ce que S3 Files fait techniquement – et ce qu’il ne fait pas
Qu’est-ce qu’Amazon S3 Files ? S3 Files est une nouvelle fonctionnalité d’Amazon S3 qui fournit un point de montage de système de fichiers compatible POSIX pour les compartiments S3 existants. Sous le capot, un service géré traduit les appels POSIX en opérations d’API S3. Le résultat : une application qui lit /mnt/data/model.bin accède en fait à s3://bucket/model.bin sans le savoir.
La base technique est l’agent S3 Files, un processus secondaire qui s’exécute sur l’instance EC2 ou dans le pod Kubernetes. Il effectue la traduction POSIX vers S3 et maintient un cache de métadonnées local. L’agent est intégré à EKS via le pilote CSI AWS S3 ; pour EC2, il existe un paquet RPM et DEB. La prise en charge de Lambda est disponible via les couches d’exécution gérées.
Ce que S3 Files n’est pas : un système de fichiers POSIX complet. Le verrouillage de fichiers (flock/fcntl) n’est pas pris en charge. Les liens symboliques sont en lecture seule. Les opérations de renommage n’ont pas de garantie atomique en cas d’accès concurrent. Pour les applications qui dépendent de ces primitives – en particulier les bases de données SQL classiques ou les systèmes de build avec verrouillage de fichiers – EFS reste le bon choix.
Trois scénarios pour les équipes DACH
Pour quelles charges de travail S3 Files est-il concrètement avantageux ?
Entraînement ML et mise en production de modèles : C’est le scénario principal. Les données d’entraînement et les points de contrôle des modèles sont déjà stockés dans S3. Avec S3 Files, un job d’entraînement PyTorch peut lire les données via /mnt/training-data, sans que le code n’ait besoin de connaître S3. L’accès multi-pods au même bucket permet des configurations d’entraînement distribué sur SageMaker et EKS. L’avantage coûts par rapport à EFS est considérable pour des jeux de données de l’ordre du TiB : avec 10 TiB de données d’entraînement, S3 Files permet d’économiser environ 2 770 USD/mois par rapport à EFS Standard.
Applications héritées avec interface de système de fichiers : De nombreuses applications anciennes en Java et C++ lisent leurs configurations et données temporaires depuis le système de fichiers local. Si le stockage principal est déjà dans S3, S3 Files permet d’éliminer la couche EFS supplémentaire. Cela simplifie l’architecture de déploiement, notamment lors de migrations Lift-and-Shift encore non refactorisées.
Lambda et pipelines serverless : Jusqu’à présent, les fonctions Lambda n’avaient que EFS comme système de fichiers persistant. S3 Files est moins coûteux. Pour les charges Lambda qui opèrent déjà sur des données S3 (ETL, traitement d’images, transformations par lots), le montage direct est une approche plus naturelle que des appels API S3 dans le code.
Comparaison des coûts des options de stockage (us-east-1)
$0,023
S3 Files / Go / Mois (Standard)
$0,30
EFS Standard / Go / Mois
$0,145
FSx for Lustre Scratch / Go / Mois
« Cette fonctionnalité permet de monter directement les buckets S3 comme un système de fichiers compatible NFS sur EC2, EKS et Lambda – sans modifier le code des applications existantes. »
Ce qui change avec EKS
Pour les équipes Kubernetes, le point d’entrée pertinent est le pilote AWS S3 CSI en version 1.10, qui apporte la prise en charge des fichiers S3. Un PersistentVolume avec des fichiers S3 ressemble à ceci :
kind: PersistentVolume
metadata:
name: s3-files-pv
spec:
capacity:
storage: 100Gi
accessModes:
– ReadWriteMany
mountOptions:
– allow-delete
– allow-overwrite
csi:
driver: s3.csi.aws.com
volumeHandle: s3-files-bucket-name
ReadWriteMany signifie que plusieurs pods peuvent écrire simultanément sur le même bucket. Dans le cadre d’un entraînement distribué en apprentissage automatique avec des serveurs de paramètres ou dans le cas de dépôts partagés de modèles, cela constitue un avantage clair par rapport à un volume EBS unique qui ne peut qu’être ReadWriteOnce.
Une remarque pour les équipes DACH soumises au RGPD : le bucket S3 doit se trouver dans une région européenne. Francfort (eu-central-1) et Stockholm (eu-north-1) sont entièrement prises en charge. L’agent S3 Files communique exclusivement avec l’endpoint S3 régional – aucune donnée ne sort de la région.
Quand EFS et FSx restent meilleurs
S3 Files n’est pas un remplacement d’EFS. Les différences de latence sont réelles : pour les applications comportant de nombreuses petites opérations séquentielles sur le système de fichiers – comme les serveurs web classiques, les applications PHP lisant fréquemment des fichiers de configuration, ou les systèmes de construction – EFS reste nettement supérieur. Les opérations sur les métadonnées, telles que stat() ou les listages de répertoires, sont nettement plus lentes avec S3 Files.
FSx for Lustre demeure le choix privilégié lorsque la bande passante doit être maximisée – Lustre est conçu pour un débit élevé parallèle, ce que S3 Files n’est pas. Pour les charges de travail très importantes en apprentissage automatique (modèles de plus de 100 Go, lectures séquentielles intensives), le surcoût de FSx reste justifié.
S3 Files : adapté pour
- Entraînement en apprentissage automatique sur grands ensembles de données (>100 GB)
- Points de contrôle de modèles et stockage d’artefacts
- Fonctions Lambda avec interface système de fichiers
- Applications héritées lors du lift-and-shift sans refactoring
- Optimisation des coûts pour les charges de travail gourmandes en stockage
Continuer avec EFS/FSx pour
- Applications nécessitant un verrouillage de fichiers
- De nombreuses petites opérations séquentielles sur les métadonnées
- Serveurs web avec lectures fréquentes de fichiers de configuration
- Fichiers classiques de bases de données SQL
- Débit maximal (>10 Go/s par pod)
La bonne question à se poser : le stockage principal de la charge de travail se trouve-t-il déjà dans S3 – et l’application n’a-t-elle pas besoin de verrouillage de fichiers ? Dans ce cas, S3 Files est la solution évidente. Si le stockage est sur EBS ou EFS – et si l’application est fortement sensible à la latence – alors EFS reste la meilleure option.
Sources : documentation AWS S3 Files GA (avril 2026), calculateur de tarifs AWS, documents de la session AWS re:Invent sur S3.
Questions fréquentes
Les fichiers S3 sont-ils compatibles avec toutes les classes de stockage S3 ?
S3 Files prend en charge S3 Standard, S3 Intelligent-Tiering et S3 Standard-IA pour les opérations de lecture et d’écriture. S3 Glacier et Glacier Deep Archive ne peuvent pas être montés directement — les objets dans Glacier doivent d’abord être restaurés. Pour les ensembles de données ML, AWS recommande S3 Intelligent-Tiering comme classe de stockage standard, car les modèles d’accès aux données d’entraînement varient.
Comment se comporte S3 Files lors de déploiements multi-régions ?
S3 Files est monté uniquement sur des buckets situés dans la même région que le point de montage. L’accès cross-region n’est pas directement pris en charge. Si vos workloads s’étendent sur plusieurs régions, vous devez soit utiliser S3 Replication pour les accès en lecture, soit installer des points d’accès S3 multi-régions en tant que couche séparée. Pour les équipes d’Europe centrale (DACH) dont les régions principales sont eu-central-1 et eu-west-1, cette solution constitue un point stratégique lors de déploiements globaux.
S3 Files nécessite-t-il des autorisations IAM supplémentaires par rapport à l’accès normal à S3 ?
Oui. En plus des permissions S3 standard (GetObject, PutObject, DeleteObject), S3 Files requiert s3:ListBucket, s3:GetBucketLocation, ainsi que les nouvelles actions s3files:* pour les opérations sur les métadonnées. La politique IAM complète est documentée dans la documentation AWS sous la rubrique « S3 Files IAM Permissions ». Dans le cadre de politiques à moindre privilège, ces actions doivent être explicitement ajoutées.
Peut-on utiliser S3 Files dans AWS GovCloud et dans les déploiements EU-Sovereign ?
S3 Files est disponible dans AWS GovCloud (US-East et US-West). Pour les exigences EU-Sovereign selon BSI C5 et DSGVO : S3 Files fonctionne dans eu-central-1 (Francfort) et peut donc être utilisé dans le cadre des règles allemandes de protection des données. AWS a intégré S3 Files dans le cadre du processus d’attestation C5 ; la mise à jour de l’attestation pour 2026 était en cours lors du lancement de GA. Les entreprises qui ont besoin de cette solution pour la conformité KRITIS devraient directement contacter l’équipe de conformité AWS pour obtenir l’attestation C5 actuelle.
Plus d’informations du réseau MBF Media
Photo : Pexels
Source de l’image de titre : Pexels / panumas nikhomkhai (px:17323801)
