More SAA-C03 questions hinge on storage than most candidates expect. The exam rarely asks “what is EBS?” — instead it hands you a scenario (“a shared file system for a fleet of Linux web servers,” “sub-millisecond block storage for a database,” “eleven nines of durability for backups”) and expects you to map it to exactly the right service in under two minutes. Get the storage taxonomy wrong and you’ll burn time second-guessing on questions that should be free points.
This guide organizes every AWS storage service the AWS Solutions Architect Associate (SAA-C03) exam cares about into a decision framework you can recall under pressure. We’ll cover the three storage paradigms, then each service’s exam-critical details, and finish with the scenario keywords that pick the answer for you. For the domains this feeds into, pair it with designing high-performing architectures and cost-optimized architectures.
The Three Storage Paradigms
Every storage question starts with one decision: block, file, or object? Get this right and you’ve usually narrowed five services to one or two.
| Paradigm | Access model | Analogy | AWS services |
|---|---|---|---|
| Block | Raw volumes attached to one instance, formatted with a filesystem | A virtual hard drive | EBS, Instance Store |
| File | Shared filesystem mounted by many clients over a network protocol (NFS/SMB) | A network file share | EFS, FSx |
| Object | Flat namespace of objects accessed via HTTP API, each with metadata | A giant key-value store for files | S3, S3 Glacier |
The mental shortcuts that resolve most questions:
- “Attached to a single EC2 instance / boot volume / database disk” → block (EBS).
- “Shared by many instances at once” → file (EFS for Linux, FSx for Windows).
- “Web-accessible, static assets, backups, data lake, unlimited scale” → object (S3).
Amazon EBS — Block Storage for a Single Instance
Elastic Block Store (EBS) provides persistent block volumes you attach to EC2 instances. It’s the default answer whenever a scenario needs a durable disk for one instance — a boot volume, a database’s data files, or any application that expects a raw block device.
Exam-critical EBS facts:
- AZ-scoped. An EBS volume lives in one Availability Zone and can only attach to an instance in that same AZ. To move a volume across AZs, you snapshot it (snapshots live in S3, regionally) and create a new volume from the snapshot in the target AZ.
- One instance at a time — with the exception of io1/io2 Multi-Attach, which lets a single volume attach to multiple instances in the same AZ for clustered applications.
- Persistent. Data survives an instance stop/terminate (unless “delete on termination” is set for the root volume).
- Snapshots are incremental, stored in S3, and can be copied across regions for DR.
- Encryption is available at rest with KMS; snapshots and volumes created from encrypted volumes stay encrypted.
The volume types matter because the exam tests “which one fits this workload”:
| Volume type | Category | Best for |
|---|---|---|
| gp3 / gp2 | General purpose SSD | Boot volumes, most workloads; gp3 lets you provision IOPS/throughput independently |
| io2 Block Express / io1 | Provisioned IOPS SSD | Latency-sensitive, high-IOPS databases; supports Multi-Attach |
| st1 | Throughput HDD | Big, sequential workloads — log processing, data warehouses |
| sc1 | Cold HDD | Infrequently accessed, lowest-cost HDD |
Exam signal: the words “highest IOPS,” “critical database,” or “sub-millisecond latency” point to io2; “large sequential throughput at low cost” points to st1.
Instance Store — Fast but Ephemeral
Instance Store is block storage physically attached to the host serving your EC2 instance. It delivers very high IOPS because there’s no network hop, but it comes with the single most-tested caveat in AWS storage:
Instance store data is ephemeral. It is lost when the instance stops, hibernates, or terminates (and if the underlying hardware fails).
Use it for scratch data, caches, buffers, or replicated data where losing a node is acceptable. If a question says “temporary,” “scratch,” “cache,” or “highest possible IOPS and data loss is acceptable,” it’s steering you to instance store. If the data must survive a stop/start, it must be EBS, not instance store.
Amazon EFS — Shared File Storage for Linux
Elastic File System (EFS) is a fully managed NFS file system that many resources mount simultaneously. This is the answer whenever a scenario needs shared files across a fleet — think a group of Linux web servers all serving the same content, or containers sharing a data directory.
What makes EFS distinct on the exam:
- Linux only (NFS protocol); it is not for Windows workloads.
- Multi-AZ by design in Standard mode — mount targets in each AZ give you a highly available shared filesystem.
- Elastic — it grows and shrinks automatically; you never provision capacity.
- Storage classes — Standard, Infrequent Access (IA), and Archive, with lifecycle management to move cold files to cheaper tiers automatically. One Zone classes trade multi-AZ resilience for lower cost.
- Mountable by EC2, ECS/EKS containers, and Lambda.
Exam signal: “shared file system,” “multiple Linux instances,” “concurrent access,” “POSIX” → EFS. The contrast the exam draws constantly is EFS (shared, many instances) versus EBS (attached to one instance).
Amazon FSx — Managed File Systems for Specialized Workloads
FSx is a family of managed third-party and high-performance file systems. For SAA-C03, two members dominate the questions:
- FSx for Windows File Server — a fully managed Windows-native SMB file share with Active Directory integration, NTFS permissions, and DFS. This is the answer for Windows shared storage. If EFS is “shared files for Linux,” FSx for Windows is “shared files for Windows.”
- FSx for Lustre — a high-performance file system for compute-intensive workloads: HPC, machine learning, media processing, and big-data analytics. It integrates natively with S3, presenting an S3 bucket as a file system and writing results back. Scenario words like “HPC,” “machine learning training,” “millions of IOPS,” or “high-performance computing” point here.
Two more members appear occasionally: FSx for NetApp ONTAP (multi-protocol, NAS features) and FSx for OpenZFS (ZFS-based). You mainly need to recognize the names and that they exist for teams standardizing on those file systems.
| Service | Protocol | OS / workload | Signature keyword |
|---|---|---|---|
| EFS | NFS | Linux, shared | ”shared Linux file system” |
| FSx for Windows | SMB | Windows, AD | ”Windows file share” |
| FSx for Lustre | Lustre | HPC / ML | ”high-performance computing,” “ML training” |
Amazon S3 — Object Storage at Any Scale
Simple Storage Service (S3) is object storage with eleven 9s (99.999999999%) of durability, virtually unlimited capacity, and access over an HTTP API. It is not a filesystem you mount for an OS — it’s the backbone for static assets, backups, data lakes, logs, and content distribution.
Because storage-class selection is a favorite exam topic, know the tiers and their trade-offs:
| Storage class | Best for | Notes |
|---|---|---|
| S3 Standard | Frequently accessed data | Low latency, high throughput |
| S3 Intelligent-Tiering | Unknown or changing access patterns | Auto-moves objects between tiers; no retrieval fees |
| S3 Standard-IA | Infrequently accessed, rapid retrieval | Lower storage cost, retrieval fee |
| S3 One Zone-IA | Infrequent, reproducible data | Single AZ — cheaper, less resilient |
| S3 Glacier Instant Retrieval | Archives needing millisecond access | Cheap storage, higher retrieval cost |
| S3 Glacier Flexible / Deep Archive | Long-term archival | Minutes-to-hours retrieval; lowest cost |
Exam signals: “eleven nines of durability,” “static website hosting,” “data lake,” “store unlimited backups cheaply,” or “lifecycle to archive” all point to S3. If a scenario mentions unknown access patterns, the intended answer is almost always Intelligent-Tiering. For a full breakdown of buckets, policies, versioning, and encryption, see the complete S3 guide for SAA-C03.
The Decision Matrix
When a question lands, walk it through these dimensions:
| Dimension | EBS | Instance Store | EFS | FSx (Windows) | S3 |
|---|---|---|---|---|---|
| Type | Block | Block | File | File | Object |
| Attach/mount | 1 instance* | 1 instance | Many (NFS) | Many (SMB) | HTTP API |
| Scope | Single AZ | Single host | Multi-AZ | Multi-AZ | Regional |
| Persistence | Persistent | Ephemeral | Persistent | Persistent | Persistent (11 9s) |
| OS fit | Any | Any | Linux | Windows | N/A |
| Capacity | Provisioned | Fixed to instance | Elastic | Provisioned | Unlimited |
* Except io1/io2 Multi-Attach within one AZ.
Scenario Keyword Cheat Sheet
Under time pressure, these keyword-to-service mappings resolve most storage questions instantly:
| Scenario language | Pick |
|---|---|
| ”Boot volume / attach a disk to one instance” | EBS |
| ”Sub-millisecond, high-IOPS database volume” | EBS io2 |
| ”Temporary scratch / cache, highest IOPS, loss acceptable” | Instance Store |
| ”Shared file system for many Linux servers” | EFS |
| ”Windows file share with Active Directory” | FSx for Windows |
| ”HPC / machine-learning / millions of IOPS” | FSx for Lustre |
| ”Static website, backups, data lake, 11 nines” | S3 |
| ”Unknown or changing access pattern, minimize cost” | S3 Intelligent-Tiering |
| ”Long-term archive, retrieval in hours is fine” | S3 Glacier Deep Archive |
| ”Move EBS data to another AZ” | Snapshot → new volume |
A Worked Example
“A company runs a fleet of Linux application servers behind a load balancer. All servers must read and write the same set of uploaded documents concurrently, and the solution must scale automatically without capacity planning. Which storage service should the architect choose?”
Walk the framework: multiple servers, concurrent access, shared documents → file storage, not block. Linux → EFS, not FSx for Windows. “Scale automatically without capacity planning” → EFS’s elastic model. Answer: Amazon EFS. EBS is wrong because it attaches to a single instance; S3 is wrong because the application expects a mounted filesystem, not an object API. This is the exact reasoning chain the exam is testing — and once you internalize it, storage questions become some of the fastest on the paper.
Turn Storage Into Guaranteed Points
Storage rewards pattern recognition. The candidates who finish these questions in seconds aren’t recalling documentation — they’ve drilled enough scenarios that the keywords trigger the answer automatically. The way you build that reflex is by working realistic, scenario-based questions and reading why each distractor is wrong.
Sailor.sh’s AWS Certified Solutions Architect - Associate (SAA-C03) Mock Exam Bundle gives you exam-style storage scenarios that mirror the real format and difficulty — including the EBS-vs-EFS and EFS-vs-FSx traps covered here — with detailed explanations for every answer. Working through them is the most efficient way to find the gaps in your understanding before they cost you points on exam day. Combine it with a structured SAA-C03 study plan and you’ll walk in knowing storage cold.
Frequently Asked Questions
What’s the core difference between EBS and EFS?
EBS is block storage attached to a single EC2 instance in one Availability Zone — think of it as a virtual hard drive. EFS is a shared file system (NFS) that many Linux instances can mount at the same time across multiple AZs. If the scenario needs concurrent access from a fleet, it’s EFS; if it needs a disk for one instance, it’s EBS.
When would I choose Instance Store over EBS?
Only when you need the highest possible IOPS from locally-attached storage and the data is temporary — scratch space, caches, or buffers you can afford to lose. Instance store data is ephemeral and disappears when the instance stops or terminates, so anything that must persist belongs on EBS.
EFS or FSx — how do I decide?
By operating system and workload. Use EFS for shared file storage on Linux (NFS). Use FSx for Windows File Server for Windows shared storage with SMB and Active Directory. Use FSx for Lustre for high-performance computing and machine-learning workloads that need extreme throughput and S3 integration.
Can an EBS volume be attached to instances in different Availability Zones?
No. An EBS volume is tied to a single AZ and can only attach to an instance in that same AZ. To use the data in another AZ, take a snapshot (which is stored in S3 regionally) and create a new volume from that snapshot in the target AZ.
Which S3 storage class should I pick when access patterns are unpredictable?
S3 Intelligent-Tiering. It automatically moves objects between frequent- and infrequent-access tiers based on usage, with no retrieval fees for the movement, so you get cost savings without having to predict or manage access patterns yourself.
Is S3 a good replacement for a mounted file system?
Generally no. S3 is object storage accessed over an HTTP API, not a POSIX filesystem your OS can mount and use like a directory. When an application expects to read and write files through a normal filesystem interface, use EFS (Linux) or FSx (Windows); use S3 for static assets, backups, data lakes, and web-accessible objects.
Ready to make storage a strength? Drill realistic, explained scenarios with the Sailor.sh SAA-C03 mock exams, then round out your prep with the AWS Solutions Architect Associate exam guide.