AWS casse la frontiere objet vs fichier
Andy Warfield l’a annonce le 7 avril 2026 sur le blog de Werner Vogels. S3 Files est officiellement disponible. Concretement, vous pouvez desormais monter un bucket S3 comme un systeme de fichiers NFS standard, directement sur EC2, sur un conteneur ECS ou depuis une fonction Lambda.
Depuis 2006, S3 a toujours ete un store d’objets. Pas un file system. Pour manipuler ses donnees, il fallait passer par l’API PutObject et GetObject, composer avec la latence, gerer la mise en cache cote client. Ce modele a fonctionne a l’echelle (S3 traite aujourd’hui 25 millions de requetes par seconde et emet 300 milliards de notifications par jour), mais il imposait des contraintes structurelles a toutes les equipes qui voulaient faire autre chose que du stockage froid.
L’approche stage and commit
L’equipe S3 a fait un choix tranche : ne pas tenter la fusion parfaite entre semantique fichier et semantique objet. Au lieu de ca, ils ont accepte une frontiere explicite. Les modifications en cours sont accumulees dans EFS (Elastic File System), puis synchronisees vers S3 toutes les 60 secondes environ. C’est ce qu’Andy Warfield appelle stage and commit.
Le compromis est interessant. Vous gardez la durabilite de S3 (11 nines), la tarification objet, l’integration avec toutes les couches de service AWS. Mais vous gagnez la simplicite d’acces d’un FS classique pour les workloads qui en ont besoin.
Les cas d’usage qui changent vraiment
Warfield mentionne plusieurs cas concrets ou S3 Files debloque des workflows jusque-la impossibles ou couteux a architecturer :
- Recherche genomique : analyse ADN sur des fichiers fasta de plusieurs giga sans reecrire l’outillage POSIX
- Pretraitement ML : les frameworks comme PyTorch ou JAX consomment directement le bucket sans boilerplate
- Effects visuels : les studios peuvent monter leurs assets 3D et leurs rendus comme un NAS classique
- Conception silicium : les flows EDA qui supposent un FS partage fonctionnent sans modification
Avec le mode read bypass, S3 Files monte jusqu’a 3 GB/s de debit lecture par client. Pas de quoi remplacer un FSx Lustre sur du HPC extreme, mais largement suffisant pour la majorite des workloads d’entreprise.
Ce qui reste a surveiller
La latence de commit a 60 secondes est le point a scruter. Si vous ecrivez un fichier et que vous le lisez immediatement depuis un autre client monte sur le meme bucket, vous ne verrez pas forcement la nouvelle version. Ce n’est pas un POSIX strict, c’est un FS eventuellement coherent avec une fenetre de propagation.
Chez Linkuma, on va tester ca rapidement sur nos pipelines de crawl et de parsing. Des teraoctets de HTML stocke dans S3, manipules aujourd’hui via SDK, qui pourraient passer directement en acces fichier pour certains traitements batch. Le gain de simplicite de code pourrait etre significatif.
On suit cette evolution de pres. Ce n’est pas juste une fonctionnalite en plus, c’est un changement de philosophie qui pourrait rebattre les cartes entre S3, EFS et FSx.
