Question

Our current plan for a site is to use Amazon’s Cloudfront service as a CDN for asset files such as CSS, JavaScript, and Images, and any other static files.

We currently have 1 bucket in S3 that contains all of these static files. The files are separated into different folders depending on what they are, “Scripts” are JS files, “Images” are Images, etc yadda yadda yadda.

So, what I didn’t realize from the start was that once you deploy a Bucket from S3 to a Cloudfront Distribution, then every subsequent update to the bucket won’t deploy again to that same Distribution. So, it looks as if you have to redeploy the bucket to another Cloudfront instance every time you have a static file update.

That’s fine for images, because we can easily make sure that if there is a change to an image, then we just create a new image. But, that’s difficult to do for CSS and JS.

So, that gets me to the Best Practice questions:

1. Is it best practice to create another Cloudfront Distribution for every production deployment? The problem here would be that causes trouble with CNAME records.
2. Is it best practice to NOT warehouse CSS and JS in Cloudfront because of the nature of those files, and their need to be easily modified? Seems like the answer to this would be NO because that’s the purpose of a CDN.
3. Is there some other method with Cloudfront that I don’t know about?

Answer 1

You can issue invalidation requests to CloudFront.

http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

Instead of an S3 bucket, though, we use our own server as a custom origin. We have .htaccess alias style_*.css to style.css, and we inject the file modification time for style.css in the HTML. As CloudFront sees a totally different URL, it’ll fetch the new version.

(Note: Some CDNs let you do that via query string, but CloudFront ignores all query string data for caching, hence the .htaccess solution.)

edit: CloudFront can be (optionally) configured to use query strings now.