MLA-C01 Practice Question 93: S3 Request Rate Prefixes
AWS Certified Machine Learning Engineer – Associate (MLA-C01) · Test 10 · question 3 of 10
A computer-vision team stores 60 million small training images in one S3 bucket, all directly under the prefix images/ (for example images/000000123.jpg). When several large distributed training jobs and preprocessing jobs start at the same time, together issuing tens of thousands of GET requests per second against that prefix, the jobs intermittently receive HTTP 503 Slow Down responses and training stalls. The problem happens only under this combined load.
What is the most effective long-term fix?
Show answer and explanation
Answer:
S3 request performance scales *per prefix*: an application can achieve at least 5,500 GET/HEAD requests per second for each partitioned prefix, and a bucket can have unlimited prefixes. With every object under one prefix, tens of thousands of reads per second exceed what that prefix supports. While S3 adjusts to a sudden new request rate, clients get temporary 503 responses. Spreading objects across many prefixes spreads the read load, so 64 prefixes can support far higher combined throughput, and retries with backoff absorb any short-lived 503 responses while S3 scales (option C).
- A is wrong because Transfer Acceleration speeds up long-distance transfers through edge locations. It does not raise the request rate a prefix supports, and the training jobs run in-Region. - B is wrong because there is no quota to raise here. S3 request capacity scales automatically per prefix, so the fix is in how keys are laid out, not in a limit increase request. - D is wrong because more parallel connections send even more requests to the same overloaded prefix, which produces more 503 Slow Down responses, not fewer.
Reference: Best practices design patterns: optimizing Amazon S3 performance