SlowDown

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 ListObjects or HeadObject on the same prefix.

How to Fix Slow Down

1. 1Add Random Prefixes: Prepend a short hash (e.g., 3-4 characters) to your object keys to distribute them across different S3 partitions.
2. 2Implement Adaptive Retry: Configure your AWS SDK to "Adaptive" retry mode, which handles 503 SlowDown with exponential backoff and jitter.
3. 3Flatten Folder Structures: Instead of deep nesting under a single date folder, spread files across multiple top-level prefixes.
4. 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

1. 1Verify the error: Confirm it is SlowDown (503) and not ServiceUnavailable or InternalError.
2. 2Identify the "Hot Prefix": Analyze your S3 server access logs or CloudWatch request metrics to find which folder/prefix is receiving the highest RPS.
3. 3Check Key Patterns: Are your keys starting with a timestamp? (e.g., 20260316125001_file.txt). If so, you are creating a hot partition.
4. 4Calculate RPS: Measure if your request rate is nearing the 3,500 write / 5,500 read threshold per prefix.

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.log

import 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 5xxErrors metric 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.

Related Errors

Decision Support

Official References

• -Best Practices: S3 Performance
• -AWS Blog: Scaling S3 Throughput
• -AWS S3 Performance Optimization Guidelines
• -AWS Official Documentation