Don't upload assets (js/css) to S3 when using Cloudfront
Instead, just set a custom origin header on your Cloudfront distribution, and point it to your application.
Pros
- No need to pay for a S3 bucket.
- No need to upload assets to S3 during deploy.
- Possibly less gem dependencies.
- Possibility to serve gzipped assets depending on the Accept-Encoding header. (Why we moved to this solution at Mynewsdesk)
Cons
- Could mean slower initial requests if loading asset from a very remote location
- Need to distribute precompiled assets to all of your application nodes, if behind a load balancer.
Read more: http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support-for-custom-origins.html
Written by Richard Johansson
Related protips
2 Responses

We've used custom origin in a recent project and it is great!
It is worth noting that you should version your assets to avoid serving cached content from cloudfront.
Example
<link rel="stylesheet" href="http://yourcloudfronturl.com/content/style.css?v=1"/>

The other benefit is its easier to handle access-control-allow-origin issues with fonts and Firefox if serving from your app instead of S3