Fix: SlowDown: Please reduce your request rate. (S3 503)

A 503 SlowDown from S3 means your request rate briefly exceeded what the service will absorb for the keys you are hitting. S3 scales automatically, but it partitions by key prefix and needs time to react to sudden spikes. This error is a throttle, not an outage: the correct immediate response is a backed off retry, and the correct permanent fix is usually key design or request spreading.

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

What this error means

S3 shards a bucket internally into partitions keyed by prefix. Each partitioned prefix supports at least 3,500 write requests and 5,500 read requests per second, and S3 adds partitions automatically as sustained traffic grows. When a burst arrives faster than repartitioning can happen, or when a workload concentrates on a single prefix, S3 answers some requests with HTTP 503 and the SlowDown error code. The response carries a retryable signal: the AWS SDKs treat it as a transient error and back off before retrying.

The error tells you where the pressure is: the specific keys in the failing requests share the hot prefix.

Common causes

• A burst of writes or reads to one prefix, typically sequential or date stamped keys like logs/2026/07/13/... that funnel all traffic to a single partition.
• A batch job, backfill, or migration that starts hundreds of parallel workers against the same bucket at once.
• Many clients retrying immediately without backoff, turning one throttle into a retry storm.
• LIST heavy workloads, since ListObjectsV2 against a huge prefix is expensive and throttles earlier than GETs.
• A new bucket or a newly hot prefix that has not yet been repartitioned for the traffic level.
• Misconfigured SDK retry settings (retries disabled or set to zero) that surface throttles as hard failures.

How to fix it

STABILIZE first. Reduce concurrency at the source: pause or slow the batch job that triggered the spike, and confirm your clients retry with exponential backoff so in flight work completes instead of failing.

1. DIAGNOSE which keys and callers are hot. Turn on request metrics or query the request logs to find the prefix taking the traffic.

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 \
  --dimensions Name=BucketName,Value=my-bucket Name=FilterId,Value=EntireBucket \
  --start-time 2026-07-13T00:00:00Z --end-time 2026-07-13T12:00:00Z \
  --period 300 --statistics Sum

2. Confirm and tune SDK retry behavior. Adaptive mode adds client side rate limiting on top of backoff.

export AWS_RETRY_MODE=adaptive
export AWS_MAX_ATTEMPTS=10

3. FIX the concurrency. Cap parallel workers and add jitter between requests in batch jobs. For the AWS CLI itself, lower its internal concurrency:

aws configure set default.s3.max_concurrent_requests 5

4. FIX the key design if one prefix is hot. Introduce entropy at the front of the key so writes spread across partitions, for example a3f/logs/2026/07/13/file.gz where a3f is a short hash of the object name. Keep the number of distinct leading prefixes roughly proportional to the throughput multiple you need.

5. If the workload is read heavy on the same objects, put CloudFront or S3 Transfer Acceleration in front so repeated GETs are served from cache instead of hitting the bucket.

How to prevent it

• Design keys with entropy at the front for high throughput workloads; never funnel all writes to one date stamped prefix.
• Ramp batch jobs gradually so S3 can repartition, rather than starting hundreds of workers cold.
• Keep SDK retries on, with adaptive mode for spiky workloads, and add jitter to any custom retry loop.
• Cache hot reads with CloudFront so object popularity spikes never reach the bucket.
• Alert on the S3 5xxErrors metric per bucket so throttling is visible before users feel it.

When to call a senior engineer

Call for help when SlowDown persists after backoff and concurrency caps, when a migration or backfill deadline does not allow slowing down, or when redesigning a key scheme risks breaking consumers that depend on the current layout. Erzon engineers can profile the hot prefixes from real request logs, design a key and caching layout that meets the target throughput, and get the backfill done without taking production down with it.