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.
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.
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'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.