3 ms·

You're not done. You've done 99% of the work to get your images serving quickly to your users, but then you stopped. Why??? Cloudfront takes exactly four min

You're not done. You've done 99% of the work to get your images serving quickly to your users, but then you stopped. Why??? Cloudfront takes exactly four minutes to set up, and it's a full-blown CDN. Nobody, not even Amazon, recommends serving content directly from S3 anymore. Either this article is 2 years out of date or the author doesn't understand his subject as well as he thinks.

brlewis 16y ago
For whatever reason they want to serve arbitrary sizes on the fly. They do mention cloudfront in their future optimizations section, but complain about the price of CDNs in general. Cloudfront looks awfully cheap unless I'm missing something.
- ant5 16y ago
  For whatever reason they want to serve arbitrary sizes on the fly. The primary advantage here is that you don't have to coordinate generation of new images just because someone, somewhere requires a specific size in some client of your image system. Of course, just stick a CDN in front of your on-demand scaling implementation, potentially backed by S3, and you're done.
  - swindsor 16y ago
    We wanted to be able to serve arbitrary sizes so we can handle different demands for thumbnails and new use cases. Having to resize all of your images because you've re-designed your homepage sucks, and is no fun (especially if you have a large set of images). Cloudfront is really enticing, though. For a cheap CDN, if we really had the need, we'd probably migrate to cloudfront, then come up with a task to batch resize our S3 images, then stick them back into S3. This could probably be done on a one-off task on ec2 by spinning up a few instances, or even with Hadoop. If anyone's taken this approach, I'd love to see it!
- jasonkester 16y ago
  Unless their business revolves around serving arbitrarily sized versions of user images, they're probably doing that wrong too. The "solved" way to deal with this is to generate all the sizes your app will need and store them on the CDN. Resizing images is pretty much the most expensive thing you do in a run-of-the-mill web app. Best to do it once and be done with it, especially now that cloud storage is so cheap. And speaking of cheap, Cloudfront is as close to free as S3 itself. It will roughly double your S3 bill, leaving you paying a grand total of $8.04 per month for your image hosting on a ~1,000,000 unique/month site. Remember the 90's when that would run you $400/month? It's so cheap that it's not worth calculating. Just flip on Cloudfront, configure your CNAME and get on with your life.

brlewis 16y ago

For whatever reason they want to serve arbitrary sizes on the fly. They do mention cloudfront in their future optimizations section, but complain about the price of CDNs in general. Cloudfront looks awfully cheap unless I'm missing something.

ant5 16y ago
For whatever reason they want to serve arbitrary sizes on the fly. The primary advantage here is that you don't have to coordinate generation of new images just because someone, somewhere requires a specific size in some client of your image system. Of course, just stick a CDN in front of your on-demand scaling implementation, potentially backed by S3, and you're done.
- swindsor 16y ago
  We wanted to be able to serve arbitrary sizes so we can handle different demands for thumbnails and new use cases. Having to resize all of your images because you've re-designed your homepage sucks, and is no fun (especially if you have a large set of images). Cloudfront is really enticing, though. For a cheap CDN, if we really had the need, we'd probably migrate to cloudfront, then come up with a task to batch resize our S3 images, then stick them back into S3. This could probably be done on a one-off task on ec2 by spinning up a few instances, or even with Hadoop. If anyone's taken this approach, I'd love to see it!
jasonkester 16y ago
Unless their business revolves around serving arbitrarily sized versions of user images, they're probably doing that wrong too. The "solved" way to deal with this is to generate all the sizes your app will need and store them on the CDN. Resizing images is pretty much the most expensive thing you do in a run-of-the-mill web app. Best to do it once and be done with it, especially now that cloud storage is so cheap. And speaking of cheap, Cloudfront is as close to free as S3 itself. It will roughly double your S3 bill, leaving you paying a grand total of $8.04 per month for your image hosting on a ~1,000,000 unique/month site. Remember the 90's when that would run you $400/month? It's so cheap that it's not worth calculating. Just flip on Cloudfront, configure your CNAME and get on with your life.