One word, three different things
“Storage” in the cloud is not a single product. Providers usually offer three broad styles: object, block and file. They all keep data, but they organize it differently and suit different jobs. Choosing the wrong one tends to cause trouble later in cost, speed or convenience.
A helpful comparison is a warehouse, a set of empty shelves and a filing cabinet. Each holds things, but you use each one differently.
Object storage
Object storage keeps data as separate items called objects. Each object is the file itself, a unique identifier, and some descriptive information (metadata) such as its type or when it was created. Objects live in a flat container, often called a bucket, rather than in a tree of folders. Some tools display slashes in names to make it look like folders, but underneath it is a flat collection.
You usually reach objects through web requests rather than by opening them like a drive on your computer. This is where API basics become relevant: applications ask for an object by its identifier and receive it.
Typically suits:
- photos, videos and documents that a website or app serves to users
- backups and archives
- large collections of files used for analysis, such as the raw material that feeds big data work
- log files that accumulate steadily
Strengths: it generally scales to very large amounts of data, is relatively inexpensive per unit stored, and is designed so that data is kept in several places.
Limits: you generally replace a whole object rather than editing a small part of it, and it is not meant for workloads that need frequent small changes with very fast response times.
Block storage
Block storage divides data into fixed-size pieces called blocks, which behave like the raw disk inside a computer. A virtual server sees a block volume as a drive. The server’s operating system then formats it with a file system and uses it as it would a physical disk.
Typically suits:
- the system disk of a virtual server
- databases that read and write small pieces of data often, such as relational databases
- applications that need fast, consistent response times
Strengths: low delay and good for frequent small updates.
Limits: a block volume is normally attached to one server at a time, it is often priced by the amount you set aside whether or not you fill it, and it does not make sense for serving files directly to the public.
Because it behaves like a disk, you are responsible for the layer above: the formatting, and for making sure its contents are copied elsewhere. Snapshots, which capture the state of a volume at a moment, are a common feature, but they are not a complete protection plan on their own.
File storage
File storage presents a shared set of folders and files, much like a network drive in an office. Several computers can connect at once, browse a familiar directory tree, and open, edit and save files using normal tools. Permissions are usually set per folder or file.
Typically suits:
- shared team folders
- applications that expect a conventional directory structure and need several servers to see the same files
- moving older software to the cloud when it was written for a shared drive
Strengths: it feels familiar, supports editing in place and allows sharing between machines.
Limits: it is often more expensive than object storage for the same volume, and very large scale or very heavy access can be harder to manage.
Side by side
| Object | Block | File | |
|---|---|---|---|
| Organized as | Flat set of objects with metadata | Raw fixed-size blocks | Folders and files |
| Reached through | Web requests | Attached to a server as a disk | Network share |
| Edits | Replace whole object | Small changes are efficient | Edit in place |
| Sharing | Many users or apps via requests | Usually one server at a time | Many servers at once |
| Common use | Media, backups, archives | Databases, system disks | Team folders, shared content |
Questions that help you choose
- How is the data accessed? Served over the web, mounted as a disk, or shared as folders?
- How often does it change? Rarely updated data suits objects; constantly changing data suits blocks.
- How much is there, and will it grow? Large and growing collections favor object storage on cost grounds.
- Who needs to see it at once? Several servers reading the same files points toward file storage.
- How fast must it respond? Latency-sensitive workloads lean to block storage.
Many real systems use all three: a server runs from block storage, shares working documents on a file share, and sends finished media and backups to object storage.
Habits that apply to any type
- Classify before you store. Knowing how sensitive information is, as covered under data classification, guides where it should go and who may reach it.
- Encrypt. Protecting stored and transmitted data with data encryption is a sensible default.
- Control access tightly. A common cause of exposed data is a storage container set to be readable by anyone. Apply least privilege.
- Plan for deletion. Storage that is never cleaned up keeps growing and billing. A data retention schedule helps.
- Do not confuse durability with backup. Providers may keep multiple copies to guard against hardware failure, but that does not protect you from an accidental delete or an overwrite. Follow your own backup strategy.
The right choice depends on the job. Matching the storage type to how the data is used usually saves money and avoids awkward redesigns later.