Object Storage Services for Hosting Secure AI-Generated Images (Reliability First)

The least complex reliable design for a fintech application receiving large private images is a private object-storage boundary, resumable transfer, application-owned authorization, and a retention record that can be reconciled. The service name is secondary. If a network interruption restarts a large upload, or a deletion deadline cannot be proved, the design has failed on the properties that matter. TL;DR: measure completed bytes per second and recovery behavior, keep the bucket private, issue a narrowly scoped download capability only after authorization, and treat retention as application state with an auditable repair path. Keep selected images and the evidence required by policy; stop retaining unselected candidates when their review window ends. This is a reliability and governance decision before it is a product comparison. What does the bill actually represent? For a service that stores AI-generated images, the first useful accounting model is retained bytes multiplied by retention duration. Request and transfer activity can matter when images are viewed repeatedly, but the durable architectural move is to decide which bytes remain after generation and review. A thumbnail, an original, several candidates, and an abandoned multipart upload are four different retention questions, even if they appear in one user workflow. Securely hosting the images means making each of those states explainable, not merely placing them behind a private endpoint. I would record the original byte count, object key, creation time, deletion deadline, and legal-hold state before making an image downloadable. The key should not contain sensitive profile data. The retention row is the control plane; an object lifecycle rule is an enforcement aid, not the complete policy. That creates a real trade-off. Deleting every unselected candidate after the review window limits retained data and reduces the surface that must be recovered. It also removes material that could help resolve a later moderation dispute. Keeping all candidates preserves that evidence at the cost of bytes, review obligations, and a larger deletion set. The right answer belongs in the retention policy, with an explicit owner, rather than in an unexamined default. The accounting should follow the object through its whole life. An upload can be present before validation, available after validation, held for review, selected for delivery, or waiting for deletion. Each state changes the business reason for retaining the bytes, while the storage service sees only objects and requests. If those states are absent from the application record, a later invoice can reveal the mistake, but it cannot tell the team which evidence was safe to remove. The practical review is a ledger exercise, not a slogan about durability. For each state, I want the owner, the next transition, the deletion deadline, and the recovery consequence written down. A selected image may need delivery for the user while an unselected candidate may need only a short review window; a legal hold can suspend the normal transition; an abandoned upload needs cleanup even though it never became a finished image. These distinctions also make incident review less speculative because the team can ask which transition was allowed, which worker attempted it, and which observation proves completion. The storage service supplies useful primitives, but the application supplies the meaning. Where does reliability disappear during recovery? The difficult case is not the successful upload. It is the process that completes one side of a state change and disappears before recording the other side. A deletion worker can remove an object and fail before updating its database row; the inverse can leave a row marked deleted while the bytes remain. Retries must not turn either race into a second business event or a resurrected link. I would make deletion idempotent and add a reconciliation scan. It compares eligible database rows with object metadata, records an auditable outcome, and leaves legal holds untouched. A missing object should produce a clear not-found result for a later download, not an endless retry storm. An object that remains after its deadline should produce an operational alert and a bounded repair action. The database is a record of intent, not proof that the bytes exist. That distinction matters during a migration as well as during deletion. A copied object can have the expected key while its metadata, content type, retention state, or delivery policy is wrong. I would make the migration check those fields before switching readers, then keep the old boundary available for the documented rollback window. The rollback window itself is a retention choice: it preserves recovery options, but it also preserves bytes that the normal policy would eventually remove. The same discipline applies to abandoned multipart uploads. A throughput test that counts only completed files can hide unfinished parts accumulating behind the successful path. The test needs a representative image set, a defined part size, client concurrency, retry behavior, completed bytes per second, failed parts, and cleanup time for abandoned work. My review sheet has five operational outcomes: completed bytes per second, failed parts, p50 latency, tail latency, and cleanup time. One average cannot describe a large transfer with a stalled part. The upload succeeded. The workflow still may not be safe. This is the small state machine I want reviewers to be able to reason about: from dataclasses import dataclass from datetime import datetime @dataclass(frozen=True) class RetentionRecord: object_key: str delete_after: datetime legal_hold: bool deletion_recorded_at: datetime | None = None def eligible_for_deletion(record: RetentionRecord, now: datetime) -> bool: return ( not record.legal_hold and record.deletion_recorded_at is None and now >= record.delete_after ) The code does not delete anything. That is deliberate. The worker still needs a transaction boundary, an object-store result policy, and a reconciliation path. Making the predicate visible prevents a lifecycle setting from quietly becoming the only definition of “safe to remove.” Which object storage services suit hosting AI-generated images securely? A provider comparison is useful only when it tests the boundary the application actually owns. Amazon S3 exposes presigned URLs and multipart upload behavior; Google Cloud Storage exposes signed URLs; Azure Blob Storage uses delegated access tokens such as shared access signatures. Those mechanisms differ in syntax and policy controls. None removes the need to authenticate the requester, check ownership or sharing rules, constrain expiry, and observe the result. Service family Access surface Useful fit Boundary to verify Amazon S3 SDKs and REST APIs Presigned delivery and multipart transfer Application authorization remains separate from the signed request Google Cloud Storage Client libraries and REST APIs Signed-URL delivery for private objects Expiry, identity checks, and retention still need application tests Azure Blob Storage SDKs and REST APIs Delegated access with shared access signatures Token scope and lifetime do not replace retention reconciliation This is a capability comparison, not a ranking. The three services are all plausible object storage services for hosting images; the winning choice is the one whose large-file and recovery behavior the team can demonstrate under its own network conditions. The adapter should expose a small capability rather than leak provider-specific objects through the application. That makes migration a testable operation: write an object, read its metadata, resume an interrupted transfer, issue a bounded download capability, and reconcile a deletion. The code below leaves the concrete service deliberately unspecified. from datetime import datetime, timedelta, timezone def create_download_capability(storage, record, requester, now=None): current = now or datetime.now(timezone.utc) if record.owner_id != requester.id: raise PermissionError("object is not owned by requester") if record.deleted_at is not None or current >= record.download_until: raise FileNotFoundError("object is no longer downloadable") return storage.sign_download( key=record.object_key, expires_at=current + timedelta(minutes=10), ) Ten minutes is a policy example, not a universal setting. A slow mobile transfer may need longer, while a sensitive administrative export may need less. The question is how long an authorized bearer capability remains useful after it leaks. Expiry limits exposure; it does not revoke bytes already downloaded. Can browser policy be tested separately from authorization? Yes, and separating the tests avoids a common category error. CORS is the browser’s cross-origin permission mechanism, not an object authorization layer. A browser may send a preflight request, and the endpoint must return headers matching the requested origin, method, and headers. MDN documents this browser behavior and its distinction from server-side access control. Test the production origin, upload method, required content headers, and response headers from a real browser. An exact origin allowlist is easier to review than reflecting whatever appears in a request header. A command-line transfer can prove that bytes reached an endpoint while saying nothing about whether browser JavaScript may read the response. The deployment test set should include an interrupted large-file transfer, a resumed part, an expired capability, an unapproved origin, a legal hold, a retry after deletion, and a retention worker that stops between object removal and database recording. Test just below and just above every application size boundary. Test clock skew too: disagreement between signer and validator can reject a valid request or extend access unexpectedly. What should be retained, measured, and reviewed? Log a privacy-safe object identifier, operation type, byte count, status, duration, retry count, and the policy decision that allowed the operation. Do not put the signed URL itself in ordinary logs; until expiry it is a bearer capability. Correlate the application request with storage request identifiers where available, then alert on abnormal download volume, repeated signature failures, unfinished multipart work, and lifecycle deletion errors. The decision rule is narrow: choose the storage boundary that demonstrates large-file transfer, private delivery, retention enforcement, and recovery under test. Then choose the service whose operational controls fit that evidence. Do not let a durability label, a dashboard screenshot, or a low request count substitute for a recovery exercise. The architecture should remain understandable when the image is large, the network is unreliable, the capability leaks, and the deletion deadline arrives on a weekend. Further reading MDN, “Cross-Origin Resource Sharing (CORS)”: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS Amazon S3 User Guide, “Sharing objects with presigned URLs”: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html Google Cloud Storage documentation, “Signed URLs”: https://cloud.google.com/storage/docs/access-control/signed-urls Microsoft Learn, “Delegate access with a shared access signature”: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview RFC 9110, “HTTP Semantics”: https://www.rfc-editor.org/rfc/rfc9110