If you’re studying for the AWS Certified Solutions Architect (Associate or Professional), storage is one of those “always show up” domains. And three services dominate the conversation: Amazon S3, Amazon EBS, and Amazon EFS. They’re all “AWS storage,” but they behave completely differently in networking, consistency, durability, and billing.
This guide is built for exam relevance and real-world design thinking. You’ll get a deep comparison, decision frameworks, architecture patterns, and practical scenarios—so you can choose the right storage service quickly under pressure.
You’ll also see how these services connect to the bigger AWS puzzle, including compute and networking choices. If you want a broader mental model first, check out AWS Core Services Every Solutions Architect Must Master: Compute, Storage, Networking, and More.
The “mental model” that makes S3 vs EBS vs EFS click
The fastest way to differentiate S3, EBS, and EFS is to stop thinking “which is faster?” and start thinking what kind of access they provide:
- S3 (Object storage): store objects accessed via API. Built for scale and durability.
- EBS (Block storage): attach volumes to EC2 with block device semantics (like a virtual disk).
- EFS (File storage): provide POSIX-like file system access over NFS, shared across instances.
That single framing helps you answer most exam-style questions. The service name doesn’t matter as much as the required access pattern:
- Is the workload object-based? Think S3.
- Is the workload a server-local disk attached to one instance? Think EBS.
- Does the workload require shared file access across multiple compute nodes? Think EFS.
Quick comparison: what each service is really for
Table stakes: core purpose and access style
| Service | Storage Type | Primary Access Model | Best Fit | Classic Exam Triggers |
|---|---|---|---|---|
| S3 | Object | HTTP/S APIs | Large-scale storage, backups, data lakes, static assets | “Store objects,” “lifecycle policies,” “durable & scalable,” “event notifications,” “S3 bucket” |
| EBS | Block | Attached to EC2 as a block device | OS/app disks, databases on EC2, low-latency volumes | “Attach volume,” “boot from volume,” “IOPS,” “provisioned throughput,” “performance tuning” |
| EFS | File | NFS shared filesystem | Shared storage for containers, web roots, shared home dirs | “Shared across AZs,” “NFS,” “multiple instances mount same filesystem” |
These are the kinds of words that show up in Solutions Architect exam scenarios.
If you’re also building your compute patterns foundation, it helps to connect storage decisions to compute choices. Start with Designing with EC2, Lambda, and Fargate: Compute Patterns You Need for the AWS Solutions Architect Exams.
Amazon S3: object storage built for scale, durability, and cost control
What S3 is
Amazon Simple Storage Service (S3) stores data as objects inside buckets. Each object consists of:
- a key (name/path),
- metadata, and
- the data payload.
S3 isn’t attached like a disk. You access it via API calls (SDK/CLI/console/REST). That makes it perfect for workloads where storage is decoupled from compute and where you want enormous scalability without managing underlying hardware.
Why S3 shows up constantly on the exam
S3 is popular in AWS architecture questions because it solves common needs:
- Durable storage for data at rest
- Scalable storage across virtually any dataset size
- Flexible retrieval patterns (frequently accessed vs archival)
- Security controls (encryption, bucket policies, access points)
- Lifecycle management for cost optimization
- Event-driven integration (S3 notifications triggering Lambda, etc.)
S3 is one of the easiest services to describe in an interview—and one of the easiest to misconfigure. So the exam expects you to understand both “use it for X” and “configure it safely.”
S3 durability and availability (what to know)
S3 is designed for high durability and strong availability. You don’t typically make “availability” design decisions in the same way as with EC2 and EBS, because S3 is architected for it. That said, your choice of storage class and replication strategy affects cost and recovery behavior.
Storage classes: performance vs cost trade-offs
S3 storage classes are basically a set of “how much do you pay for how fast can you retrieve?” knobs:
- S3 Standard: default general-purpose; good for frequent access.
- S3 Intelligent-Tiering: automatically moves objects to cheaper tiers based on access patterns.
- S3 Standard-IA: for less frequent access but needs faster retrieval than archival.
- S3 One Zone-IA: cheaper, but lower resilience than multi-AZ options.
- S3 Glacier classes: archival storage with longer retrieval times.
Exam questions often look like:
“You need long-term retention at low cost, and retrieval doesn’t happen often.”
That’s almost always Glacier or a lifecycle policy to transition objects.
Expert tip: storage class decisions are a budget lever. If your architecture ROI is being questioned, you’ll want to show you can reduce long-term storage costs without breaking access SLAs.
Security and compliance considerations (the exam loves these)
S3 security is where you demonstrate architectural maturity. Typical topics include:
- Encryption at rest (SSE-S3, SSE-KMS)
- Block Public Access settings
- Bucket policies and least privilege IAM
- Bucket ownership controls
- VPC endpoints (to keep traffic private)
- Access points and optional S3 Object Lambda
If you’re securing data flows, you also need networking context. If you want that, read VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs.
S3 patterns you’ll repeatedly see
These show up in training, exams, and real deployments.
1) Static website hosting / asset delivery
- Store images, CSS, JS in S3
- Put CloudFront in front for caching and global low latency
Even though CloudFront isn’t one of the three services being compared, the architecture pattern is inseparable from S3 usage.
2) Data lake / analytics staging
- Store raw datasets in S3
- Run analytics (often via Athena, EMR, or Spark on AWS)
S3 is the “landing zone” for data, and compute pulls what it needs.
3) Backup and disaster recovery
- Use S3 for backups and snapshots of data sets
- Combine with lifecycle rules for retention
S3 billing mental model
S3 pricing combines:
- storage consumed (GB-month),
- requests (PUT/LIST/GET),
- data transfer out,
- optional analytics/replication/lifecycle costs.
The “aha” is that requests can matter at scale. Many exam scenarios ignore this until you’re forced to think about cost optimization.
Amazon EBS: block storage for EC2 that you can tune for performance
What EBS is
Amazon Elastic Block Store (EBS) provides block-level storage volumes you can attach to EC2 instances. To the operating system, the volume looks like a physical disk device.
EBS is ideal when:
- you need persistent block storage for a VM,
- you want fast random IO (depending on volume type),
- you want to manage capacity and performance characteristics.
EBS is “close” storage (in the compute sense)
Unlike S3, which is accessed over API, EBS volumes are attached to EC2. This changes performance characteristics and operational patterns:
- You mount it like a disk.
- You manage filesystem (ext4, XFS, etc.) on top.
- You can snapshot volumes for backups.
EBS volume types (and when to use them)
EBS volume types include:
- General Purpose SSD (gp3, gp2): balanced performance/cost; common default.
- Provisioned IOPS SSD (io1/io2): high-performance with guaranteed IOPS.
- Throughput Optimized HDD (st1): throughput-heavy for HDD use cases.
- Cold HDD (sc1): cheaper HDD for infrequent access.
Exam questions often include keywords like:
- “Need high random IOPS”
- “Provisioned IOPS”
- “General purpose default”
- “Warm/cold storage”
Those map directly to volume types.
Expert tip: On the exam, don’t over-engineer. If the question doesn’t explicitly require provisioned IOPS or guaranteed performance, gp3 is commonly the “best answer” in cost-performance terms.
Boot volumes and snapshots
Common architecture patterns:
- Boot from EBS volume for EC2
- Use EBS snapshots for backups and recovery
- Restore volumes from snapshots when needed
Snapshots are also how you build resilient recovery workflows and implement DR strategies.
EBS consistency and failure behavior (what to know)
EBS volumes:
- are tied to an AZ for availability,
- are resilient within that scope,
- and their durability depends on AWS storage engineering plus your snapshot strategy.
That’s why you’ll often see designs combining:
- EBS for performance,
- S3 for longer-term backup/archive,
- and replication/snapshot copies across regions.
EBS billing mental model
EBS costs depend on:
- volume type,
- provisioned capacity,
- IOPS/throughput provisioned (for some types),
- and snapshot storage.
For cost ROI, this is a major lever: if you over-provision IOPS or store too long in snapshots without lifecycle management, your bill grows quietly.
Amazon EFS: elastic shared file storage for multi-instance workflows
What EFS is
Amazon Elastic File System (EFS) is a managed file system that multiple compute instances can mount using NFS. Unlike EBS, it’s shared storage, not a single attached block volume.
EFS is a strong match for workloads like:
- shared home directories,
- content management systems with shared state,
- container workloads that need shared volumes,
- legacy applications expecting POSIX file semantics.
EFS is “shared by design”
If EBS is “one disk per instance,” EFS is “one file system mounted by many instances.” That distinction is central to exam answers and real architecture.
Typical exam cue:
“Multiple EC2 instances must access the same directory concurrently.”
That’s EFS territory.
EFS performance modes
EFS offers performance modes that affect throughput and latency:
- General Purpose: balanced, default-friendly.
- Max I/O: optimized for high-throughput use.
Exam scenarios often include “many small files” or “bursty workloads,” which can change your performance mode choice.
EFS throughput modes
Throughput modes relate to how EFS scales with data size and expected load.
EFS storage classes
EFS supports storage classes like Standard and Infrequent Access, depending on AWS offerings and current service capabilities. The exam may ask about lowering cost for “files accessed infrequently but still need POSIX access.”
Expert tip: EFS lifecycle and tiering can be a cost win—but ensure the retrieval latency for infrequently accessed data meets your app expectations.
EFS availability across AZs
EFS can be mounted from multiple AZs, but network and security group design still matters. The exam is as much about architecture correctness as service choice.
S3 vs EBS vs EFS: the decision framework you can use under exam pressure
When you’re faced with a scenario, run this mental checklist.
Step 1: What access pattern is described?
Ask:
- Are clients accessing data via objects (PUT/GET, keys, buckets)?
→ S3 - Is the workload described as a disk/volume attached to a VM?
→ EBS - Is the requirement for a shared filesystem directory across instances?
→ EFS
Step 2: Who needs to read/write concurrently?
- One instance (or mainly one OS volume per instance)
→ EBS - Many instances mounting the same files simultaneously
→ EFS - Many producers/consumers reading/writing objects over the network
→ S3
Step 3: What are the latency and performance expectations?
- Block storage IO patterns (IOPS, low latency)
→ EBS - Shared NFS filesystem semantics (throughput modes)
→ EFS - API-based access and “fetch when needed” patterns
→ S3
Step 4: How should you optimize costs?
- Frequently accessed large datasets with predictable patterns
→ S3 Standard / gp3 - Infrequently accessed archival content
→ S3 Intelligent-Tiering / Glacier - Bursty shared filesystem with tiering
→ EFS storage classes
Real architecture scenarios (Associate + Professional flavored)
Below are scenario “story problems” that look like common exam questions. Use them as practice.
Scenario A: “Store images for a public web app”
Requirements
- Millions of images
- Access patterns are spiky but generally read-heavy
- Need durability and low operational overhead
- Want cost control for long retention
Best choice: S3
Why: Object storage maps perfectly to static assets. You can add:
- lifecycle policies (move older assets to cheaper classes),
- encryption and bucket policies,
- event notifications for image processing via Lambda.
Where EBS/EFS don’t fit
- EBS is for instance-attached block storage, not web asset storage at scale.
- EFS is shared filesystem, but object-style retrieval is a better fit for static assets and CDN caching.
Scenario B: “Run a relational database on EC2 with consistent disk performance”
Requirements
- Need persistent block storage
- App expects a disk-like interface
- Database IO performance matters
- Want snapshots for backup/restore
Best choice: EBS
Why: Databases running on EC2 often use EBS volumes for the underlying storage. You can select gp3 for general purpose or io1/io2 for high guaranteed performance.
Pro-level twist
- For cost, you might also evaluate managed DB services instead of EC2 storage—then the discussion moves to Managed Databases on AWS: RDS, DynamoDB, and Aurora Scenarios Every Solutions Architect Candidate Should Know.
Scenario C: “Multiple services need shared access to the same web root directory”
Requirements
- Several EC2 instances (or ECS tasks) must mount and serve content
- The app writes files and reads files frequently
- Need shared state across instances
Best choice: EFS
Why: EFS provides a shared filesystem mounted via NFS. That matches multi-instance shared directory needs.
Pro-level twist
- You might choose a different approach (like storing immutable assets in S3 + serving via CloudFront) depending on workload.
- But if the app truly depends on shared POSIX file semantics, EFS is the architecture-correct answer.
Scenario D: “Back up important data and keep it for years”
Requirements
- Long-term retention
- Low cost over time
- Should be resilient and auditable
Best choice: S3 (often combined with snapshots elsewhere)
Why: S3 is built for durable long-term retention and supports lifecycle management.
How EBS fits
- EBS snapshots can be a backup mechanism.
- But for long-term “archive-like” retention and tiering, S3 lifecycle policies are often part of the strategy.
How S3 + EBS + EFS often work together (the “stack” you should recognize)
Real solutions rarely use only one storage service. A healthy architecture uses each where it fits.
Common “composition” pattern
- EBS for EC2 instance OS + app runtime data
- EFS for shared filesystem dependencies (if required)
- S3 for durable data storage, backups, logs, and analytics inputs
Example flow:
- App reads/writes small operational data on EBS.
- Shared directory content lives on EFS.
- Backups, exports, and processed artifacts go to S3.
This isn’t just plausible—it’s how many production systems are built.
Expert insight: On the Professional exam, you’ll be evaluated on holistic design trade-offs: security, cost, operational complexity, scalability, and maintainability. Using the right storage services in combination is a strong signal you understand architecture.
Security deep-dive: storage is where “least privilege” is won or lost
Storage services are high-value targets. Your exam answers should show awareness of security boundaries.
S3 security highlights
- Use bucket policies and IAM least privilege.
- Block public access.
- Enable encryption (SSE-S3 or SSE-KMS).
- Consider VPC endpoints for private access patterns.
- Use lifecycle rules and access logging where appropriate.
EBS security highlights
- Ensure instance roles and security groups restrict who can attach/manage volumes.
- Use encryption for volumes.
- Manage snapshot permissions carefully (snapshots inherit access requirements).
- Follow least privilege for creating/modifying volumes.
EFS security highlights
- Use security groups and NFS access restrictions.
- Encrypt in transit if required by your compliance posture.
- Restrict mount targets to trusted networks.
- Use IAM authorization features where applicable.
If you’re building a full design, security is inseparable from networking decisions. That’s why it’s worth studying VPC, Route 53, and CloudFront Fundamentals: Networking Concepts That Make or Break Your AWS Architect Designs alongside storage.
Performance and consistency: what to expect (and what to avoid assuming)
A lot of “wrong answer” behavior comes from incorrect assumptions about storage semantics.
S3: object access semantics
- You interact with objects via API.
- It’s not mounted as a filesystem.
- You design with object-level operations in mind.
EBS: block device semantics
- Your application sees block IO.
- You tune performance via volume type and IOPS/throughput settings (depending on type).
- Consistency is tied to filesystem behavior and instance lifecycle.
EFS: NFS filesystem semantics
- Your application sees a filesystem mounted over NFS.
- Shared concurrency patterns matter.
- You choose performance/throughput modes to match workload characteristics.
Exam insight: If a scenario describes “mount a filesystem across instances,” it’s almost never S3 or EBS. If it describes “attach a volume to EC2,” it’s almost never S3 or EFS.
Cost and ROI: storage decisions can make or break the business case
In career ROI terms, storage expertise is valuable because storage is a major portion of cloud spend. If you can justify storage choices with architecture logic and cost controls, you look like the kind of architect companies want.
The cost drivers (what you should remember)
- S3
- storage GB-month,
- request charges,
- retrieval and data transfer out,
- lifecycle tier transitions,
- replication (if configured).
- EBS
- volume size,
- performance configuration (IOPS/throughput),
- snapshot storage and snapshot frequency.
- EFS
- storage GB-month by storage class,
- throughput costs / performance mode considerations,
- mount target and network-related costs (indirect).
Cost optimization strategies that frequently appear in exam-style thinking
- Use S3 lifecycle policies to move older data to cheaper storage classes.
- Prefer S3 Intelligent-Tiering when access patterns are unpredictable.
- Use EBS gp3 as a balanced default unless guaranteed performance is required.
- Avoid snapshot sprawl—implement retention policies.
- Use EFS storage classes and throughput settings based on access frequency.
Professional-level mindset: cost optimization should not break the requirements. If the app needs fast retrieval, don’t silently push everything to deep archival tiers.
Troubleshooting and operational considerations (how good architects think)
Even if you choose the “right” service, operational reliability matters.
S3 operational considerations
- Versioning and lifecycle: protect against accidental overwrites/deletions.
- Replication for regional resilience.
- Monitoring for access errors, lifecycle transitions, and event processing.
EBS operational considerations
- Snapshot management (retention policies, encryption).
- Reattachment and boot-time processes for volumes.
- Performance monitoring (IOPS, queue depth, latency).
EFS operational considerations
- NFS mount stability and security group rules.
- Performance mode selection and throughput monitoring.
- Understanding how app patterns affect file system performance (e.g., many small files).
Practice questions (with “why” explanations)
Use these to reinforce decision rules.
Practice 1
A media processing pipeline writes thousands of image files per day and requires long-term retention. Retrieval is needed occasionally for audits. Which storage service is best?
Answer: S3
Why: Object storage with lifecycle/archival tiering is ideal for large retained datasets with infrequent retrieval.
Practice 2
You need a persistent disk for an EC2-based app server and the workload is latency sensitive. You also want to tune performance.
Answer: EBS
Why: EBS volumes attach to EC2 and let you select volume types/performance settings.
Practice 3
You’re running multiple application servers that must share a single directory structure and allow concurrent reads/writes.
Answer: EFS
Why: Shared POSIX-like filesystem access over NFS matches the requirement for multiple instances mounting the same filesystem.
Common misconceptions (the “gotchas” that cost points)
Misconception 1: “EFS is just like EBS but cheaper.”
Not really. EFS is file-based shared storage over NFS, while EBS is block storage attached to a specific instance in an AZ.
Misconception 2: “S3 is slow, so it can’t be used for app data.”
S3 latency is different, but many architectures use S3 successfully for:
- asset storage,
- logs,
- backups,
- event-driven workflows,
- data lakes,
- and intermediate artifacts.
The real question is access pattern and how the application is designed to consume it.
Misconception 3: “If I need persistence, I should pick EBS.”
Persistence alone isn’t the deciding factor. If multiple compute nodes must share the same files, persistence could point to EFS. If data needs to persist as durable objects for analytics/backups, it points to S3.
How this connects to your overall Solutions Architect exam readiness
Storage questions are rarely standalone. They tie back into:
- compute patterns,
- networking choices,
- and database/storage design trade-offs.
That’s why your study strategy should be cross-service, not service-by-service only. Revisit:
- AWS Core Services Every Solutions Architect Must Master: Compute, Storage, Networking, and More
- Designing with EC2, Lambda, and Fargate: Compute Patterns You Need for the AWS Solutions Architect Exams
- Managed Databases on AWS: RDS, DynamoDB, and Aurora Scenarios Every Solutions Architect Candidate Should Know
When you can connect storage to compute and data, you stop memorizing answers and start selecting architectures.
Mapping service choices to exam skill levels: Associate vs Professional
Associate (SA-A)
Expect lots of straightforward mapping:
- “Need object storage?” → S3
- “Need block volume for EC2?” → EBS
- “Need shared filesystem?” → EFS
- “Need CDN for web assets?” → CloudFront + S3 pattern
Professional (SA-Pro)
Professional questions are more likely to test:
- multi-service trade-offs (cost vs latency vs durability),
- security posture and correct access controls,
- operational design choices (backup strategy, lifecycle, disaster recovery),
- and architecture evolution (“what changes when the workload scales?”).
On Professional, the question may still be about S3 vs EBS vs EFS, but the answer selection depends on the full system design.
Final cheat sheet: memorize this, then think architecturally
Choose S3 when you need:
- durable object storage
- lifecycle and cost tiering
- event-driven workflows
- data lake / backups / artifacts
- scale that feels unlimited without managing servers
Choose EBS when you need:
- block-level storage attached to EC2
- IOPS/performance tuning
- OS/app disks on VMs
- snapshot-based backup and restore workflows
Choose EFS when you need:
- shared filesystem across multiple instances
- NFS mount semantics
- POSIX-like directory structure used concurrently by apps
- elastic scaling of shared storage capacity
Your next study step (practical and high-ROI)
If you want this to stick, don’t just reread comparisons—turn it into quick decision drills. Pick one scenario and force yourself to answer:
- Which storage service fits and why?
- What would you change for cost?
- What would break if you swapped services incorrectly (EBS ↔ EFS, or S3 ↔ EBS)?
That habit mirrors how Solutions Architect exams reward thinking.
When you’re ready to broaden your architecture fundamentals beyond storage, go back to AWS Core Services Every Solutions Architect Must Master: Compute, Storage, Networking, and More and connect storage choices to the compute and networking patterns you’ll keep seeing.
Good architecture isn’t memorization—it’s recognizing requirements instantly. S3, EBS, and EFS are the big three that teach that skill fast.
