Pair your devices with a code and playback position follows you: pause on this device, hit resume on the other. Position is saved to the site every minute and on pause.
Open this panel on your other device and enter the same code.
Starts this lesson and continues through 13 more to the end of certification prep.
Task statement 3.1 lists three knowledge items: "Hybrid storage solutions to meet business requirements", "Storage services with appropriate use cases (for example, Amazon S3, Amazon EFS, Amazon EBS)", and "Storage types with associated characteristics (for example, object, file, block)". The two skills are "Determining storage services and configurations that meet performance demands" and "Determining storage services that can scale to accommodate future needs".
The last one is the one people skip. "Scale to accommodate future needs" is the exam's way of asking which of these services has a ceiling you'll hit. An EBS volume has a maximum size. An EFS file system does not make you choose one.
The first cut is always the storage type:
access by KEY over HTTP, any scale, many readers → OBJECT → S3
shared FILESYSTEM, many instances mount it → FILE → EFS (Linux) · FSx (Windows, Lustre, …)
a DISK attached to one instance → BLOCK → EBS · instance store
Get that cut right and most storage questions have two candidates left, not four.
From Amazon EBS volume types, verified 2026-09-25. The page splits the types by what they optimise:
SSD-backed volumes are "optimized for transactional workloads involving frequent read/write operations with small I/O size, where the dominant performance attribute is IOPS."
HDD-backed volumes are "optimized for large streaming workloads where the dominant performance attribute is throughput."
That is the first discriminator. Small random I/O → SSD. Large sequential I/O → HDD.
gp3 |
gp2 |
io2 Block Express |
io1 |
|
|---|---|---|---|---|
| Size | 1 GiB – 64 TiB | 1 GiB – 16 TiB | 4 GiB – 64 TiB | 4 GiB – 16 TiB |
| Max IOPS | 80,000 | 16,000 | 256,000 | 64,000 |
| Max throughput | 2,000 MiB/s | 250 MiB/s | 4,000 MiB/s | 1,000 MiB/s |
| Durability | 99.8–99.9% | 99.8–99.9% | 99.999% | 99.8–99.9% |
| Multi-Attach | ✗ | ✗ | ✅ | ✅ |
| Boot volume | ✅ | ✅ | ✅ | ✅ |
The use-case rows are where exam stems come from. io2 Block Express is for workloads that need
"Consistent sub-millisecond latency with average latency under 500 microseconds", "Sustained IOPS
performance", or "More than 80,000 IOPS or 2,000 MiB/s of throughput". io1 is for "sustained IOPS
performance or more than 16,000 IOPS" and "I/O-intensive database workloads".
⚠️ Two footnotes that decide questions. The 256,000-IOPS figure needs a Nitro-based instance: "Other instance types can be attached to volumes provisioned with up to 64,000 IOPS, but can achieve up to 32,000 IOPS." And the page opens with "To fully use the IOPS provisioned on an EBS volume, use EBS–optimized instances." A fast volume on a slow instance is a slow volume.
From General Purpose SSD volumes:
⚠️ The gp2 trap. "A 100 GiB gp2 volume performs well in the morning and badly by afternoon" is a
burst-credit story: baseline is 300 IOPS (100 × 3), burst is 3,000, and the BurstBalance metric is
draining. The fix that doesn't require buying capacity you don't need is migrate to gp3, which the
page says you can do with Elastic Volumes "without interrupting your Amazon EC2 instances".
st1 Throughput Optimized |
sc1 Cold |
|
|---|---|---|
| Size | 125 GiB – 16 TiB | 125 GiB – 16 TiB |
| Max IOPS (1 MiB I/O) | 500 | 250 |
| Max throughput | 500 MiB/s | 250 MiB/s |
| Use cases | "Big data · Data warehouses · Log processing" | "data that is infrequently accessed" · "lowest storage cost" |
| Boot volume | ✗ | ✗ |
⚠️ HDD cannot be a boot volume. The Boot volume row reads "Not supported". Any option that puts the OS on
st1 or sc1 is wrong on that alone.
From Instance store temporary block storage:
"This storage is provided by disks that are physically attached to the host computer. Instance store is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content."
And "There is no additional charge to use the instance store volumes provided for your instance." That's why it shows up in performance questions: locally attached, included in the price.
What it costs you is persistence. From Data persistence for instance store volumes:
| Event | Data |
|---|---|
| Reboot | persists |
| Stop | lost |
| Hibernate | lost |
| Terminate | lost |
| Instance type changed | lost |
| Underlying disk fails | lost (on that disk) |
"When the instance is stopped, hibernated, or terminated, every block of the instance store volume is cryptographically erased."
Also: "You can't attach instance store volumes after launch" and "You can't detach an instance store volume from one instance and attach it to a different instance."
⚠️ The exam pattern: "highest possible I/O for a scratch/cache workload, data is replicated
elsewhere or can be regenerated" → instance store. "The data must survive a stop/start" → not
instance store, however fast it is. The d suffix in an instance type name (c7gd, m6id) means
"Instance store volumes" — lesson 2 covers the naming.
From What is Amazon EFS?:
"Amazon EFS provides serverless, fully elastic file storage … Amazon EFS is built to scale on demand to petabytes without disrupting applications, growing and shrinking automatically as you add and remove files."
The facts that answer questions:
That last line is the most-tested EFS fact. A shared file system for Windows is never EFS.
From Amazon EFS performance specifications:
⚠️ Bursting is the gp2 trap in file form. Baseline is "50 KiBps per each GiB of storage". A small file system on Bursting throughput runs out of credits under sustained load. If a stem says "the EFS file system is small but throughput-bound", the answer is Elastic (or Provisioned), not adding dummy data to grow the baseline.
The exam guide's in-scope list says "Amazon FSx (for all types)". I fetched the two that carry the examinable discriminators.
FSx for Windows File Server (What is FSx for Windows File Server?): "fully managed Microsoft Windows file servers, backed by a fully native Windows file system", the "industry-standard Server Message Block (SMB) protocol", "consistent sub-millisecond latencies", and "Users accessing file systems are authenticated with Microsoft Active Directory." SSD or HDD storage; Single-AZ or Multi-AZ ("a standby file server in a separate Availability Zone"). → Windows + SMB + Active Directory = FSx for Windows.
FSx for Lustre (What is Amazon FSx for Lustre?): "for workloads where speed matters, such as machine learning, high performance computing (HPC), video processing, and financial modeling", with "sub-millisecond latencies, up to multiple TBps of throughput and up to millions of IOPS". Two things make it exam-shaped:
→ HPC/ML reading a dataset that lives in S3 = FSx for Lustre linked to the bucket. Short job, cheapest → scratch. Long-lived → persistent.
⚠️ I did not fetch the FSx for NetApp ONTAP or FSx for OpenZFS guides. This lesson makes no claim
about their protocols or features. Read docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html
and docs.aws.amazon.com/fsx/latest/OpenZFSGuide/what-is-fsx.html before relying on either.
From Optimizing Amazon S3 performance, verified 2026-09-25:
"your application can achieve at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned Amazon S3 prefix. There are no limits to the number of prefixes in a bucket."
And the worked scaling example: "if you create 10 prefixes in an Amazon S3 bucket to parallelize reads, you could scale your read performance to 55,000 read requests per second." The scaling "happens gradually and is not instantaneous", and during it "you may see some 503 (Slow Down) errors."
The levers, from Performance guidelines for Amazon S3:
| Lever | What AWS says |
|---|---|
| Spread across prefixes | request rate is per prefix; more prefixes, more aggregate rate |
| Parallel connections | "Amazon S3 doesn't have any limits for the number of connections made to your bucket." |
| Byte-range fetches | "fetch different byte ranges from within the same object … higher aggregate throughput" |
| Multipart upload | "best practice to use multipart upload for objects that are 100 MB or larger" (mpuoverview); parts numbered 1 to 10,000 |
| Same Region | access the bucket "from Amazon EC2 instances in the same AWS Region" — "reduce network latency and data transfer costs" |
| Retry aggressively | "if the first request is slow, a retried request is likely to take a different path and quickly succeed" |
| Cache | "single-digit millisecond latencies, use Amazon CloudFront or Amazon ElastiCache" |
| Transfer Acceleration | long distances between client and bucket — lesson 5 |
⚠️ KMS can be the bottleneck, not S3. The optimizing page says that if your workload uses SSE-KMS,
see the AWS KMS limits "for information about the request rates supported". A stem where S3 request
rates look fine but uploads throttle under SSE-KMS is pointing at KMS quotas. (Encryption itself is
SAA1 material.)
From High performance workloads: "purpose-built to deliver consistent, single-digit millisecond data access", "data access speeds up to 10x faster and with request costs 80 percent lower than S3 Standard", objects stored in directory buckets in a single Availability Zone you choose, designed for "99.95 percent availability within a single Availability Zone". It does "doesn't store data redundantly across Availability Zones."
→ Latency-critical, co-located with compute, AZ loss tolerable → S3 Express One Zone. If the stem also requires surviving an AZ failure, it's out.
| The stem says | Answer |
|---|---|
| "database on EC2 needs 100,000 IOPS, sub-millisecond latency" | io2 Block Express on a Nitro instance |
| "general workload, predictable cost, want to tune IOPS without growing the volume" | gp3 |
| "gp2 volume fast at first, slow under sustained load" | burst credits → gp3 |
| "big sequential log processing, cheapest per GB that still streams well" | st1 |
| "two instances must attach the same block volume" | io1/io2 Multi-Attach |
| "temporary scratch, highest I/O, data can be regenerated" | instance store |
| "shared POSIX file system for Linux instances, Lambda and Fargate, grows automatically" | EFS |
| "shared file system for Windows servers joined to Active Directory" | FSx for Windows File Server |
| "HPC cluster processes a dataset stored in S3" | FSx for Lustre linked to the bucket |
| "S3 returns 503 Slow Down under a read surge" | spread keys across more prefixes, retry with backoff |
| "upload 5 GB files reliably over a flaky link" | multipart upload |
| "single-digit ms object reads next to compute, one AZ is acceptable" | S3 Express One Zone |
The skill "storage services that can scale to accommodate future needs" is really asking you to know which services make you pick a ceiling up front. EBS does: you choose a size and a type, and gp2's IOPS are welded to its size. EFS and S3 don't: they grow as you write. That's why "the data volume is unpredictable and will grow for years" pushes toward EFS or S3 even when EBS would be faster today.
BurstBalance in CloudWatch next to a gp3 volume's
flat baseline. It turns the burst-credit trap into something visible.