Incomplete multipart uploads
A large upload that failed midway leaves the parts already sent in the bucket. They are billed, and they do not appear in the object listing.
What this problem is
Large files reach S3 in parts, and only become an object once the upload is completed. If the process is interrupted before that — the connection dropped, a deploy failed, the client crashed — the parts that already arrived remain in the bucket, occupying billed space.
What makes this hard to notice is that those parts are not objects yet. They do not show up when you list the bucket's contents, do not appear in the console as files, and are not counted where most people look to understand what is stored. Only the invoice and the bucket size metric know they exist.
The fix is a lifecycle rule with AbortIncompleteMultipartUpload, which automatically removes abandoned parts after a few days. It is worth applying as a default on any bucket that receives large file uploads — it clears what is already there and stops it coming back.
How we detect it
We list buckets with ListAllMyBuckets and, within each, the in-flight multipart uploads with ListBucketMultipartUploads and ListMultipartUploadParts, which report how long ago each upload started and how much its parts occupy.
- Incomplete multipart uploads
What it costs
Parts are billed at the bucket's storage class — about $0.023 per GB-month in Standard (us-east-1). Abandoned uploads of large files accumulate tens of gigabytes without appearing in any listing.
Public AWS list prices, us-east-1, subject to change. The figure in your report is computed against your resources in your regions.
How it appears in the report
An illustrative example, with invented resources and figures. In the report each finding carries the real resource, its region, and the fix command where a safe one exists.
Does your account have this?
The scan is read-only and shows you what it found before you pay for anything.
Run a free scan