Side by side
| Dimension | S3 | EBS |
|---|---|---|
| Storage model | S3: Objects addressed by bucket and key | EBS: Block volumes attached to EC2 |
| Access pattern | API requests; whole-object writes and byte-range reads | Random block reads and in-place writes |
| Typical workloads | Media, backups, archives, data lakes | Database files, journals, application filesystems |
| Latency | Higher per-request latency; suited to bulk transfer | Lower-latency I/O; depends on volume and instance |
| Sharing | Many clients access objects through APIs | Usually one attached instance; limited Multi-Attach support |
| Failure boundary | S3 Standard stores data across multiple AZs | Volume data replicated within one AZ |
| Capacity and performance | No volume provisioning; request patterns still matter | Provision capacity and choose IOPS/throughput limits |
| Cost drivers | Stored bytes, requests, retrieval, and data transfer | Provisioned capacity, performance, snapshots, and transfer |
The differences that matter
The access model changes the application. S3 exposes objects through APIs, not a general-purpose POSIX filesystem. For ordinary object updates, write a replacement object rather than modifying arbitrary bytes in place. EBS exposes blocks, so a filesystem or database can update pages, maintain indexes, and issue durable log writes. Mounting S3 through an adapter does not make it equivalent to a local disk.
Latency and throughput are different requirements. A database doing small random reads and synchronous log writes generally needs EBS-style block storage. A video pipeline transferring large files can use S3 with parallel requests and multipart uploads. For EBS, check both volume limits and the EC2 instance's EBS bandwidth; for S3, consider request concurrency, object sizes, retries, and client connection reuse.
The failure boundaries differ. S3 Standard stores data across multiple Availability Zones, while an EBS volume is replicated within a single AZ and attaches to instances in that AZ. EBS can survive the loss of an attached instance, but surviving an AZ outage requires a separate plan, such as database replication to another AZ. EBS snapshots provide backups, not a continuously available standby. Some S3 storage classes are single-AZ, so name the class rather than assuming every S3 option has the same resilience.
Sharing storage does not provide application-level coordination. S3 supports strong read-after-write consistency for object writes, overwrites, deletes, and listings, but it does not provide general transactions across objects. EBS does not coordinate competing application writers either. Its Multi-Attach feature is limited to supported configurations and requires software designed for shared block access; mounting an ordinary filesystem read-write on multiple hosts can corrupt data.
Choose S3 when
- Store user-uploaded photos, videos, and documents that many application servers or clients need to access.
- Keep immutable exports, database backups, log archives, or large analytical datasets independently of compute instances.
- Serve media through a CDN, using private bucket access and controlled client authorization.
- Scale upload and download workers without attaching a storage volume to each worker.
Choose EBS when
- Run a database on EC2 that needs random page updates, a write-ahead log, and filesystem durability operations.
- Support software that requires a conventional filesystem or raw block device rather than an object API.
- Keep persistent working data across EC2 instance replacement within an AZ.
- Provision storage performance for a measured workload with explicit IOPS, throughput, capacity, and latency requirements.
A worked example
Photo storage with a separate metadata database
Suppose a photo service receives 100,000 uploads per day at an average of 8 MB each, adding roughly 800 GB of originals daily before thumbnails. Store originals and generated variants in S3, and let processing workers fetch objects by key. Keep ownership, album membership, and processing state in a database; if self-hosted on EC2, its active files can live on EBS. Replicate that database across AZs rather than relying on one volume. Clients upload through short-lived presigned URLs, and a CDN serves authorized downloads. Publish a photo only after verifying the upload and required processing. This avoids copying the media library onto every application server.
In the interview
- Start with the operation, not the product: are you replacing a 20 MB object or updating an 8 KB database page? State the read/write pattern, object size, concurrency, and latency target before choosing storage.
- Separate blobs from metadata. Put media in S3 and searchable ownership, processing status, and permissions in a database. Expect follow-up questions about incomplete uploads, orphaned objects, and publishing metadata before processing finishes.
- Draw the failure boundary. For EBS-backed databases, explain cross-AZ replication, failover, fencing, and backup restoration. For S3, identify the storage class and explain whether regional disaster recovery requires another copy.
- Estimate the full cost path. Include retained bytes, request volume, download traffic, and CDN use for S3; include provisioned capacity, performance, replicas, and snapshots for EBS. Neither is universally cheaper.
Common mistakes
- Calling S3 eventually consistent. S3 provides strong consistency for object operations, but this does not create transactions between S3 and a metadata database.
- Treating EBS replication within an AZ as database replication across AZs, or treating a snapshot as an immediately usable failover replica.
- Using one EBS volume as a shared media store for a fleet, without accounting for attachment limits, shared-filesystem requirements, and the AZ boundary.
- Comparing storage price alone while ignoring access semantics, latency requirements, request charges, provisioned performance, and recovery costs.
Where it comes up
Interview questions where choosing between S3 and EBS comes up.
- Design Google PhotosSeparate large private objects from searchable metadata, then explain upload completion, image processing, and authorized delivery.
- Design a video streaming service like YouTubeUse object storage for originals and encoded segments while distinguishing durable media from worker storage and database files.
- Design Dropbox or Google DriveStore file content as objects while coordinating versions, resumable uploads, permissions, and metadata transactions separately.
- Design a distributed key-value storeJustify block storage for active logs and indexes, object storage for backups or immutable files, and replication for node or AZ failures.
- Design a system to sort huge datasetsDistinguish durable input and output in object storage from block-backed working storage used during external sorting and merge operations.
Questions people ask
What is the main difference between S3 and EBS?
S3 is object storage accessed through APIs using bucket names and object keys. EBS is block storage attached to EC2, typically used through a filesystem or directly by a database. Choose based on the application's access pattern, not just how many bytes it stores.
Is S3 cheaper than EBS?
It depends on the storage class, access pattern, retention, and provisioned performance. S3 is often a better fit for large media collections and archives, but requests, retrieval, and data transfer contribute to cost. EBS charges for provisioned capacity and, depending on the volume type and configuration, additional performance; snapshots add another cost.
Can S3 replace EBS for a database?
Not as a drop-in replacement for a conventional database's active files. Such databases generally require random writes and filesystem semantics that ordinary S3 object access does not provide. Storage engines explicitly designed around object storage can use S3, often with caching or a separate write path, while conventional databases commonly use S3 for backups and exports.