We just moved this site to S3 and cloud front.
We have told our customers so often to move their sites to AWS cloudfront and S3 that we deemed it necessary to move our own site as well. In this blogpost we’ll tell you a bit about the journey.
Basic architecture principles.
At easytocloud we like to make as much use of managed services as possible. More often than not, we create server-less solutions as we aim to get rid of operating system responsibility were possible.
However, as this site is a Wordpress site, we need to run at least one instance for the PHP code that makes WordPress.
In addition to an instances, WordPress needs a database. We could have run the database on the instance itself but that defeats one of our basic design principles:
Treat your servers as cattle not pets
We do not want to store any data on our instance, so rather than running the database locally, we run it as a RDS multi-AZ deployment. mySQL as a managed service, high available replicated over two Availability Zones.
We created the (Aurora) database and exported/imported the content from the original site to the RDS instance. After changing the DB connect in wp-config.php, the instance got the posts from the RDS database.
The next step in ‘cattle not pet’ is the ability to create a new instance. There are two options to create new instances, either ‘from scratch’ with userdata or by creating an AMI specifically for the purpose of a wordpress site.
We decided to write a userdata-script. After a few iterations, the script was put in S3 and the userdata copies and runs the script.
The script takes care of installing all of the WordPress prerequisites and copies a tar-ball containing WordPress itself. It would be better even to actually install WordPress but that could be a next step.
An autoscaling group with a minimum of 1 instance makes sure there is one instance running at any time.
The instance has a rol attached so it can access the S3 bucket.
The instances live in a private subnet, behind a loadbalancer that lives in the public subnet. The load balancer performance is used to determine the necessary amount of EC2 instances to run the website.
With a plugin, we moved the /wp-content/uploads directory to an S3 bucket.
Cloudfront is configured with two sources; the S3 bucket and the ELB. Any reference to /wp-content/uploads is sent to S3, all other requests go to the ELB.
More details on each of the components will be presented in future posts.