Object Storage vs Block Storage
Two things both called storage, with almost nothing in common. Choosing the wrong one makes straightforward work unnecessarily hard.
Both are sold as storage and they are not interchangeable. The difference is
not performance or price; it is how you reach the data, and that determines what
each is good for.
Block storage
A virtual disk attached to a server. You format it with a filesystem and it
behaves like a drive: open files, seek within them, write to the middle of one.
- Attached to one instance at a time, in almost all cases.
- Fixed, provisioned size, which you pay for whether or not it is full.
- Low latency, suitable for random access.
- Exists within one availability zone.
This is what your operating system, your installed software and your database
files live on. Anything expecting a filesystem needs block storage.
Object storage
A service you talk to over HTTP. You store whole objects under keys and
retrieve them whole. There is no filesystem and no seeking: updating part of an
object means replacing it.
- Reachable from anywhere, by many clients simultaneously.
- No capacity to provision; you pay for what you store.
- Higher latency per request, very high aggregate throughput.
- Replicated across facilities, with much higher durability.
- Can serve directly to browsers, often behind a CDN.
Despite the folder-like paths in object keys, there are no directories. The
slashes are part of the name.
What to put where
Database files: block storage. Databases depend on random
access and specific write ordering. This is not a preference; most databases
cannot run correctly on object storage.
User uploads: object storage. Writing uploads to a server’s
disk ties them to that machine, which breaks as soon as you have two servers and
complicates every rebuild. Moving uploads to object storage is one of the
highest-value changes in a small deployment.
Static assets: object storage, behind a CDN. Cheaper than
serving from your server and faster for users.
Backups: object storage. Higher durability, no capacity to
manage, and it can live in a different region or account, which is the property
that matters for backups. See
backups: what your provider
does not do for you.
Logs for retention: object storage, with lifecycle rules to
expire them.
The operating system and installed software: block storage.
There is no alternative.
Cost behaves differently
Block storage bills for provisioned capacity. A hundred gigabyte volume with
three gigabytes on it costs the same as a full one, so oversizing is a permanent
cost.
Object storage bills for what you actually store, plus requests, plus egress.
For small volumes the request charges are negligible; for workloads making very
large numbers of small requests they become visible. And serving large files
publicly makes egress the dominant cost, which is covered in
data egress fees explained.
Durability is not comparable
Object storage is typically replicated across multiple facilities and is
substantially more durable than a block volume, which lives in one zone.
Neither is a backup. A deletion replicates perfectly in both cases. Durable
means the provider will not lose it; it does not mean you can recover a previous
version unless you enabled versioning.
A useful rule
If something needs a filesystem, it needs block storage. If it is a whole
file that gets written once and read many times, it belongs in object
storage.
Most small deployments start with everything on one volume because that is
the default, and the first improvement is almost always moving uploads and
backups off it. That single change makes the server disposable, which makes
scaling, rebuilding and migrating dramatically easier.