Cloud Storage: Object vs Block vs File

Three kinds of storage, and why it matters

"Just store the file" turns out to have three very different answers in the cloud, and picking the wrong one is a classic, and expensive, beginner mistake. People put a database on the wrong storage and it's slow; or they store millions of images on a disk that can only attach to one server. The three types are object, block, and file storage. Each is built for a different shape of data.

Note: Who this is for: Beginners. If you've wondered when to use S3 vs an EBS volume vs a shared file system, this clears it up for good.

The everyday analogy

Three different ways to keep your stuff, each suited to different things.

Object storage is a vast warehouse: you drop in items (objects), each with a label (key) and a receipt (metadata), and retrieve them by name over the web. Practically infinite, cheap, but you replace whole items rather than editing in place. Block storage is a hard drive attached to one machine, fast, editable byte-by-byte, perfect for an OS or database, but tied to a single server. File storage is a shared filing cabinet many machines open at once, organised in familiar folders.

The differences that actually decide it

Pick by access pattern: web-accessible blobs → object; one fast disk → block; shared folders → file.

Choosing right (it's mostly common sense)

• 
  Storing user uploads, images, videos, backups, or hosting a static site? Object storage (S3). Cheap, durable, web-accessible.


• 
  Need a disk for a server's OS or a database that wants fast, low-latency, byte-level access? Block storage (EBS).


• 
  Multiple servers need to read/write the same files at once? File storage (EFS).

Tip: When in doubt, default to object storage (S3). It's the cheapest, the most durable, and the right answer for the majority of "where do I put this file?" questions, anything that doesn't need to be a live disk.

It really is this simple to use

Object storage is just an API call away, no disk to provision, no server to attach to:

s3-basics.sh

# Create a bucket (your warehouse)

aws s3 mb s3://my-app-uploads



# Put an object in, and get it back out, by name, over the web

aws s3 cp ./photo.jpg s3://my-app-uploads/users/42/photo.jpg

aws s3 cp s3://my-app-uploads/users/42/photo.jpg ./downloaded.jpg



# List what's in there

aws s3 ls s3://my-app-uploads/users/42/

Warning: The headline-making mistake: Making an S3 bucket public when it holds private data. "Open to the world" buckets are behind countless data leaks. Keep buckets private by default and grant access deliberately.

Common mistakes that cost people money

1. 
   Storing millions of files on a block volume. A disk attaches to one server and has a size cap. Use object storage for bulk blobs.


2. 
   Running a database on object storage. Databases need fast, in-place, byte-level writes, that's block storage. S3 isn't a disk.


3. 
   Leaving buckets public. Default to private; this is the most common cloud data leak.


4. 
   Ignoring storage tiers. Rarely-accessed data left on the hot tier wastes money, lifecycle it to cheaper cold/archive tiers.


5. 
   Forgetting durability ≠ backup. S3 is extremely durable, but a bad deploy can still delete objects. Enable versioning for anything important.

Where to go next

The whole article in 4 lines

• 
  Object (S3) = a web warehouse for blobs, cheap, durable, the default for files.


• 
  Block (EBS) = a fast disk for one server, use it for OS volumes and databases.


• 
  File (EFS) = a shared folder many servers open at once.



• Default to S3 for "where do I put this file?"; keep buckets private.




• Related lesson: Disaster Recovery, where durability and backups come together.




• Practice the CLI in the Linux Lab and Bash Lab.




• See storage in the bigger picture in the Cloud Engineer path.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.