I have been a WordPress user for years now but up until now have always relied on others for the hosting duties. I am a big believer in learning through doing so it was an easy decision to supplement the training I was doing for AWS with self-hosting a WordPress blog, especially as I wanted a new platform specific to my role as a Solution Architect. While it is super-easy to take the Bitnami WordPress AMI from the AWS Marketplace and be blogging within minutes I wanted to do it the manual way to help the learning process, and this blog is the end result.
I started with a fully redundant setup, doing what a good architect should do and ensuring that in the event of failure in any component the site would stay up. I opted to keep images in a dedicated S3 bucket and this is made available to any instances that are spun up, the resulting design for hosting WordPress on AWS looked like this:
This design worked a treat, but I soon realised that I might have over designed things for what I actually needed. This blog isn’t critical, it doesn’t need to be available at all times no matter what and at the end of the day, I was paying for all this! So I revisited the design and amended it to something that was better suited to what I actually needed.
Number of Instances – I reduced this down to a single instance, still behind a load balancer and still part of an auto-scaling group but set at a single instance. This has the added benefit that should anything happen to the primary instance and it become unavailable this will be detected and a fresh instance spun up.
Instance Size – I moved down to a smaller instance so it is now running on a t2.small instead of the medium I was on previously.
Storage Class – I changed the storage class for the S3 bucket down to Reduced Redundancy as the images stored in the bucket are not absolutely essential and don’t require the redundancy offered by Standard class.
MySQL – I changed the class down to a db.t2.small and removed Multi-AZ replication as I no longer required that level of of redundancy.
The resulting design of hosting WordPress on AWS now looks like this:
I have left the scaling group details for EU-West-1c as they are still part of it, there are just no running instances available. It means I can easily put this back in place should I need to – gives me some flexibility.
There really is no substitute for getting your hands dirty when learning something new and this blog has been fantastic at helping me on my journey with AWS. A perfect example happened earlier today, before I finished off this post….
I wanted to snapshot the blog before I carried out some WordPress upgrades, so shutdown the instance prior to taking the snapshot. I refreshed and to my horror the instance was terminated! I refreshed again and another appeared, phew. I waited a while and checked the blog, all seemed okay. Thinking it was a one-off, I tried again and the same thing happened. I did a few Google searches but nothing came up so took the dog out for a walk, while out walking in the park it struck me, Auto Scaling!!
It was doing exactly what I had designed it to do, it detected that an instance had disappeared and spun up a new one, as it was set to a single instance only, the other one was terminated. I suspended Auto Scaling and this time it behaved as I had expected, I stopped the instance and it stayed stopped so I could snapshot.
This is just one of numerous things I have discovered while working on this blog and I am sure I will find others as I continue to change the design. I like the idea of taking advantage of EFS (Elastic File System) now that it is available as I can share the storage between the instances, moving the WordPress installation onto it. This would get around the issue I found while upgrading plugins with multiple instance running, you flip-flop between instances behind the load balancer so when you click upgrade on one you can be switched to another that then also needs doing.
All about the journey….