SAA-C03 practice question: Choosing shared storage (2 of 3)
Design High-Performing Architectures A free question from our original SAA-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
A research team runs a weekly 8-hour genomics job across 400 Linux EC2 instances.
The input data lives in Amazon S3, which holds the permanent copy, and the results must be written back to S3. During the job, all instances need a shared POSIX file system that they can read and modify at the same time, with consistent sub-millisecond latency. If the file system fails mid-job, the team can simply rerun the job.
Which storage option meets these requirements MOST cost-effectively?
Choose one answer.
AA. An Amazon FSx for Lustre scratch file system linked to the S3 bucket, created for each run and deleted after results are exported.
BB. An Amazon FSx for Lustre persistent file system linked to the S3 bucket, left running between the weekly runs to keep data loaded.
CC. An Amazon EFS file system with Elastic throughput, loaded from the S3 bucket by AWS DataSync before each run and mounted on every instance.
DD. Mountpoint for Amazon S3 installed on every instance, mounting the bucket directly so the job reads and writes objects as files.
Show the answer and explanation
Answer: A
A. Right: Correct. FSx for Lustre on SSD storage gives sub-millisecond latency and very high aggregate throughput, and a linked file system presents S3 objects as files and can write results back to S3. Scratch file systems do not replicate data, which makes them the cheaper choice for short jobs whose data is safe in S3 and that can be rerun. Learn more: Deployment and storage class options for FSx for Lustre file systems (opens in a new tab)
B. Wrong: A persistent file system meets the performance needs and replicates data to survive server failures. That durability is not needed here because S3 holds the permanent copy, and keeping the file system running all week adds cost. A scratch file system per run is cheaper. Learn more: Linking your file system to an Amazon S3 bucket (opens in a new tab)
C. Wrong: EFS is a shared POSIX file system, but its best-case latency is about 1 ms for reads and 2.7 ms for writes, so it does not give consistent sub-millisecond latency. Copying the data in and out with DataSync also adds steps that a linked FSx for Lustre file system avoids. Learn more: Amazon EFS performance specifications (opens in a new tab)
D. Wrong: Mountpoint gives high-throughput access to S3 objects as files and costs nothing extra, but it cannot modify existing files and does not support file locking. It does not meet the need for a shared file system that the instances can read and modify concurrently. Learn more: Mount an Amazon S3 bucket as a local file system (opens in a new tab)
Explanation
The job needs a shared, fully POSIX file system with sub-millisecond latency, linked to S3, for a few hours a week, and the data can be rebuilt from S3. FSx for Lustre is built for this kind of HPC work, and the scratch deployment type is the lower-cost option for temporary, rerunnable processing. EFS is too slow for the latency target, and Mountpoint cannot modify existing files.
Want more on Choosing shared storage? The 5 full-length practice sets have 10 more Choosing shared storage questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →