--- title: "Where an S3 Multipart Upload Becomes a Readable Object" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/s3-multipart-upload-parts-before-object-completion" last-updated: "2026-10-20" --- # Where an S3 Multipart Upload Becomes a Readable Object Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. An S3 multipart upload becomes an object when its completion succeeds, assembling the selected parts in part-number order. Successful part uploads alone can leave data retained and chargeable while no new object is available at the target key. For a model-artifact handoff, distinguish upload progress, the completed object's identity and the scope of storage accounting. ## Identify the upload and its target object An upload report can accurately say that every part is stored while the recipient still has no new artifact to read. AWS separates multipart initiation, part uploads and completion. This comparison uses Amazon S3 general purpose bucket behavior documented on October 20, 2026. Initiation identifies the target bucket and key and returns an upload ID that associates the parts with that particular upload. Within the upload, a part number identifies a part and its position in the intended object. These identifiers describe work toward the target object. Completed-object evidence instead identifies the bucket and key, with the version ID where bucket versioning is enabled. Each part can be uploaded independently. Its arrival time does not determine its position in the final artifact. Successful completion creates the object from the parts specified for completion, in ascending part-number order. A progress counter reaching its last byte leaves that completion event to be established. References: [A1](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html), [A2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html), [A4](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html), [A5](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html) ## Follow three stored parts through the completion boundary Consider a fictional, deliberately small artifact that makes the accounting visible. Use one general purpose bucket with versioning disabled and S3 Standard storage. The target key, model-package.bin, has never held an object. There is one upload ID. No part is replaced, and there are no operations beyond the part uploads and completion described below. Parts 1, 2 and 3 contain 5 MiB, 5 MiB and 2 MiB respectively. Each part upload succeeds; their arrival order is 2, 1, 3. The retained part payload totals 12 MiB, or 12,582,912 bytes. AWS's documented minimum for a nonfinal part is 5 MiB; the last part has no minimum size, so the smaller third part meets that constraint. At observation A, completion has not occurred. There are three stored parts associated with this upload and zero completed objects at the target key. An object-only listing correctly has no model-package.bin to report. The 12 MiB remains retained as parts; it has not become three separately readable artifacts. Now separately stipulate successful completion naming those exact three parts, with their matching ETags, in 1, 2, 3 order. At observation B, there is one 12 MiB object: part 1's bytes followed by part 2's and then part 3's. The earlier arrival order does not change this sequence. After successful completion, the separate upload parts no longer exist. These are deductions from the fictional assumptions, rather than an observed transfer result. References: [A1](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html), [A2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html), [A3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts.html), [A6](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html) ## Read the final completion outcome CompleteMultipartUpload has a specific response behavior that matters when assessing a handoff record. S3 can send initial HTTP 200 headers while still processing the request and subsequently include an error in the response body. A status-only log entry saying 200 therefore leaves successful completion unresolved. The useful record establishes the final successful operation outcome for the identified upload and connects it to the resulting object. In the example, observation B expressly stipulates that success. Merely showing that a completion request was sent, or that its initial headers arrived, would leave the example at an unestablished completion state. References: [A2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html) ## Reconcile object availability with retained upload storage An object listing and a multipart-upload listing describe different populations. AWS defines the latter around uploads that have started but have yet to complete or stop. For general purpose buckets, ListObjectsV2 also excludes prefixes arising solely from in-progress multipart uploads. A completed-object count therefore cannot inventory all retained upload data. At observation A, zero objects at the target key and 12 MiB of retained part payload are compatible measurements. Neither establishes corruption. The first describes completed output; the second describes data still associated with unfinished work. A supplier's report needs a common bucket, key, upload scope and observation time before those quantities can be reconciled. For this fully uploaded case, AWS documents completion or abort as the ending of incomplete-part storage charges. Successful completion ends that separate-part storage, while the completed object has its own storage charges. Multipart activity can also incur request and bandwidth charges. The example's 12 MiB is a payload quantity, not a complete bill calculation; the storage class and applicable pricing still matter. An idle upload alone supplies no evidence that its retained parts have ceased to incur storage charges. References: [A1](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html), [A4](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html), [A6](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html), [A7](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListMultipartUploads.html) ## Match the handoff milestone to the evidence With successful part records alone, the supported milestone is upload progress. A handoff requiring one stored artifact needs evidence of successful completion and the resulting object's identity. If the recipient must read it, establish authorized access to that object as a further condition; completion alone demonstrates no recipient download. Keep the next assessment aligned with the actual claim. The related S3 ETag and Checksum guide explains how to compare integrity evidence for the completed bytes. The S3 Dataset Release guide addresses whether several completed objects form the intended generation. The Presigned Artifact Link guide addresses the recipient's access window. Before accepting an upload-finished milestone, clarify whether it means every part is stored or final object completion succeeded. For an ongoing-charge question, clarify which retained-upload storage the accounting covers. Successful progress can be valuable evidence without satisfying either a completed-artifact requirement or a claim that incomplete-upload storage charges have ended. ## Scope any surrounding physical connections If the artifact handoff accompanies a physical storage-network installation, Leviathan's Structured Cabling & Fiber Installation service provides a route to discuss agreed cabling, endpoint identification, labels and connection records using customer-furnished or separately sourced materials. Use the related physical-project inquiry with a nonconfidential equipment outline, approved endpoints and routes, requested installation work and required handoff records. Multipart operation and cloud storage administration remain with the appointed storage provider; the inquiry concerns the surrounding physical connections. References: [L1](https://www.leviathansystems.co/services/structured-cabling) ## Primary sources - [A1 — AWS: Uploading and copying objects using multipart upload in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html). Checked 2026-10-20. Multipart stages, independent part arrival, completion and pricing distinguish retained upload data from the completed artifact. - [A2 — AWS S3 API: CompleteMultipartUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html). Checked 2026-10-20. Defines assembly of the supplied parts and the operation-specific possibility of an embedded error after initial HTTP 200 headers; also identifies the returned object and version fields. - [A3 — AWS: Amazon S3 multipart upload limits](https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts.html). Checked 2026-10-20. The 5 MiB nonfinal-part minimum and last-part exception support the illustrative 5 MiB, 5 MiB and 2 MiB case. - [A4 — AWS S3 API: CreateMultipartUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html). Checked 2026-10-20. The target key and returned upload ID identify an initiated upload; the operation also explains separate-part storage charging. - [A5 — AWS S3 API: UploadPart](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html). Checked 2026-10-20. The upload ID and part number identify an upload's part and its intended position, rather than a completed object version. - [A6 — AWS S3 API: ListObjectsV2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html). Checked 2026-10-20. Describes bucket object listings and the general purpose bucket exclusion of prefixes related only to in-progress multipart uploads. - [A7 — AWS S3 API: ListMultipartUploads](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListMultipartUploads.html). Checked 2026-10-20. Defines the separate population of initiated uploads that have not completed or stopped; useful when interpreting an object-only availability report. - [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Agreed physical cabling, endpoints, labels and connection records define the relevant inquiry when surrounding equipment also needs installation work. ## Related Leviathan resources - [S3 ETags and checksums: assess completed-object integrity evidence](/articles/ai-dataset-s3-etag-versus-checksum-integrity) - [S3 consistency and a complete multi-object dataset release](/articles/ai-dataset-s3-consistency-versus-complete-release) - [Presigned artifact links and the recipient's access window](/articles/s3-presigned-artifact-link-credential-expiry) - [Structured Cabling & Fiber Installation](/services/structured-cabling) - [Project inquiry for surrounding physical storage connections](/contact?service=structured-cabling&from=%2Farticles%2Fs3-multipart-upload-parts-before-object-completion) ## Does the surrounding equipment need physical connections? Share a nonconfidential equipment outline, approved endpoints and routes, requested cabling work and required records to discuss physical scope and availability. [Discuss the scope](/contact?service=structured-cabling&from=/articles/s3-multipart-upload-parts-before-object-completion)