I personally don't like the default theme that Octopress comes with, so after I tried rolling with Octopress I digged deeper and made a custom Jekyll Site. Awesome learning experience and dead-simple deploy
To expand on this, you can easily host your Jekyll blog (or any static site) on Amazon S3 and use CloudFront to serve assets. I would imagine this will be more reliable than Heroku and is certainly less complicated than the OP's setup. Unless you have an enormous amount of traffic or huge assets, S3+CloudFront will be essentially free (dollars per month, if that).
A pure static solution like Cloudfront doesn't allow dynamic behavior. One incredibly useful use-case is having redirects, because your content moved around, after a cleanup, or a migration, or something. HTTP redirects are useful for moving the Google juice you received on your original link, doing Javascript-redirects does not work in the same way.
So I like the idea of a static site, but sometimes you really need dynamic behavior. Also, I hate the www. prefix for some reason. I think it is obsolete. It's just an opinion, but I hate that Google's App Engine or Cloudfront doesn't let me go naked.
The problem is that the DNS RFC (RFC1033) requires the "zone apex" (the naked domain) to be an "A Record," not a CNAME. And these services insist on CNAME. It is understandable why, because CNAMEs scale better and a CDN (for instance) couldn't function properly with A records, but I hate this situation it nonetheless. In my view, root domains should be used naked, not with the "www." prefix.
Another easier solution to this would be hosting with a service like http://nearlyfreespeech.net. They're pay-by-usage like AWS, but you get full Apache config abilities + dynamic pages if you need them.
I've noticed that with a micro instance a blog can became irresponsive when it is indexed by Google.
Probably with a static blog a better solution is to use S3 and not ec2 as I've used.
Heroku limits you to one dyno, which is equivalent to one server instance (mostly to one server process). So if your app is serving requests from Ruby, then on the Bamboo stack at least it can only serve one request at a time. For static content this doesn't bother me though, as on the Bamboo stack you also have Varnish, which has great async behavior a really good performance for serving static assets.
GAE has daily limits. For instance you have 28 frontend instance hours, which get depleted quickly when using multiple instances. You also have a 1 GB bandwidth limit, which apparently is really insufficient for serving images bigger than small logos (looking at their dashboard now). And the list goes on. It's OK for low to medium traffic, if you're not doing lots of background processing and if you're not serving big files.
AWS's free tier allows for renting a micro-instance for a whole year. However the micro instances, as I discovered, have really poor performance characteristics. They work in bursts of available CPU. So one minute they may have better performance characteristics than the next instance type and the next minute a micro instance can get completely frozen with pending activity.
I don't like AWS micro instances. You're much better off paying for a small Linode instance, something like $20 / month.