VaultS3 se présente comme une nouvelle alternative pour déployer un stockage d’objets compatible S3 d’Amazon dans une infrastructure autonome, avec une approche peu courante : un seul binaire, sans services externes obligatoires et une consommation en veille que son développeur situe autour de 17 MiB de mémoire. Le projet vise un marché où cohabitent des services gérés tels que Amazon S3 et des plateformes open source établies comme Ceph, Garage ou SeaweedFS.

Les points clés de VaultS3 en 20 secondes

• VaultS3 implémente plus de 80 opérations de l’API S3 et fonctionne comme un seul binaire.
• Son développeur mesure environ 17 MiB de RAM au repos, bien que la consommation augmente sous charge.
• Il intègre le chiffrement, IAM, OIDC, le versionnage, Object Lock, métriques Prometheus et le codage par effacement (erasure coding).
• Il concurrence des solutions telles que Ceph, Garage, SeaweedFS ainsi que des services gérés comme Amazon S3.
• Le mode distribué de VaultS3 dispose encore de composants considérés comme en bêta.

La compatibilité avec S3 s’est imposée comme une composante courante dans de nombreuses architectures de stockage. Les applications de sauvegarde, plateformes d’analyse, référentiels de données, Kubernetes et de nombreux outils d’entreprise peuvent utiliser cette interface, qu’il s’agisse d’une plateforme Amazon Web Services (AWS) ou d’une infrastructure auto-hébergée.

VaultS3 vise précisément à occuper cette seconde place, tout en évitant la complexité que peuvent engendrer certaines solutions distribuées. Le projet est principalement développé en Go et distribué sous licence AGPL-3.0.

De 17 MiB au repos à environ 185 MiB en charge

Ce qui peut sauter aux yeux, c’est sa faible consommation de mémoire. Selon les tests publiés par le projet, VaultS3 utilise environ 17 MiB de RAM lorsqu’il est inactif.

Cela ne signifie pas qu’il peut gérer toute charge de stockage avec cette quantité.

Dans un test d’écriture d’objets de 64 MiB avec 16 opérations simultanées, la consommation peut atteindre environ 185 MiB. La mémoire requise dépendra donc du nombre de connexions, de la taille des objets et de la charge du serveur.

De plus, les comparaisons disponibles proviennent principalement du projet lui-même et ne constituent pas un benchmark indépendant. Il faut considérer les 17 MiB comme une indication de la légèreté du processus de base, et non comme une exigence fixe pour la production.

VaultS3 concentre une grande partie de ses fonctionnalités dans un seul exécutable. Il ne nécessite pas de base de données externe pour démarrer et utilise BoltDB pour stocker ses métadonnées. Il propose également des images Docker, des packages pour plusieurs distributions Linux et des options pour Kubernetes.

Il comprend aussi une interface web intégrée, une authentification Signature Version 4 de AWS, IAM, une intégration OIDC et LDAP, un chiffrement AES-256-GCM, des politiques par bucket, des métriques Prometheus, ainsi que divers mécanismes de protection des données.

VaultS3 face à Ceph, Garage et SeaweedFS

Le stockage compatible S3 dispose de plusieurs alternatives, rendant le critère de consommation mémoire insuffisant pour faire un choix définitif.

Voici une comparaison approximative pour situer chaque solution :

Ce tableau ne vise pas à désigner un vainqueur, car les architectures sont très différentes.

Ceph, par exemple, appartient à une catégorie distincte. Il peut offrir du stockage d’objets, blocs de données et fichiers sur un seul cluster distribué. Son RGW (RADOS Gateway) implémente une large partie de l’API S3 d’Amazon, avec des fonctionnalités telles que le versionnage, le cycle de vie, les politiques, le chiffrement, IAM et la configuration multisite.

Mais cette capacité implique un coût opérationnel. Déployer Ceph revient à gérer plusieurs composants et généralement plusieurs serveurs ou dispositifs OSD pour constituer une plateforme redondante. La documentation indique souvent qu’au moins trois OSD sont nécessaires pour garantir la redondance et la haute disponibilité.

VaultS3 vise presque l’extrémité opposée : commencer avec un serveur modeste et une configuration simple.

Garage est également intéressant dans cette comparaison, car il a été conçu avec une philosophie de stockage distribué relativement léger, adapté à du matériel et des connexions hétérogènes. VaultS3 tente de se différencier en intégrant dans le même projet des fonctionnalités supplémentaires d’administration et de protection des données.

SeaweedFS, pour sa part, a une portée plus large qu’un simple serveur S3. Son architecture distribuée peut exploiter différents composants pour gérer les volumes, métadonnées et accès aux données, offrant ainsi davantage de possibilités de déploiement, mais aussi un ensemble plus complexe à administrer.

MinIO n’est plus tout à fait le même qu’il y a quelques années

Il faut aussi mentionner MinIO, qui a longtemps été une référence notable pour déployer du stockage compatible S3 en dehors d’AWS.

Son contexte commercial et licence ont évolué.

La documentation actuelle précise que MinIO utilise une licence propre pour sa version distribuée, limitant, sauf accord Enterprise, le logiciel couvert par cette licence à une instance pour évaluation ou usage non produit. La société commercialise maintenant sa plateforme sous la famille AIStor.

Comparer directement MinIO AIStor à un projet open source comme VaultS3 sous AGPL, en restant sur l’étiquette de « stockage S3 open source », risque d’être trompeur.

VaultS3 tente justement de retrouver l’expérience qui a rendu les premières plateformes S3 auto-hébergées attrayantes : télécharger un programme, le lancer, et disposer rapidement d’un endpoint compatible avec les clients S3.

Amazon S3 répond à une problématique différente

L’autre extrémité de la comparaison est Amazon Web Services S3.

AWS gère l’infrastructure physique, la redondance, le remplacement du matériel et une large partie de la disponibilité. Dans une solution auto-gérée comme VaultS3, ces responsabilités incombent à l’exploitant des serveurs.

Cela change complètement l’équation économique.

Un serveur S3 auto-hébergé peut être intéressant lorsque le volume de données locales est important, ou pour éviter que certaines charges ne quittent l’infrastructure de l’organisation, ou encore lorsque le coût de transfert de grandes quantités vers le cloud est élevé.

Mais, attention, un logiciel seul ne transforme pas automatiquement un serveur en un service équivalent à Amazon S3.

La durabilité finale dépendra de la configuration des disques, des sauvegardes, de la réplication, des serveurs et des centres de données.

L’erasure coding et la réplication pour étendre les possibilités

VaultS3 ne se limite pas à stocker une seule copie de chaque objet. Il implémente l’erasure coding Reed-Solomon, le versionnage, Object Lock, des sauvegardes programmées et des processus de récupération de fragments endommagés.

Il propose aussi le clustering via Raft, le hachage cohérent et la réplication active-active.

C’est là que résident certaines de ses principales limitations actuelles.

Le projet différencie ses fonctionnalités entre celles considérées comme stables et celles encore en développement. Les déploiements en mode mono-nœud, y compris avec erasure coding multi-disk, sont les plus matures. Certaines fonctionnalités de clustering et de réplication distribuée restent en bêta.

Pour un laboratoire à domicile, cette distinction peut paraître mineure. Mais pour une entreprise souhaitant stocker des téraoctets de sauvegardes ou des données critiques, cela change tout.

Un système de stockage ne doit pas être jugé uniquement sur sa consommation mémoire au démarrage. La résilience face aux pannes, la cohérence des données, le comportement lors de partitions réseau, la mise à jour entre versions, la surveillance et la capacité à reconstruire de grands volumes après perte de disques ou de serveurs sont tout aussi cruciaux.

Une option particulièrement attractive pour des laboratoires et edge

VaultS3 possède aujourd’hui un positionnement clair : son faible coût, sa simplicité d’installation en font une option intéressante pour homelabs, petits serveurs, environnements de développement, dispositifs edge ou applications nécessitant un endpoint S3 local.

Il peut aussi servir à tester des applications conçues pour S3 sans dépendre en permanence d’un service externe.

Pour des déploiements d’entreprise plus importants, Ceph offre une architecture distribuée bien plus mature et un ensemble de fonctionnalités beaucoup plus large, notamment la possibilité d’utiliser des politiques IAM, OpenID Connect, LDAP, le chiffrement et la configuration multisite sur le stockage Ceph.

Les services managés comme Amazon S3 répondent à une autre partie du problème : ils transfèrent la gestion de l’infrastructure au fournisseur, en échange d’un modèle de consommation et de coûts associés.

VaultS3 cherche à faire la jonction entre ces deux extrêmes. Son vrai défi viendra avec la croissance des déploiements et la mise à l’épreuve de ses fonctionnalités distribuées sous charges soutenues, mises à jour et défaillances matérielles.

En attendant, ces 17 MiB de RAM au repos soulignent une idée plus intéressante : il reste encore de la marge pour construire un stockage S3 compatible, sans avoir forcément besoin d’un cluster complexe dès le départ.

Questions fréquentes

VaultS3 est-il compatible avec Amazon S3 ?

Il implémente plus de 80 opérations de l’API S3 et fonctionne avec des outils et SDK compatibles, mais cela ne signifie pas qu’il reproduit toutes les fonctionnalités d’Amazon S3.

VaultS3 peut-il remplacer Ceph ?

Cela dépend du scénario. VaultS3 privilégie la simplicité et la faible consommation, tandis que Ceph est conçu pour créer de vastes systèmes distribués d’objets, blocs et fichiers.

VaultS3 utilise-t-il réellement seulement 17 MiB de RAM ?

C’est la valeur mesurée par le développeur en mode récepteur. En charge, la consommation augmente ; une des tests rapportés indique environ 185 MiB lors de l’écriture d’objets de 64 MiB avec une concurrence de 16.

VaultS3 est-il prêt pour la production ?

Sa configuration mono-nœud est la plus mature. Certaines fonctionnalités distribuées, notamment celles liées au clustering et à la réplication active-active, sont encore en bêta et doivent être testées soigneusement avant de stocker des données critiques.