Cloud providers offer several genuinely different storage models, not one generic “storage” product with different price tiers. Choosing the wrong one for a given workload is a common, avoidable architecture mistake — one that usually shows up as a scaling or performance problem much later, once a lot of code already assumes the wrong access pattern.

Block storage: raw chunks a server formats itself

Block storage presents storage as raw, fixed-size blocks of data, addressable individually, with no inherent file structure of their own — the attached operating system is responsible for formatting the block device with a filesystem and managing files on top of it, exactly as it would with a physical hard drive. This is the model behind services like AWS’s EBS or Google Cloud’s Persistent Disk: virtual disks attached to a single virtual machine, offering low latency and the flexibility to use whatever filesystem the OS supports.

Block storage’s defining constraint is that it’s typically attached to one server at a time. It’s the right choice for a database’s primary storage, or a virtual machine’s boot volume — workloads that need fast, low-latency, block-level access from a single attached instance.

File storage: shared, hierarchical, familiar

File storage organizes data in the traditional hierarchical structure of folders and files that most people are already familiar with, and — unlike typical block storage — is designed to be mounted and accessed concurrently by multiple servers at once, using standard network file-sharing protocols. This makes it the right fit for workloads that genuinely need a shared filesystem across multiple machines: shared application data, home directories, or content multiple servers in a cluster all need to read and write through normal file operations.

Object storage: whole objects, metadata, and HTTP access

Object storage takes a different approach entirely: instead of raw blocks or a hierarchical filesystem, it stores discrete objects — each one a whole file plus associated metadata and a unique identifier — accessed over an HTTP API rather than mounted as a traditional filesystem. Amazon S3, the service that helped establish this model at scale (see A Brief History of Cloud Computing for its 2006 launch), and Google Cloud’s equivalent, described in Google’s overview of object storage, are the canonical examples.

Object storage’s architecture is what lets it scale to a size neither block nor file storage is designed for — effectively unlimited numbers of objects, accessed concurrently by an effectively unlimited number of clients, with strong durability guarantees, at a lower cost per gigabyte than block storage. The trade-off is access pattern: objects are typically retrieved or replaced wholesale rather than modified in place the way a block device or a mounted file can be, and typical latency per request is higher than block storage’s direct, low-level access.

Matching the model to the workload

A few patterns hold in most architectures:

  • A database’s primary data files almost always belong on block storage, where the database engine needs fast, low-latency, direct access to specific bytes.
  • Static assets, backups, logs, and media files — anything read and written as whole files, at scale, from potentially many clients — are usually a strong fit for object storage, which is why it’s the default choice for a CDN’s origin, discussed in What Is a CDN?.
  • Shared configuration, shared application state across a cluster of servers, or legacy applications built around a traditional filesystem are the more typical file storage use case.

Getting this wrong is a common, if quiet, cost driver in its own right — provisioning expensive, low-latency block storage for data that’s really just being written once and read occasionally is one of the oversized-resource patterns discussed in Why Cloud Bills Get Out of Control.

Key takeaway

Block, file, and object storage aren’t interchangeable tiers of the same thing — they’re genuinely different models suited to different access patterns: block for fast, direct access from a single attached server, file for a shared traditional filesystem across multiple servers, and object for massive-scale, HTTP-accessed, whole-file storage. Picking based on actual access pattern, rather than habit or whichever option is cheapest per gigabyte, avoids a class of scaling problems that only shows up once a workload has already outgrown the wrong choice.

This article explains general cloud storage concepts; specific product names, performance characteristics, and pricing vary by provider. See our disclaimer.