8 · Storage Performance¶
Domain 3 — Design High-Performing Architectures · 24%
Storage questions are about picking the right kind of storage (object / block / file), then the right tier or volume type within it. The big recurring judgments: S3 storage class for a given access pattern, EBS volume type for a given IOPS/throughput need, and EFS vs FSx vs EBS for shared access.
Core concept¶
Three storage shapes — match the workload to the shape first:
| Shape | Service | Looks like | Attach model |
|---|---|---|---|
| Object | S3 | Files addressed by key, via API/HTTP | Accessed from anywhere; not a mounted disk |
| Block | EBS, instance store | A raw disk volume | One instance (EBS; Multi-Attach for a few) |
| File | EFS, FSx | A shared network file system | Many instances mount it concurrently |
If a scenario says "many instances need to read/write the same files at once," that's file (EFS/FSx), not EBS.
S3 storage classes¶
All classes give 11 nines (99.999999999%) durability. They differ in availability, minimum storage duration, retrieval cost, and speed:
| Class | Best for | Notes |
|---|---|---|
| S3 Standard | Frequently accessed | Highest availability; no retrieval fee |
| Intelligent-Tiering | Unknown / changing access patterns | Auto-moves between tiers; no retrieval fees; small monitoring fee |
| Standard-IA | Infrequent, needs fast access | Cheaper storage + retrieval fee; min 30 days |
| One Zone-IA | Infrequent + reproducible data | Stored in one AZ (lost if that AZ is destroyed); ~20% cheaper than Standard-IA; min 30 days |
| Glacier Instant Retrieval | Archive, need milliseconds | Cheap storage; min 90 days |
| Glacier Flexible Retrieval | Archive, retrieval in minutes–hours | Expedited/Standard/Bulk; min 90 days |
| Glacier Deep Archive | Coldest, cheapest | Retrieval in hours; min 180 days |
Cues: unknown/changing pattern → Intelligent-Tiering; predictable infrequent → Standard-IA; reproducible + cheap → One Zone-IA; archive with instant access → Glacier Instant; coldest, cheapest, hours OK → Deep Archive. Automate transitions with lifecycle rules.
S3 performance facts:
- ~3,500 PUT/COPY/POST/DELETE and ~5,500 GET/HEAD requests per second, per prefix — and this scales horizontally by spreading objects across more prefixes.
- Multipart upload for large objects (recommended > 100 MB, and a single PUT maxes at 5 GB so it's required beyond that). Max object size is 5 TB.
- S3 Transfer Acceleration speeds long-distance uploads via CloudFront edge locations.
- Byte-range fetches parallelize/partial-read a large object.
EBS volume types (verified)¶
Block storage attached to a single instance in one AZ (some support Multi-Attach). SSD is IOPS-oriented; HDD is throughput-oriented and can't be a boot volume.
| Type | Category | Max IOPS | Max throughput | Pick for |
|---|---|---|---|---|
| gp3 | General Purpose SSD | 16,000 (up to 80,000) | up to 2,000 MiB/s | Default — baseline 3,000 IOPS / 125 MiB/s, IOPS & throughput scalable independently, cheaper than gp2 |
| gp2 | General Purpose SSD | 16,000 | 250 MiB/s | Legacy general purpose (IOPS scales with size at 3 IOPS/GiB) |
| io2 Block Express / io1 | Provisioned IOPS SSD | 256,000 / 64,000 | 4,000 / 1,000 MiB/s | Critical high-IOPS DBs; io2 adds 99.999% durability + Multi-Attach |
| st1 | Throughput Optimized HDD | 500 | 500 MiB/s | Big sequential throughput: big data, log processing (not boot) |
| sc1 | Cold HDD | 250 | 250 MiB/s | Infrequently accessed, lowest cost (not boot) |
Cues: general workloads → gp3 (default); highest IOPS / mission-critical DB → io2; large sequential streaming / logs → st1; cold & cheap → sc1. Need a volume shared by a few clustered instances → io1/io2 Multi-Attach (same AZ).
Instance store = physically attached, ephemeral disk. Highest IOPS / lowest latency, but data is lost on stop, terminate, or hardware failure — use only for caches, buffers, and scratch.
EFS vs FSx (shared file systems)¶
| Service | Protocol / OS | Use when |
|---|---|---|
| Amazon EFS | NFS, Linux | Shared POSIX file system, many Linux instances across AZs, elastic auto-scaling |
| FSx for Windows File Server | SMB, Windows | Windows shared drives, Active Directory integration |
| FSx for Lustre | Lustre, HPC | High-performance computing / ML, huge throughput, S3-integrated |
| FSx for NetApp ONTAP / OpenZFS | multi-protocol | Migrating existing ONTAP/ZFS workloads |
Cues: shared Linux across AZs → EFS; Windows/SMB shared → FSx for Windows; HPC/ML fast scratch → FSx for Lustre.
Worked example — shared storage across AZs¶
A fleet of Linux application servers in an Auto Scaling group spanning two AZs must all read and write the same set of user-uploaded files simultaneously, and storage should grow automatically. A teammate suggests attaching a large EBS volume.
Will EBS work? What's correct?
Answer
EBS won't work here. A standard EBS volume attaches to a single instance in a single AZ — it can't be shared read/write by many instances across AZs (Multi-Attach is same-AZ, limited volume types, and needs a cluster-aware app). The right answer is Amazon EFS: a managed NFS file system that many Linux instances across AZs mount concurrently, growing elastically. (If the servers were Windows, you'd use FSx for Windows File Server instead.)
Exam traps¶
- Same files, many instances at once → file storage (EFS/FSx), not EBS.
- EBS is single-AZ, single-instance (Multi-Attach is a narrow exception); snapshots go to S3.
- HDD (st1/sc1) can't be boot volumes; gp3 is the default SSD and is cheaper than gp2.
- Highest IOPS / mission-critical DB → io2 (Provisioned IOPS); big sequential throughput → st1.
- Instance store is ephemeral — data lost on stop/terminate; never for persistent data.
- Unknown/changing access pattern → S3 Intelligent-Tiering (no retrieval fees); predictable infrequent → Standard-IA.
- One Zone-IA lives in a single AZ — only for reproducible/non-critical data.
- IA/Glacier minimum durations: Standard-IA/One Zone-IA 30 days, Glacier 90, Deep Archive 180 — deleting earlier still incurs the minimum charge.
- EFS = Linux/NFS; FSx for Windows = SMB; FSx for Lustre = HPC/ML.
Practice questions¶
Q1. Multiple Linux EC2 instances across two Availability Zones must concurrently read and write the same files, and the storage should scale automatically. Which service?
- A. Amazon EBS with Multi-Attach
- B. Amazon EFS
- C. Amazon S3
- D. FSx for Windows File Server
Answer: B
B. EFS is a managed, elastic NFS file system that many Linux instances across AZs mount concurrently. EBS Multi-Attach (A) is same-AZ and limited. S3 (C) is object storage, not a mounted file system. FSx for Windows (D) is SMB for Windows, not Linux.
Q2. A mission-critical relational database needs sustained high IOPS with consistent low latency on its storage volume. Which EBS type is most appropriate?
- A. gp2
- B. Provisioned IOPS SSD (io2)
- C. Throughput Optimized HDD (st1)
- D. Cold HDD (sc1)
Answer: B
B. Provisioned IOPS SSD (io1/io2) is designed for high, consistent IOPS for critical databases, and io2 adds higher durability and Multi-Attach. gp2 (A) can't guarantee the same high IOPS. st1/sc1 (C, D) are throughput-oriented HDDs, poor for random IOPS and not for boot volumes.
Q3. A dataset has unpredictable, changing access patterns — some objects are read often, then go cold, then get popular again. The company wants automatic cost optimization with no retrieval fees for tier changes. Which S3 storage class?
- A. S3 Standard
- B. S3 Standard-IA
- C. S3 Intelligent-Tiering
- D. S3 Glacier Deep Archive
Answer: C
C. Intelligent-Tiering auto-moves objects between access tiers based on usage, with no retrieval fees for those moves — built for unknown/changing patterns. Standard (A) doesn't optimize; Standard-IA (B) assumes predictable infrequent access and adds retrieval fees; Deep Archive (D) is cold storage with hours-long retrieval.
Q4. A big-data pipeline streams large, sequential log files and needs high throughput at the lowest cost for that pattern. Which EBS volume type fits best?
- A. gp3
- B. io2
- C. st1 (Throughput Optimized HDD)
- D. Instance store
Answer: C
C. st1 is optimized for large, sequential, throughput-heavy workloads like log/big-data processing at low cost. gp3 (A) and io2 (B) are SSDs optimized for IOPS (more expensive for pure throughput). Instance store (D) is ephemeral and unsuitable for persistent pipeline data.
Q5. Windows-based application servers need a shared file system using SMB with Active Directory integration. Which service?
- A. Amazon EFS
- B. FSx for Windows File Server
- C. FSx for Lustre
- D. Amazon S3
Answer: B
B. FSx for Windows File Server provides SMB shares with native Windows and Active Directory integration. EFS (A) is NFS for Linux. FSx for Lustre (C) targets HPC/ML. S3 (D) is object storage, not an SMB file share.
Next: 9 · Database & Caching Performance → · Revise — Storage Performance