Cloud Computing Fundamentals
Storage Services
Object, block, and file storage: how each one organizes data differently, which workloads each one actually fits, and the exam-favorite mistake of treating them as interchangeable.
- Distinguish object, block, and file storage by how each one organizes and grants access to data
- Match a storage type to a workload based on its access pattern
- Explain why durability and availability are 2 separate guarantees, not one
- Identify the object, block, and file storage products offered by AWS, Azure, and Google Cloud
The same word, 3 very different jobs
"Storage" sounds like one thing until you actually need it. A photo-sharing app storing 50 million user photos, a database writing thousands of small updates a second, and 5 web servers that all need to read the same shared configuration folder are 3 completely different problems, and no single storage design solves all 3 well. Cloud providers ship 3 distinct storage types for exactly this reason: object, block, and file. Telling them apart by what they are built to do, not just by their names, is the actual skill this lesson teaches.
Object storage: buckets full of tagged files
Start with the photo-sharing app. Every image is uploaded once, read many times, and never edited in place, you replace a photo, you do not modify 4KB of it. Amazon S3, the model for object storage, organizes data around exactly that pattern: a bucket is a container, and each file inside it is an object, addressed by a unique key rather than a folder path. There is no real folder hierarchy underneath, just a flat namespace where the key "photos/vacation/beach.jpg" looks like a path but is really just a string.
Object storage trades away in-place editing for massive scale, low cost, and strong durability, S3 is designed for 99.999999999% (11 nines) durability, achieved by storing data redundantly across multiple Availability Zones. That combination is why object storage is the default choice for data lakes, backups, static website assets, and media files: workloads defined by write-once, read-often access, not by constant small edits.
Block storage: numbered chunks for one machine
Now consider a relational database writing and rewriting rows constantly. That workload needs low latency and the ability to change small pieces of data in place, exactly what object storage does not offer. Block storage, modeled on Amazon EBS, divides a volume into fixed-size chunks, addressed by number, and attaches that volume to a single instance, the same way a hard drive attaches to one computer. The operating system running on that instance can format the volume, mount it, and treat it like local disk, because functionally, that is what it is.
Block storage is zonal: an EBS volume lives in 1 specific Availability Zone and can only attach to instances in that same AZ, which is exactly why a database sitting on a single EBS volume still needs its own replication or backup strategy to survive an AZ failure. In exchange for that constraint, block storage delivers the low-latency, high-IOPS performance a running database, or a virtual machine's own boot disk, actually needs.
File storage: one folder tree, many machines at once
The third scenario, 5 web servers sharing the same configuration directory, needs something neither of the other 2 provides directly: simultaneous access from multiple machines to the same hierarchical folder structure. File storage, modeled on Amazon EFS, solves this using a network file system protocol (NFS), so every server mounts the same file system and sees the same folders and files, with changes from one visible to the others immediately. Unlike a single-attach EBS volume, a file system like EFS scales automatically as data is added and can be mounted by many EC2 instances, containers, and even on-premises servers at once.
The boundary, side by side
| Property | Object | Block | File |
|---|---|---|---|
| Data organized as | Flat namespace of key-addressed objects | Fixed-size numbered blocks | Hierarchical folders and files |
| Attaches to | Accessed over the network by any authorized client | One instance at a time (typically) | Many instances at once |
| Best access pattern | Write once, read often, no in-place edits | Frequent small reads and writes, low latency | Shared reads and writes across machines |
| Typical use case | Backups, media, data lakes, static assets | Databases, boot volumes, transactional workloads | Shared content, home directories, config shared across a fleet |
| AWS product | S3 | EBS | EFS |
| Azure product | Blob Storage | Managed Disks | Azure Files |
| Google Cloud product | Cloud Storage | Persistent Disk | Filestore |
Worked example: 1 e-commerce site, 3 storage decisions
An e-commerce platform needs to store 3 different kinds of data, and the right answer is different every time. Product photos, millions of them, uploaded once and served to shoppers constantly: object storage, because nothing about a product photo needs in-place editing, and the volume favors object storage's scale and cost. The transactional database tracking orders and inventory: block storage, because every checkout writes and rewrites rows and needs the low latency only a directly attached volume delivers. A shared directory of session cache files that 6 identical web servers behind a load balancer all need to read and write together: file storage, because it is the only one of the 3 built for simultaneous multi-instance access to the same folder tree.
Swap any 2 of those choices and the system either breaks outright, a database will not run acceptably on object storage, or works but wastes money and performance on a mismatch it did not need to make.
The misconception: cheaper does not mean interchangeable
It is tempting to look at object storage's low per-gigabyte price and assume it is simply the "budget option" you can swap in anywhere. It is not. Object storage is cheap precisely because it gives up the in-place, low-latency random access a running database or a boot volume depends on. Moving a database's data files onto object storage does not save money on a working system, it produces a system that does not work, because the storage type and the access pattern have to match. Price is a consequence of the tradeoff, not a substitute for understanding it.
Where this leaves you
3 questions sort almost any storage decision: does the data get edited in place or just written once and read, does it need to be shared by multiple machines at once, and does it need to boot or run an operating system directly. Object storage answers "written once, read often, no sharing requirement." Block storage answers "attached to one machine, edited constantly, needs speed." File storage answers "shared folder, multiple machines." The next lesson moves from raw storage to the layer most applications actually talk to directly: databases.