New and improved AWS architecture for WordPress deployments
I wrote a while back about my first Amazon (AWS) deployment for WordPress, which featured Geo-optimised, and multi-zone availability.
Since that deployment, I’ve experimented and continued to roll out WordPress architecture that is stable, redundant and optimised for a global audience. I’ve also been inspired by my good friend Shaun who’s an AWS engineer and does much more advanced/enterprise AWS deployments.
Mid October 2013 – Amazon Cloudfront announced it supported POST, PUT, and other HTTP methods. Meaning you can now route your entire website through Cloudfront. Rather than just using Cloudfront for static assets.
At Amazon re:Invent – the global Amazon conference late 2013, There was a great talk about Dynamic Content Acceleration using Amazon CloudFront and Amazon Route 53.
With these new changes out in the wild, my new AWS setup for hosting enterprise WordPress installs looks a bit like this.
This solution basically creates the notion that there is a master server, where we do all our media uploads, where we run crons, where we run memcache (or AWS’ redundant Elasticache if you so choose).
Having a master server makes it easier to administer crons, which is something that gets a bit tricky with multiple servers. It also means we need to do one way synchronisation of uploaded assets / media.
This setup also includes the ability to spin up unlimited servers and all play along nicely.