Le plafond de verre des applications legacy
Pendant des annees, les DSI ont bute sur le meme mur lors des projets de migration cloud. Les applications ecrites pour fonctionner sur des systemes de fichiers partages refusaient de se plier a un modele objet. Migrer supposait reecrire. Et reecrire, ca coute cher. Tres cher.
Avec S3 Files, annonce le 7 avril 2026, AWS attaque directement ce plafond. Plus besoin de reecrire. Vous montez votre bucket S3 comme un NAS via NFS, votre binaire legacy pense qu’il ecrit sur disque, et AWS se charge de tout le reste par derriere.
Ce que ca represente economiquement
Prenez un logiciel de post-production video tournant sur des serveurs on-premise avec 200 To de storage SAN. Le lift-and-shift vers AWS etait jusqu’ici complexe : soit vous passiez par FSx Lustre (cher, avec un couplage a l’instance qui limite la flexibilite), soit vous reecriviez l’application pour consommer S3 en API.
Avec S3 Files, vous gardez votre code tel quel. Votre bucket S3 coute 23 dollars par teraoctet par mois en tier standard, vous profitez des regles de lifecycle (passage en Glacier), vous beneficiez de la replication cross-region native. L’equation change completement.
Un piege a eviter
Attention, le discours marketing va vite aller vers le tout-S3. Ce serait une erreur. S3 Files n’est pas un remplacement universel. La coherence eventuelle a 60 secondes signifie que les workloads transactionnels (bases de donnees, file de messages, metadonnees chaudes) n’ont rien a faire la-dedans.
Le bon usage, c’est l’acces fichier sur des donnees froides ou chaudes mais avec un ratio lecture / ecriture eleve. Pour tout ce qui est ecriture intense en simultane avec lecture cross-client immediate, restez sur EFS ou FSx.
Les nouveaux arbitrages
Pour un architecte cloud, l’arrivee de S3 Files redistribue les cartes. On pourra desormais proposer trois niveaux :
- Workloads transactionnels et POSIX strict : EFS ou FSx, selon le debit requis
- Workloads analytique et batch avec besoin FS : S3 Files (nouvelle couche)
- Workloads objet pur et API-native : S3 classique (inchange)
Les economies potentielles sur les postes 1 et 2 sont substantielles, parce que beaucoup d’equipes mettaient du FSx Lustre par defaut la ou un S3 Files suffirait largement.
L’angle business pour les editeurs de logiciels
Pour les editeurs qui vendent un produit on-premise historique, c’est aussi une porte. Si votre logiciel peut tourner sans modification sur un storage monte NFS, vous avez desormais un argument credible pour proposer une version cloud-native sans avoir a reecrire le moteur de stockage.
Chez Linkuma, on accompagne quotidiennement des editeurs de SaaS dans leurs reflexions de packaging cloud. S3 Files va faire partie des questions a se poser systematiquement d’ici la fin de l’annee. On surveille comment les acteurs comme Snowflake, Databricks ou les equipes media en interne reagissent. Ca pourrait bouger vite.
