Cloud providers sell storage in three shapes: block, file and object. They differ in what unit you work with, how you reach it, and how far it scales. Picking the wrong one is a common design mistake, for example putting a database on object storage or shared uploads on a single disk. This note explains each shape without tying it to one vendor. The AWS services come in the next notes.
The three shapes at a glance#
The quickest way to tell them apart is the unit you read and write.
| Block | File | Object | |
|---|---|---|---|
| Unit | Fixed-size block with an address | File inside a folder tree | Object: data, metadata and a key |
| Access | Raw device; the OS puts a file system on it | Paths over a network protocol (NFS, SMB) | HTTP API calls (PUT, GET) by key |
| Structure | None until you format it | Hierarchy of folders | Flat namespace inside a bucket |
| Sharing | Usually one machine at a time | Many machines at once | Any client with permission, anywhere |
| Latency | Lowest | Low to moderate | Higher per request |
| Scaling | You resize the volume | Grows with data (managed services) | Grows with no practical limit |
| Good for | Databases, VM boot disks | Shared content, home folders | Backups, media, logs, data lakes |
Every major cloud sells all three. On AWS they map to EBS (block), EFS (file) and S3 (object). On Google Cloud they map to Persistent Disk, Filestore and Cloud Storage. On Azure they map to Managed Disks, Azure Files and Blob Storage.
Block storage#
Each shape makes more sense once you see how it works, starting with the lowest level. Block storage splits data into fixed-size blocks, often 512 bytes or 4 KiB. Each block has a number called a logical block address (LBA). The device knows nothing about files; it only stores and returns numbered blocks.
How block I/O works#
Since the device only knows block numbers, something else has to know about files. A file system (ext4, XFS, NTFS) sits on top of the device. It keeps metadata that maps each file to the blocks that hold it. The blocks of one file do not need to sit next to each other.
When an application reads a file, the request goes through several layers:
- The application calls
open()andread()on/data/report.csv. - The kernel passes the call to the file system.
- The file system looks up its metadata and finds that the bytes live in, say, blocks 1002 to 1008.
- The kernel sends a block read for those addresses to the device driver.
- The device (a local disk, or a network volume such as EBS) returns the blocks.
- The file system puts the bytes in order and hands them back to the application.
A write follows the same path in reverse. A 10 MiB file on a file system with 4 KiB blocks takes 2,560 blocks.
Why it is fast#
Block storage gives random access, which is what makes it fast for databases. To change one row in a database file, the database rewrites only the blocks that hold that row. It does not read or rewrite the whole file. This is why databases and VM disks run on block storage.
Trade-offs#
- You must format, mount and manage a file system on it.
- A volume usually attaches to one machine at a time, so it is not a sharing tool.
- You choose a size up front and grow it yourself.
- It costs more per GB than object storage.
File storage#
Block storage leaves the file system to you and ties the volume to one machine. File storage fixes both by giving you a ready-made file system over the network. Clients mount it and see ordinary folders and files. The server handles the blocks underneath, and this setup is called network-attached storage (NAS).
- Clients talk to it with a file protocol: NFS (common on Linux) or SMB (common on Windows).
- Many machines can mount the same file system at once and see the same files.
- It supports normal file operations: rename, list a folder, lock a file, change permissions.
- Concurrent writers to the same file can still clash. Use file locks or coordinate in the application.
File storage fits workloads that expect a shared POSIX-style file system. Examples are a fleet of web servers that serve the same uploaded images, build servers that share artifacts, or user home folders.
NAS vs local storage#
The obvious alternative to a network file system is a disk in the machine itself. Local storage is a disk attached directly to the machine, while NAS sits on the network and serves many machines.
| NAS (network file storage) | Local storage | |
|---|---|---|
| Location | On the network, outside the machine | Inside or directly attached to the machine |
| Access | Many machines over the network | Only that machine |
| Latency | Higher: every call crosses the network | Lower: no network hop |
| Scaling | Add capacity on the storage side | Limited by the machine's slots |
| If the machine dies | Data is safe on the NAS | Data may be lost with it |
| Cloud examples | Amazon EFS, Google Cloud Filestore | EC2 instance store |
Object storage#
The third shape drops files and folders altogether. Object storage keeps each item as an object in a bucket. An object has three parts:
- Data: the bytes, such as a photo or a log file.
- Metadata: content type, size, and your own tags.
- Key: a unique name in the bucket, such as
users/42/avatar.png.
The namespace is flat. The slashes in a key look like folders, but there are no real directories, so "rename a folder" means copying every object under that prefix.
You reach objects over HTTPS with an API. You upload a whole object, and you read it whole or by byte range. You cannot edit the middle of an object in place; you replace it. In return, the provider spreads objects across many servers and locations. It scales to billions of objects with no capacity planning, and it is the cheapest of the three per GB.
Because metadata is separate from data, a client can read an object's metadata without downloading the bytes. Listing filters only by key prefix, not by metadata. Object storage still has no query language, so keep searchable details in a database. For the pattern of "metadata in the database, bytes in the blob store", see Core Databases.
Choosing between them#
The three shapes come down to access patterns, so start by asking how your application reads and writes the data.
- Small random reads and writes from one server (a database, a boot disk): block storage.
- Many servers that need the same files through normal file calls: file storage.
- Whole files written once and read many times, from anywhere (images, video, backups, logs, analytics data): object storage.
- Scratch space that can vanish (caches, temporary sort files): local disk on the machine.
You may be tempted to blur the lines. Tools exist that mount an object store as if it were a file system. They work for simple reads, but rename, append and locking behave differently from a real file system. Do not run a database on them.
Key takeaways#
- Block storage stores numbered blocks. A file system on top maps files to blocks, which gives fast random access.
- File storage (NAS) is a shared file system over NFS or SMB that many machines mount at once.
- Object storage keeps whole objects with metadata under keys in a flat bucket, reached over HTTP. It scales furthest and costs least.
- Use block for databases and boot disks, file for shared files, object for backups, media and logs.
- Local disks are fastest but tie the data to one machine.