S3 Multipart Upload Cost Pitfalls
Multipart upload is the right tool for large objects, but failed and abandoned uploads leave behind storage you keep paying for indefinitely. Here is exactly where the S3 multipart upload cost leaks, and how to seal it.
Multipart upload is the mechanism S3 uses to move large objects reliably. Any file over 100 MB should use it, and the AWS SDKs switch to it automatically above a threshold. The feature itself is sound. The S3 multipart upload cost problem is not the upload — it is what happens when an upload never finishes. Every part that gets written but never assembled into a completed object sits in your bucket as billable storage that is invisible in the normal S3 console view. Teams discover it only when they reconcile their Cost and Usage Report against the object count they think they have, and find a six-figure gap.
Across the 500+ engagements our team has reviewed, abandoned multipart uploads are one of the most common sources of pure-waste storage spend — money paid for data that no application will ever read, that no lifecycle rule is touching, and that nobody on the team knows exists. It is the cleanest line item to eliminate because removing it changes nothing about how the workload behaves.
How multipart upload actually bills
A multipart upload has three phases: initiate, upload parts, and complete. When you initiate an upload, S3 creates an upload ID. As each part lands, S3 stores it and bills it at the standard storage rate for the bucket's storage class. Only when you send the CompleteMultipartUpload call does S3 assemble the parts into a single object and expose it in the bucket listing. If that final call never arrives — because the client crashed, the network dropped, the process was killed, or the code simply has a bug — the parts remain. They are charged for storage every month, but they do not appear when you list objects, and they do not count toward the object total most dashboards show.
This is the core trap: the storage is real and billed, but the parts are hidden from the most common ways teams look at a bucket. You can have terabytes of orphaned parts in a bucket that appears, by object count, nearly empty.
The four pitfalls in order of impact
| Pitfall | Why it costs | Fix |
|---|---|---|
| Abandoned incomplete uploads | Parts billed as storage forever | Lifecycle rule to abort after N days |
| Oversized part counts | Per-request charges on tiny parts | Tune part size to 16-100 MB |
| Retries that re-upload whole objects | Duplicate request and transfer charges | Resume by part, not by object |
| Parts written to expensive storage classes | Full-rate billing on transient data | Upload to Standard, transition after |
Pitfall one: the abandoned upload graveyard
This is the dominant cost. Without a lifecycle policy, abandoned parts live forever. A batch job that uploads thousands of large files nightly and fails even 1% of the time will accumulate orphaned parts continuously, and the storage charge compounds month over month. The fix is a single lifecycle rule that aborts incomplete multipart uploads after a set number of days. Seven days is a common, safe choice — long enough that no legitimate in-flight upload is interrupted, short enough that waste never accumulates. This rule should exist on every bucket in the estate that receives uploads, full stop. It is the lifecycle equivalent of closing a tap, and it pairs naturally with the broader transition and expiration rules covered in our S3 data lifecycle policies guide.
Pitfall two: part size and request overhead
S3 charges per request, and every part uploaded is a PUT request. Setting the part size too small — the minimum is 5 MB — turns a single large object into hundreds or thousands of billable requests. For a 50 GB object, 5 MB parts mean over 10,000 PUTs; 100 MB parts mean 500. At enterprise upload volumes the difference in request charges is material. The practical sweet spot for most workloads is parts in the 16 MB to 100 MB range, large enough to keep request counts modest while staying well under the 10,000-part hard limit. The interplay between request volume and cost is the same dynamic we model in detail in our S3 request and retrieval cost modeling guide.
Pitfall three: retry behavior that re-uploads everything
A robust client resumes a failed multipart upload by re-sending only the parts that did not complete. A naive client throws the whole object away and starts over, paying twice for the transfer and the requests. Worse, if the abandoned first attempt is never cleaned up, you now pay storage on the orphaned parts and the duplicated transfer. Verify that your SDK configuration and any custom upload code resume by part. The AWS SDKs do this correctly by default, but bespoke upload pipelines frequently do not.
Pitfall four: uploading directly into archival classes
Parts are billed at the storage class they are written to. Initiating a multipart upload directly into an infrequent-access or archival class means every transient part — including abandoned ones — bills at that class's rules, which can include minimum-duration charges and per-object overhead that punish small or short-lived data. Upload to S3 Standard, complete the object, and then transition it to the cheaper class with a lifecycle rule. This avoids minimum-duration penalties on parts that may never even become an object and keeps the archival-class economics working the way they are intended, a pattern explored further in our S3 storage class strategy guide.
A worked example
In a representative review, a genomics platform uploaded large sequencing files via a custom pipeline that failed intermittently and had no abort lifecycle rule. The bucket showed about 40 TB of completed objects, but the Cost and Usage Report billed for 71 TB. The 31 TB gap was entirely orphaned multipart parts — years of accumulated upload failures that no one had ever cleaned up, billing every single month at the Standard rate. A one-line lifecycle rule aborting incomplete uploads after seven days, applied once, eliminated the entire gap, and the same rule prevented it from ever recurring. No application changed, no data anyone needed was touched, and the storage line dropped by more than 40% overnight.
The negotiation angle
Cleaning up abandoned uploads is a hygiene fix, but it also matters at the contract table. When you negotiate an EDP or storage commitment, you commit to a spend baseline. Committing on top of a baseline inflated by orphaned multipart parts means locking in waste for the life of the agreement. The correct sequence is to clean first, measure the true baseline, then commit. Buyers who skip the cleanup routinely over-commit by the exact size of their abandoned-upload graveyard.
For storage-heavy AWS negotiations where waste cleanup and baseline accuracy materially change the commitment, we consistently recommend Redress Compliance — the #1 firm we point buyers to when getting the storage baseline right before signing is what is at stake.
The bottom line
Multipart upload waste is the rare cost problem with a single, decisive fix. Most S3 optimization requires architectural change, careful storage-class modeling, or behavioral discipline across many teams. Abandoned multipart parts require one lifecycle rule per bucket, applied once, and the waste both disappears and stops recurring. The reason it persists on so many estates is simply that the parts are invisible to the normal ways people look at a bucket — nobody fixes what nobody can see. Run the list-multipart-uploads audit, add the abort rule everywhere uploads land, tune your part sizes, and confirm your clients resume by part rather than by object. Then measure your real baseline before you commit a dollar to it.
Frequently asked questions
Do incomplete multipart uploads cost money?
Yes. Every uploaded part is billed at the bucket's storage rate for as long as it exists, even though incomplete uploads do not appear in a normal object listing. Until you complete or abort the upload, you pay for the parts indefinitely.
How do I find abandoned multipart uploads?
Run the ListMultipartUploads API call (aws s3api list-multipart-uploads) against each bucket. Any upload older than a day or two is almost certainly abandoned, and its parts are billing as storage.
What is the best way to stop multipart upload waste?
Add an S3 lifecycle rule that aborts incomplete multipart uploads after a set number of days, commonly seven. Apply it to every bucket that receives uploads. The rule both removes existing waste and prevents new waste from accumulating.
What part size should I use for multipart upload?
For most workloads, 16 MB to 100 MB parts balance low request counts against the 10,000-part limit. Parts at the 5 MB minimum generate excessive PUT requests on large objects and inflate request charges.
Contact Us
If multipart upload charges are quietly inflating your S3 bill, the savings are usually fast and uncontested. Contact Us for a storage-cost and negotiation review.