Cloud Fundamentals
Intermediate 15 min read Cloud Fundamentals

Cloud Storage: Object, Block & File

Cloud storage comes in three flavors: object, block and file. Learn how S3, EBS and EFS (and their Azure/GCP equivalents) differ, how durability and lifecycle rules work, and when to pick hot versus cold tiers.

object storageblock storagefile storageS3EBSEFSdurabilitystorage tierslifecycle
Prerequisites: Cloud Computing Fundamentals
Introduction

What is this?

Cloud storage is split by access pattern. Object storage (Amazon S3, Azure Blob, GCS) stores files as objects in flat buckets — massively durable, HTTPS-accessible, ideal for data at rest. Block storage (Amazon EBS, Azure managed disks, GCE persistent disks) attaches raw volumes to a single VM for low-latency database workloads. File storage (Amazon EFS, Azure Files, Filestore) serves shared network filesystems over NFS or SMB to many clients.

Motivation

Why do you need it?

  • Choosing the wrong storage type wastes money and performance — putting a database on object storage is a classic disaster.
  • Durability claims (S3's eleven nines) only hold when you follow the provider's replication and versioning guidance.
  • Lifecycle policies automate hot-to-cold tiering, which is where most storage cost lives.
  • Backups, logs, media, databases and shared code each map to one of the three types.
  • Block storage is what your VMs boot from; you will attach, resize and snapshot it constantly.
Think about it

Mental model

Imagine

A warehouse, a desk drawer, and a shared filing cabinet

Think of

Object, block and file storage

Object storage is a warehouse with numbered bins you reach over the web — great for archives, slow to use as a workspace. Block storage is your personal desk drawer attached to your desk (VM) — fastest, but only you can use it. File storage is the shared filing cabinet on NFS — many desks can reach it, but it is slower than the drawer.

Mechanics

How it works

  • Object storage keeps data as objects (data + metadata + a unique key) in a flat namespace under an HTTPS endpoint; the provider replicates each object across multiple devices and AZs.
  • Block storage formats raw volumes into a filesystem attached to one instance over the network; reads and writes go to fixed-size blocks with an in-memory cache for speed.
  • File storage exports a POSIX/NFS/SMB share that many instances mount simultaneously, with the provider handling locking and consistency.
  • Durability comes from replication: objects are copied (S3 Standard stores 3 copies across 2 or more AZs), giving 99.999999999% annual durability.
  • Lifecycle rules age data automatically: hot tiers serve active data fast, while infrequent-access and archive tiers (S3 Glacier, Azure Cool/Cold) cost less but charge retrieval fees.

Choosing a storage type by access pattern.

Data source
Object (S3/Blob/GCS)
Block (EBS/disks)
File (EFS/Files)
Lifecycle
Durability check
Reference

Key commands

df -h

See attached block volumes and their usage from inside a VM.

ls -lah /data

Inspect file sizes and permissions on a shared or local filesystem.

find /data -type f

Enumerate every file in a directory tree — useful before a lifecycle move.

wc -c /data/big-object.log

Report the exact byte size of a file for capacity planning.

curl -sI <object-url>

Fetch object headers to check storage class, ETag and encryption state.

Hands-on

Examples

Inspect object storage metadata over HTTPS

Inspect object storage metadata over HTTPS
$ curl -sI https://devopsforge-assets.s3.amazonaws.com/logo.png | grep -i -E "HTTP|x-amz-storage-class|ETag|Last-Modified"
HTTP/1.1 200 OK
x-amz-storage-class: STANDARD
Last-Modified: Tue, 15 Jul 2025 09:00:00 GMT
ETag: "9f2c8a1d6b3e4f5a0c7d8e9f1a2b3c4d"

Every object in S3 is addressable over HTTPS. The response headers expose the storage class (STANDARD here), when the object was last changed and its ETag (a content checksum). Storage class and encryption headers are the first thing to check when an object is unexpectedly expensive to serve or slow to download.

Real world

In production

  • Media and static assets are served straight from object storage, often via a CDN in front.
  • Databases run on block storage with snapshots for backup and point-in-time recovery.
  • Shared application state (uploads, configs) lives on file storage mounted by many instances.
  • Logs and backups age automatically from hot to archive classes to cut storage bills by 80% or more.
Guidelines

Best practices

  • Match the storage type to the workload: block for databases, object for data at rest, file for shared state.
  • Enable versioning and object lock on buckets that hold critical or audit data.
  • Set lifecycle rules early — you cannot retroactively budget for a runaway log bucket.
  • Encrypt everything at rest (SSE-KMS) and in transit (TLS) as a baseline, not an afterthought.
  • Right-size block volumes; resizing is possible, but every over-provisioned GB is billed monthly.
Watch out

Common mistakes

  • Treating object storage like a filesystem and paying per-request costs on millions of tiny GETs.
  • Running a production database on an unmounted, un-backed-up block volume.
  • Forgetting that archive tiers charge retrieval fees, so 'cheap' cold storage can surprise you.
  • Putting a public bucket on the internet without access controls and leaking customer data.
Root cause analysis

Common issues

Error
No space left on device but df shows free space
Root cause

Inodes exhausted, or a deleted file is still held open by a running process.

Fix

Check inode pressure with find / -type f 2>/dev/null | wc -l and lsof for deleted files, then release them.

Error
Object download is extremely slow from the cold tier
Root cause

The object lives in an archive class that requires restoration before reads.

Fix

Initiate an object restore, wait for the retrieval window, then serve it; or reclassify the tier.

Error
AccessDenied when reading a public-looking bucket
Root cause

The bucket policy or the object's ACL blocks anonymous access.

Fix

Review the bucket policy and object ACL, or use credentials with s3:GetObject permission.

When things break

Debugging tips

  • Use df -h inside the VM to separate disk-full from application failure.
  • Check the storage class header (x-amz-storage-class) before assuming why an object is slow to serve.
  • Compare ETags between a source object and its copy to prove whether replication is in sync.
  • Watch IOPS and latency metrics on block volumes; saturated volumes degrade far before they fail.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Storage Tiering on a Filesystem
25 min · intermediate
In progress
Objectives
  • Create hot, warm and cold storage directories
  • Write objects with realistic content and inspect sizes
  • Move files between tiers the way lifecycle rules do
  • Verify the final layout and disk usage

Simulate Storage Tiering on a Filesystem

25 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which storage type provides byte-range, low-latency access typically attached to a single VM?

2

Which storage type is best for immutable, web-accessible data like images and backups?

3

S3 Standard provides 99.999999999% (eleven nines) of object durability.

Quick reference

Cheat sheet

Which storage type?
Object (S3/Blob/GCS)Unstructured data, HTTPS, tiered — media, logs, backups
Block (EBS/disks)Single VM, low latency — OS, databases
File (EFS/Files)Shared NFS/SMB — multi-instance app state
S3 StandardHot tier, 3 AZs, eleven nines durability
S3 GlacierArchive tier, minutes-to-hours retrieval, ~90% cheaper
Inspect storage from the shell
df -hVolume usage and free space
ls -lah /dataFile sizes and timestamps
find /data -type fWalk every file in a tree
wc -c <file>Exact byte size
curl -sI <s3-url>Storage class, ETag, headers
Go deeper

Official documentation

Amazon S3: User Guide
docs
Amazon S3: Storage Classes
docs
Azure: Blob Storage Access Tiers
docs
Google Cloud: Storage Classes
docs