> ## Documentation Index
> Fetch the complete documentation index at: https://docs.springwinter.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Amazon S3 Internals: Request Routing and Multipart Uploads

> Learn how Amazon S3 routes object requests, scales prefixes, provides strong consistency, validates checksums, and completes 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.

| Concept | Visible to you | Safe conclusion |
| - | - | - |
| Bucket | Yes | Select the correct regional endpoint and authorization scope |
| Object key | Yes | Use the exact key; slashes are ordinary characters |
| Prefix | Derived from the key | Spread sustained traffic when one prefix is insufficient |
| Internal partition | No | Do not depend on placement or split behavior |
| Version ID | With Versioning | Address one immutable object version |

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

<AccordionGroup>
  <Accordion title="Should I randomize every S3 object key?">
    No. S3 automatically scales partitioned prefixes, and AWS does not require universal key randomization. Design keys for listing and access patterns, spread exceptionally high sustained traffic when needed, ramp abrupt workloads, and retry temporary 503 responses with exponential backoff.
  </Accordion>

  <Accordion title="Can ETag verify every downloaded object?">
    Not safely. An ETag can differ from an MD5 digest for multipart uploads and some encryption paths. Store an explicit supported checksum, retrieve its metadata, calculate the same algorithm over the downloaded bytes, and compare those values.
  </Accordion>

  <Accordion title="When does a multipart upload become visible?">
    The object is published after S3 successfully processes `CompleteMultipartUpload`. Before that, uploaded parts belong to the upload ID and consume storage but are not retrieved through a normal object GET. Abort abandoned uploads or expire them with a lifecycle rule.
  </Accordion>
</AccordionGroup>

## Sources and further reading

* [Amazon S3 performance guidelines](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)
* [Organizing objects using prefixes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html)
* [Amazon S3 consistency model](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel)
* [Checking object integrity](https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity-upload.html)
* [Multipart upload overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.