Cloud platforms sell three quite different things under the word “storage”. They are not substitutes, and choosing the wrong one produces problems that look like performance problems and are really architecture problems.
Block storage
A block device is a virtual disk. You attach it to one server, format it with a filesystem, and it behaves like a drive — because from the operating system’s point of view it is one.
- Good for: databases, anything that expects a filesystem with normal locking semantics, the boot volume of the server itself.
- Constraint: attached to a single instance at a time. It does not exist independently of a machine that mounts it.
- Billing: you pay for the provisioned size, not the used size, for as long as the volume exists — including after the server it belonged to is deleted. Orphaned volumes are one of the most common surprise line items on any cloud bill.
Object storage
Object storage is a flat namespace of immutable blobs behind an HTTP API. There are no directories, only key prefixes that look like directories. You cannot mount it and expect a filesystem to behave; you can, and should, serve from it directly.
- Good for: user uploads, images, video, backups, static site assets, logs, data lakes, anything write-once-read-many.
- Constraint: no partial writes in the way a filesystem allows, and consistency semantics that vary by provider. Do not put a database on it.
- Billing: storage per gigabyte, plus request charges, plus — the one that catches people — egress when the data leaves the provider’s network. See what egress and bandwidth charges actually mean.
Object storage is usually the cheapest place to keep a large amount of data and the most expensive place to repeatedly read it from outside the cloud. Both facts follow from the same pricing model.
File storage
A managed network filesystem — NFS or SMB — that several servers can mount at once.
- Good for: shared assets across a fleet, legacy applications that assume a shared directory, home directories, media processing pipelines.
- Constraint: network latency is now in the path of every file operation. Applications that treat the filesystem as free will feel it immediately.
- Billing: typically per gigabyte with a throughput component, and generally the most expensive per gigabyte of the three.
Choosing between them
Two questions settle most cases:
- Does more than one machine need to write to it at the same time? If yes, it is file storage or object storage, never block.
- Does the application need filesystem semantics — seeking, locking, partial writes? If yes, it is block or file, never object.
The common architecture on a single cloud account is all three: block storage for the boot volume and the database, object storage for uploads and backups, and file storage only if something genuinely requires a shared mount.
The expensive mistakes
- Uploads on the boot volume. It works until the disk fills, and then it takes the whole server down rather than one feature.
- Backups in the same place as the data. A backup that shares a failure domain with production is a copy, not a backup. See snapshots vs backups.
- Serving object storage through the application. Every byte then costs application CPU and a second network hop for no benefit.
- Leaving volumes behind. Deleting a server frequently does not delete its disks. Check for unattached volumes after every teardown.
Where to go next
- What egress and bandwidth charges actually mean
- Snapshots vs backups: what each one protects
- How cloud billing works, and how bills get out of hand
Questions
Frequently asked
Can I run a database on object storage?
Not a conventional one. Object storage has no filesystem locking and no efficient partial writes, which are exactly what a relational database depends on. Databases belong on block storage.
Which cloud storage type is cheapest?
Object storage is normally the cheapest per gigabyte stored, but it charges per request and for egress. For data you read constantly from outside the provider's network, the total can exceed block storage.
Do I get charged for a volume after deleting the server?
On most providers, yes. Detaching or deleting an instance does not necessarily delete its block volumes, and an unattached volume keeps billing at its full provisioned size.