S3 vs EBS vs EFS: choosing storage without guessing

Three storage services, three different shapes of problem. The wrong choice is usually discovered on the bill, months later.

S3 — objects over HTTP

Anything you would serve or store as a whole file: images, backups, logs, static sites, data lake objects. Accessed over HTTP, effectively unlimited size, eleven nines of durability.

Use S3 when the access pattern is "get this object" rather than "read byte 400 of this file". Lifecycle rules and storage classes make it the cheapest place to keep data you rarely touch.

EBS — a disk attached to one instance

A block device that behaves like a hard drive. An EC2 instance mounts it, formats it, writes to it. It lives in one Availability Zone, and it can only attach to instances in that same AZ.

Use EBS for databases, operating system volumes, and anything that needs a filesystem with low latency and predictable IOPS. Snapshots are how you back it up.

EFS — a shared filesystem

NFS that many instances can mount at once, across AZs. Pay per gigabyte stored, and it grows and shrinks automatically.

Use EFS when several machines genuinely need the same files at the same time: shared content directories, home directories, lift-and-shift applications that expect POSIX.

The decision in one line each

• One file, fetched by many clients, over HTTP → S3.
• One disk, one instance, low latency → EBS.
• One filesystem, many instances → EFS.

Cost traps worth knowing

EBS charges for provisioned capacity, not used space — a 500 GB volume costs the same whether it holds 5 GB or 500 GB. EFS charges per gigabyte but adds throughput charges depending on mode. S3 charges for requests and retrieval, which is what surprises people who move infrequently accessed data to a cold tier and then read it daily.

In the live Solutions Architect batch we price all three for the same workload and watch the numbers diverge.