Storage Fundamentals
Cloud Platform Fundamentals
Chapter 4 · Storage Fundamentals
Chapter 3 mentioned "attached storage" as one of the choices made when launching a VM without explaining it — this chapter covers storage properly, both the storage attached directly to a VM and the separate, independent storage services that exist alongside it.
Object Storage vs. Block Storage — Two Different Models
Cloud storage splits into fundamentally different models, not just different products:
| Block storage | Object storage | |
|---|---|---|
| What it looks like | A raw disk volume, mounted as a filesystem | A flat namespace of "objects," accessed via an HTTP API |
| Access pattern | Low-latency, random-access reads/writes in fixed blocks | Whole-object reads/writes, higher per-request latency |
| Scale | Sized per volume, attached to one VM at a time | Virtually unlimited, massively parallel |
| Typical use | OS boot volumes, databases | Backups, static assets, logs, data lakes |
Object Storage — S3, Blob Storage & Cloud Storage
Applying Chapter 2's terminology map: S3 (AWS), Blob Storage (Azure), and Cloud Storage (GCP) all organize data into buckets (or containers) holding objects — each object being the actual data plus a key/name and metadata. Access happens through a REST API or SDK, not a traditional filesystem mount — a common misconception worth clarifying directly, though tools exist (FUSE-based mounts, gateway appliances) that can simulate filesystem-style access on top of the underlying API.
Object storage is typically engineered for extremely high durability — commonly advertised around "11 nines" (99.999999999%) — via automatic replication across multiple facilities within a region. Durability and availability are genuinely different claims, worth keeping separate: durability means the data itself won't be lost; availability means the data is currently reachable when requested. A brief regional service disruption can affect availability without the underlying data ever being at risk of loss.
Block Storage — EBS, Managed Disks & Persistent Disk
Block storage (EBS on AWS, Managed Disks on Azure, Persistent Disk on GCP) attaches directly to a single VM as a virtual disk, used for OS boot volumes and anything needing low-latency, random-access I/O — databases especially. It persists independently of the VM's own lifecycle: a volume can be detached from one VM and reattached to another, and — directly echoing Chapter 3's stopped-VM billing gotcha — it continues to exist, and continues billing, even while its VM is stopped.
Snapshots capture a point-in-time backup of a block volume — incremental after the first full snapshot, and typically stored in the object storage layer underneath.
A Third Option, Briefly — File Storage
Neither block nor object storage directly solves one common need: shared, simultaneous access from multiple VMs at once. That's what network file storage (EFS on AWS, Azure Files, Filestore on GCP) is specifically for — a mountable, shared filesystem multiple VMs can read and write to concurrently, used for shared application data, home directories, or content management systems that genuinely need simultaneous multi-VM access. It's a real, distinct third category worth knowing exists, even though this course doesn't go deep on it.
Choosing Between Them — A Practical Decision Table
| Need | Right choice |
|---|---|
| OS boot disk / low-latency database storage | Block storage |
| Large numbers of files, backups, static assets, cost-effective at scale | Object storage |
| Shared access from multiple VMs simultaneously | File storage |
Storage Tiers & Lifecycle Policies
Object storage typically offers multiple tiers trading cost against retrieval speed: standard/frequent-access, infrequent-access, and archive/cold storage (S3 Standard/IA/Glacier; Azure Hot/Cool/Archive; GCP Standard/Nearline/Coldline/Archive). Lifecycle policies automatically move objects between tiers — or delete them entirely — after a defined age, a genuinely practical cost-management tool that Chapter 9 builds on further.
Data Durability, Redundancy & Replication
Both block and object storage typically offer a choice of redundancy — single-zone, multi-zone, or cross-region replication — trading additional cost for protection against a zone- or region-level failure, directly building on Chapter 1's regions/availability-zones concept.
Hands-On Exercises
Classify each storage need as block, object, or file storage, and justify each choice: (a) an OS boot disk for a VM, (b) millions of small log files that must be retained for compliance for 7 years, (c) a shared directory accessed simultaneously by 10 VMs.
📄 View solutionExplain the difference between durability and availability, and give one concrete example incident for each — one that affects durability, and one that affects availability without touching durability at all.
📄 View solutionA customer is surprised that restoring an old backup took several hours and incurred an unexpected extra charge. Explain why this happened, and what a support engineer should proactively communicate about lifecycle policies before this becomes a surprise.
📄 View solutionChapter 4 Quick Reference
- Block storage — mounted, low-latency, one VM at a time (OS disks, databases); object storage — HTTP API, massively scalable (backups, assets, logs)
- File storage — the third option, mountable and shared across multiple VMs simultaneously (EFS/Azure Files/Filestore)
- Block volumes persist and keep billing independently of the VM, even while stopped — a direct callback to Chapter 3's billing gotcha
- Durability (will the data survive) ≠ availability (can it be reached right now) — a real distinction worth using in support conversations
- Lifecycle policies automatically move objects to cheaper, slower tiers or delete them — archive-tier retrieval is neither instant nor free
- Redundancy (single-zone/multi-zone/cross-region) trades cost for protection against zone/region failure
- Next chapter: Networking Fundamentals — VPCs/VNets, subnets, load balancers, and DNS