Amazon S3 Internals: Request Routing and Multipart Uploads

An Amazon S3 request names a bucket and object key, reaches a regional endpoint, is authenticated, and is routed to the internal capacity responsible for that key. A general purpose bucket remains a flat key namespace rather than a filesystem. Updated October 9, 2026. An S3 object is addressed by bucket, key, and optionally version ID; slashes in a key do not create directories.

​

Keys and prefixes are naming tools

An object key is a UTF-8 string up to 1,024 bytes. A key such as images/2026/hero.webp looks hierarchical because applications commonly use / as a delimiter, but S3 stores the entire string as the key. A prefix is the beginning of a key, not a separately created resource. ListObjectsV2 can filter by Prefix and group results by Delimiter, which lets clients present folder-like navigation. AWS documents at least 3,500 write requests or 5,500 read requests per second per partitioned prefix, with no limit on the number of prefixes in a bucket. Scaling is gradual, so a sudden increase can temporarily produce 503 Slow Down responses while S3 adapts. A prefix helps organize, list, and scale requests; it is not a directory or independent storage container.

​

What partition means

AWS describes S3 as partitioning key names to support high request rates, but it does not publish the partition map, placement algorithm, partition size, or split thresholds. Treat partitions as service-internal routing units rather than resources your application can inspect or control. Randomized prefixes are not a universal requirement. Choose key layouts for access patterns and operations, then load-test the workload.

​

A practical request flow

Consider a GET for images/hero.webp:

1. DNS resolves the regional S3 endpoint.
2. The client establishes a connection and sends the HTTP request.
3. AWS Signature Version 4 normally binds the request details to the caller’s credentials.
4. S3 identifies the bucket and Region.
5. S3 authorizes the action using applicable identity and resource policies.
6. The service routes the key to internal capacity and locates the requested version.
7. S3 returns the data or an error, and the client can verify a stored checksum.

Use SDK retry behavior and exponential backoff. Retrying a PUT to an unversioned key can replace the object; retrying it in a versioned bucket creates another version.

​

Strong consistency changes application design

S3 provides strong read-after-write consistency for PUT and DELETE operations. After a successful write, a subsequent GET or HEAD receives the latest state. LIST operations are also strongly consistent. That guarantee does not make a multi-request workflow transactional. Two keys can change independently, and a reader can observe one update before another. Use immutable keys and a manifest or an application database when several objects need one commit point. Strong consistency applies to each completed S3 operation, not to a sequence of object requests as one transaction.

​

Checksums are the integrity contract

S3 supports explicit checksum algorithms for applicable operations. You can send a checksum during upload, and S3 rejects a mismatch. You can retrieve stored checksum metadata later and compare it with downloaded content. Do not treat every ETag as an MD5 digest. Multipart uploads and encryption can produce ETags that are not full-object MD5 checksums. Use explicit checksum fields when integrity must be independently verified. An ETag identifies an object response; it is not a universal promise that it equals the object’s MD5 digest.

​

Multipart upload is a commit protocol

Multipart upload separates transfer from publication:

1. CreateMultipartUpload returns an upload ID.
2. UploadPart sends numbered parts, often in parallel.
3. The client records each part number and ETag.
4. CompleteMultipartUpload submits the ordered part list.
5. S3 assembles and publishes the object.
6. AbortMultipartUpload releases an abandoned upload’s parts.

Part numbers range from 1 through 10,000. Except for the last part, parts must be at least 5 MiB. Incomplete parts incur storage charges, so configure a lifecycle rule to abort abandoned uploads. Multipart completion is the publication point; uploaded parts are billable but are not a normal object before completion.

​

Frequently asked questions

​

Sources and further reading

• Amazon S3 performance guidelines
• Organizing objects using prefixes
• Amazon S3 consistency model
• Checking object integrity
• Multipart upload overview