Cloud Infrastructure Fundamentals · Module 05 of 12

Block, file and object storage

Choose storage by access pattern: block devices for attached volumes, shared filesystems for file semantics, and object storage for API-addressed durable objects.

Learning objectives

By the end of this module, you should be able to:

Differentiate block, file and object storage semantics.
Match persistence requirements to workload access patterns.
Explain lifecycle, versioning and backup as separate controls.

Block storage behaves like a device

Block volumes are commonly attached to compute and formatted with a filesystem. Their lifecycle, availability-zone constraints and snapshot model matter to recovery design.

File storage provides shared filesystem semantics

Managed file services expose files/directories to multiple clients and suit workloads requiring shared POSIX/NFS-style access patterns.

Object storage is API-addressed and massively scalable

Objects live in buckets/containers with keys and metadata. Object storage is excellent for backups, artifacts, logs and static assets, but it is not a drop-in replacement for a local POSIX filesystem.

Worked examples

See the idea in practice.

Storage decision

Database data directory → block volume
Shared content repository → managed file service
Build artifacts/backups → object storage

Start from access semantics, durability and sharing requirements.
Encryption, retention and lifecycle policies are orthogonal decisions.

Core lab · Modes 1–2 · Concept + local simulation

Lab — Classify storage requirements

Goal: Use a local decision table to map workloads to storage types.

Before you start

No cloud account required.

STEP 1

Create workload requirements

cat > /tmp/storage.csv <<'EOF'
workload,shared_files,posix,object_api,choice
database,no,yes,no,block
team_share,yes,yes,no,file
backup,no,no,yes,object
static_assets,no,no,yes,object
EOF

STEP 2

Validate choices

python3 - <<'PY'
import csv
rows=list(csv.DictReader(open('/tmp/storage.csv')))
expect={'database':'block','team_share':'file','backup':'object','static_assets':'object'}
for r in rows: assert r['choice']==expect[r['workload']]
print('storage choices validated')
PY

STEP 3

Add recovery controls

For each row, write which controls you would add: snapshots, versioning, replication, retention or backup.

Verify

All four workloads map to the intended storage semantics.
You can name at least one recovery control per workload.

Expected outcome

You choose storage from workload semantics instead of product familiarity.

Diagnose / troubleshoot

If the storage classifier disagrees, restate whether the workload needs block-device, shared-filesystem or object-API semantics before choosing a product.
If a recovery design relies only on replication, simulate deletion/corruption and identify the independent recovery point.

Real-world connection

Architecture reviews should separate primary storage choice from backup, retention, encryption and cross-region recovery requirements.

Mode 3 · Optional AWS lab

Optional AWS — inspect storage service metadata

Relate object, block and file concepts to existing AWS resources without creating storage.

Resources created

None — this is a read-only inspection lab.

Estimated cost / risk

Expected incremental resource cost: none because the supplied commands are read-only.
Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

Optional sandbox AWS account and AWS CLI.
Use a least-privilege or federated identity; do not paste long-lived access keys into course files.

AWS 1

aws s3api list-buckets --query 'Buckets[].Name' --output table

AWS 2

aws ec2 describe-volumes --query 'Volumes[].{Id:VolumeId,Type:VolumeType,SizeGiB:Size,State:State}' --output table

AWS 3

aws efs describe-file-systems --query 'FileSystems[].{Id:FileSystemId,State:LifeCycleState}' --output table

Verify

Existing object, block or file resources are visible if the sandbox contains them.
No AWS resources are created by the supplied commands.

Cleanup

No AWS cleanup is required because this lab creates no AWS resources.

Warnings

Optional only: not required for course completion or the main validator.
Listing permissions vary by organization; a permission denial is not a reason to broaden the lab identity.

Avoid these traps

Common mistakes

Using instance-local ephemeral storage for critical durable data.
Assuming replication automatically provides point-in-time recovery.
Choosing storage only by price per GB.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Which storage model is API-addressed by keys?

Object storage.

2Which model commonly backs an attached filesystem on a VM?

Block storage.

3Why are backups different from replication?

Replication improves availability but can also replicate deletion or corruption; backups provide separate recovery points.

4Scenario: a replicated file is accidentally deleted and the deletion immediately replicates. Which separate control is needed to recover an older copy?

A retained backup/versioning or point-in-time recovery mechanism; replication alone can propagate the deletion.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.