Design High-Performing Architectures practice questions

HDD volumes sell throughput and SSD volumes sell IOPS; for large sequential scans, st1 delivers the required throughput at HDD prices.

The access pattern is large and sequential with almost no random I/O — the exact workload st1 was built for, so it meets the performance requirement at the lowest cost that still performs. gp3 and io2 both work but pay SSD premiums for random-I/O capability that goes unused, which the MOST cost-effective qualifier punishes. sc1 is the trap in the other direction: it is the cheapest EBS volume, but it targets cold, rarely touched data and delivers lower throughput, so a nightly performance-sensitive scan can fall short of the requirement. Cheapest-that-still-meets-the-requirement is the rule, and that is st1 here.

1. Identify the access pattern: large sequential reads, minimal random I/O.
2. Map pattern to media: sequential throughput favors HDD volumes over SSD on price.
3. Check the access frequency: nightly, throughput-sensitive scans are regular work, ruling out cold-tier sc1.
4. Confirm st1 meets the throughput requirement at lower cost than gp3 or io2.

Exam tip: Sequential big-data scans resolve to st1 — SSDs overpay for unused IOPS, and sc1 undershoots on regularly accessed data.

sc1 is the bottom of the EBS cost ladder: lowest price per gigabyte, lowest performance, intended for cold, infrequently accessed volume data.

The requirement is purely cost: the data must stay on mounted EBS volumes, access is rare, and speed is explicitly not a concern. sc1 is the cheapest volume type per gigabyte, so it wins outright. st1 is the tempting near-miss — also HDD, also cheap — but it charges more to provide sequential throughput this workload will never exercise. gp3 and io2 fail the qualifier even harder, paying SSD and provisioned-IOPS premiums for an archive. Note the constraint that keeps this an EBS question: the data must remain attached as volumes, so object-storage archival tiers are out of scope.

1. Note the constraint: data must remain available as mounted EBS volumes.
2. Note the access pattern: a few reads per year, with no performance requirement.
3. Rank the EBS types by cost: sc1 is the lowest per gigabyte.
4. Confirm sc1's lower performance is acceptable because speed is explicitly not required.

Exam tip: When EBS data is cold and cost is the only requirement, sc1 is the answer — st1 is the overpriced near-miss.

The SSD-versus-HDD split is decided by access pattern, not price: SSD volumes serve small random I/O, HDD volumes serve large sequential throughput.

The workload is continuous small random reads and writes — transactional shape — so the HDD proposal fails on physics before it saves a cent: st1 and sc1 are sequential-throughput devices that degrade badly under random I/O, so the cheaper volume would not meet the performance need at all. Among SSDs, the qualifier decides: gp3 handles the workload at balanced cost, and the scenario states no sustained-extreme-IOPS or latency-consistency requirement that would justify io2's premium. gp3 is therefore the cheapest option that still meets the requirement, which is what MOST cost-effectively means.

1. Read the access pattern: continuous small random reads and writes.
2. Apply the media rule: random I/O requires SSD, eliminating st1 and sc1 regardless of price.
3. Check for io2 justification: no stated demand beyond gp3's envelope, so io2 is an overshoot.
4. Select gp3 as the lowest-cost volume that meets the performance requirement.

Exam tip: Cost-effective never means the cheapest volume — it means the cheapest volume whose media matches the access pattern.

gp3's defining feature is that IOPS and throughput are provisioned independently of volume size — performance is a dial, not a side effect of capacity.

The volume is well under capacity, so the team needs more IOPS without more storage — the exact case gp3's decoupling exists for. Raising provisioned IOPS on the existing volume adds only the incremental performance cost. Growing the volume is the gp2-era reflex: it buys 60 percent more unneeded space and is not how gp3 scales performance. io2 works but is the overpriced rung of the ladder when gp3 can still reach the required number. RAID 0 striping also works but multiplies volumes to manage, doubles the blast radius of a single volume failure, and replaces a one-line configuration change with an infrastructure project — losing on both cost and overhead.

1. Identify the constraint: IOPS ceiling reached while capacity is barely used.
2. Recall gp3's model: IOPS and throughput are provisioned independently of size.
3. Eliminate size increases (buys capacity, not the performance mechanism) and io2 (higher cost tier not justified).
4. Eliminate RAID 0 as added complexity for a problem a setting solves.
5. Raise provisioned IOPS on the existing gp3 volume.

Exam tip: Needs more IOPS but not more storage resolves to adjusting gp3's provisioned performance, never to a bigger disk.

Instance store is the fastest storage an EC2 instance can touch because it is physically attached to the host; its ephemerality is acceptable only when the data is replaceable — which scratch data is by definition.

The qualifier is MOST performant and the data is explicitly regenerable, which removes instance store's only weakness. Physical attachment beats every network-attached option, so instance store outruns io2 and gp3 alike; the durable copies live in S3 at both ends of the pipeline, so losing a node's scratch data merely restarts a job. io2 is the tempting distractor — very fast, very durable — but it pays a premium for durability the scratch data does not need and still crosses the network on every operation. gp3 is slower again, and EFS is the worst fit: shared NFS semantics and network latency for data no other instance ever reads.

1. Check whether the data must survive the instance: it is regenerated on restart, so no.
2. With durability off the table, rank raw speed: physically attached NVMe instance store beats all network-attached EBS options.
3. Eliminate io2 and gp3 as slower and paying for durability the workload does not need.
4. Eliminate EFS as shared file storage with network latency for single-instance scratch.
5. Confirm the durable system of record is S3, keeping the architecture safe.

Exam tip: For replaceable scratch data under a MOST performant qualifier, instance store beats every EBS type — including io2.

Instance store is correct when data is replicated or replaceable, and well-designed architectures pair its speed with a durable layer — cluster replication rebuilds a lost node, while S3 backups survive a whole-cluster loss.

The database already replicates each partition across AZs, so losing one node's ephemeral disk costs nothing — peers rebuild it. That makes storage-optimized instances with local NVMe the maximum-I/O choice, faster than any network-attached volume. But the requirement also names recovery from a complete cluster failure, which replication cannot survive; scheduled backups to S3 provide the durable layer. io2 Multi-Attach fails three ways: same-AZ restriction against a three-AZ cluster, a cluster-aware file-system requirement nothing here satisfies, and network-attached speed below local NVMe. EFS is file storage with NFS latency, wrong for database block I/O. sc1 abandons the performance requirement entirely.

1. Confirm per-node data is replaceable: three-way cross-AZ replication rebuilds any lost node.
2. Choose maximum per-node I/O: storage-optimized instances with local NVMe instance store.
3. Address the stated whole-cluster failure case: replication dies with the cluster, so back up to durable S3.
4. Eliminate Multi-Attach (same-AZ, cluster-FS requirement, slower) and EFS (file latency) on architecture grounds.
5. Eliminate sc1 as a cost play that ignores the performance requirement.

Exam tip: Pair instance store's unmatched speed with a durable layer: replication covers node loss, S3 backups cover cluster loss.