26

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?
Mike Richards
  • 5,557
  • 3
  • 28
  • 34

2 Answers2

18

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.

ceejayoz
  • 176,543
  • 40
  • 303
  • 368
  • 4
    Both are good solutions, but I think your second is perfect. Before the CDN, we appended "?v=2.0.x" (whatever the version number is) to all asset URLs for cache busting, but if we alter that to "stylesheet-v2.0.x.css" with CloudFront using our server as the origin, I think that'll work great. Thanks! – Mike Richards Jul 14 '11 at 18:03
  • Glad I could help! We got bitten by CF dropping query strings a few times before we wised up. :-) – ceejayoz Jul 14 '11 at 19:53
  • 3
    Invalidation has limits on the number of files that can be processed at once and can be slow, so the second solution is definitely better. – Kevin Borders Jun 29 '13 at 13:03
8

CloudFront has started supporting query strings, which you can use to invalidate cache. http://aws.typepad.com/aws/2012/05/amazon-cloudfront-support-for-dynamic-content.html

Mayank Jain
  • 2,995
  • 2
  • 23
  • 19
  • how, exactly do you use this to invalidate cache on a particular file? Perhaps it's in that link somewhere but it's not very clear. – gMale Aug 21 '13 at 17:06
  • when you activate query strings cloudfront caches the ressource for each parameter combination. so you could append a version. img.jpg?version=1 and ?version=2 for more details look into the manual http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/QueryStringParameters.html – Dukeatcoding Feb 16 '15 at 16:19