Stockage objet vs stockage bloc : lequel choisir ?

Le stockage objet l'emporte pour les fichiers déposés par les utilisateurs, les ressources statiques, les sauvegardes et les archives — essentiellement tout ce à quoi on accède via HTTP et qu'on modifie rarement en place. Le stockage bloc l'emporte quand on a besoin d'écritures aléatoires à faible latence : bases de données, volumes de démarrage, systèmes de fichiers à transactions élevées. Pour les charges de travail de transfert de fichiers spécifiquement, le stockage objet est presque toujours le bon choix car il passe à l'échelle horizontalement, coûte 0,015 à 0,023 $/Go/mois contre 0,08 à 0,125 $/Go/mois pour le bloc, et gère des buckets à l'échelle du pétaoctet sans repartitionnement.

Comment ils diffèrent vraiment sous le capot

Le stockage bloc expose un périphérique brut (LUN ou volume EBS) que le système d'exploitation formate en ext4, XFS ou NTFS. Les lectures et écritures se font en blocs de taille fixe, typiquement 4 Ko ou 16 Ko, via iSCSI, NVMe-oF ou SCSI. Le système d'exploitation possède le système de fichiers ; le périphérique bloc ne connaît rien aux fichiers, seulement des offsets.

Le stockage objet expose une API HTTP (S3, Azure Blob, GCS) où chaque objet possède une clé, des octets et des métadonnées. Il n'y a pas de système de fichiers dessous — les objets sont des unités atomiques qu'on met et qu'on récupère entièrement. Les écritures créent de nouvelles versions ; on ne peut pas modifier l'octet 1 000 000 d'un objet de 2 Go sans réécrire l'objet entier. Cette immuabilité est une fonctionnalité : elle permet la réplication multi-région, le versionnage et les règles lifecycle que le stockage bloc ne peut pas facilement égaler.

Comparaison rapide

| Dimension | Stockage objet | Stockage bloc | |-----------|----------------|---------------| | API typique | S3 HTTP REST | POSIX + iSCSI/NVMe | | Coût (AWS niveau chaud) | 0,023 $/Go/mois | 0,08 $/Go/mois (gp3) | | Taille unitaire max | 5 To par objet | 64 Tio par volume EBS | | Latence | 10-100 ms | Sous la milliseconde | | Lecteurs simultanés | Illimité | Un hôte à la fois (généralement) | | Durabilité annoncée | 11 neuf (S3) | 5-6 neuf (EBS) | | Idéal pour | Fichiers, médias, sauvegardes | Bases de données, disques de démarrage | | Mal adapté à | Écritures aléatoires dans de grands fichiers | Passage à l'échelle au-delà d'un volume |

Débit vs latence : des gagnants différents

Un volume EBS gp3 sert des lectures de 4 Ko en moins de 1 ms ; un GET S3 pour les mêmes 4 Ko prend 20 à 80 ms selon la région. Pour un journal WAL PostgreSQL qui traite 5 000 transactions par seconde, cet écart de latence est rédhibitoire. Pour un utilisateur qui télécharge un .zip de 500 Mo, c'est sans importance car le délai du premier octet disparaît derrière le débit.

En débit séquentiel, le stockage objet l'emporte souvent à grande échelle. S3 peut servir un seul bucket à 5 500 requêtes GET/seconde par préfixe, et avec le partitionnement des taux de requête (clés à préfixes hachés) cela monte à plusieurs dizaines de milliers. Un seul volume gp3 plafonne à 1 000 Mo/s et 16 000 IOPS. Pour dix utilisateurs simultanés téléchargeant un fichier de 10 Go, le stockage objet sature leurs connexions ; le stockage bloc devient un goulot d'étranglement.

Coût à grande échelle

Pour 100 To de médias relativement froids :

S3 Standard : 2 300 $/mois
S3 Standard-IA : 1 250 $/mois
S3 Glacier Instant Retrieval : 400 $/mois
S3 Glacier Deep Archive : 99 $/mois
EBS gp3 : 8 000 $/mois
EBS st1 (HDD optimisé pour le débit) : 4 500 $/mois

Le stockage bloc ne s'hiérarchise pas. Vous payez le prix d'accès crête pour des données que vous touchez une fois par an. Les règles lifecycle du stockage objet déplacent automatiquement les objets : chaud pendant 30 jours, Standard-IA pendant 60, Glacier après 90. Pour un service de transfert de fichiers qui stocke des envois avec une expiration de 7 jours, le stockage objet avec une règle Expiration est considérablement moins cher que de faire tourner un serveur sur EBS.

Cohérence et concurrence

S3 offre désormais une cohérence forte en lecture après écriture pour les PUT et DELETE, globalement. Azure Blob et GCS font de même. Cela a supprimé l'un des reproches historiques au stockage objet — on voyait autrefois des surprises de cohérence éventuelle où un fichier fraîchement envoyé renvoyait un 404 pendant quelques secondes.

Mais les écrivains simultanés comptent toujours. Le stockage bloc suppose généralement un seul écrivain ; des modes multi-attach existent mais ajoutent de la complexité. Le stockage objet permet à un million de clients de faire des PUT simultanément, avec une sémantique last-writer-wins (ou versionnage pour les conserver tous). Pour un système de partage de fichiers où deux utilisateurs pourraient envoyer des fichiers différents avec la même clé, le versionnage sur le bucket préserve les deux.

Quand les applications de transfert de fichiers ont quand même besoin du stockage bloc

La nuance : l'application qui sert le stockage objet tourne souvent sur des hôtes à base de bloc. Une API d'envoi de fichiers a besoin d'un disque local pour le spoulage temporaire (blocs multipart, scan antivirus), le stockage de métadonnées (généralement dans PostgreSQL sur EBS) et les journaux. Les objets eux-mêmes vont vers S3/R2/Blob ; la machinerie autour d'eux vit sur du bloc.

Pour les envois en streaming à haut débit, les pipelines en mémoire surpassent le disque. Des bibliothèques comme aws-sdk-js et boto3 supportent les envois multipart en streaming qui n'atteignent jamais le disque local. Un service d'envoi bien réglé peut pousser un fichier de 5 Go du client vers le stockage objet avec moins de 500 Mo de RAM et zéro fichier temporaire.

Les métadonnées : la différence méconnue

Le stockage objet transporte des métadonnées avec chaque objet : métadonnées système (taille, mtime, etag), métadonnées utilisateur (paires clé-valeur arbitraires, en-têtes x-amz-meta-*) et tags. On peut rechercher par métadonnées via S3 Object Lambda, les rapports d'inventaire, ou en couplant avec DynamoDB. Le stockage bloc laisse les métadonnées entièrement au système de fichiers, ce qui signifie qu'étiqueter 10 millions de fichiers nécessite une base de données personnalisée.

Pour une application de transfert qui doit répondre instantanément à « trouvez tous les fichiers de plus de 100 Mo envoyés la semaine dernière par des utilisateurs en France », les métadonnées d'objet plus un inventaire Parquet permettent une requête Athena en quelques secondes. La même question sur un volume bloc monté en NFS est une commande find qui prend des heures.

Chiffrement et contrôle d'accès

Les deux types de stockage supportent le chiffrement au repos avec AES-256. Le stockage objet facilite le contrôle d'accès par objet : politiques de bucket, URLs présignées, ACL d'objet et conditions IAM. L'accès au stockage bloc est plus grossier — tout le volume est attaché ou ne l'est pas.

Pour le partage sécurisé de fichiers avec des liens de téléchargement à durée limitée, les URLs présignées S3 (valables 7 jours maximum) sont le schéma standard. Pour les transferts sans exposition de texte clair côté serveur, le chiffrement côté client avant l'envoi fonctionne avec n'importe quel stockage objet. HexaTransfer chiffre avec AES-256-GCM dans le navigateur et ne stocke que du texte chiffré — le backend d'objets ne voit que des octets incompréhensibles.

La règle de décision simple

Répondez à trois questions :

Accédez-vous aux données via une API de système de fichiers (POSIX, SMB, NFS) ? Si oui, stockage bloc ou fichier.
Y accédez-vous via HTTP, les modifiez-vous rarement en place, et souhaitez-vous une échelle illimitée ? Si oui, stockage objet.
Le jeu de données dépasse-t-il 10 To et est-il en croissance ? Presque toujours du stockage objet.

Pour les charges de travail de transfert de fichiers, la réponse à (2) est toujours oui. Utilisez S3, R2, Azure Blob ou GCS pour les fichiers eux-mêmes, et réservez le stockage bloc pour la base de données et la couche web qui les gère.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.