Storage types: object, block, and file storage

Different workloads need fundamentally different things from storage: a database needs fast, consistent, low-latency reads/writes to a disk only it touches; a static website's images need to be served over HTTP to millions of users at once; a team of render nodes might need to all read and write the same shared folder simultaneously. One storage design can't serve all three well — which is why cloud providers offer three distinct storage types, not one "storage" product with configuration knobs.

Object storage (AWS S3 is the canonical example, covered in depth in the AWS domain) stores data as discrete objects — a file's bytes plus metadata plus a unique key — accessed over HTTP, not mounted as a filesystem a program reads and writes to directly. There's no real directory hierarchy underneath (folder-like prefixes are a UI convenience, not real nested directories), and objects are typically immutable — you replace an object rather than editing part of it in place.

Best fit: static website assets, user-uploaded files (images, videos, documents), backups, data lake storage, anything accessed as whole files over a network rather than needing filesystem-level read/write semantics.

Block storage (AWS EBS is the canonical example) behaves like a raw hard disk — a set of fixed-size blocks a single virtual machine attaches to, formats with a filesystem, and reads/writes to at the byte level, exactly like a physical disk plugged into a computer. It offers the low-latency, consistent read/write performance a database or application needing a real filesystem depends on — something object storage's HTTP-based, whole-object model isn't designed for.

Best fit: a database's data files, a VM's boot/root volume, anything needing genuine filesystem semantics and low-latency access from one specific machine.

File storage (AWS EFS is the canonical example) provides a real, POSIX-style shared filesystem that multiple machines can mount and access concurrently — closer to a traditional network file share (NFS) than to either object or block storage. Where block storage is one disk for one machine, file storage is explicitly designed for many machines reading and writing the same directory tree at once.

Best fit: shared configuration or content that multiple application servers need to read simultaneously, a content-management system's uploaded-media directory shared across a fleet of web servers, render farms where many worker nodes need to read/write the same working files.

The recurring, avoidable mistake is picking the wrong shape for the job: trying to run a database directly on object storage (which lacks the low-latency, in-place-write semantics a database engine assumes a real disk provides), or trying to serve a public website's images from block storage attached to a single VM (which doesn't scale to many concurrent HTTP readers the way object storage is explicitly built for, and creates a single point of failure the VM itself becomes). Matching the storage type to the actual access pattern — HTTP objects, one-machine disk, or shared filesystem — is the entire decision; everything else (specific product names, pricing, durability guarantees) is detail on top of getting that first choice right.