I recently switched this site from WordPress to be static pages stored on Amazon S3. I had significantly more problems than I anticipated with hosting a simple static site. This is my story.

Why static?

Every static site generator out there has a section header on their front page posing essentially the same question. While I don't particularly want to duplicate this list, I did want to spend a moment and speak to my own motivation for doing so.

• No server needed! - I've been using WordPress basically since I started blogging, so about 4 years on and off. During that time, I had to find a place to host my blog that had PHP and MySQL installed. I moved from shared hosting to hopping AWS Free Tier accounts for a while, which has been getting old for a while now. I chose S3 specifically because it was a service that is far more available than I could accomplish by myself and is far simpler to use. Plus, the cost of a little bit of storage in S3 is stupidly cheap compared with running an EC2 instance or in a dedicated or shared host at any provider.

• Security - With a CMS, it's very important to keep your systems patched. You have to worry about things at a platform level (for me: OS, PHP, Apache, MySQL) as well as the application layer (and don't forget about all the plugins!). With static hosting via S3, I have nothing to worry about except keeping my AWS credentials safe. Reducing this exposure was important to me as I don't have time to keep up on vulnerabilities at all these layers.

I'm sure there are plenty of other benefits, but I was already sold.

Pitfalls

As I said earlier, I hit quite a few more snags (and used a few more workarounds) than I anticipated when initially evaluating S3. Below are the major ones I encountered, hopefully I can help someone avoid these in the future.

• Lack of CloudFront aliases in Route53 - This was a bit of an issue for me as I used to host my blog off the domain apex (whatan00b.com). I had to add a 'www.' in front to make this work properly using a CNAME. Of course, less than 24 hours after I post this I get an email in my inbox saying this feature was released.. :)

• Lack of solid on-the-fly compression support - I greatly misunderstood this one at first. S3 does support serving gzip-compressed content, however you have to upload and link directly to the gzipped files. You essentially just gzip your HTML, CSS, etc files and serve them up directly, hoping that every single client that connects supports gzip. This probably isn't a terribly unsafe assumption with browsers, but I am a little worried about crawlers, not wanting to cause issues with SEO, etc. It may be a non-issue, but certainly something to consider carefully. For now I have opted to leave things plain.

• CloudFront does not forgive. CloudFront does not forget. Expect CloudFront. - CloudFront can cache things for a while, which is of course a big part of why it's awesome and useful. Unfortunately, if you cache badness, badness lives on for a while. In my case, I changed the site to use "www." and changed the S3 bucket redirects in the correct order, but I did forget to change the origin for my CloudFront distribution to use the new bucket without a redirect. This caused infinite redirect loops for the site at various places throughout the world, but not all. It was impossible for me to catch without a tool like Pingdom. This took a couple of invalidation requests, but seems to have quieted down for me now.

• Don't set CloudFront to front-end your S3 bucket directly - CloudFront does have the option to use an S3 bucket as the origin when setting up an origin. This works great if you aren't concerned about needing the index option or error document. To get both of those to work properly, use the endpoint URL from the Static Website Hosting setup section for the S3 bucket instead.

Performance

I use Pingdom for monitoring my website (and would highly recommend it), and saw some weird results when switching to the static site hosted on S3. The average response time globally went from ~500ms with WordPress on a single EC2 micro instance to ~700ms with S3. I would probably blame lack of gzip on this, but didn't take the time to properly investigate. CloudFront far more than made up for the performance difference. After the switch, the response time hangs out just above 150ms for a worldwide average.

Cost

I've been running the site on S3 + CloudFront for just shy of 10 days and so far have racked up a giant bill of 28 cents. Around half of that was due to a stupid amount of PUTs I generated when experimenting with deployment tools.. Oops. The pricing can't possibly compete with trying to run cloud systems on my own, and performance (and price!) is far better than any shared provider I have found.