Skip to content



  • Ensure site was DDOS Resilient
  • Ensure that site would autoscale with client demand
  • Site was secure

Technology used

AWS Terraform GitHub WordPress Apache Linux Ansible Confluence Jira

Project Breakdown

The client came to my company explaining that they were looking for a new way to host their existing site as currently it was hosted on a single cpanel server, which as you know, has lots of operating overhead

What I did?

  • Took clients requests in to consideration
    • Client wanted to keep the cPanel server operational so the web devs could upload files through cpanel's web UI
    • Still direct users based on country to correct site
    • Ability to scale database and servers
    • Be cost-efficient
  • Build POC Environment

Issues I had to overcome

Cpanel server

This is a fun one as the client wants to keep their server, and all files are uploaded here.

What I landed up doing was sectioning this server off from the load balancer, place it behind its own target group and set a rule that any request to */wp-admin* or /wp-login.php would be sent to the cpanel server, and then all other requests went to the ASG group of instances

Redirect to correct country

As this was a global client, we needed to ensure that each country saw the correct site. For this the web server was using apache2 (well httpd as it was centos) so we were able to write a .htaccess redirect rule based on the headers that cloudfront added

Ability to scale and be cost-effective

This was done by using smaller machines, and then scaling them down to 3 instances over US night (As most visitors were from the US)

Scale RDS

This is why it's important to run an in-depth discovery phase, as we found that the site was not only making read requests to the RDS cluster, but there was the ability to leave comments. This was a write request on the database.

My Initial idea was to point the instances that scaled up and down to the read instance in the RDS cluster, as no edits were being made here.

Realistically there are 2 options here

  1. Set all the servers to the write instance and beef it up
  2. Put a proxy between the servers and use it to route queries based on type

If only WordPress had the ability to use a read and write endpoint for SQL, opposed to one endpoint

Due to complexity, and reducing single points of failure, I had to go with option 1, and ensure that there was always a read replica on standby that could be used to automatically get promoted

Closing notes

Sadly this project was delivered late to the client, due to PMO issues, but the client approved, and it's being implemented now! (After I left the company)