I built a file-management microservice that uses the AWS SDK. Uploads currently work through presigned URLs generated by my application backend and passed to the service.
Now I'm deciding how to list and display the uploaded images. Think of a product catalog where customers upload one or more images for each product. Presigned URLs seem useful for uploads, but they expire, so they don't seem ideal for image URLs embedded in pages. Routing every image request through the microservice to generate a fresh download URL would also add unnecessary overhead.
I'm considering putting a CDN in front of the bucket so the images can be cached and served through stable URLs. What is the recommended production setup for public, read-only product images? Should the S3 bucket remain private behind CloudFront with Origin Access Control, or is a public bucket or another CDN strategy more appropriate? Also, what is the usual way to maintain and return the list of image URLs?
3 Answers
For images that are meant to be public, the usual AWS setup is a private S3 bucket behind CloudFront. Configure Origin Access Control so only the CloudFront distribution can read from S3, then use the CloudFront URL—or a custom domain—as the image source. CloudFront handles caching and delivery, so you don’t need to generate a download presigned URL for every image request.
Presigned URLs still make sense for uploads. If the images later need access control, CloudFront can also use signed URLs or signed cookies instead of making the objects publicly readable.
CloudFront is the simplest fit if the rest of your infrastructure is on AWS: private bucket, CloudFront distribution, OAC, and a custom domain with HTTPS. Another CDN can work too, especially if its pricing or egress model better matches your traffic, but it doesn’t remove the core design principle—keep the origin private and expose only the CDN.
A public S3 bucket can work for genuinely public assets, but it gives up some protection and makes it easier to bypass the CDN. I’d only choose that intentionally, not just to avoid handling URLs.
Keep the image metadata in your application database rather than trying to use S3 as the catalog. When an upload completes, store the product ID, object key, content type, dimensions, and any other useful metadata. Your API can return the records along with stable URLs such as `https://images.example.com/products/...`.
The CDN serves the actual files, while the database remains responsible for listing which images belong to each product. Consider using versioned object keys when replacing files, or invalidate the old CDN path when you need the same URL to show new content.
Exactly. A CDN solves delivery and caching, but it doesn’t know which images belong in a product listing. That relationship should come from the application database.