SlowDown
AWS S3 SlowDown is a 503 error indicating that the request rate to a specific S3 prefix has exceeded the service internal throughput limits. It serves as a back-pressure signal to reduce request frequency while S3 scales its internal partitions.
Last reviewed: March 16, 2026|Editorial standard: source-backed technical guidance
What Does Slow Down Mean?
A SlowDown error is S3 saying "I am scaling, please wait." S3 automatically partitions data based on key prefixes. Each prefix supports at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second. If you hit these limits suddenly (e.g., thousands of writes to the same folder), S3 throttles with a 503. This is transient; S3 will split the partition over 15-30 minutes to accommodate higher load, but only if your keys are well-distributed.
Common Causes
- -Hot Partitions: Writing thousands of objects to the same prefix (e.g.,
logs/2026-03-16/...) simultaneously. - -Sequential Key Names: Using timestamps or sequential IDs as prefixes, which causes all I/O to hit the same internal index partition.
- -Sudden Traffic Spikes: A marketing event or data migration job that exceeds the 3,500/5,500 limit before S3 has time to scale the prefix.
- -Aggressive Polling: Multiple workers constantly calling
ListObjectsorHeadObjecton the same prefix.
How to Fix Slow Down
- 1Add Random Prefixes: Prepend a short hash (e.g., 3-4 characters) to your object keys to distribute them across different S3 partitions.
- 2Implement Adaptive Retry: Configure your AWS SDK to "Adaptive" retry mode, which handles 503 SlowDown with exponential backoff and jitter.
- 3Flatten Folder Structures: Instead of deep nesting under a single date folder, spread files across multiple top-level prefixes.
- 4Ramp Up Gradually: If starting a massive data job, increase the request rate over 15-30 minutes to allow S3 to scale preemptively.
Step-by-Step Diagnosis for Slow Down
- 1Verify the error: Confirm it is
SlowDown(503) and notServiceUnavailableorInternalError. - 2Identify the "Hot Prefix": Analyze your S3 server access logs or CloudWatch request metrics to find which folder/prefix is receiving the highest RPS.
- 3Check Key Patterns: Are your keys starting with a timestamp? (e.g.,
20260316125001_file.txt). If so, you are creating a hot partition. - 4Calculate RPS: Measure if your request rate is nearing the 3,500 write / 5,500 read threshold per prefix.
Key Naming Strategy: Sequential vs. Hashed
- -BAD (Sequential):
images/0001.jpg,images/0002.jpg... (All land on one partition). - -GOOD (Hashed):
a1b2/images/0001.jpg,c3d4/images/0002.jpg... (Distributed across 16+ partitions).
S3 Scaling Timeframes
- -S3 scales automatically by splitting partitions. This takes time (typically minutes). If you spike instantly, you MUST use retries until the split is complete.
Implementation Examples
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { createHash } from "crypto";
const getPartitionedKey = (originalKey) => {
// Take MD5 hash of filename to create a random 4-char prefix
const hash = createHash('md5').update(originalKey).digest('hex').substring(0, 4);
return `${hash}/${originalKey}`;
};
// Key: logs/file.log -> a3f2/logs/file.logimport boto3
from botocore.config import Config
# The 'adaptive' mode specifically handles SlowDown/503 better
config = Config(retries={'max_attempts': 10, 'mode': 'adaptive'})
s3 = boto3.client('s3', config=config)How to Verify the Fix
- -Monitor the
5xxErrorsmetric in CloudWatch for the bucket; it should trend toward zero as keys are redistributed. - -Confirm that the request latency (TTFB) stabilizes even as throughput remains high.
- -Verify that distributed workers are no longer receiving "Reduce your request rate" exceptions.
How to Prevent Recurrence
- -Hash-Based Prefixes: Always use a random hex or hash prefix for high-throughput buckets from day one.
- -Enable Request Metrics: Turn on CloudWatch request metrics for high-traffic buckets to monitor per-prefix throughput.
- -Use CloudFront: For read-heavy static assets, use CloudFront to cache GET requests and shield S3 from spikes.
- -Pro-tip: Prepending just one random hex character (0-f) creates 16 potential partitions, effectively multiplying your throughput limit by 16x.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
AWS ThrottlingException vs GCP RESOURCE_EXHAUSTED
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Rate Limit Recovery Playbook (429 / ThrottlingException / RESOURCE_EXHAUSTED)
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.