Choosing High-Performing Storage

AWS storage splits into three types, and picking the wrong one is one of the most common exam traps. Object storage (Amazon S3) stores whole files with metadata, accessed over HTTP, with no fixed limit on total capacity. Block storage (Amazon EBS) presents raw, low-level volumes that an operating system formats and mounts like a local disk — the natural fit for a database's data files. File storage (Amazon EFS, Amazon FSx) presents a shared file system that many instances can mount at once, complete with a directory structure.

An EBS volume lives in one Availability Zone and attaches to one instance at a time (a few volume types support Multi-Attach to several instances in the same AZ, but that's the exception, not the default). Within EBS, gp3 is the default general-purpose SSD: every volume gets a 3,000 IOPS and 125 MiB/s baseline free, and you can provision more independently of size. io2 is the provisioned-IOPS SSD for the most demanding, latency-sensitive transactional workloads — the highest IOPS ceiling EBS offers. st1 (throughput-optimized HDD) and sc1 (cold HDD) are priced for large, sequential, throughput-heavy workloads like log processing, not for high IOPS.

aws ec2 create-volume \
  --availability-zone us-east-1a \
  --volume-type gp3 \
  --size 500 \
  --iops 6000 \
  --throughput 500

When several instances need to read and write the same files at once — a shared content repository, a home directory for a fleet of application servers — a block volume won't do, because only one instance can mount it at a time. Amazon EFS is a managed, POSIX-compliant file system that many instances (and Lambda functions) can mount concurrently across multiple Availability Zones. Its General Purpose performance mode is the default and gives the lowest per-operation latency; Max I/O is a legacy mode that trades higher latency for a higher ceiling on aggregate throughput and IOPS, and AWS recommends General Purpose for nearly every workload today. EFS's throughput can scale with Bursting (tied to file system size), Provisioned (a fixed rate you set), or Elastic (scales automatically with actual usage).

Amazon FSx offers purpose-built file systems for specific ecosystems: FSx for Windows File Server for SMB-based Windows workloads, and FSx for Lustre for high-performance computing workloads — like machine learning training — that need very high, parallel throughput straight from S3 data.

A quick decision framework: if the workload is a database's data files or a boot volume, and only one instance needs it, reach for EBS, and pick the volume type by the dominant performance need — IOPS for io2, throughput for st1, cost for sc1, and gp3 for nearly everything else. If several instances or functions need concurrent read/write access to the same files, reach for EFS. If the workload is Windows-native file sharing or high-performance computing with a Lustre-aware toolchain, reach for the matching FSx file system. And if what you're really storing is discrete objects — images, backups, log files, data lake files — none of the above is right: that's S3.