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

Storage on AWS comes in three types defined by how the application addresses its data: object (Amazon S3), block (Amazon EBS) and file (Amazon EFS and FSx). Every Task 3.1 question starts with that silent classification. 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.

An EBS volume type is chosen by the shape of the I/O first and the size of the requirement second. 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. An HDD offered to cut the bill for a random-I/O workload fails the performance need, however cheap it is.

Two older types still appear in scenarios as the starting point of a change. gp2 ties IOPS to size at 3 IOPS per GiB and caps at 16,000 IOPS, so it cannot be grown to match a higher provisioned-IOPS requirement and costs more than gp3 for the same performance. io1 is the previous Provisioned IOPS generation; a workload on io1 whose IOPS fit within gp3's ceiling and that tolerates single-digit-millisecond latency usually runs for less on gp3 at the same provisioned IOPS.

Three configuration facts carry questions. First, gp3 decouples performance from capacity: you raise IOPS or throughput without buying a bigger volume, so "needs more IOPS, the disk is mostly empty" resolves to new gp3 settings, not a larger disk or a new volume type. Second, latency is a property of the volume type. Striping several gp3 volumes with RAID 0 adds their IOPS and throughput together, but each I/O still has gp3 latency, so RAID 0 cannot turn single-digit-millisecond storage into sub-millisecond storage; only io2 Block Express (or instance store) changes the latency class. Third, the IOPS number and the latency requirement are separate tests: a database needing 20,000 IOPS with single-digit-millisecond latency is a gp3 workload, while the same database needing 120,000 IOPS, or sub-millisecond latency at peak, is an io2 Block Express workload.

Most EBS changes happen in place. Elastic Volumes lets you increase a volume's size and change its type, IOPS and throughput while it stays attached and in use, with no downtime: io1 to gp3, gp2 to gp3, gp3 with higher provisioned IOPS, or a large volume of cold data moved to sc1. Size can only grow, and after a modification you wait before modifying the same volume again (the volume passes through an optimizing state). When a scenario says the database cannot be taken offline, a snapshot-and-restore migration or a new volume with a data copy loses to an Elastic Volumes modification.

Multi-Attach: a shared block device, not a shared file system

EBS Multi-Attach attaches one volume to several Nitro-based instances at the same time. It is supported only on Provisioned IOPS SSD volumes (io1 and io2), never on gp3, gp2 or HDD types; every instance must be in the volume's Availability Zone (up to 16 instances); and the application must coordinate writes with a cluster-aware file system, because a standard file system such as ext4 or XFS mounted by several hosts corrupts data. Keep the distinction sharp: clustered software that needs a shared block device every node attaches directly uses io1/io2 Multi-Attach; ordinary applications that need shared files, especially across AZs, use a file service (EFS, or FSx for Windows/SMB).

Cost levers that keep the data where it must be

The deciding detail is usually whether the data must stay mounted. If auditors need to browse files on an attached volume, sc1 keeps them there; if only a point-in-time copy must be retained, a snapshot in the archive tier is cheaper still, but it is not a mounted volume.

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.

The durable alternative for the same high-I/O workload is io2 Block Express. It is network-attached, so its sub-millisecond latency is still higher than local NVMe, but it survives stops, host failures and instance replacement, can be snapshotted, and can be detached and reattached. For a distributed database that already replicates every partition to nodes in other AZs, instance store wins: losing one node's disk is repaired from its peers, and paying for durable provisioned IOPS on every replica buys protection the cluster already provides. For a database that keeps a single authoritative copy, or that must restart on a new host without rebuilding from peers, io2 Block Express is the answer. Scheduled backups to S3 add a recovery point for both designs.

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. EFS also mounts from on-premises servers over Direct Connect or VPN.

Its second strength is elasticity: you never provision capacity. The file system grows and shrinks 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. Against EBS, scaling means resizing volumes; against a self-managed file server, it means new hardware.

Throughput modes: how throughput is supplied and billed

The classic failure is the small-but-busy Bursting file system: little data, heavy traffic, credits exhausted by midday. Both other modes fix it, and the scenario's load shape decides which: a steady, all-day load with a known rate points to Provisioned; occasional, unpredictable bursts with idle time between points to Elastic, which avoids paying for a provisioned peak most of the week. You can switch throughput modes on an existing file system.

Performance modes are a separate, creation-time setting. AWS recommends General Purpose for all file systems. Max I/O is a previous-generation mode with higher latency; it cannot be changed after creation and is not supported with Elastic throughput or One Zone file systems, so it is no longer the answer to a performance problem.

Storage classes and lifecycle management: the cost levers

EFS storage cost is set by storage class, not throughput mode. Lifecycle management moves files that have not been accessed for a chosen period from EFS Standard to Infrequent Access (IA), and on to EFS Archive for data read a few times a year or less. Each colder class has a lower storage price and a per-access charge. Archive has a 90-day minimum storage duration and is supported only on file systems that use Elastic throughput, so a file system on Provisioned or Bursting throughput must switch to Elastic before files can move to Archive. An optional "transition into Standard" policy moves a file back to Standard on its first access: it improves performance for files that become active again, but it adds cost, because those files pay the Standard price once more. Switching a file system to Provisioned throughput changes how throughput is billed and adds a fixed charge; it does nothing to the per-GB storage price.

Regional versus One Zone

Regional file systems store data redundantly across multiple AZs and survive the loss of an AZ. One Zone file systems store data in a single AZ at a lower price. Instances in other AZs can still mount a One Zone file system, but they pay cross-AZ data-transfer charges, see extra latency, and lose access if that AZ fails. You cannot convert between the two: moving data from Regional to One Zone (or back) means creating a new file system and copying the data into it, for example with DataSync.

Remember the boundary: EFS is Linux/NFS. A scenario with Windows instances or SMB shares walks past EFS to FSx. "Shared," "concurrent," "across AZs," and "POSIX" are the four EFS signals; 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: the scenario names the ecosystem or protocol, and that names the FSx variant.

FSx for Windows File Server is fully managed Windows-native file storage: SMB protocol, NTFS permissions and, the detail most scenarios lean on, integration with Active Directory. Windows applications, mapped network drives, SMB shares or users authenticating against AD resolve here. EFS is wrong for these because it speaks NFS to Linux clients. Its deployment type decides availability: Single-AZ runs one file server in one AZ (data is replicated within that AZ), so an AZ outage takes the share down; Multi-AZ runs an active file server and a standby in a second AZ with synchronous replication and automatic failover, so the share survives an AZ failure. A requirement that the share stay available if an AZ fails means Multi-AZ.

FSx for Lustre is the high-performance computing answer: a parallel file system built for very high aggregate throughput, sub-millisecond latencies and massive concurrency, used for machine learning training, genomics, financial simulation and rendering. Its signature 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 process them at Lustre speed, and writing results back to S3. Deployment types set cost and durability: scratch file systems are cheaper and do not replicate data (a failed server loses its data), built for short-lived processing; persistent file systems replicate within the AZ for longer-running workloads. A processing burst over data whose durable copy lives in S3 pairs naturally with scratch.

FSx for OpenZFS cannot serve SMB shares or Active Directory permissions, so it is never the answer for Windows clients; among the FSx variants, only Windows File Server and ONTAP speak SMB. The usual FSx scenario is a shared-file requirement with one qualifying noun (Windows, Active Directory, HPC, Lustre, NetApp, ZFS) 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 ruled Linux/NFS out.

S3's aggregate throughput scales automatically and is virtually unlimited; you do not provision S3, so S3 performance work means matching an optimization to the bottleneck: object size, distance, request rate or latency.

Multipart upload splits a large object into parts uploaded in parallel; a failed part retries alone instead of restarting the whole transfer. It is recommended for large objects generally and is the answer when large uploads are slow or fail partway on unreliable connections. Byte-range fetches are the download mirror: request ranges of an object in parallel to use more bandwidth, or fetch only the bytes you need, such as a header at a known offset, instead of the whole object.

Transfer Acceleration attacks distance, not size: clients upload through the nearest CloudFront edge location and the data travels Amazon's backbone to the bucket's Region. It helps clients far from the bucket and buys little for clients already near it. It is a network path, not a cache: every request still reaches the bucket. Multipart and Transfer Acceleration combine for globally distributed large-file ingestion.

Request rates, prefixes, and 503 Slow Down

S3 supports at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per partitioned prefix, with no limit on the number of prefixes in a bucket. Traffic above a prefix's current rate is answered with HTTP 503 Slow Down while S3 scales. Two fixes match two causes. Spreading keys across many prefixes multiplies the request rate the bucket can serve, but only for objects stored under those prefixes: hot objects that already exist must be copied to the new keys (and references updated) to benefit; re-keying only new uploads leaves the hot objects throttled. When the load is the same objects read over and over, CloudFront in front of the bucket serves them from edge caches, so most requests never reach S3 at all, and readers worldwide get lower latency. Clients should also retry 503s with exponential backoff.

S3 Express One Zone: lowest latency next to the compute

S3 Express One Zone is a storage class that stores data in directory buckets in a single Availability Zone you choose, delivering consistent single-digit-millisecond access and very high request rates for compute running in the same AZ, such as ML training or interactive analytics reading many small objects. Because data lives in one AZ, it fits data that can be re-created or has a copy elsewhere. It does nothing for uploaders far from the Region; distance is Transfer Acceleration's job.

When the same objects must be written and read at low latency from multiple Regions, S3 replication and Multi-Region Access Points put copies near each set of users. In short: object size (multipart, byte-range), distance (Transfer Acceleration for uploads, CloudFront for reads), request rate (prefixes, CloudFront for repeated reads), same-AZ latency (S3 Express One Zone). Name the bottleneck first and the optimization follows.

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: S3 File Gateway presents NFS or SMB shares backed by S3 objects (SMB shares can authenticate users against Active Directory), 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 (iSCSI VTL), so existing backup software keeps writing to "tapes" with its current jobs. Active virtual tapes are stored in S3; when the backup application ejects a tape, it is archived to the pool you choose: S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive, the lowest-cost option for long-term copies that are rarely restored (retrieving an archived tape takes hours). Pointing the backups at an S3 File Gateway share with lifecycle rules could also reach Glacier storage, but it would mean reconfiguring tape-based backup jobs to write to a file share instead, which is exactly what Tape Gateway avoids.

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 toward io2 Block Express, instance store, Lustre or S3 Express One Zone; cost qualifiers push toward gp3, HDD types, or S3.

Scenario 1. A market-data platform writes every incoming tick to a write-ahead log on a single EC2 instance before acknowledging it. The log needs only around 25,000 IOPS, but the acknowledgement path is budgeted for storage latency well under a millisecond, and the log must survive an instance stop. What should back the log volume?

Reasoning: Start with what the numbers say, one requirement at a time. On IOPS alone, 25,000 sits comfortably inside gp3's range, so if throughput were the only constraint, gp3 with raised IOPS would be the cost-first answer. The latency requirement is a separate test, and gp3 fails it: gp3 is a single-digit-millisecond volume regardless of how many IOPS you provision, and adding volumes in a stripe raises the aggregate rate without moving any single I/O into a lower latency class. Durability rules out instance store, which is fast but is lost on a stop. That leaves io2 Block Express, provisioned near the measured 25,000 IOPS rather than at its maximum, because latency is the reason to choose it and paying for unused IOPS buys nothing. The lesson: IOPS and latency are independent gates. A modest IOPS figure does not make gp3 sufficient when the latency budget is sub-millisecond, and a high IOPS figure above gp3's ceiling forces io2 even when latency is relaxed. When neither gate is crossed, gp3 is the answer and io2 is overspend.

Scenario 2. During a phased migration, a Linux build farm runs partly on EC2 instances in two Availability Zones and partly on on-premises Linux servers connected over AWS Direct Connect. Both groups must read and write one shared directory of build artifacts with ordinary file operations, and the team does not want to manage file servers. What storage fits?

Reasoning: Name the pattern before the service: shared, read-write, POSIX/NFS, multiple AZs, plus on-premises clients, no servers to run. Shared file semantics points to file storage rather than block or object storage. Linux clients with no Windows, SMB or Active Directory requirement point to NFS, and nothing mentions HPC scratch or a NetApp feature set, so Amazon EFS fits. A Regional EFS file system has mount targets in each AZ, and on-premises Linux servers can mount it over Direct Connect or a VPN, so both halves of the farm see the same directory with no gateway to operate. The variants show how the pattern drives the answer. If the clients were Windows and used SMB shares joined to AD, the answer would move to FSx for Windows File Server. If the on-premises side needed a low-latency local cache of data whose system of record is S3, the answer would be S3 File Gateway. If the on-premises data only had to be copied into AWS once, DataSync would replace a shared mount altogether.