S3 Object Storage, Presigned URLs and Multipart Uploads

1. The problem: “upload succeeded” is not one conclusion

An object-upload path usually contains several distinct layers: bucket/key identity, signer authority, the presigned request, browser/CORS behavior, transfer method, multipart state, final storage, and application acceptance. Collapsing them into one green/red status hides both cause and security boundaries.

The owned artifact is Object Upload Access and Multipart Evidence Record v1. It keeps authorization, transport, transfer lifecycle, and application acceptance separate.

2. Object storage and object identity

In object storage, an object is normally addressed by bucket and object key. A key is not merely a display filename; it is part of the namespace and often part of access policy. Metadata may also affect application behavior, but storage identity and business identity are not interchangeable.

Record the bucket, key, required metadata, and responsible actor explicitly. Similar filenames are not proof of the same storage target.

3. What a presigned URL is

In Amazon S3, a presigned URL grants time-limited access to an object operation without exposing the original credentials to the caller. Its effective authority comes from the principal that generated it; the URL does not create permissions beyond the signer boundary.

Treat presigning as a bounded capability: operation, bucket/key, and expiry must match the actual job.

4. Signer authority and least scope

If the signer has broad permissions, presigned requests are generated within that broad boundary. A safer design gives the signer only the prefix, operations, and resources required for the workflow.

Record signer_principal and allowed prefix/operation separately from the URL. A working URL does not prove least privilege.

5. Method and object key must match the capability

A URL signed for PUT against one key should not be assumed valid for a different method or key. In the local fixture, changing method or key without re-signing creates a binding mismatch.

Analyze this separately from expiry: a request can be time-valid yet fail operation/key binding.

6. Expiry is an authorization boundary

Presigned URLs are time-bounded. After the validity window, diagnose the failure first as an authorization-time issue rather than inferring object deletion or a network outage.

One lab case replays after expiry. The bounded conclusion is AUTH_EXPIRED, not “file missing” or “storage down.”

7. CORS is not authorization

CORS is a browser transport policy. A request may be storage-authorized while a browser blocks it because of CORS. Conversely, permissive CORS does not grant storage permission.

Keep cors_transport_boundary separate. If the same signed request remains valid outside the browser, the browser symptom does not invalidate the authorization model.

8. Single PUT or multipart: a workload decision

Single PUT is simpler and often sufficient for smaller workloads without resume needs. Multipart adds parallelism, independent part retry, and resumability, but also state and cleanup complexity.

Do not turn provider numbers into universal laws. AWS and R2 publish provider-specific guidance and limits that must be rechecked when they matter.

9. Multipart lifecycle: upload ID and part ledger

Multipart upload is managed with an upload ID and a set of numbered parts. Each part has its own transfer evidence; if one part fails, successful parts do not need to be retransmitted.

Record upload ID, part number, checksum/ETag or equivalent evidence, and retry history so recovery is deterministic.

10. Complete and Abort are different terminal actions

Until completion succeeds, uploaded parts are not the final assembled object. If the workflow will not continue, an explicit abort/cleanup decision is required; an abandoned multipart session remains open state.

A lab case intentionally remains incomplete so the learner must identify MULTIPART_ABORT_REQUIRED.

11. Storage completion is not application acceptance

An object can be stored successfully and still fail application checks such as checksum policy, media type, schema, malware scanning, or business rules. That rejection is not a transport failure.

The artifact therefore keeps stored_object_observation and application_acceptance as separate evidence.

12. R2 and the meaning of S3-compatible

Cloudflare R2 exposes S3-compatible APIs, but compatibility does not imply identical behavior in every feature. Current R2 documentation separately defines supported presigned operations, bearer-token handling, and upload-method constraints.

For provider-specific decisions, use that provider’s current documentation rather than copying an AWS assumption without verification.

13. Object Upload Access and Multipart Evidence Record v1

The record includes: bucket/key, signer scope, requested operation, signed constraints, issued/expiry time, authorization result, browser/CORS state, transfer method, upload ID, part state, retry evidence, complete/abort evidence, final object observation, application acceptance, inference, unknowns, and final decision.

This is a MAKNOW instructional synthesis, not a required AWS or Cloudflare form.

14. Lab and transfer

The lab is fully local and deterministic. Eight fixtures cover a valid single PUT, expiry, key mismatch, a CORS-only failure, multipart retry, an orphaned multipart upload, storage-complete-but-app-rejected, and a changed transfer with a new prefix/size/failed part.

In transfer, no token, key, expiry, or part decision from the first case may be copied; every state is recomputed from the changed evidence.

15. Sources, freshness, and claim limits

Current Amazon S3 documentation still describes presigned URLs as time-limited access using the signer’s credentials and multipart upload as independently uploaded parts with retry plus completion/abort semantics. Current Cloudflare R2 documentation treats presigned URLs as bearer tokens for specific operations and distinguishes upload methods by size, parallelism, resumability, and provider-specific limits.

These sources were rechecked on 2026-09-19 and are due for review on 2026-10-17. No provider-specific numeric limit is presented here as a universal object-storage rule.