Your post does not say it, but the title does that your end goal is to serve assets using CloudFront. I do exactly the same, skipping the S3 for assets altogether.
You can create a distribution with origin being your own server, and not S3, and you can configure it to be cached on CloudFront. Effectively the asset is then downloaded to CF once, cached there, and your app does not need to do anything special. Maybe that suits your use case too
@hubertlepicki@jaysoifer Could you please shed some light on the method of using Cloudfront without uploading the assets on S3? When I go to the “Create distribution page”, from the “Origin Domain Name” dropdown, I am only given the options to select an existing S3 bucket, or an Elastic Load Balancer (which I don’t have). I’m currently using Heroku. Thanks a lot!
I see. To answer your question: I have none of these. Assets are just bundled with the app and are served statically from the same Heroku instance. I do have a ServiceWorker that caches the assets locally, so I’m simply interested in optimising the first hit for users without SW cache.
After a bit of research, it seems that Heroku discourages uploading to S3:
Many developers make use of Amazon’s S3 service for serving static assets that have been uploaded previously, either manually or by some form of build process. Whilst this works, this is not recommended as S3 was designed as a file storage service and not for optimal delivery of files under load. Therefore, serving static assets from S3 is not recommended.
Interestingly, in the same article, they say:
You should type the domain name for your application as the 'Origin Domain Name’. By default, Amazon shows a list of your S3 buckets. This value can be overtyped.
I’m going to give that a go when I have a chance and will post if I make it work.