PacketSensei

AWS `SlowDown`: What It Means and How to Fix It

PacketSensei

SlowDown is S3 throttling a single prefix — a partitioning problem, not a bucket-wide limit. It comes from S3, and the message reads:

SlowDown: Please reduce your request rate. (HTTP 503)

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error SlowDown
Service S3
Message SlowDown: Please reduce your request rate. (HTTP 503)
Most common cause All objects under one prefix

What it actually means

S3 scales to very high request rates, but the scaling is per prefix, not per bucket. Each prefix supports at least 3,500 write requests and 5,500 read requests per second, and S3 adds partitions automatically as load grows — but partitioning takes time, typically 30 to 60 minutes.

So a workload that suddenly writes 20,000 objects per second under one prefix gets SlowDown until S3 catches up. The bucket is not the limit; the key layout is.

The old advice to prefix keys with a random hash is obsolete — S3 introduced automatic partitioning in 2018 and no longer needs randomised prefixes for read performance. What still matters is having enough distinct prefixes for the partitioning to work with.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 All objects under one prefix A date-based layout like logs/2026-08-21/ concentrates a whole day of writes on one prefix. Add a dimension that spreads them: logs/2026-08-21/shard=07/.
2 A sudden traffic spike S3 partitions reactively. A ten-fold jump outruns it for a while. Ramp up gradually where you can.
3 Listing a very large prefix repeatedly ListObjectsV2 on a prefix with millions of keys is expensive. Use S3 Inventory for bulk enumeration instead.
4 A retry storm amplifying the problem Aggressive retries without backoff turn a brief throttle into a sustained one.

How to tell which one you have

Enable S3 request metrics in CloudWatch — they are not on by default — and look at 5xxErrors alongside AllRequests, filtered by prefix.

aws s3api put-bucket-metrics-configuration --bucket my-bucket --id EntireBucket \
  --metrics-configuration '{"Id":"EntireBucket"}'

aws cloudwatch get-metric-statistics --namespace AWS/S3 \
  --metric-name 5xxErrors --start-time "$(date -u -d '3 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --period 300 --statistics Sum \
  --dimensions Name=BucketName,Value=my-bucket Name=FilterId,Value=EntireBucket

S3 Server Access Logs or CloudTrail data events give you the per-key detail when the metrics confirm the pattern.

Preventing it

Design the key layout for the write pattern before the volume arrives. A prefix dimension that distributes writes — a shard number, a hash bucket, a partition key — costs nothing and removes the ceiling.

Use the SDK’s adaptive retry mode so a throttle produces backoff rather than a retry storm, and where a sustained ramp is planned, raise it over hours rather than minutes.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.