S3 prefix request rate calculator

Enter the write (PUT, COPY, POST, DELETE) and read (GET, HEAD) rates your application sends to one bucket, then describe how its keys spread them: how many prefixes are in use at once and what share the busiest one gets. The bars compare each prefix's load with the documented per-prefix rates. The chart runs a minute of traffic with every prefix held at those rates, the situation before S3 has scaled, and shows what the client's retries add.

S3 stores objects under flat string keys; the slashes in logs/2026/10/16/app.json are just characters, and the console's folders are a display convention. A prefix is any leading part of a key, such as logs/ or logs/2026/10/. Behind the scenes S3 divides a bucket's key space into partitions by prefix and gives each its own request capacity, adding partitions as traffic grows.

The S3 User Guide states that an application can achieve at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned prefix, that there is no limit on the number of prefixes in a bucket, and that performance grows with parallelism across prefixes: ten prefixes can serve 55,000 reads a second. It also says scaling to higher rates "happens gradually and is not instantaneous", and that S3 may return 503 Slow Down errors while it scales.

So the question for a design is not the bucket's total rate but the rate aimed at each part of the key space. 10,000 writes and 20,000 reads a second need at least 3 and 4 prefixes' worth of capacity, and only if the keys spread the traffic over them.

A date-first layout such as logs/2026/10/16/14/… sends every write in the current hour under the same prefix, however many prefixes the bucket has in total. With 10,000 writes and 20,000 reads a second, a single prefix at the documented rates serves 9,000 a second and turns the rest away. Putting a short hash first, logs/a/2026/10/16/… with 16 values, spreads the same traffic over 16 prefixes, each well under its rate: all 30,000 requests a second are served.

Spreading has to be even to help. A tenant-first layout with 40 tenants looks well spread, but if one tenant sends 40% of the traffic, its prefix carries 4,000 writes and 8,000 reads a second on its own, and the model serves 27,000 of 30,000. The fix is the same: a hash or shard number inside the big tenant's keys.

A 503 Slow Down is a signal to back off, and AWS SDKs retry it automatically with exponential backoff and full jitter; their standard retry mode makes up to 3 attempts by default, and the SDK reference guide gives a 1,000 ms base delay for throttling errors and a 20 s cap, the defaults used here. Retries smooth out a short burst. Under sustained overload, though, every rejected request comes back, so the hot prefix receives more requests than the application sends: with all traffic on one prefix and 3 attempts, it gets 79,258 requests a second for 30,000 sent, 2.64 attempts per request, and still serves only 9,000. Raising the attempts to 10 pushes the arrivals to 170,155 a second without serving any more. Without retries, 21,000 requests a second simply fail.

Retries buy time while S3 scales; they do not replace spreading the keys. Watching the 503 rate, for example with S3 request metrics in CloudWatch, shows when a layout is close to its limit.

Before July 2018, AWS advised adding random characters, such as a hash, to the start of keys for workloads with high request rates. That month it announced the per-prefix rates above and said the increase removed the earlier guidance to randomise prefixes. A hash in front of a hot, date-ordered key is still a sound way to spread sustained traffic over several prefixes; what changed is that ordinary layouts no longer need it, and listing objects by date stays simple when the date comes first and traffic is modest.