How I serve my site using only CloudFront, S3, and a few small tools(blog.andrewvc.com)
blog.andrewvc.com
How I serve my site using only CloudFront, S3, and a few small tools
http://blog.andrewvc.com/how-i-switched-to-using-only-s3-and-cloudfron
6 comments
You can do that, but it's a pretty bad idea.
Cloudfront will server your content anywhere in the world with a latency of 43ms. S3 latencies range between 200 and 800ms, which is not particularly suitable for delivering web content.
For the privilege of this faster delivery, it will take you 30 seconds in your AWS tool of choice, and will roughly double your monthly bill (thus potentially pushing you above the $1/month barrier.)
I'm sure there are levels of laziness and thriftiness for which serving straight from s3 seems attractive, but off the top of my head I can't think of any.
Cloudfront will server your content anywhere in the world with a latency of 43ms. S3 latencies range between 200 and 800ms, which is not particularly suitable for delivering web content.
For the privilege of this faster delivery, it will take you 30 seconds in your AWS tool of choice, and will roughly double your monthly bill (thus potentially pushing you above the $1/month barrier.)
I'm sure there are levels of laziness and thriftiness for which serving straight from s3 seems attractive, but off the top of my head I can't think of any.
In the past, S3 was required for SSL, but I hear they've fixed that now. CloudFront is pretty sweet...
> Doing so I wound up saving money, and increasing my site's load times as well.
Well, if that's what you want...
Personally, I serve my site by putting files on a computer running Apache.
Well, if that's what you want...
Personally, I serve my site by putting files on a computer running Apache.
Hehe, I meant 'improving' not 'increasing'.
I'll admit it's less convenient in some ways, but not significantly so.
At any rate, it being my personal site, I'm going to make experimental engineering decisions. I like the aesthetic of S3 and CF as an ultra-minimalist deployment stack. If all I wanted was 'easy' I'd have stayed w/ my VPS at Rackspace, or gotten a Dreamhost account.
You'd probably be crazy to do this in production for a real site however, at least until cache invalidation with CF gives you more control.
I'll admit it's less convenient in some ways, but not significantly so.
At any rate, it being my personal site, I'm going to make experimental engineering decisions. I like the aesthetic of S3 and CF as an ultra-minimalist deployment stack. If all I wanted was 'easy' I'd have stayed w/ my VPS at Rackspace, or gotten a Dreamhost account.
You'd probably be crazy to do this in production for a real site however, at least until cache invalidation with CF gives you more control.
Have you thought about uploading the index.html with a version number ( index_12345.html ) and all the support files (css, js, etc) in a directory like 'support_12345', then just changing the DRO in cloudfront?
That might make the updates faster while not requiring you to set a low cache value.
That might make the updates faster while not requiring you to set a low cache value.
Yeah, definitely thought about it. It probably makes more sense, however it's a bit more of a pain since you have to re-upload everything to that folder. However, it's probably a better way of doing things in terms of invalidation, as visitors either get site version X, or Y, instead of a potential mishmash of both if you invalidate only some part of it by mistake.
Just did an experiment out of curiosity.
Once you change the DRO it takes about 3-5mins for the changes to be visible on the cloudfront url, another advantage seems to be that once the served version is updated you no longer get the previous version.
Also it seems you cannot change the DRO if an update of the distribution is in progress ( i.e. you cant change it twice in quick succession. )
Once you change the DRO it takes about 3-5mins for the changes to be visible on the cloudfront url, another advantage seems to be that once the served version is updated you no longer get the previous version.
Also it seems you cannot change the DRO if an update of the distribution is in progress ( i.e. you cant change it twice in quick succession. )
I'm a little surprised how slow the initial image loads are (the download is choppy; kind of reminded me of my old 56k connection :)). Obviously, once the cache is warmed it's much better, but it's not like they're huge files.
I really see no benefit to doing this as opposed to using shared hosting or a cheap vps (prgrm's smallest is like 8 bucks right?) ... nevermind that, doesn't amazon have a free tier right now for aws?
Wow, I hadn't checked Prgrmr's rates in a while. Their smallest is now $5 for 64MB of ram, and for $20 you get 1GB.
http://prgmr.com/xen/
http://prgmr.com/xen/
Why don't you just host it on github pages or similar? With a CNAME entry it would be seamless.
Surely there are simpler and cheaper (free?) solutions than this.
Surely there are simpler and cheaper (free?) solutions than this.
It's my personal site, experiments like this are why it exists :)
As far as costs go, my Rackspace VPS was $11/mo. Given that I get close to zero traffic and CF is $0.15/GB, this will cost less than $1/mo. I'd say that's a pretty good price for having my site hosted on a high performance CDN with points of presence worldwide.
As far as costs go, my Rackspace VPS was $11/mo. Given that I get close to zero traffic and CF is $0.15/GB, this will cost less than $1/mo. I'd say that's a pretty good price for having my site hosted on a high performance CDN with points of presence worldwide.
One big(?) problem with this: really ugly 404 pages -- http://www.andrewvc.com/asdgadf
However, S3 doesn't have default root object support, so you do need CloudFront if you want http://mydomain.com/ (vs http://mydomain.com/index.html) to return an object instead of an error.