If you’re reading this, then my site is now being served purely from AWS and I didn’t completely screw things up!

Since starting this blog, I’ve been running it on a WordPress installation hosted on a shared server with SiteGround. There has been nothing particularly wrong with this setup and the one time I had to contact SiteGround support they were pretty decent. That being said, I’ve decided to move it all to AWS. This post will take a look at the “why” of my decision. There were a few small hiccups during my migration - but none that caused any downtime. I’ll review these challenges and provide more information on the “how” in another post soon.

Why move the site?

As I said, I’ve not had any particular issues with my previous setup. SiteGround has been decent enough and WordPress has served its purpose to help get a site up and running for someone who isn’t a web developer. I recently helped a friend get his site up and running in AWS in order to move away from a ridiculously overpriced service they were paying about £50 a month for. After some thought I decided to do this by running some static HTML out of an AWS S3 bucket that was fronted by CloudFront (primarily for TLS termination). It worked well so I figured - why not do the same for my site.

There seem to be more and more sites moving to hosting static content (i.e plain HTML, not dynamically generated content using PHP for example). This comes with its own pros and cons. I’ll explore some of the more relevant ones for me below.


A bit of a no-brainer here. For my previous SiteGround subscription I was paying just shy of £50 a year. Not exactly bank-breaking, but probably unnecessary for such a low-traffic site (small violin playing in the background). I’m not really sure what my AWS costs are going to be yet because it’s currently costing me 0 as part of the free-tier, but I believe it will work out a fair bit cheaper.

Maybe not a great saving for me, but for my friend who was paying just shy of £50 a month to get some web presence this is a significant saving.


I went to the effort of ensuring (to the best of my capabilities) that my WordPress site was secured. This included things such as applying the relevant htaccess settings, installing WordFence for a basic WAF, adding 2FA, updating frequently and even some security through obscurity by way of changing to a random admin name (along with auto blacklisting for incorrect attempts). Even with all these measures though, I was never left with a very warm fuzzy feeling.

WordPress and its plugins are somewhat renowned for issues with frequent vulnerabilities. Granted, I was careful which plugins I used and updated all the time, but I was always left wondering what undiscovered issues lurked. Moving to a static HTML-based site gets rid of a lot of my responsibilities. There is no dynamic server-side processing I have to worry about now - all you can do as a user of my site is simply perform a GET/HEAD on my static HTML code.

Static HTML doesn’t remove all vulnerabilities from a solution - you still have to take care of the lower layers such as Apache/IIS and server OS. But by using S3 buckets and CloudFront I needn’t concern myself with this either - under a cloud “shared responsibility model” it’s AWS’s responsibility to maintain this (and lets face it they will probably do a better job).

It is still my responsibility to take care of the security of my AWS account and the relevant bucket/CloudFront policies, but even then (in reference to bucket policies), there isn’t much cause for concern as only non-sensitive public content for my site (in the form of HTML/CSS/images etc.) is hosted in my bucket (that being said you can’t access directly anyway and must traverse CloudFont).


With my old hosting setup, I only had a single server on which I was hosting. Yes, I had some backups, but I’d probably have been scrambling around if I needed to restore it all. Static HTML makes it a lot simpler to restore should the absolute worst happen. I store copies of the HTML locally and in a Git repository.

The chances of that failure scenario ever occurring are hopefully very rare as well. S3 and CloudFront are both resilient, fault-tolerant solutions offering outstanding SLAs (99.9% on both I believe). If either of those were to completely go down there would be much bigger problems than my little blog!


Perhaps not one I need to be too concerned about! I don’t see demand for my blog drastically taking off and causing capacity issues, but if it does then I’m covered. S3 and CloudFront will scale to meet my demand and grow as my site does. Granted, I’ll start paying more for the service if that happens but still, it is good to know I have the ability just in case.


Again, not one high on my list of priorities given the site type and usage, but worth thinking about for larger sites. Most PHP sites (such as those provided by WordPress) dynamically generate the HTML on the fly as the client request comes in. This increases the time to first-byte back from the server and subsequently causes pages to take longer to load.

With static HTML - the content is there, just waiting to be served back to the browser. No additional delays. Probably completely unnoticeable to your average user on on a site like mine, but for larger sites this could mean significant differences. In addition to this, CloudFront provides caching closer to users, meaning subsequent requests can be served from cache at one of AWS’s edge locations. Not the reason I chose to use the service, but a bonus nonetheless!

The downsides

It isn’t all silver-linings when it comes to this cloud! There are a few things I quite liked with my WordPress setup that I’m losing by moving to a static HTML site (at least at the moment anyway).

Loss of control over security headers

On my previous platform I had a number of security headers set such as HSTS, CSP, X-XSS-Protection, X-Frame options etc. Out of the box with S3 and CloudFront I don’t have these as options so unfortunately I now don’t have these.

I made the call to lose these for the time being as I need to move off my old platform so I don’t have to pay for a renewal. I intend to have a look at seeing what is possible around this using something such as Lambda functions integrated with CloudFront - I’m sure I’m not the only one with this requirement.

No more comments

On my previous site I was utilising the in-built WordPress comment system to allow people to comment on my posts for corrections/opinions. This was reliant on the backend WordPress database and dynamic nature of PHP. Now I’ve moved to a static site I can’t do this as easily. So, what are my options?

  1. 3rd-party system - I could utilise a 3rd-party system such as Disqus to embed a comments system as external JavaScript. I did consider this with my original site, but decided to steer away from it from a privacy and simplicity perspective.
  2. Social media - I could just Tweet links to my blog and allow discussion to take place there. Not a very nice solution though and means comments get lost in the ether over time.
  3. Some other solution - Using what I know of AWS services I believe I could get a comments system up and working using a combination of API gateways and Lambda functions.
  4. Don’t allow comments - Just forget about them and chat to myself!

Given the relatively low number of comments I’ve had since the site has been running, I am opting for option four to start, with a view of implementing something based on option three at some point in the future (more out of interest than necessity).

No email subscriptions

I previously provided the option to subscribe to my blog for email alerts by way of an integration with the Jetpack plugin. Again, with a static HTML site I don’t have this luxury out of the box. Given I had a grand total of three subscribers (no, it wasn’t myself, my wife and my Mum!) I can probably cope without this for the time being.

As with the comments approach, I intend to integrate with native AWS services in the future - something probably using AWS’ Simple Notification Service (SNS).

Bye-bye WordPress

Despite the negative publicity it gets (of which I’ve not helped in this article) WordPress is a great little CMS that has helped numerous people get sites online who otherwise may not have. As I said before, I’m not a web developer and I know limited HTML/CSS - so something like WordPress has been ideal.

So how did I get this up and running? Have I quickly skilled up in HTML and coded my site from scratch? No. I chose to use a tool written in Go called Hugo and built my site that way (more on that in the next article). Whilst this has been pretty easy for me to get on with, it is not necessarily as easy to get on with for your average non-tech user. WordPress (once setup) offers a level of simplicity that makes it easy for techs and non-techs alike to use.

Static HTML sites that are decoupled from their CMS are becoming increasingly popular and as such there are CMS solutions (such as Forestry) available now. Again, we will look at that a bit in the next article.

Other changes

As part of changing the platform used to build the site, I had to pick a new theme. I went for a theme that offered a much cleaner and simpler interface (it is dark by default too - who doesn’t love a good dark theme!). Less pointless images, more content. Better for hosting costs, page download and my time.


I’m keen to hear any opinions on the new look and feel - good or a pile of steaming dung? Obviously you can’t submit your thoughts in a comment as I scrapped that, so Twitter, LinkedIn or Email will have to do for now :)