Hosting a blog on S3 for pennies a month

Wordpress is great, but it isn't free...

I'm no expert in authoring great online content (clearly), but I do know a thing or two about common blogging software. If you have something you want to say online, you only have a few choices. Either you pay a monthly fee to host (or join) a blogging platform such as Wordpress, or you swim with the swarms of people posting on social media.

There's nothing wrong with firing up a free tumblr or the like, but then it isn't really your content, is it? They literally own it, and you're just a small cog in a vast machine.

Maybe your content is more likely to be seen and discovered within that machine, but you sure as hell don't own it. You also need to understand how that machine works -- which, let's be honest, is just exhausting. I don't want to know how to make my tweets (or "exes" or whatever the hell they're called now) reach more people and get more likes.

Google might not be any more equitable in ranking content such that any human actually reads it, but at least it's mine. Does that count for something? Probably not, but it's more fun for me to build it myself, anyway!

With this system, I can avoid paying a hefty fee for servers or a platform fee, while still owning my content on my domain.

I value my own opinions...but I don't want to pay $20 or so each month just to host some text! It'd rather pay less than a dollar per month.

The Solution: throw it on S3!

I know it's cheap to host content on S3, and I know that CloudFront can be used to easily cache requests to the S3 bucket. So...let's use that, why not?

Yes, I get that I'm still paying one of those evil villain corporate overlords, but at least it's far, far cheaper this way. Even with decent traffic, static pages will scale easily.

CloudFront will cache requests, reducing the number of hits against S3. I don't need comments or other dynamic features, and even if I did, I know I could power them with javascript additions like Disqus. I don't need a complicated CMS, so I can rig something up in Laravel in a day or two.

The best part is that I don't need a host at all -- my Laravel editor can run locally, pushing static files to S3 for easy and secure updates. It wouldn't be hard to back up my database, and I don't need to worry about exposing a notoriously insecure Wordpress backend to the interweb.

Why not use "static hosting"?

S3 has a simple, built-in solution for activating static hosting on any bucket. Unfortunately, it does not allow for SSL-enabled custom domains as of yet. I

expect that someday (hopefully soon?) that will change and it will be far easier to utilize this great option...but sadly, today is not that day. As with many things Amazon, you can still utilize S3 to efficiently host simple static content, but not without some extra steps. In this case, you'll need to set up a CloudFront distribution.

How the app works

The simple laravel app powering this blog is really no more than a day's coding. It has a simple database table storing each article and builds and uploads a simple static page when pages are created or updated. It also rebuilds the article "index" page. There's a bit of boilerplate, but nothing too intricate.

I opted for a single "Article" model and controller and used a pair of services to handle uploading to AWS (although Laravel's built-in abstractions make this a one-line method call anyway) and building the static article file.

I may not be unique, but a good idea is a good idea

There's plenty of other people that have already implemented this idea with varying levels of sophistication, but it's still fun to do it myself!

I do believe that being able to publish simple text on the Internet is a great thing that shouldn't be locked away in expensive hosting fees, mountains of legal agreements, or surrendered to a few evil overlords. I encourage anyone reading this to set up a similar system as a fun project...well, it was fun for me.

How to set up a simple static site on S3 with a custom domain

As with many things Amazon, documentation is scattered, often out-of-date, and sometimes incomplete or contradictory. That's the nature of having such a dizzyingly complex cloud product (I guess).

This is how I set up my custom domain to serve a static site from an S3 bucket. Just...do some Googling yourself, especially if you find this article in some dismal distant future. Things often change, especially in a cloud platform like AWS.

1. If you're registering a fresh domain, think about hosting it on Route53. It's slightly easier to stay within Amazon's ecosystem. Vendor lock, baby!
2. If you plan to host content on your root domain, you actually have no choice but to host the domain on Route53.
3. You must use a CNAME to host the static site otherwise. In my case, I used "articles" as the subdomain.
4. Create a certificate for your custom domain in AWS Certificate manager. This is required before you can create a Cloudfront distribution using a custom domain.
5. You'll likely need to add a DNS entry to verify your domain ownership (if not in Route53).
6. Create a CloudFront distribution -- be sure that the CNAME you use matches the certificate you requested in the previous step if using a custom domain. Be sure to select the certificate you created in the previous step, too (you'll get an error if you try to add a CNAME without the cert, anyway)
7. Use the default "Origin access control" for "Origin access"
8. Choose "Create control setting" leave the default "sign requests" enabled
9. Scroll down and click create -- on the next page, you'll see that AWS provides you with a security policy. You will need to copy/paste this policy when creating the S3 bucket in a later step.
10. Be sure to add your custom domain as an "Alternate domain name", and select the certificate you created previously.
11. Note: if you see access denied errors, be sure to double check the origin access control setting (I've seen it revert to 'public' when making edits to the distribution)
12. Copy the CloudFront "distribution domain name" (it will look like a URL), then go back to your registrar and add a CNAME to that cloudfront distribution name.
13. Create the S3 bucket.
14. Under permissions, copy/paste the security policy created by CloudFront
15. Check it! The DNS should resolve eventually and serve your static content.
16. Caveats: if you have a directory (such as /articles) and have an index file within it, accessing "/articles" will not work! Only "/articles/index.html" will resolve.
17. This is very easy to fix by setting the default root object, although slightly more involved if you want to use a subdirectory

Can't you still use Wordpress for this...?

Yes, you could definitely create a plugin that hooks into post creation and creates static files. I just might make a plugin that does that!

That said, there's obviously more complexity and caveats when trying to construct static pages with Wordpress. No server-side functions will work, but that's just fine for many use cases.

Personally, I felt using Laravel was faster, easier, leaner, and more fun.

Site not updating? Invalidate your CloudFront Cache!

The only downside to using CloudFront to cache requests against S3 is that it...caches your content. If you publish an update to an article, you might be dismayed to see it isn't refreshing no matter how much you spam.

Drill into your CloudFront distribution and click on "Invalidations". In the path, use "/*". Or use your own path, if you want to be more granular. You're (probably) an adult, make your own choices! It wouldn't be hard to implement an API request that auto-invalidates the cache if you really need it.

In theory, this solution could actually scale fairly well, but the main downside comes down to the simplicity of the Laravel-based editor. That said, enriching it with features typical to most blogs sounds like a fun project for the future.