AWS Services
S3 vs EBS vs EFS vs Instance Store
Compare AWS object, block, file, and ephemeral storage choices for application data, databases, shared files, uploads, caches, and exam scenarios.
After this, you will understand
Storage questions stop feeling like memorization once you classify the access pattern: object, block, shared file, or temporary local disk.
Use S3 for objects, EBS for instance-attached block storage, EFS for shared files, and instance store for temporary high-performance local storage.
Learners treat every storage service as a place to put files and miss attachment model, durability, sharing, and access semantics.
Choose storage by API and lifetime: object API, block device, NFS shared file system, or ephemeral local disk.
Think before readingWhy is S3 usually better than EBS for user-uploaded images in a web app?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Object storage
- Block storage
- File storage
- Ephemeral storage
- Amazon S3
- Amazon EBS
- Amazon EFS
- EC2 instance store
- Durability and attachment model
- Storage exam traps
1. Plain-English Mental Model
S3, EBS, EFS, and instance store are not interchangeable storage buckets. They represent different storage models.
Amazon S3 is object storage. You store objects in buckets and access them through APIs.
Amazon EBS is block storage. You attach a volume to an EC2 instance and use it like a disk.
Amazon EFS is managed file storage. Multiple compute clients can mount the same file system over NFS.
Instance store is temporary local storage physically attached to an EC2 host. It can be fast, but it is not durable beyond the life of the instance.
The short model is:
S3 = object storage
EBS = block storage for EC2
EFS = shared file storage
instance store = temporary local disk
The right choice depends on how the application reads and writes data, whether data must be shared, how durable it must be, and whether it should outlive compute.
2. Why This Service Exists
This comparison exists because applications use storage in different ways.
A user-uploaded image should not live on the local disk of one web server. It should survive instance replacement and be accessible to any app instance. S3 fits.
A database running on EC2 needs a low-level block device with consistent performance characteristics. EBS fits.
Several EC2 instances need to read and write shared application files through a filesystem interface. EFS fits.
A high-performance temporary cache, scratch directory, or buffer can be recreated if the instance disappears. Instance store may fit.
For SAA-C03, storage questions often include one decisive phrase: "object", "block", "shared file", "NFS", "multiple EC2 instances", "attached to an instance", "temporary", "survive stop and start", "low cost archive", "static website", or "database volume."
3. The Naive Approach And Where It Breaks
The naive approach is to put all application data on the EC2 instance filesystem.
That breaks when the instance is replaced, when you scale to multiple instances, when a deployment moves traffic, when you need global object access, or when the disk fills.
Another naive approach is to use S3 as if it were a mounted local filesystem. S3 is object storage. It is excellent for objects and APIs, but it is not a POSIX file system for low-latency file mutations.
Another naive approach is to use EBS for shared files across many instances. EBS is normally attached to one EC2 instance in one Availability Zone. Multi-Attach exists for specific volume and file system patterns, but it is not the general shared file answer. EFS is usually the exam answer for shared file access.
Storage choice should begin with semantics, not service popularity.
4. Core Primitives
S3 primitives are buckets, objects, keys, metadata, storage classes, lifecycle rules, versioning, and bucket policies. Applications call S3 APIs.
EBS primitives are volumes, snapshots, volume types, IOPS, throughput, encryption, and attachment to EC2 instances. An EBS volume and the instance it attaches to must be in the same Availability Zone.
EFS primitives are file systems, mount targets, security groups, performance modes, throughput modes, and storage classes. For Regional EFS, you can create mount targets in multiple AZs so clients in those AZs can mount the file system.
Instance store primitives are local disks available on certain EC2 instance types. They are attached at launch and tied to the instance lifecycle.
Each primitive implies a failure model. S3 is managed object storage. EBS persists independently from an instance but is AZ-scoped. EFS can be Regional or One Zone. Instance store is ephemeral.
5. Architecture Use Cases
Use S3 for user uploads, static assets, logs, backups, data lakes, exports, archives, and event-driven object processing.
Use EBS for EC2 boot volumes, database volumes on EC2, file systems that belong to one instance, and workloads needing block-level storage.
Use EFS for shared content directories, web servers that need common files, lift-and-shift Linux applications expecting NFS, home directories, shared build artifacts, and serverless or container workloads needing shared file access.
Use instance store for temporary scratch space, caches, buffers, high-throughput temporary data, and workloads that replicate or regenerate data elsewhere.
An image upload app might use EC2 or Lambda for compute, S3 for uploaded objects, CloudFront for delivery, and DynamoDB or RDS for metadata. The image bytes do not belong on the app server disk.
7. Security Model
S3 access is controlled with IAM policies, bucket policies, Block Public Access, access points, ACLs when needed, KMS encryption, and pre-signed URLs.
EBS access is mostly through the attached EC2 instance and AWS API permissions. Encrypt volumes and snapshots with KMS when needed. Protect snapshots because they can recreate data.
EFS access uses mount targets, security groups, NFS permissions, access points, IAM authorization options, and encryption in transit or at rest depending on configuration.
Instance store data must be treated as local instance data. Do not place valuable long-term data there unless it is replicated elsewhere. It is not a backup boundary.
Storage security also includes lifecycle, deletion controls, logging, backup policy, and key management.
8. Reliability And Resilience
S3 is designed for high durability across multiple facilities within a Region for general purpose buckets and common storage classes.
EBS volumes persist independently from the running life of an EC2 instance and are replicated within an Availability Zone. Snapshots can back up EBS volumes and create new volumes.
EFS Regional file systems can span multiple AZs through mount targets and are designed for shared access. EFS One Zone trades broader AZ resilience for cost and placement characteristics.
Instance store data does not persist when the instance is stopped, hibernated, or terminated. It also cannot be detached and reattached to another instance. Reboot behavior can preserve data, but that is not a durability strategy.
Match storage resilience to business need. A cache can disappear. A database cannot.
9. Performance And Scaling
S3 scales as a managed object store. Use multipart upload for large objects, CloudFront for global delivery, and lifecycle rules for storage class movement.
EBS performance depends on volume type, provisioned IOPS, throughput, instance limits, and file system behavior. It is a good fit when the operating system expects a block device.
EFS performance depends on throughput mode, performance mode, storage class, client behavior, and access patterns. It is convenient for shared files but not a magic replacement for every database or low-latency block workload.
Instance store can provide very high local performance for certain instance types, but the application must tolerate data loss and replacement.
Performance questions usually contain clues: random disk I/O, shared NFS, object retrieval, archive, or temporary high-speed scratch.
10. Cost Model
S3 cost depends on storage class, requests, retrieval, lifecycle, replication, and data transfer. It can be very cost-effective for object storage and archival patterns.
EBS cost depends on provisioned volume size, volume type, provisioned IOPS or throughput where applicable, snapshots, and data transfer patterns.
EFS cost depends on stored data, storage class, throughput mode, and access patterns. It is convenient but can be expensive if used casually for data that belongs in object storage.
Instance store is included with supported instance types, but the real cost is architectural risk if you store data there that cannot be recreated.
The cheapest wrong storage service is expensive once it forces redesign, data loss, or operational workarounds.
12. SAA-C03 Exam Signals
"Object storage", "static website", "user uploads", or "data lake" points to S3.
"Block storage attached to EC2" points to EBS.
"Shared file system for multiple EC2 instances" points to EFS.
"NFS" points to EFS.
"Temporary high-performance local storage" points to instance store.
"Data must persist after EC2 stop/start" points away from instance store and toward EBS, S3, EFS, or a database.
"Database on EC2 needs storage volume" usually points to EBS, though managed database services may reduce operational overhead.
13. Common Exam Traps
Do not use instance store for valuable long-term data.
Do not choose EBS when many instances need a shared file system unless the question is about a specialized supported pattern.
Do not choose EFS when the data is object-style uploads better served by S3.
Do not choose S3 when the workload needs a block device attached to an operating system.
Do not forget that EBS is Availability Zone scoped.
Do not confuse durability with accessibility. A storage service can be durable but still require the right permissions, network path, or mount target.
15. Related Topics
Review Amazon S3 for object storage mechanics and Amazon EC2 for how block and instance storage attach to compute.
Next, study RDS Multi-AZ vs Read Replicas, which applies the same "what problem are we solving?" thinking to databases.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.