Question about Amazon's Cloud Front with regards to Rails app w/image uploads

Newbish AWS question: Our Rails app currently allows image uploads via Carrierwave to an S3 bucket. Things work well...but it's starting to get a bit confusing (and cumbersome) as some original files are in one bucket (uploaded photos) while others are in another bucket (site logos, etc) while still others (javascript & css) are served directly from the Rails host.

We're looking at Cloud Front to possibly help consolidate & simplify our delivery...but none of us have any prior experience with it. Once properly configured (with a custom origin) can/should we expect to bring all assets back to our local server and then "simply" rely on Cloud Front for delivery? This would mean bringing all the uploaded images (currently on S3) back down to the local Rails server and instead of using Carrierwave with the Fog gem to upload them we just process & store the files on the local filesystem. This would have many advantages, chief of which is we'd have a complete copy of the entire application, including all assets, locally on our hosts.

Also, can we expect delays on a new image being served after it is uploaded...beyond what happens currently where there is a slight delay after processing an uploaded image as it is uploaded to S3 via Fog?

Lastly, is/would there be any reason to keep our S3 buckets alive? I understand "unused" assets are purged from CloudFront but it's not clear, to me anyway, what metric defines "unused".

Is this a common use case? Mostly just looking for validation or a told-you-so.

Thank开发者_如何学运维s!

As far as the carrierwave s3 using cloudfront, I wrote up a blog article on exactly how to do this. (It's super easy to get the cloudfront part to work if you already have s3 working) http://jeffdickey.info/using-carrierwave-on-heroku-for-image-uploading-w-cloudfront

And on the js/css asset notes, if you're using rails 3.1 asset pipeline, all you need to do is go into your production.rb file and set your asset host to a cloudfront cdn that points to the rails server.

I like to use content.domain.com and assets.domain.com for these 2 cdns.

No need to upload your js/css assets to S3, then serve them from CloudFront, just serve them directly. CloudFront will handle the caching for you.

Two suggestions:

1) Use jammit and jammit-s3 to manage your assets and deliver them to cloudfront. In development your assets are on your local filesystem but on deploy you push to cloudfront. The s3 gem is smart enough to check which files have changed etc. I'm not sure how this will be affected by rails 3.1 but it has worked well for me on 3.0.

2) Use cloudflare. This service is incredibly exciting and aside from the security benefits also caches your static assets and delivers them using their own cdn. Surprisingly there is a free service which does mostly everything most of us need, though I don't know about your app's requirements. Highly recommended you check it out.

Regarding bringing the uploaded images back to your server there are a few things to keep in mind:

• Instead of paying for storage in one bucket you will potentially be paying for several cloudfront edge locations(about 20 of them at the moment). On the other hand you will only be paying for files that are actually used and the location where your users are, so the difference depends on how your files are used.
• If a file is changed you need to change its name or your user may not see the change, maybe you already solve this by giving uploads unique names.

There is no significant delay in serving, if a file is missing from an egde location Cloudfront will simply fetch the file from your server, forward it and store it for the next time it is accessed. So if a file is purged it does not really matter as Cloudfront will just fetch it again if needed.

As for your other files, since you are using Rails 3.1 with the asset pipeline it is pretty easy. I have documented my set up here:

http://blog.ertesvag.no/post/10720082458