S3 buckets holding incomplete multipart uploads with no abort lifecycle rule
What does ZopNight detect here?
ZopNight targets S3 buckets that hold incomplete multipart uploads and have no lifecycle rule using `AbortIncompleteMultipartUpload`. S3 bills the orphaned parts as storage until the upload is completed or aborted. A finding needs the bytes those parts occupy, which ZopNight cannot yet measure per bucket, so it currently reports nothing.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-074 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | at least 1 incomplete upload and no abort rule |
| Source | ZopNight |
| Permissions used | s3:ListBucketMultipartUploads · s3:GetLifecycleConfiguration |
Where it applies
Parts of an unfinished upload are billed like any object
Multipart upload sends a large object in pieces and assembles it at the end. The multipart upload overview explains that S3 keeps every uploaded part until you complete or stop the upload, and that you are billed for all storage, bandwidth and requests for the upload and its parts in the meantime. A client that crashes halfway through a 50 GB upload leaves those parts behind, invisible in a normal object listing.
AWS recommends a lifecycle rule with the AbortIncompleteMultipartUpload action for exactly this
reason.
Seeing what is left over
aws s3api list-multipart-uploads --bucket my-bucket \ --query 'Uploads[].[Key,UploadId,Initiated]' --output table
aws s3api get-bucket-lifecycle-configuration --bucket my-bucketUploads initiated weeks ago are almost certainly abandoned. S3 Storage Lens reports
IncompleteMultipartUploadStorageBytes, which its
metrics glossary
lists among the free cost-optimization metrics, if you want the byte total without walking every
upload.
The gates ZopNight applies
- The bucket’s lifecycle configuration was read and contains no abort rule for incomplete multipart uploads. If the configuration could not be read, the bucket is skipped.
- At least one incomplete upload was actually found. A missing rule on its own is not evidence of waste.
- The bucket has a price, used only to confirm pricing is available and never as the saving.
- ZopNight knows how many bytes the incomplete parts hold and has the S3 Standard storage rate for the Region.
Why no finding appears today
The last gate is not met yet. Counting the bytes held by incomplete parts for every bucket would mean listing the parts of every upload, which is the expensive fan-out ZopNight deliberately avoids, so that measure is not collected. Without it there is no honest dollar figure, and pricing the whole bucket instead would overstate the waste by orders of magnitude. The check therefore raises nothing on any bucket until a per-bucket byte measure is available.
How the saving will be priced
saving = incomplete part GiB x S3 Standard price per GiB-hour x 730cost after fix = 0 for those partsAdding an abort rule now
- In the S3 console, open the bucket’s Management tab and create a lifecycle rule.
- Choose to delete incomplete multipart uploads and set the number of days, such as 7.
- Or apply it from the CLI with
aws s3api put-bucket-lifecycle-configurationand a rule containingAbortIncompleteMultipartUploadwithDaysAfterInitiation, as in the lifecycle example. - Abort a specific upload immediately with
aws s3api abort-multipart-upload.