AWS Certified Solutions Architect – Associate
S3 performance: prefixes, multipart upload, Transfer Acceleration
Amazon S3 supports at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per partitioned prefix, so spread heavy traffic across prefixes and parallel connections. Use multipart upload for objects of 100 MB or more so parts upload in parallel and a failed part is resent alone. Use S3 Transfer Acceleration when clients far from the bucket's Region upload or download large amounts of data.
Request rates and prefixes
There is no limit on the number of prefixes in a bucket. With 10 prefixes, reads can scale to 55,000 requests per second. Scaling to a higher rate happens gradually, not instantly. While S3 scales you may see 503 (Slow Down) errors, which stop when scaling completes. The AWS SDKs retry 503 errors automatically.
Spreading across prefixes raises request rate, not per-request latency. For single-digit millisecond latency or higher transfer rates on one connection, AWS points to caching with Amazon CloudFront or Amazon ElastiCache in front of S3. Running compute in the same Region as the bucket also cuts latency and data transfer cost.
Multipart upload and byte-range fetches
Multipart upload splits one object into parts numbered 1 to 10,000. Parts can upload in any order and in parallel. If a part fails, only that part is resent. You can pause and resume, and start before you know the final size. AWS calls it a best practice for objects of 100 MB or larger.
Parts of an unfinished upload are stored and billed until you complete or abort the upload; an upload has no expiry of its own. Add a lifecycle rule with the AbortIncompleteMultipartUpload action to delete abandoned uploads after a set number of days.
For downloads, the Range header fetches part of an object. Several byte-range requests over separate connections give higher total throughput than one whole-object request, and a failed range retries faster.
S3 Transfer Acceleration
Transfer Acceleration routes data through CloudFront's edge locations and then over an optimized network path to S3. AWS lists three cases: customers uploading to a central bucket from around the world, regular transfers of gigabytes to terabytes across continents, and clients that cannot use all their bandwidth over the internet.
You enable it per bucket and use the bucket-name.s3-accelerate.amazonaws.com endpoint. The bucket name must be DNS-compliant and must not contain periods. Only virtual-hosted style requests work. Speeds can take up to 20 minutes to improve after you enable it, and extra data transfer charges may apply.
Where the exam catches people
- Believing 503 Slow Down on a new busy prefix means a misconfiguration: S3 scales gradually; retry with backoff and the errors stop.
- Believing more prefixes lower latency: they raise the request rate; cache with CloudFront or ElastiCache for lower latency.
- Believing abandoned multipart uploads clean themselves up: the parts are billed until an abort, so add an
AbortIncompleteMultipartUploadlifecycle rule. - Believing Transfer Acceleration works on any bucket name: names with periods cannot use the accelerate endpoint.
- Believing Transfer Acceleration fixes a failed large upload on its own: pair it with multipart upload so only the failed part is resent.