AWS a présenté lors de son Summit deux annonces dont la portée dépasse le cycle ordinaire des mises à jour produits. S3 Files élargit le service de stockage objet à un accès système de fichiers réseau, sans migration des données existantes. En cybersécurité, AWS déploie Claude Mythos Preview via Amazon Bedrock et passe AWS Security Agent en disponibilité générale. L’outil teste activement les vulnérabilités identifiées pour en confirmer la réalité avant toute remontée d’alerte.
Le stockage objet et le stockage fichier ont longtemps coexisté dans des architectures séparées, chacune optimisée pour des cas d’usage distincts. S3 a imposé le modèle objet comme référence pour les données en volume, les pipelines analytiques et les charges de travail cloud natives. Mais de nombreuses applications, outils de traitement de données, pipelines d’apprentissage automatique, utilitaires Unix, continuent d’interagir avec les données via des interfaces POSIX orientées fichiers. Les équipes IT devaient jusqu’ici maintenir des copies synchronisées entre S3 et des systèmes de fichiers montés, ou modifier leurs applications pour consommer directement l’API S3. S3 Files supprime cette friction.
La fonctionnalité intègre Amazon EFS à S3 pour permettre le montage direct de n’importe quel bucket ou préfixe comme système de fichiers réseau, dans une instance EC2, un conteneur ou une fonction Lambda. Les bibliothèques standard comme pandas, les pipelines d’apprentissage automatique et les utilitaires Unix peuvent ainsi interagir avec des données S3 sans modification du code applicatif et sans déplacement des données. En cas de conflit entre une modification côté fichier et une modification côté objet, S3 fait office de source de vérité et prime sur toute autre version.
Import progressif, synchronisation et performances en lecture
Le modèle de chargement de S3 Files est conçu pour absorber les buckets de plusieurs millions d’objets sans délai initial. À la connexion, les fichiers inférieurs à 128 Ko sont importés immédiatement dans le système de fichiers. Au-delà de ce seuil, seules les métadonnées sont chargées, le contenu étant récupéré au moment de la lecture. Ce comportement évite de saturer la bande passante à l’initialisation tout en garantissant une disponibilité immédiate du namespace complet. La synchronisation est bidirectionnelle et automatique, les modifications apportées via l’interface fichier étant propagées vers S3 toutes les soixante secondes environ. Pour les lectures séquentielles intensives, une fonction de contournement redirige les requêtes directement vers S3 via des appels GET parallèles, avec un débit annoncé de 3 Go/s par client.
S3 Files supprime la friction d’accès, mais ne modifie pas le modèle de facturation des transferts sortants d’AWS. Chaque lecture de fichier déclenche une requête GET vers S3. Les lectures restant dans la même région ne génèrent pas de frais de sortie, mais toute lecture depuis une région différente ou vers l’extérieur du réseau AWS est facturée aux tarifs egress standard. La synchronisation bidirectionnelle génère par ailleurs des appels API de type PUT, GET et LIST dont le volume peut s’accumuler sur des buckets très actifs. Les DSI qui maintenaient des architectures avec copies locales précisément pour éviter les appels S3 répétés devront évaluer l’impact tarifaire d’un basculement vers S3 Files avant d’en généraliser l’usage. L’économie de complexité architecturale que promet la fonctionnalité ne se traduit pas automatiquement en économie de coûts d’exploitation.
S3 Files complète un triptyque de stockage multimodal
S3 Files prolonge une évolution engagée lors de re : Invent 2024. S3 Tables avait introduit un format de tables Iceberg nativement géré, avec plus de deux millions de tables disponibles. S3 Vectors avait ajouté des index vectoriels élastiques pour les charges de travail d’IA générative. S3 Files complète ce triptyque en adressant les applications orientées fichiers. AWS construit une couche de stockage multimodale unifiée dans laquelle un même service d’objet expose des interfaces adaptées aux différents modes de consommation, sans forcer les équipes à choisir une architecture de stockage à la conception.
Cette évolution de l’infrastructure de stockage accompagne une transformation parallèle des couches de sécurité. Sur le volet cybersécurité, AWS annonce deux évolutions qui concernent directement les RSSI. La première est le déploiement de Claude Mythos Preview sur Amazon Bedrock dans le cadre du Project Glasswing, initiative couverte sur IT Social le 8 avril. Le modèle, développé par Anthropic pour la détection autonome de vulnérabilités dans les logiciels les plus exposés, devient accessible aux équipes de sécurité via l’infrastructure AWS. Amy Herzog, RSSI d’AWS, chiffre l’engagement opérationnel : 400 000 milliards de flux réseau analysés par jour, 300 millions de tentatives de chiffrement malveillant bloquées en 2025, et une réduction du temps d’analyse des journaux SecOps de six heures à sept minutes grâce à l’IA, soit un gain de traitement multiplié par cinquante.
AWS Security Agent passe en disponibilité générale
Sa caractéristique opérationnelle distingue AWS Security Agent des outils de détection classiques. L’outil tente activement de tester les vulnérabilités identifiées pour en confirmer la réalité avant de les remonter. Chaque résultat est accompagné d’un score CVSS et d’étapes de reproduction détaillées. En phase de préversion, les délais de test sont passés de plusieurs semaines à quelques heures. Pour les RSSI, ce passage à l’exploitation contrôlée change la nature de l’outil. AWS Security Agent produit un inventaire de vulnérabilités confirmées et exploitables, accompagné des éléments nécessaires à leur priorisation et à leur correction.
Ces deux annonces illustrent une tendance structurelle dans l’offre cloud d’AWS. Le fournisseur intègre progressivement les capacités d’IA avancées, qu’elles soient développées en interne ou en partenariat, directement dans les couches d’infrastructure et de sécurité, sans les positionner comme des modules optionnels. Pour les DSI et RSSI, cela signifie que les gains d’efficacité liés à l’IA deviennent accessibles sans déploiement spécifique, mais au prix d’une dépendance accrue à l’écosystème AWS et à une exposition au Cloud Act que les organisations régulées ne peuvent pas ignorer.
