S3 vs EBS vs EFS: Picking the Right AWS Storage
AWS offers three fundamental storage types, and exam questions test whether you can match one to a described workload. The key distinction: object storage (S3) is accessed over HTTP at unlimited scale, block storage (EBS) is a disk attached to one instance, and file storage (EFS) is a mounted file system shared by many instances.
S3 — object storage
S3 stores objects (files plus metadata) in buckets, replicated across multiple AZs for extreme durability. You access it via API — you cannot mount it as a disk. It is the answer for static assets, backups, data lakes, media, and anything that needs 11-nines durability and unlimited scale.
EBS — block storage
EBS volumes behave like hard drives attached to a single EC2 instance in a single AZ. Use it for boot volumes, databases, and any workload needing low-latency block access. Snapshots to S3 provide backup and cross-AZ/Region portability. io2 volumes deliver provisioned IOPS for demanding databases.
EFS — shared file storage
EFS is a managed NFS file system that many instances across multiple AZs mount simultaneously. When an Auto Scaling group must share files — content management, shared config, web roots — EFS is the standard answer. (Windows workloads needing SMB should look at FSx for Windows File Server.)
Quick decision table
- Unlimited durable storage accessed via API → S3
- Disk for one instance / database storage → EBS
- Shared file system across a multi-AZ fleet → EFS
- Ephemeral scratch storage on the instance → instance store