Introduction
Cloud providers offer three distinct storage models: object storage, block storage, and file storage. Each was designed for a different access pattern, and choosing the wrong one can hurt performance, cost, or even make an application impossible to build correctly. Understanding the differences is one of the most practical skills in cloud architecture.
Cricket analogy: A ground staff choosing between a video archive, a groundsman's toolshed, and a shared equipment room for different needs mirrors how cloud teams must choose among object, block, and file storage for the right access pattern, or risk hurting performance or cost.
Explanation
Object storage (such as Amazon S3, Azure Blob Storage, or Google Cloud Storage) stores data as immutable objects inside a flat namespace, accessed over HTTP/HTTPS APIs. There is no real directory hierarchy — 'folders' are just prefixes in an object key. Object storage scales to virtually unlimited capacity and is ideal for unstructured data: images, videos, backups, log files, and static website assets. It is not designed for frequent partial updates or low-latency random access.
Cricket analogy: A cricket board's public video archive of every past match, tagged by date and team rather than folders, and never edited once uploaded, mirrors object storage's flat, immutable, HTTP-accessible namespace ideal for unstructured highlight reels.
Block storage (such as Amazon EBS or Azure Managed Disks) presents raw storage volumes that attach directly to a single virtual machine, much like a physical hard drive. The operating system formats the volume with a filesystem and can perform fast, low-latency random reads and writes. Block storage is required for anything that needs a real filesystem and consistent low-latency I/O — database data files, boot volumes, and transactional workloads.
Cricket analogy: A groundsman's private toolshed attached to one specific ground, formatted and organized exactly how that ground's crew needs for fast daily access, mirrors block storage's low-latency volume tied to a single instance.
File storage (such as Amazon EFS or Azure Files) provides a hierarchical, POSIX-like filesystem that can be mounted simultaneously by many servers over network protocols like NFS or SMB. It is the right choice when multiple compute instances need to read and write the same shared files concurrently, such as shared configuration, content management systems, or home directories.
Cricket analogy: A shared team locker room's kit cupboard that every player and support staff can access and update simultaneously through the same corridor mirrors file storage's shared, concurrent, multi-user filesystem.
Example
Object storage: s3://my-bucket/images/logo.png (HTTP API, flat namespace)
Block storage: /dev/xvdf mounted as /var/lib/mysql (attached to ONE VM, raw volume)
File storage: efs-12345.efs.us-east-1.amazonaws.com:/ mounted by 20 web servers (shared, hierarchical)# Mount a file storage share on Linux (NFS-based, e.g. Amazon EFS)
sudo mount -t nfs4 -o nfsvers=4.1 fs-0123456789abcdef.efs.us-east-1.amazonaws.com:/ /mnt/shared-dataAnalysis
A common mistake is trying to run a relational database directly on object storage — it cannot support the random-write, low-latency access a database engine requires, so block storage is used instead. Conversely, storing millions of user-uploaded photos on block storage would be wasteful and hard to scale, since block volumes are tied to a single instance and have finite provisioned capacity. File storage sits in between: it trades some of the raw performance of block storage for the convenience of shared, multi-instance access without building a distributed filesystem yourself.
Cricket analogy: Trying to run live ball-by-ball scoring off a public highlight archive would fail since it can't handle rapid updates, so a dedicated scorer's terminal drive is used instead, while storing millions of fan photos there would waste a single-instance resource, and a shared team folder sits between the two for concurrent access.
Key Takeaways
- Object storage: flat namespace, HTTP API, unlimited scale, best for unstructured data like backups and media.
- Block storage: raw volumes attached to one VM, low-latency random I/O, required for databases and boot disks.
- File storage: hierarchical shared filesystem over NFS/SMB, mountable by many instances at once.
- Matching workload access patterns to the right storage type avoids both performance problems and unnecessary cost.
Practice what you learned
1. Which storage type would you use as the root/boot volume for a virtual machine?
2. What is the defining characteristic of object storage's namespace?
3. Why is file storage a better fit than block storage for a shared content management system used by 10 web servers?
4. Which of these is a typical use case for object storage?
Was this page helpful?
You May Also Like
Cloud Storage Classes
Learn how hot, cool, and cold/archive storage tiers trade off cost against retrieval latency for different access patterns.
Managed Databases Overview
Learn what a cloud provider handles for you in a managed database service versus running your own database on a VM.
Virtual Machines in the Cloud
Learn how cloud virtual machines work, how to size them, and how on-demand, reserved, and spot pricing models trade off cost against reliability.