Serving up a static website using S3 and Cloudfront involves a few tricks, but ultimately it is worth it to get their distributed content network working in your favor.

So here's the skinny on how it's done. Not too long ago you could have your S3 account on the web as, say, michael.lucassmith.website.s3.amazonaws.com however, if you went to / you would get either access denied or a listing of files, depending on the ACL of the s3 bucket. You could go to /index.html and get the website. The problem is, everyone expects to be able to go straight to / and get the website.

Along came Cloudfront, which promised to distribute your s3 bucket to its different data centers around the USA (and may be the world one day) automagically for you, to make your site as fast and efficient as possible. Pretty cool, however it too didn't solve the / problem. So what good was it?

Luckily, they recently fixed up this problem by adding a DefaultRootObject property. To set it, you have to twist your arm inside out -- or you can find a few applications that let you specify it in a GUI (don't bother with Amazon's console, as of this writing the option doesn't exist there).

Two that I found that did it on the Mac (BerryExplorer does it on Windows) are Cyberduck and Bucket Explorer. Cyberduck is pretty slick, but when it comes to dealing with S3.. get Bucket Explorer. Why? Because it's not just the default object you need to set, but there's also this concept of 'Invalidation'.

Cloudfront takes your files from s3 and spreads them around to its data centers for fast access. This takes time and they want to do it as a single transaction to avoid half-updating your website. If you make a change to your s3 account, you often don't see that change reflected in your website for hours at a time. Recently, Amazon added a low level invalidation API which you can use to tell it to synchronize files from you S3 bucket around the cloudfront. Bucket Explorer has a UI interface for doing this, so, another big thumbs up there. Instead of waiting hours, you wait minutes.

The final piece of the puzzle comes from godaddy.com for me. I've used them as my domain name registrant for many years now and I won't complain too much about their service. Today I hit a particular complicated scenario. Once you have cloudfront set up, you're given a bizarre domain name for your website. In my case it was d5eqjnoai3ca7.cloudfront.net. You can point a CNAME dns record to this address, but not an A record, because A records must point to an IP address.

After struggling with Total DNS Control for a while, I finally found my answer. You must park your domain at godaddy to enable TotalDNS, then delete all the CNAME records and the A record in the Expert/Advanced mode. Add in your www CNAME to point to the cloudfront domain. This makes www.michaellucassmith.com work, but what about michaellucassmith.com ? .. it was broken, so how do you fix that? you add a domain forwarding rule back on your advantage domain management page. You forward your main domain to the subdomain, in my case michaellucassmith.com -> www.michaellucassmith.com.

Finally, the whole thing is up and running. Now it's just a matter of me writing more blog posts and adding new content. The good news is, the cloud just keeps on getting better. When I wrote my new blog four months ago, this configuration was not option - a few months later not only is it an option but software has caught up enough to make using it palatable.