S3 Multipart Part Size: 16 MiB Parts Cut 500 MiB Upload PUT Requests 68%

A rule-based guide to choosing Amazon S3 multipart part sizes while controlling request counts, retry exposure, and incomplete-part risk. It shows how a 500 MiB object requires 32 PUT requests with 16 MiB parts instead of 100 with 5 MiB parts.

How S3 Multipart PUT Count Works

Amazon S3 multipart upload divides an object into parts, then uploads each part with an individual UploadPart request. The upload also requires one CreateMultipartUpload call and one CompleteMultipartUpload call. Therefore, the total number of PUT-class requests for the operation is the part count plus two. For a 500 MiB object with a 5 MiB part size, the division is exact: 500 ÷ 5 = 100 parts, producing 102 PUT-class requests. Raising the part size to 16 MiB gives ⌈500 ÷ 16⌉ = 32 parts, producing 34 PUT-class requests. That is a reduction of 68 individual part requests, from 100 to 32.

The request-count mechanism is straightforward: parts = ceil(object size ÷ part size). The final part may be smaller than the configured part size, so rounding up is required. The calculation should use the same binary units for both values; mixing MiB with decimal MB can produce an incorrect part count and an incorrect final upload size.

AWS’s Amazon S3 multipart upload limits documentation says that when an object reaches 100 MB, you should consider multipart upload instead of a single upload operation. Below that threshold, a single PUT is the appropriate operation: multipart upload would add the initiation, part-upload, and completion requests without providing a useful benefit for the smaller object. A practical check is to compare the object size with the threshold before selecting multipart upload.

Part size is a free variable within S3’s multipart constraints, but it is not unrestricted. The named limits are a 5 MiB minimum part size, a 1 GiB default ceiling for the selected part size, and a maximum of 10,000 parts per multipart upload. Check all three together. For example, calculate ceil(object size ÷ part size) before starting the upload and confirm that the result does not exceed 10,000. If the proposed size would violate that maximum, increase the part size and recalculate.

Use the same formula to validate the target configuration: divide the object size by the proposed part size, round up, and then add two for the multipart lifecycle calls. This check establishes the request count independently of the upload framework. It also makes the effect of changing part size visible: a larger part size reduces the number of individual uploads while leaving the object’s payload size unchanged.

The Evidence: Three Sources Converge

Amazon’s own multipart upload limits establish the first practical checkpoint: AWS says that when an object reaches 100 MB, you should consider multipart upload rather than a single operation. A 500 MiB object is comfortably beyond that threshold, so multipart is not an edge-case optimization; it is the normal upload path. The documentation also points to multipart uploads as the relevant mechanism, which makes part size the primary control for reducing request activity.

The clearest demonstration comes from the 500 MiB case. At the 5 MiB minimum part size, the upload uses 100 parts. Raising the part size to 16 MiB reduces that to 32 parts—a 68% reduction in PUT requests. The arithmetic is straightforward: 500 MiB divided into 5 MiB pieces gives exactly 100, while 500 MiB divided into 16 MiB pieces requires 32 because the final piece is fractional. This matters because request count drives both per-request charges and the number of operations that can fail, time out, or need retrying.

The cost implication extends beyond the successful upload. A September 17, 2026 c3x.dev analysis documents that parts from abandoned or failed multipart uploads can remain stored and continue generating storage charges indefinitely. Those parts are not visible through normal object listing, so an operator may see no obvious orphaned object even while the account continues to incur storage costs. AWS’s thresholds therefore answer when to use multipart uploads, while c3x.dev shows why minimizing the number of parts is a cost-control decision rather than merely a performance tweak.

A third source, ScreenshotNeo’s guide to uploading screenshots to S3-compatible storage, describes multipart uploads as part of a presigned-URL implementation, including client-side handling and multipart-specific fixes. That does not establish S3’s limits, but it does show how multipart behavior appears in a real application integration. The same part-size decision therefore affects both infrastructure cost and implementation complexity: fewer parts mean fewer client-side upload operations, less retry handling, and less opportunity for an incomplete upload to leave additional stored state behind.

The evidence supports a concrete verification routine. First, confirm that the object is above AWS’s multipart decision threshold. Next, calculate the part count at the proposed size, check that the final part is not unnecessarily small, and inspect failed or abandoned uploads for retained parts. ScreenshotNeo’s implementation guidance and c3x.dev’s lifecycle analysis should be used as operational checks, while AWS’s limits page remains the authoritative source for deciding when multipart upload should be considered. Together, they support treating part size as a deliberate policy setting and verifying both request reduction and cleanup behavior after deployment.

Part Size Options Compared

Amazon S3’s multipart upload limits provide a useful starting point: AWS recommends considering multipart uploads when an object reaches 100 MB. For a 500 MiB object, the practical part-size decision is a tradeoff between fewer requests and the amount of data that must be transferred again after a part fails.

The table counts the requests needed to transfer the parts plus the two requests used to initiate and complete the multipart upload. Among the compared choices, 16 MiB is the winner for this object because it substantially reduces request activity without making failed-part recovery unnecessarily expensive. A failed 16 MiB part requires at most 16 MiB to be uploaded again, whereas a failed 64 MiB part requires four times as much retransmission.

That distinction matters on unreliable connections. Moving from 16 MiB to 64 MiB saves 22 requests for this upload, but each failed part adds another 48 MiB of retry traffic. The check is therefore not simply “choose the largest permitted part”; it is to compare request savings against the likely retransmission burden by measuring failed-part frequency and retry bytes on a representative connection.

Use 16 MiB as the default choice for the 500 MiB case, then adjust if the environment’s failure profile differs. A connection with stable part uploads may justify evaluating 64 MiB, while a connection with frequent transient failures should favor smaller parts. In either case, measure failed-part frequency and retry bytes rather than optimizing only for the lowest request count.

Costs: Requests, Storage, Cleanup

The cost of a multipart upload has three lines: PUT-class request charges, storage for incomplete parts, and API overhead such as ListParts calls. The first line is usually the easiest to estimate, but the second can become the larger exposure when failed uploads are not cleaned up. Together, these costs should be evaluated across the expected upload volume rather than from a single object.

For a 500 MiB object, a 5 MiB multipart configuration produces 102 PUT-class requests, while a 16 MiB configuration produces 34. Because request charges depend on the current per-request rate for your AWS Region, check the S3 pricing page for your Region before budgeting, then multiply that rate by the request count for each configuration. At high upload volumes the difference in request counts grows proportionally, so request cost can become material at scale even though it is negligible for a single object.

Incomplete-part storage deserves the stronger operational control. The c3x.dev analysis of S3 multipart uploads notes that abandoned parts can continue billing indefinitely and may be invisible in ordinary object listings. A visible bucket can therefore make storage appear tidy while unreferenced multipart data continues accumulating. Include both the uploaded-part bytes and their retention period in the cost model rather than treating storage as zero until an upload is completed.

The named control for this exposure should be an AbortIncompleteMultipartUpload lifecycle rule, such as one that aborts incomplete multipart uploads after seven days. Configure the rule on the bucket, then verify that it covers multipart uploads and that aborted data is no longer billed. This gives failed uploads a defined cleanup path without requiring every application path to discover and manually abort its own abandoned uploads.

Finally, include ListParts and related API activity in the operational budget. A monitoring system that scans multipart uploads can add request charges, and frequent scans may also become costly at scale. Record the number of multipart uploads, the number of parts inspected, and the volume of incomplete data returned by each scan. The practical cost check is therefore threefold: compare PUT charges for the chosen part size, track incomplete-part bytes until the lifecycle rule removes them, and count the API calls used to find and manage unfinished uploads.

What the Evidence Does Not Establish

The cited 68% reduction is an arithmetic comparison for one 500 MiB object, not a measured throughput gain. It shows fewer PUT requests; it does not establish that the upload will finish 68% faster. The available sources includes no latency or bandwidth benchmark, so no completion-time improvement should be inferred without testing the actual object, client, and network path.

The practical boundary begins with object size. Amazon’s S3 multipart upload documentation says that multipart uploads should be considered when an object reaches 100 MB. Below that threshold, a single PUT is the simpler choice: multipart adds initiation, part-transfer, and completion requests without a demonstrated benefit. The rule therefore works in the middle range, where 16 MiB parts reduce request volume while keeping uploads comfortably within S3’s part-count limit.

The final check is empirical. Measure request counts, transfer duration, retry frequency, and recovery effort on a connection representative of production. A high-failure link may erase the advantage of fewer requests because each failed part transfer represents more retransmitted data. Similarly, changing part size can affect client memory use and concurrency requirements.

Accordingly, treat 16 MiB as a well-bounded default rather than a universal law. The supported evidence establishes request-count arithmetic and S3’s multipart guidance, not a universal speed multiplier. Validate the rule at each size boundary and on unreliable networks before treating it as a performance guarantee.

500 MiB Retention Upload

The governed-pipeline worked example is a 500 MiB regulatory meeting recording assigned a seven-year retention class under the site’s retention matrix. It is uploaded to Amazon S3 Standard in us-east-1 with a configured part size of 16 MiB. The expected result is 32 parts because 500 divided by 16 is 31.25, which rounds up to 32. Those 32 part uploads plus the multipart initiation and completion calls produce 34 expected PUT-class requests. This is an implementation example, not a general request-count rule.

Checkpoint 1 occurs before transfer: verify that the SDK upload configuration actually sets the part size to 16 MiB and does not leave it at the stated 8 MiB default. Record the configured value, bucket, region, object key, and retention class in the pipeline’s upload manifest. That record gives an operator enough context to distinguish a configuration defect from an S3-side failure without rerunning the upload blindly.

Checkpoint 2 occurs during transfer: run ListParts and confirm that the multipart upload contains no more than the expected 32 parts. A result above that boundary indicates that the effective part size differs from the governed configuration. A result below 32 is not automatically a failure, because part uploads may still be pending; it is a reason to check upload progress before intervening.

Checkpoint 3 occurs after completion: inspect the CompleteMultipartUpload response and confirm that it lists exactly 32 parts. Then reconcile the returned object with the upload manifest, including its size, key, region, and retention metadata. Only after the object is successfully completed should the pipeline mark the upload record as closed and release any temporary operational state.

The abort rule must cover both outcomes. If the upload fails, is abandoned, or cannot be reconciled, invoke AbortMultipartUpload and record the abort in the operational log. If completion succeeds, do not issue an abort against the completed upload. As the c3x.dev discussion of incomplete multipart uploads notes, abandoned parts can remain stored and billable even when they are absent from ordinary object listings. The cost of being wrong therefore runs in both directions: unnecessary request activity wastes transfer resources, while an unclosed multipart upload leaves retained parts behind. The checkpoints make either error observable without inventing a fee the sources do not provide.

Decision Rules for Part Sizing

Use this decision rule: if the object is under 100 MB, use a single PUT. Amazon S3’s multipart guidance says to consider multipart uploads when an object reaches 100 MB, so smaller uploads generally gain little from splitting. Multipart adds control operations and can leave abandoned parts behind, which the S3 multipart upload cost documentation identifies as billable storage that may remain hidden from ordinary object listings.

If the object is between 100 MB and 160 GiB, start with 16 MiB parts. This is the baseline part-size rule for the normal range: it provides a practical starting point without making every part unnecessarily small. If your network has a high per-part retry cost—such as a constrained, high-latency, or expensive link—consider scaling the part size upward within S3’s per-part maximum. Before choosing that larger size, test a representative upload and compare the additional time spent retrying a large part with the request savings from using fewer parts. Otherwise, retain the 16 MiB baseline.

If the object exceeds 160 GiB, do not keep blindly applying a fixed 16 MiB part size. Instead, calculate ceil(object size ÷ 10,000), then round that value up to a 16 MiB multiple, while respecting S3’s per-part maximum. Apply the same scaling principle when an object sits just below 160 GiB and its baseline parts would approach the multipart part-count ceiling. The check is simple: after rounding, confirm that the selected part count remains within S3’s upload limit. This makes the 16 MiB choice a baseline for ordinary objects and a controlled starting point for larger ones, not an unconditional setting.

Before uploading, make the lifecycle prerequisite explicit: verify that an S3 lifecycle rule is configured to clean up incomplete multipart uploads, and verify that the rule’s scope, age, and prefix filters match the upload path. A rule that targets only completed objects will not protect you from abandoned multipart parts. After the upload, inspect the configured lifecycle behavior and check for retained parts before concluding that cleanup is working. This matters because incomplete multipart data can continue consuming storage and generating charges even when the intended object never appears in the normal listing.

What to do next

Frequently Asked Questions

When should multipart upload be considered instead of a single PUT?

Multipart upload should be considered when objects reach 100 MiB.

How many parts does a 500 MiB object use with 16 MiB part sizes?

A 500 MiB object uses 32 parts with 16 MiB part sizes.

How many total PUT-class requests does a 500 MiB upload with 5 MiB parts require?

A 500 MiB upload with 5 MiB parts requires 102 PUT-class requests, including 100 UploadPart calls and the CreateMultipartUpload and CompleteMultipartUpload calls.

How many total PUT-class requests does a 500 MiB upload with 16 MiB parts require?

A 500 MiB upload with 16 MiB parts requires 34 PUT-class requests, including 32 UploadPart calls and the CreateMultipartUpload and CompleteMultipartUpload calls.

How should part size be selected for objects from 100 MiB through 1.6 GiB?

Set the part size to ceil(object size ÷ 10,000), rounded up to a 16 MiB multiple.

What limit should part sizing preserve for large objects?

Part sizing should keep the upload within 10,000 parts by scaling larger objects as needed.

Quick answers