EBS, EFS, FSx Family, and Storage Gateway

Match the protocol before you pick a brand name

Task 2.5 expects you to design storage for the access pattern, then rightsize (Task 2.6) so you are not paying file-system prices for object workloads or stuffing Windows ACL home directories onto NFS. Amazon Elastic Block Store (Amazon EBS) is disks attached to Amazon Elastic Compute Cloud (Amazon EC2) in one AZ (with snapshots as the backup/cross-AZ copy). Amazon Elastic File System (Amazon EFS) is shared Network File System (NFS) for Linux. Amazon FSx is four managed file systems with different protocols. AWS Storage Gateway presents NFS, SMB, iSCSI, or virtual tape to on-premises hosts while data lives in AWS.

A global media transcode fleet that needs many Linux workers reading the same mezzanine tree is an EFS or FSx for Lustre problem. A lift-and-shift of departmental Windows file shares is FSx for Windows File Server (or FSx File Gateway at the edge). A trading matching engine on one host is EBS. Mixing those up is how SAP-C02 distractors are written.

EBS types and IOPS

SSD volumes are for small, random, transactional I/O. HDD volumes are for large sequential throughput. General Purpose SSD (gp3) is the current default SSD: 1 GiB–64 TiB, baseline 3,000 IOPS and 125 MiB/s included with capacity, provisionable independently up to 80,000 IOPS and 2,000 MiB/s (additional IOPS scale at 500 IOPS per GiB; maximum IOPS requires at least 160 GiB). gp3 does not burst; it holds provisioned performance. gp2 still exists: IOPS scale at 3 per GiB to 16,000, with burst to 3,000 IOPS on smaller volumes, and a 16 TiB cap. Prefer gp3 for new volumes.

When the stem needs sustained performance above gp3, sub-millisecond tails, or clustering, move to Provisioned IOPS SSD. io2 Block Express is designed for average latency under 500 microseconds on 16 KiB I/O, up to 256,000 IOPS and 4,000 MiB/s, sizes 4 GiB–64 TiB, and 99.999% durability. io1 tops out at 64,000 IOPS and 1,000 MiB/s. Multi-Attach is supported on io1 and io2 in the same AZ, not on gp3; the file system or application must be cluster-aware (for example SCSI reservations on io2). st1 (throughput HDD, up to 500 MiB/s) and sc1 (cold HDD, up to 250 MiB/s) are sequential, not bootable, and wrong for databases. Instance store is ephemeral scratch: fastest local I/O, gone on stop or terminate.

Elastic Volumes let you change type, size, and provisioned IOPS without detaching. Snapshots are incremental and restorable across AZs or Regions; they are not a clustered file system. For a latency-sensitive trading database on one Nitro instance that needs more than 80,000 IOPS, io2 Block Express is the documented step up—not a larger gp3, and not EFS.

EFS: Regional file systems, throughput, and replication

Amazon EFS is elastic NFS (NFSv4) for many EC2 instances, containers, and Lambda functions. Regional file systems store data redundantly across AZs. One Zone file systems are cheaper and fail if that AZ is lost; they always use General Purpose performance mode. AWS recommends General Purpose performance mode for all file systems because Max I/O raises per-operation latency; Max I/O is a previous-generation mode and is incompatible with One Zone and with Elastic throughput.

Throughput modes:

• Elastic (recommended default): scales with activity; you pay for metered read/write; no burst credits. Best when traffic is spiky or the average-to-peak ratio is about 5% or less.
• Provisioned: you set MiB/s when you know a steady floor or the average-to-peak ratio is higher.
• Bursting: baseline grows with Standard storage (50 KiB/s per GiB). Credits let you burst; small file systems starve under media ingest. If you burn credits, move to Elastic or Provisioned.

EFS Standard is SSD-like first-byte latency (about 1 ms read, 2.7 ms write on Regional). Infrequent Access and Archive trade tens of milliseconds of first-byte latency for lower storage cost via lifecycle. EFS is the right shared POSIX store for Linux transcoders; it is the wrong origin for millions of HTTP video viewers (put objects in S3 and use CloudFront).

EFS replication copies a file system to another Region (or, with extra IAM, another account). After the initial sync, AWS documents a typical 15-minute recovery point objective for most file systems; very large file counts or huge files can take longer. Failover is a promotion/failback workflow, not a multi-AZ mount of the replica. Replication is not application-consistent backup; keep AWS Backup in the design when you need point-in-time restores.

FSx family selection

Pick FSx by the file system you already operate and the protocol clients speak.

FSx for Windows File Server is a native Windows Server file system: Kerberos, SMB encryption in transit, User/Group quotas, and integration with AWS Directory Service for Microsoft Active Directory or a self-managed AD. Single-AZ versus Multi-AZ is an availability choice. SSD versus HDD is a performance/cost choice (HDD for home directories; SSD for latency-sensitive shares). You provision storage, SSD IOPS, and throughput independently. This is the default answer for enterprise Windows file shares in AWS—not EFS, and not a fleet of EBS volumes with a DIY Samba host unless the stem forces it.

FSx for Lustre is for parallel, many-client Linux jobs. Pair it with S3 when the lake of objects is the system of record and the file system is scratch or a working set. FSx for NetApp ONTAP wins when the estate already runs ONTAP, needs iSCSI plus file, or needs NetApp efficiency features. FSx for OpenZFS wins when the on-premises NAS is ZFS and you want those snapshot/clone semantics on NFS without Windows.

Storage Gateway as the hybrid bridge

AWS Storage Gateway is an on-premises (or EC2) appliance, not a second cloud file system for EC2-only workloads.

• S3 File Gateway: NFS or SMB mount whose files are S3 objects. Good for backup landing zones and lift of file-oriented apps that can tolerate object-store semantics behind a file protocol.
• FSx File Gateway: local cache in the data center in front of FSx for Windows File Server, so branch offices keep SMB latency low while the authoritative share lives in AWS.
• Volume Gateway: iSCSI block. Cached mode stores the full volume in S3 and keeps recently used data in the on-premises cache—the usual cloud-backed pattern. Stored mode keeps the entire dataset on-premises and asynchronously snapshots to S3 for DR.
• Tape Gateway: a virtual tape library for backup apps that still speak tape; virtual tapes archive into S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive.

Do not use Tape Gateway when the application can write to S3 or EFS natively. Do not use Volume Gateway cached mode when the requirement is “every byte must remain on the SAN in the building”—that is stored mode. Do not use S3 File Gateway as a replacement for FSx for Windows when the stem requires NTFS ACLs, DFS, and VSS on a first-class Windows file server.

Putting the Windows and media scenarios together

Departmental Windows shares: Multi-AZ FSx for Windows joined to AD, HDD or SSD by latency, DFS for namespace, VSS-based backups, FSx File Gateway at remaining offices. Linux media workers: Regional EFS with Elastic throughput (or Lustre if the job is a tightly coupled HPC cluster against S3). Single-node trading DB: io2 Block Express, not a shared file system. Hybrid backup: Tape Gateway or Volume Gateway according to the protocol the existing backup software already speaks. Professional answers name the protocol first, then the managed service that implements it.