Object storage versus block storage: wat is beter?

Block storage kost $0,08-$0,125 per GB per maand op AWS. Object storage kost $0,015-$0,023 per GB per maand — en schaal mee tot petabytes zonder herpartitionering. Dat prijsverschil alleen al beantwoordt de vraag voor de meeste bestandsoverdracht-use cases. Object storage wint voor door gebruikers geüploade bestanden, statische assets, back-ups en archieven — alles wat je via HTTP benadert en zelden direct wijzigt. Block storage wint wanneer je lage-latency willekeurige schrijfacties nodig hebt: databases, opstartvolumes en bestandssystemen met hoge transactievolumes. Voor bestandsoverdracht-werkbelastingen is object storage bijna altijd de juiste keuze.

Hoe ze werkelijk van elkaar verschillen

Block storage stelt een ruw apparaat beschikbaar (een LUN of EBS-volume) dat het besturingssysteem formatteert met ext4, XFS of NTFS. Lees- en schrijfacties vinden plaats in blokken van vaste grootte, typisch 4 KB of 16 KB, via iSCSI, NVMe-oF of SCSI. Het besturingssysteem beheert het bestandssysteem; het blokapparaat kent niets over bestanden, alleen offsets.

Object storage stelt een HTTP-API beschikbaar (S3, Azure Blob, GCS) waarbij elk object een sleutel, bytes en metadata heeft. Er is geen bestandssysteem eronder — objecten zijn atomaire eenheden die je in zijn geheel PUT en GET. Schrijfacties genereren nieuwe versies; je kunt byte 1.000.000 van een 2 GB-object niet wijzigen zonder het object opnieuw te schrijven. Deze onveranderlijkheid is een functie: het maakt multi-region replicatie, versiebeheer en levenscyclusregels mogelijk die block storage niet gemakkelijk kan evenaren.

Snelle vergelijking

| Dimensie | Object storage | Block storage | |----------|----------------|---------------| | Typische API | S3 HTTP REST | POSIX + iSCSI/NVMe | | Kosten (AWS warme laag) | $0,023/GB/maand | $0,08/GB/maand (gp3) | | Maximale eenheid | 5 TB per object | 64 TiB per EBS-volume | | Latency | 10-100 ms | Sub-milliseconde | | Gelijktijdige lezers | Onbeperkt | Doorgaans één host | | Duurzaamheidsclaim | 11 negens (S3) | 5-6 negens (EBS) | | Goed voor | Bestanden, media, back-ups | Databases, opstartschijven | | Slecht voor | Willekeurig schrijven in grote bestanden | Horizontale schaling voorbij één volume |

Doorvoer versus latency: verschillende winnaars

Een gp3 EBS-volume verwerkt 4 KB-leesbewerkingen in minder dan 1 ms; een S3 GET voor dezelfde 4 KB duurt 20-80 ms afhankelijk van de regio. Voor een PostgreSQL write-ahead log die 5.000 transacties per seconde verwerkt, is dat latencyverschil fnuikend. Voor een gebruiker die een .zip van 500 MB downloadt, is het irrelevant omdat de vertraging van het eerste byte verdwijnt achter de doorvoer.

Bij sequentiële doorvoer op schaal wint object storage vaak. S3 kan een enkele bucket bedienen met 5.500 GET-verzoeken per seconde per prefix, en met verzoekrategebaseerde partitionering (hash-voorafgegane sleutels) loopt dat op in de tienduizenden. Een enkel gp3-volume is beperkt tot 1.000 MB/s en 16.000 IOPS. Voor tien gelijktijdige gebruikers die een bestand van 10 GB downloaden, verzadigt object storage hun verbindingen; block storage wordt een knelpunt.

Kosten op schaal

Voor 100 TB aan koude media:

S3 Standard: $2.300/maand
S3 Standard-IA: $1.250/maand
S3 Glacier Instant Retrieval: $400/maand
S3 Glacier Deep Archive: $99/maand
EBS gp3: $8.000/maand
EBS st1 (doorvoergeoptimaliseerde HDD): $4.500/maand

Block storage laagt niet. Je betaalt premium-toegangsprijs voor data die je eens per jaar aanraakt. Object storage-levenscyclusregels verplaatsen objecten automatisch: warm voor 30 dagen, Standard-IA voor 60, Glacier na 90. Voor een bestandsoverdrachtsservice die uploads opslaat met een vervaldatum van 7 dagen, is object storage met een Expiration-regel dramatisch goedkoper dan een server met EBS-backup draaien.

Consistentie en gelijktijdigheid

S3 biedt nu sterke read-after-write-consistentie voor PUT's en DELETE's, wereldwijd. Azure Blob en GCS komen overeen. Dit verwijderde een van de historische nadelen van object storage — vroeger zag je "uiteindelijke consistentie"-verrassingen waarbij een vers geüpload bestand een paar seconden 404'd.

Gelijktijdige schrijvers zijn echter nog steeds relevant. Block storage gaat doorgaans uit van één schrijver; multi-attach-modi bestaan maar voegen complexiteit toe. Object storage laat een miljoen clients tegelijkertijd PUT-en, met last-writer-wins-semantiek (of versiebeheer om ze allemaal te bewaren). Voor een bestandsdeelsysteem waarbij twee gebruikers verschillende bestanden met dezelfde sleutel kunnen uploaden, bewaart versiebeheer op de bucket beide versies.

Wanneer bestandsoverdrachttoepassingen toch block storage nodig hebben

Het voorbehoud: de applicatie die object storage bedient, draait vaak op block-gebaseerde hosts. Een bestandsupload-API heeft lokale schijfruimte nodig voor tijdelijke opslag (multipart-stukken, virusscan), metadata-opslag (doorgaans in PostgreSQL op EBS) en logs. De objecten zelf gaan naar S3/R2/Blob; de machinerie eromheen leeft op block.

Voor doorvoerrijke streaming uploads verslaan in-memory pijplijnen schijfopslag. Bibliotheken zoals aws-sdk-js en boto3 ondersteunen streaming multipart-uploads die nooit lokale schijf raken. Een goed afgestemde uploadservice kan een bestand van 5 GB van client naar object storage pushen met minder dan 500 MB RAM en nul tijdelijke bestanden.

Metadata: het verrassende verschil

Object storage bevat metadata bij elk object: systeemmetadata (grootte, mtime, etag), gebruikersmetadata (willekeurige sleutel-waardeparen, x-amz-meta-*-headers) en tags. Je kunt zoeken op metadata via S3 Object Lambda, Inventarisrapporten, of koppelen aan DynamoDB. Block storage laat metadata geheel over aan het bestandssysteem, wat betekent dat het taggen van 10 miljoen bestanden een aangepaste database vereist.

Voor een overdrachtsapp die onmiddellijk moet kunnen antwoorden op "vind alle bestanden groter dan 100 MB die vorige week zijn geüpload door gebruikers in Nederland": objectmetadata plus een Parquet-inventaris laat je in seconden bevragen via Athena. Dezelfde vraag op een NFS-gemount block-volume is een find-commando dat uren duurt.

Versleuteling en toegangscontrole

Beide opslagtypes ondersteunen versleuteling in rust met AES-256. Object storage maakt per-object toegangscontrole eenvoudig: bucketbeleid, presigned URLs, object-ACL's en IAM-condities. Block storage-toegang is grover — het hele volume is gekoppeld of niet.

Voor veilig bestanden delen met tijdelijk begrensd downloadlinks zijn presigned S3-URL's (maximaal 7 dagen geldig) het standaardpatroon. Voor overdrachten zonder server-side plaintext-exposure werkt client-side versleuteling vóór de upload met elk object-store. HexaTransfer versleutelt met AES-256-GCM in de browser en slaat alleen cijfertekst op — de objectbackend ziet betekenisloze bytes.

De eenvoudige beslisregel

Stel drie vragen:

Benader je de data via een bestandssysteem-API (POSIX, SMB, NFS)? Zo ja, block- of bestandsopslag.
Benader je het via HTTP, wijzig je het zelden, en wil je onbeperkte schaal? Zo ja, object storage.
Is de dataset groter dan 10 TB en groeiend? Bijna altijd object storage.

Voor bestandsoverdracht-werkbelastingen is het antwoord op vraag 2 altijd ja. Gebruik S3, R2, Azure Blob of GCS voor de bestanden zelf, en reserveer block storage voor de database en weblaag die ze beheert.

Probeer het op hexatransfer.com — gratis, geen account vereist, maximaal 10 GB.