AWS
Intermediate 15 min read AWS

AWS Storage Services

Objects, blocks and files — the storage trinity

S3 for objects, EBS for instance disks, EFS/FSx for shared files, Glacier for archive. Picking the right store is about granularity, latency, durability and price.

S3EBSEFSGlacierobject storageblock storagefile storage
Prerequisites: AWS Service Map
Before we start

What you will learn

  • Map storage models (object/block/file/archive) to workloads
  • Explain S3 durability and availability semantics
  • Design tiering and lifecycle policies
In 60 seconds

S3 is unlimited durable objects you key by name; EBS is a virtual disk attached to a VM; EFS is a shared network filesystem; Glacier is ultra-cheap long-term archive with slow retrieval.

Introduction

What is this?

S3 (Simple Storage Service) stores objects (data + metadata) in buckets, designed for high durability (11 nines) with versioning and lifecycle tiers. EBS provides network-attached block volumes for EC2 with types for IOPS (gp3/io2) or throughput (st1/sc1). EFS and FSx offer filesystems shared across instances/AZ. S3 storage classes — Standard, Intelligent-Tiering, Standard-IA, OneZone-IA, Glacier, Deep Archive — trade cost for access latency.

Motivation

Why do you need it?

  • Object storage is the ingestion hub: logs, images, backups and data lakes all land in buckets.
  • Block storage is where VMs and databases live — low latency, persistent, resizable.
  • File storage serves shared estate that needs POSIX semantics (home dirs, shared configs).
  • Lifecycle tiering quietly cuts archive bills 90%+ while keeping data retrievable.
Think about it

Mental model

Imagine

A filing cabinet of labeled boxes, a hard disk, and a shared library

Think of

S3, EBS, EFS

S3: put labeled box #123 in the cabinet (bucket) and fetch it by label anytime. EBS: the hard disk inside one PC — fast, attached, yours. EFS: the shared library shelf everyone uses, no personal drives needed.

Mechanics

How it works

  • S3 buckets hold objects; each object has a key, ETag and metadata; S3 is strongly consistent for reads after writes.
  • Versioning keeps prior object versions; lifecycle rules move or expire objects between classes automatically.
  • EBS volumes attach to one EC2 instance at a time (unless multi-attach) and snapshot to S3 for backup/DR.
  • EFS scales to thousands of NFS clients across AZs; FSx offers Windows (SMB) and Lustre flavors.
  • Access control: bucket policies, IAM, ACLs, presigned URLs, and encryption at rest with SSE-S3/SSE-KMS/SSE-C.

AWS storage models mapped to use cases.

S3
EBS
EFS / FSx
Lifecycle
Real world

In production

  • A data lake stores raw Parquet in S3 Standard-IA with a 90-day lifecycle to Glacier, cutting storage spend 75%.
  • An EKS cluster mounts EFS for shared read-write between replicas; each pod's stateful DB uses EBS.
  • A media pipeline ingests uploads to S3, transcodes via Lambda, and serves originals via CloudFront with signed URLs.
Guidelines

Best practices

  • Encrypt everything at rest and set versioning + lifecycle from day one.
  • Separate public/private buckets structurally — never put objects in a public bucket 'temporarily'.
  • Choose EBS types by IOPS/latency for databases and throughput for analytics; use snapshots for backup, not as a tier.
  • Use transition rules for cold data and be careful with deleted-marker lifecycle gotchas.
Watch out

Common mistakes

  • Using S3 as a hot filesystem — it's object storage with higher latency and no POSIX.
  • Putting a database's data on default EBS without sizing IOPS, then hitting latency walls.
  • Forgetting egress: S3 → internet costs money; host consumers in-region or use CloudFront.
  • Enabling versioning only after a deletion incident — enable it before.
Root cause analysis

Common issues

Error
Object 'not found' after a versioned overwrite
Root cause

You're reading a deleted clock or a non-latest version

Fix

List versions; restore the last-good version or implement object lock / no-delete markers.

Error
EFS mount hangs after an AZ change
Root cause

Mount target in the removed AZ is gone; DNS walk stopped

Fix

Use the EFS DNS name that resolves across AZs and keep mount targets in surviving AZs.

Error
Volume resized in console but OS still shows old size
Root cause

The filesystem/partition wasn't extended after volume resize

Fix

Grow the partition (growpart) and filesystem (resize2fs) while attached and online.

When things break

Debugging tips

  • Object missing? Check versions, the bucket/object policy for the identity, and lifecycle deletion events.
  • Slow S3 downloads? Benchmark in-region vs out-region and check large-key multi-part GET behavior.
  • EBS full? Monitor volume utilization and auto-expand, or add volumes behind LVM.
  • 'NFS server not responding' on EFS → check mount target security groups in every AZ.
Interviews

Interview checkpoint

Practice

Hands-on lab

Prove S3 Consistency and Lifecycle Behavior
30 min · intermediate
In progress
Objectives
  • Create and version an S3 bucket
  • Demonstrate strong consistency on read-after-write
  • Define a lifecycle rule and preview its steps

Prove S3 Consistency and Lifecycle Behavior

30 min · intermediate

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

Quick quiz

0/2
1

Which AWS storage service attaches to exactly one EC2 instance at a time with the lowest latency?

2

Where do you put a 7-year archive of rarely-read payment records?

Go deeper

Official documentation

AWS — S3 user guide
docs
AWS — EBS user guide
docs
AWS — Storage classes
docs