Nice post. You do however have to think about some way to invalidate content, otherwise when you change your foo.css file, Cloudfront will happily ignore and keep serving the cached version... So then you need to start adding some random parameter at the end so it looks like foo.css?d82347jslq ... or rename foo.css to foo_s398ls9cmp.css and this goes back to some kind of compiling of your static assets.
Also worth noting that CF doesn't always give you the lowest latency or overall best performance. If you know where your users are or serving a limited target geographic area, you might be better off serving it yourself with nginx from a close-by location. I once did a quick test with images. Serving them on CF took about 250ms on average, and from my own nginx server about 70ms if I remember correctly. The test was carried out from an EC2 machine, so couldn't have been that far off for Amazon to serve fast, yet my nginx server outside the Amazon network was doing a better job.
Regarding invalidation; this is a non-problem if you always keep unique URLs.
Interesting note there about a local Nginx vs. CF. I'm amazed that the difference was 70ms vs 250ms. However, the case is certainly worth keeping in mind, but I suspect it's rare. Most of my sites are hosted in the UK but the audience is mainly USA.
Validation: we always prefix our assets with something effectively corresponding to a deployment ID (usually a hash of the content being deployed). It's a lot easier than trying to manage it on a per-asset level, and makes it really easy to clean up old assets.
Response times: you might use something like Gomez to see your response time waterfall from various locations throughout the world. It's all about the PoPs. Depending on how CF is routing your request, you (specifically) maybe going a little farther to hit your content.
Comment
Nice post. You do however have to think about some way to invalidate content, otherwise when you change your foo.css file, Cloudfront will happily ignore and keep serving the cached version... So then you need to start adding some random parameter at the end so it looks like foo.css?d82347jslq ... or rename foo.css to foo_s398ls9cmp.css and this goes back to some kind of compiling of your static assets.
Also worth noting that CF doesn't always give you the lowest latency or overall best performance. If you know where your users are or serving a limited target geographic area, you might be better off serving it yourself with nginx from a close-by location. I once did a quick test with images. Serving them on CF took about 250ms on average, and from my own nginx server about 70ms if I remember correctly. The test was carried out from an EC2 machine, so couldn't have been that far off for Amazon to serve fast, yet my nginx server outside the Amazon network was doing a better job.
Replies
Regarding invalidation; this is a non-problem if you always keep unique URLs.
Interesting note there about a local Nginx vs. CF. I'm amazed that the difference was 70ms vs 250ms. However, the case is certainly worth keeping in mind, but I suspect it's rare. Most of my sites are hosted in the UK but the audience is mainly USA.
Validation: we always prefix our assets with something effectively corresponding to a deployment ID (usually a hash of the content being deployed). It's a lot easier than trying to manage it on a per-asset level, and makes it really easy to clean up old assets.
Response times: you might use something like Gomez to see your response time waterfall from various locations throughout the world. It's all about the PoPs. Depending on how CF is routing your request, you (specifically) maybe going a little farther to hit your content.