Move WordPress to AWS from cPanel Hostings

Here is our story of leaving behind managed cPanel hostings. It’s intended as a not-so-technical summary of our steps taken to make this a reality. The article is intentionally full of internal links as I have already written in detail about each major step, so treat this as a hub, if you will. Once you move WordPress to AWS, everything will change (for the better), and it’s hard to go back.

Before and after

So, for about a decade we’ve been using regular hosting companies that are in-line with the ilk of GoDaddy, BlueHost, DreamHost, HostGator, A2, SiteGround… sounds familiar? Not saying these are bad from the get-go, but thinking that a couple of dollars spent per month will net you a decent service is plain wrong. You’ll see I’m speaking from experience. During my many years of providing support for Justified Image Grid, I had the pleasure of logging in to random people’s FTP servers and cPanel-like admin areas of most popular hostings. As an occupational hazard, I endured seeing what kind of tricks companies have to play to keep thousands of sites on the same machine. I’m talking about tight limits on entry processes and other metrics that are hardly ever advertised in your face. As long as you have a 0-traffic site, everything seems okay.

What triggered the move? Loss of control. If something goes wrong, I prefer to take responsibility. The company I was using went down for a couple of days due to human error, and they had to restore from an off-site backup. My backups were old too at the time, but even if I wanted to rebuild myself, the servers were plain inaccessible. If I tried to do anything, I would only have interfered with their restoration process. I hope you see this is unacceptable in a mission-critical environment. Once the mediocre performance combined with the rising costs, the exit sign quickly appeared in sight.

AWS has always piqued my interest, and I figured creating a production workload is an excellent way to learn. After a period of a few months, we ended up with the environment that you’d call shared hosting. However, it’s only split between our sites. And this is how we did it…

Preparation steps

The system

AWS gives you the power in the form of a virtual machine and lets you do whatever you want to do with it (an EC2 instance). Before WordPress, you need to have a system with a web server. Its install is easy. The hard part is its configuration, which is why I can’t recommend this approach to novices. Which Amazon Machine Image is Best for WordPress?

Side note: I briefly tried LightSail for a managed VPS experience. You might like it when you first move WordPress to AWS. We use Amazon RDS, which means that there is no MySQL installed on the system with the webserver. It’s MariaDB and hosted separately (managed database).

Email service

All cPanel hosts pamper you with integrated email services, but with AWS you need to do some thinking. Thankfully, the cavalry is here for incoming, outgoing and transactional emails involving your domain:

• Let WordPress Send Mail from Amazon EC2 with SES
• Use MailGun to Forward Email on Your Domain to Gmail

Hosting multiple sites at once

To become your own shared hosting, you need to learn how to host multiple sites in the same environment. If you opted to use OpenLiteSpeed as per my recommendation, the following article should be of great help. I was in dire need of such a tutorial. Unfortunately, due to a lack of a better one, I had to write my own: Host Multiple Sites with OpenLiteSpeed VHost Templates

Monitoring the performance

When you move WordPress to AWS, the responsibilities are all yours for running everything smoothly. That includes provisioning your EC2 properly (choosing the right size following growth). The ability to resize the amount of disk, RAM, CPU on-demand is certainly liberating. You’ll have no idea how your server performs unless you heed my recommendation to Monitor Amazon EC2 Memory and Disk Usage with CloudWatch. An optional but useful step would be receiving alerts on your phone about the server’s health with CloudWatch Alarms to Pushbullet via SNS and AWS Lambda.

Backup is now your responsibility

No longer should you be at the mercy of others with your data. The moving process opened my eyes to the importance of not trusting 3rd parties with your backups. Therefore I wrote this: Amazon S3 WordPress Backups with UpdraftPlus

Bonus: Development

We have a copy of our server for staging purposes. If you are a developer, perhaps you like to entertain the idea of working in the cloud. This article will help you get started on that path: Remote Development with Visual Studio Code on Amazon EC2

Quick cheat sheet

There is a trick I haven’t written about yet. It’s for moving a site when you don’t intend to change the domain, just the underlying server. It’s the last hacky thing you will need to do. Add the new server’s IP address to your hosts file like this:

172.16.254.1 example.com

First, the IP then the domain. Once you do this, the site will load from AWS (or your new hosting), but only for you! This tip saves you from tinkering with the database with tools like Search Replace DB. Ideally, WordPress will not even notice you moved it. In essence, you created a temporary staging area. With this in mind, the actual move is greatly simplified and is no longer the heavy-duty part of moving to AWS.

1. Make a backup with UpdraftPlus of the site at the old location
2. Do the hosts file trick
3. Add an empty WordPress to the new server
4. Install UpdraftPlus and upload the backups
5. Restore from the backups and verify that everything works fine
6. Undo the hosts file trick and point your domain to the new IP

That’s it 🙂 It used to be way more complicated while I was testing the waters with AWS and wasn’t sure if it’s the way to go. We had staging copies for our sites for weeks to access both the original and copy simultaneously. That warranted database processing. For an in-depth guide you can still take a look: Move WordPress or Create a Staging Site

Why move WordPress to AWS?

For us, it was a learning experience. Amazon’s services might be overkill for us, sure. I mean, do you think they lack the capacity after serving the likes of Netflix and Twitch? Wouldn’t you want to be on a system that can sustain those kinds of workloads (given the right provisioning and some coin)? Nevertheless, it gives us peace of mind to host with them.

So far, it has hardly cost us anything (with some free tier benefits and coupons from AWSome Days)! I don’t wish to sell them to you, but AWS dominates the internet in terms of traffic and market share. For those of you that see Amazon as “just” an online retailer with an expensive stock, I advise taking a closer look. I especially like to have the ability to scale and grow much like how the “big ones” do it. Once you are already on their infrastructure and somewhat familiar with it, reacting to growth and adding redundancies should be less of an undertaking that you think.