Design an image upload flow. Does the file go through your server?

The main reason isn't bandwidth but memory and connection-hold time. A 50MB upload on a slow connection occupies a thread or connection for minutes; a few dozen concurrent uploads is enough to stop an instance serving ordinary requests. Presigned URLs remove that entirely, in exchange for moving your checks to signing time, including a content-length-range constraint in the policy.

The security detail most often skipped is trusting the client-declared Content-Type. Anyone can set that header, so verify the actual content after upload — read magic bytes, and for images ideally reprocess through a library (resize, re-encode), which both normalises and strips payloads embedded in metadata. And always serve files from a domain separate from the app, so an HTML file that slips through can't execute in the user's session context.

Finally, orphans: the client gets a URL, uploads, then leaves before calling the confirm step. You have a file in storage with no database row. The remedy is uploading under a temporary prefix and moving it on confirmation, plus a lifecycle rule expiring that prefix after 24 hours — configured once on the bucket, with no cleanup job to write.