A large preservation copy is not a simple download-and-upload
A hypothetical museum needs a controlled archival copy of a multi-gigabyte exhibit film already stored in S3. A single CopyObject operation has a documented 5 GB limit, so larger objects require a multipart copy strategy using appropriate tools or SDKs. Copying byte ranges from a source object can avoid moving the media through an operator’s workstation.
However, copying many ranges is not equivalent to verifying a finished preservation master. The institution must keep the authoritative source version, rights record, source checksum and target identity. A successful copy request does not prove that the film is unaltered or approved for a public exhibit.
Know the distinction between UploadPartCopy and UploadPart
UploadPartCopy creates one part of an in-progress multipart upload by copying bytes from an existing S3 object. UploadPart instead supplies new bytes in the request. Both require an initiated multipart upload and a target upload ID. The part-copy API uses x-amz-copy-source to identify the existing source object.
The caller must prepare a destination upload through CreateMultipartUpload before copying parts, and later complete that upload. A copied part is not a standalone accessible video and does not itself change the source master. Keep source and destination resource IDs separate in the transfer ledger.
Pin the source version before starting copy work
For versioned source buckets, AWS documents that x-amz-copy-source normally refers to the current version. To pin a specific source version, append its versionId as described in the API reference. This matters if conservation staff may replace the current video master while a long transfer is running.
Without a pinned version or other approved source-stability control, different workers might copy ranges from changing source content. The final object could then be internally inconsistent even if every range request succeeds. Record the selected source version, size and checksum before starting the destination session.
Plan nonoverlapping byte ranges
UploadPartCopy supports x-amz-copy-source-range to select an inclusive byte range in the form bytes=first-last, with zero-based offsets. The API states that a range can be copied only when the source object is greater than 5 MB. Make a deterministic plan mapping contiguous source byte ranges to destination part numbers and expected lengths.
Check every boundary, especially the final short range. An off-by-one error can skip or duplicate a video byte even though S3 accepts each requested part. Keep the range plan in a protected manifest that can be compared with the resulting part metadata and the verified source size.
Create a destination upload with approved settings
The destination multipart upload should specify the correct bucket, key, encryption and object metadata policy at initiation. Record the destination upload ID separately from the source version ID. A new copy should not silently replace an approved archive object merely because its filename matches a prior production rendition.
If a transfer is intended to create an immutable preservation master, coordinate source permissions and retention controls before proceeding. A multipart transfer does not grant publication rights, set legal hold automatically or guarantee access for the institution’s preservation team.
Check source read permissions and encryption
Copying ranges may require access to the source object plus permission to create parts in the destination. Encryption settings can introduce additional KMS rights and request parameters; the exact requirements depend on the bucket types and encryption configuration. Do not assume that a successful simple object read proves all multipart copy requests are authorized.
Use a scoped service role and an allowlisted source and destination. Avoid putting full private object paths, keys or signed URLs into a public build log. When a request fails, preserve sanitized details about the source version, range and error code for an authorized operator rather than restarting a different source copy blindly.
Preserve part order and copy evidence
Each successful UploadPartCopy request returns a copy-part result that includes metadata such as an ETag and potentially checksum details. Map each result to its requested destination part number and exact source byte range. Retrying a part must not silently change its source version or offset range.
For multipart completion, part numbers determine assembly order. Keep the complete ordered list of accepted parts for the destination upload. ETags are not a universal whole-object MD5 guarantee, so the final copy needs an appropriate integrity check against the institution’s independently stored source digest.
Treat source delete markers as meaningful failures
AWS documents special behavior for versioned source objects. If the current source version is a delete marker and no specific versionId is supplied, the copy request can return 404. If a delete marker version is explicitly named as a copy source, AWS documents a 400 response. These are distinct from general network or authorization failures.
An error handler should not interpret every missing source as evidence that all archive versions were destroyed. Investigate the version history through authorized channels and confirm whether the institution intended to copy a particular historical version. Never switch automatically to the latest current version after a source-version error.
Compare source drift, copied ranges and completed object
The instructional comparison shows a moving source reference, a set of copied ranges waiting for completion, and a final assembled object verified against a pinned source revision. These are conceptual states, not the output of a live S3 operation or a measured transfer. Merely receiving ETags for individual ranges belongs to the middle state.
A green final object should still be subject to institutional preservation QC, including checksums, catalog linkage and any required playable-media review. Transport completion and archival acceptance are not synonymous. The visual illustrates where operators need to stop before confusing one for the other.
Finish with an independently verified transfer record
After all intended parts are accepted, complete the destination multipart upload and verify the target object identity, size and supported checksum evidence. Record the source bucket/key/version, destination object identity, range manifest, completion result and source digest. Do not delete or replace the authoritative source as an automatic follow-up step.
This guide summarizes AWS API documentation and a fictional museum film transfer. We did not copy real objects, inspect storage credentials or compare video files. Reconfirm current part limits, encryption rules, versioning semantics and preservation policy before copying production material.
How We Research
For this November 11, 2026 desk review we compared authoritative documentation: Amazon S3 UploadPartCopy API; S3 multipart copy walkthrough; S3 copy object guidance; S3 multipart upload overview. We reviewed the named field definitions, failure paths, and operational limits against a fictional museum workflow, and drew original conceptual illustrations. We did not run API requests, inspect customer accounts, measure service performance, approve any copyright license, or verify live collection data. Documentation, plan availability, security settings and preview status can change; confirm the current service reference and your organization’s legal and editorial policies before production use.
Frequently Asked Questions
It copies source byte ranges into a multipart destination, including large objects that cannot be handled by a single CopyObject request.
Use the documented versionId in x-amz-copy-source when the source bucket is versioned and record that ID in the transfer manifest.
No. It produces a part of an in-progress destination multipart upload; completion is a separate operation.
Yes. AWS documents bytes=first-last with zero-based offsets, so boundary calculations require care.
No. Verify the finished object using appropriate checksum evidence and your independent source record.