I'm designing a multi-tenant workflow that generates HTML previews, documents, images, and intermediate files for several users. Reviewers need short-lived access links, tenants must never be able to access one another's files, approved outputs must remain recoverable, and disposable intermediate artifacts should expire automatically. Would you recommend immutable object keys with a small manifest pointing to the current approved revision, or stable keys with S3 Versioning? I'd also like guidance on where to store metadata such as owner, run ID, approval state, content type, and retention policy; how narrowly to scope presigned URLs; and whether S3 Object Lock is useful or unnecessarily complex. The goal is clear rollback and auditability without making every read depend on an overly complicated lookup.
3 Answers
Treat S3 as the blob store, not the system of record for business rules. Store tenant ID, owner, run ID, artifact type, approval state, revision, retention, and object key in DynamoDB or a relational database. Enforce tenant authorization there, then have a service issue presigned URLs only after checking the caller’s permissions. Keep approved artifacts in a protected prefix or bucket, and apply lifecycle rules to previews and intermediates that are not approved.
Presigned URLs should be generated for one exact object key, with the shortest practical expiration and the intended HTTP method and content type constrained where possible. Don’t use a broad prefix as the authorization boundary. S3 Versioning can provide an additional recovery layer, but I wouldn’t use stable keys as the primary revision model because overwrites are harder to reason about and audit. Object Lock is worthwhile only when you need enforced immutability or compliance retention; for ordinary application rollback, immutable keys plus restricted deletion and an audit trail are usually simpler.
For review links, point the URL at a specific immutable revision rather than the moving ‘current’ object. Once approval is recorded, update the manifest or database pointer atomically and leave the approved object protected from normal cleanup.
Use immutable keys for each generated artifact and keep the workflow state in a database or a small manifest. A manifest can identify the current approved revision, while older revisions remain available for rollback. This also prevents a bad overwrite from silently changing metadata such as Content-Type. An upload can return HTTP 200 and still break rendering if the content type or bytes are wrong, so validate the actual artifact rather than only checking the upload response.
That separation also makes future requirements easier. If approval rules, legal holds, or audit queries grow, they can change without trying to encode everything into S3 prefixes and object metadata.