High-Performing Storage: S3 vs EBS vs EFS, Volume Types, and Hybrid Options

Every Task 3.1 question starts with the same silent classification: how does the application address its data? Answer that and half the options disappear before you weigh performance at all.

Block storage presents a raw device the operating system formats and mounts. The application sees a disk, and every read or write hits fixed-size blocks at very low latency. That is Amazon EBS — attached over the network to one EC2 instance in the same Availability Zone — and it is the answer whenever the scenario involves a boot volume, a self-managed database, or any software that expects a local disk. Block is the fastest per-operation option, but it does not natively share: one volume, one instance, one AZ is the default mental model.

File storage adds a shared hierarchy on top: directories, file locking, and permissions, accessed over a network protocol by many clients at once. That is Amazon EFS (NFS, Linux) and the Amazon FSx family (SMB, Lustre, and others). File is the answer when multiple instances — often across AZs — must read and write the same data through standard file-system semantics.

Object storage drops the hierarchy and the mount entirely: each object is stored with a key and metadata and accessed over an HTTP API. That is Amazon S3 — virtually unlimited capacity and aggregate throughput, but you write and read whole objects (or byte ranges), not blocks inside them. S3 is the answer for static assets, backups, data lakes, media, and anything web-scale where the application can speak an API instead of a filesystem.

The exam encodes the pattern in verbs. "Mount," "POSIX," or "shared directory" means file. "Attach," "boot," "database on EC2," or "low-latency block" means EBS. "Store millions of images," "durable archive," or "accessed via API by a web application" means S3. Options that ignore the access pattern — an S3 bucket where the app needs a mounted filesystem, an EBS volume shared by a fleet — are eliminations, not contenders.

EBS questions are a four-way choice, and the first cut is SSD versus HDD. SSD volumes (gp3, io2) sell IOPS — small, random reads and writes, the shape of transactional database traffic. HDD volumes (st1, sc1) sell throughput — large, sequential scans at a much lower price per gigabyte, and neither HDD type can be a boot volume. If the scenario says "random," "transactions," or "latency," you are choosing an SSD; if it says "sequential," "large files," "log processing," or "streaming reads," an HDD is probably the cost-correct answer.

Two configuration facts carry questions. First, gp3 decouples performance from capacity: you provision extra IOPS or throughput without buying a bigger volume, which is why "needs more IOPS without more storage" resolves to gp3 settings, not a larger disk. Second, io2 supports Multi-Attach — one volume attached to multiple instances in the same AZ, for cluster-aware applications only. Know it exists; it is a recognition answer, not a general file-sharing mechanism.

The exam tests this as a ladder: does gp3's provisionable performance satisfy the stated requirement? If yes, gp3 wins on cost. Only a requirement gp3 cannot reach — or explicit sub-millisecond, mission-critical language — justifies io2.

When a scenario demands the absolute fastest storage an EC2 instance can touch, the answer is not an EBS type at all. Instance store is disk (typically NVMe SSD) physically attached to the host machine — no network hop between the instance and the storage — which gives it the highest IOPS and lowest latency available to EC2, at no separate storage charge, because it comes bundled with instance types that include it (the storage-optimized families are built around it).

The price is durability. Instance store is ephemeral: the data is gone when the instance stops, hibernates, or terminates, or when the underlying hardware fails. You cannot snapshot it the way you snapshot EBS, you cannot detach it and move it, and it exists only for the life of that instance on that host.

That failure mode defines the decision rule: instance store is correct only when the data is replaceable or replicated elsewhere. The legitimate uses are caches, buffers, scratch space for intermediate computation, temporary database files, and nodes of distributed data stores that replicate across instances — a NoSQL cluster where losing one node's disk costs nothing because peers hold copies. In each case the speed is pure win because durability was never this disk's job. Well-designed architectures pair it with a durable layer: intermediate results checkpointed to S3, or cluster replication that rebuilds a lost node from its peers, so the ephemeral disk is always recoverable state, never the system of record.

A useful cross-signal: the storage-optimized instance families exist precisely to ship large, fast local NVMe — when a scenario picks one of those for a high-I/O distributed database, the instance store is the point of the choice, not an accident of it.

The exam plays this from both directions. In one shape, the scenario needs "the highest possible I/O performance" for temporary processing data, and instance store beats every EBS option — including io2 — because physical attachment beats network-attached storage. In the other shape, instance store appears as a trap: an option proposes it for data the scenario clearly needs to survive a stop/start cycle, and you eliminate it on the ephemerality alone. Read for one word before you pick it: is the data temporary? If the scenario never says so, instance store is the distractor, not the answer.

Amazon EFS is the default answer when many Linux instances need read-write access to the same files. It is a managed NFS file system: thousands of concurrent connections, mounted simultaneously by instances across multiple Availability Zones, with full POSIX semantics — permissions, locking, hierarchical directories. Nothing in the EBS column does that, and the multi-AZ reach is exactly what an Auto Scaling group of web servers or a shared content repository needs.

Its second superpower is elasticity: you never provision capacity. The file system grows and shrinks automatically as files are added and removed, and you pay for what is stored — which makes EFS the "scales to accommodate future needs" option whenever a scenario worries about unpredictable growth in shared file data. That is a real differentiator against EBS, where scaling means resizing volumes, and against self-managed file servers, where scaling means new hardware; when a question stresses future scale for shared files with no capacity planning, EFS is answering it directly. Lifecycle management can move cold files to an Infrequent Access storage class automatically, answering cost-optimization variants. EFS also mounts from on-premises servers over Direct Connect or VPN — a recognition-level fact for hybrid file-sharing scenarios.

Performance configuration comes up at recognition level, in two dimensions. Throughput modes: the classic default, bursting, scales throughput with the amount of data stored — big file systems get more, small ones burst on credits. That breaks down for the small-but-busy file system: little data, heavy traffic, credits exhausted. The fix is provisioned throughput, where you dial in throughput independent of size — the exam phrase is a small file system that "needs higher throughput than its size allows." A newer elastic throughput option scales automatically with the workload and bills per use; recognize it as the no-tuning choice for spiky, unpredictable access. Performance modes: General Purpose (default, lowest latency) versus Max I/O (higher aggregate parallelism for massively concurrent workloads, at some added latency) — a one-line recognition fact.

Remember the boundary: EFS is Linux/NFS. A scenario with Windows instances or SMB shares walks past EFS to FSx. On the exam, "shared," "concurrent," "across AZs," and "POSIX" are the four EFS tells; when they appear together, the EBS and S3 options are there to be eliminated.

The FSx family exists for workloads that need a specific file-system technology, and FSx questions are close to keyword matching — the scenario names the ecosystem, you name the FSx variant.

FSx for Windows File Server is fully managed Windows-native file storage: SMB protocol, NTFS features, and — the detail the exam leans on — integration with Active Directory. Any scenario with Windows applications, SMB shares, or users authenticating against AD resolves here. EFS is wrong for these because it speaks NFS to Linux clients; that elimination is the whole question more often than you would expect.

FSx for Lustre is the high-performance computing answer: a parallel file system built for hundreds of gigabytes per second of aggregate throughput, sub-millisecond latencies, and massive concurrency — machine learning training, genomics, financial simulation, video rendering. Its signature exam feature is the S3 linkage: a Lustre file system can be linked to an S3 bucket, presenting the bucket's objects as files, letting a compute fleet churn through them at Lustre speed, and writing results back to S3. "Data lake in S3, needs a fast POSIX file system for a processing burst" is FSx for Lustre in one sentence. Cost-wise, know that Lustre offers scratch file systems — cheaper, non-replicated, built for short-lived processing jobs — alongside persistent ones for longer-running workloads; a burst of computation over S3 data pairs naturally with scratch, which is how the MOST cost-effective variant of the HPC question gets answered.

FSx for NetApp ONTAP brings the NetApp feature set (multi-protocol NFS and SMB, snapshots, replication) for enterprises migrating existing ONTAP estates; FSx for OpenZFS serves workloads that want ZFS capabilities over NFS. Both are recognition-level: match the named technology, move on.

The exam's FSx pattern is a shared-file-storage scenario with one qualifying noun — Windows, Active Directory, HPC, Lustre, NetApp — and four file services as options. The noun picks the winner; the discipline is not defaulting to EFS out of familiarity when the scenario has quietly ruled Linux/NFS out.

S3's core performance property is that aggregate throughput is virtually unlimited and scales automatically — you do not provision S3, you use it harder. What the exam tests is the toolkit for getting data in and out fast, because each tool answers a different bottleneck.

Multipart upload splits a large object into parts uploaded in parallel; failed parts retry individually instead of restarting the whole transfer. It is the recommended approach for large objects generally, and the answer whenever a scenario mentions large uploads that are slow or that fail partway on unreliable connections. Byte-range fetches are the download mirror: request ranges of an object in parallel to saturate bandwidth, or fetch only the region you need instead of the whole object.

Transfer Acceleration attacks distance, not size: clients upload to the nearest CloudFront edge location, and the data rides Amazon's optimized network backbone to the bucket's Region. The exam tell is geography — "users around the world upload to a bucket in one Region" or "long-distance transfers over the public internet are slow." If the clients are already near the bucket's Region, acceleration buys little; that nuance separates it from multipart, which helps regardless of distance. The two combine for globally distributed large-file ingestion.

Prefix parallelism is the request-rate lever, needed at concept level: S3 scales request throughput per prefix, so an application that spreads reads and writes across many key prefixes achieves far higher aggregate request rates than one hammering a single prefix. "Extremely high request rates" plus "all objects share one key prefix" is the setup; distributing keys across prefixes is the fix.

For read-heavy delivery to end users, remember that CloudFront in front of S3 moves content to the edge and cuts both latency and load on the bucket — the standard answer for global static-content performance. And when the same objects must be written and read at low latency from multiple Regions, recognize that S3 replication (and Multi-Region Access Points) put copies near each set of users rather than making every request cross an ocean. The exam distinguishes these tools by bottleneck: object size (multipart, byte-range), distance (Transfer Acceleration, CloudFront), request rate (prefixes). Name the bottleneck first and the right optimization falls out.

Hybrid questions hinge on one distinction: does the on-premises side need continuing access to data that lives in AWS, or does data need to be moved to AWS?

AWS Storage Gateway answers the first case. It is an on-premises appliance (virtual or hardware) that presents standard storage interfaces locally while the data lives in AWS — and, critically, it keeps a local cache of frequently accessed data, so on-premises applications get low-latency access to their hot set while the cloud holds the durable copy. Three types, matched by interface: File Gateway presents NFS or SMB shares backed by S3 objects — the answer for "on-premises applications need file access to data stored in S3." Volume Gateway presents iSCSI block volumes, in cached mode (data in AWS, hot blocks cached locally — extends limited local storage) or stored mode (full dataset on-premises, asynchronously backed up to AWS as EBS snapshots — for lowest-latency full-local access). Tape Gateway presents a virtual tape library so existing backup software writes "tapes" that actually land in S3 and archive tiers — the drop-in replacement for physical tape without changing backup workflows.

AWS DataSync answers the second case: an online transfer service purpose-built for moving datasets — one-time migrations or scheduled, incremental transfers — from NFS, SMB, HDFS, or object storage into S3, EFS, or FSx (and between AWS storage services), with built-in acceleration, scheduling, encryption, and integrity verification. When a scenario says "migrate," "transfer," "one-time," or "nightly sync of on-premises data to AWS," DataSync beats a gateway: it moves data efficiently and stops, rather than standing up a permanent access bridge.

The exam pairs them deliberately. "Applications keep working against the data from the datacenter" — Storage Gateway, then pick File, Volume, or Tape by the interface named. "Get the data into AWS on a schedule, decommission afterwards" — DataSync. An answer offering DataSync for continuous application access, or a File Gateway for a bulk migration, has confused access with movement — the exact confusion the question is checking for.

Most Task 3.1 questions compress to a phrase-to-service lookup. Internalize this table and read scenarios for the trigger phrase in the left column.

Exam questions built on this table hide the phrase inside operational detail — your job is extraction. When two rows both seem to fit, the constraint qualifier (MOST performant, MOST cost-effective, LEAST overhead) breaks the tie: performance qualifiers push down-column toward io2, instance store, or Lustre; cost qualifiers push toward gp3, HDD types, or S3.

Scenario 1. A company runs a mission-critical relational database on a single EC2 instance. Monitoring shows the database sustains tens of thousands of IOPS around the clock, and the business requires consistent sub-millisecond storage latency. Which storage configuration meets the requirement?

Reasoning: "Database on EC2" fixes the storage type — block, so EBS or instance store, and the S3 and EFS options fall immediately (object APIs and NFS latency are the wrong shape for database files). Instance store falls next: the speed is there, but a database's data files are the opposite of replaceable, and instance store evaporates on a stop or hardware failure. That leaves the EBS ladder. Both HDD types lose on access pattern — database I/O is small and random, HDDs are sequential-throughput devices. gp3 is the cost-first default, but two phrases exceed its brief: sustained tens of thousands of IOPS and a hard consistency requirement on sub-millisecond latency. That is precisely what provisioned-IOPS volumes exist for: io2, sized with provisioned IOPS matching the measured demand. On a variant with a modest requirement, the same reasoning flips the answer to gp3, and io2 becomes the overpriced distractor. The number and the word "sustained" decide it.

Scenario 2. A media-processing application runs on an Auto Scaling group of Linux EC2 instances spread across three Availability Zones. Every instance must read and write the same working set of project files using standard file-system operations, and the dataset's size fluctuates unpredictably. What storage should the architect choose?

Reasoning: Extract the pattern: shared, concurrent, read-write, across AZs, file-system semantics. EBS is eliminated twice over — a volume attaches within one AZ, and even io2 Multi-Attach is same-AZ and demands a cluster-aware file system nothing here justifies. S3 is durable and scales, but the application performs standard file operations, not API calls, so it fails the access pattern. That leaves file storage: the instances are Linux, no Windows, AD, or HPC keyword redirects to FSx, so EFS wins — concurrent NFS mounts from every instance in every AZ, and elastic capacity absorbs the unpredictable growth without anyone provisioning a byte. If the same scenario had said "Windows instances accessing SMB shares," every step survives except the last, and the answer becomes FSx for Windows File Server — which is exactly how the exam builds its variants.