I have migrated my site to Amazon LightSail taking less than 1hr which shows how efficient and streamlined Amazon is.
If you are considering migrating a WordPress site to aws site read on as I will highlight the steps I followed to ensure zero downtime during migration.
Why I migrated from Ezoic hosting
The main reason why I decided to move from Ezoic hosting is that I noticed a significant performance degradation over time and I noticed latencies had increased when I used pingdom to fetch the site from different server locations.
Ezoic offers free WordPress hosting provided your site is integrated with them. I have been using them for the past 3 months on a trial basis. With Ezoic, you don’t have access to your site backend as you would if you managed it on cPanel.
Ezoic hosting also doesn’t tell you the configuration of your site deployment like VCPUs running, RAM, and allocated bandwidth, which leaves you guessing whether your site is upgraded or downgraded.
Since I wasn’t building a new site from scratch, I needed to perform a lift and shift. I used the all-in-one WordPress plugin which I used successfully when performing a similar migration on GCP. If you are building a new site from scratch kindly jump to the next paragraph.
I performed a full backup of the site and downloaded the backup to my hard drive they also have other download options but they come at a fee.
setting up AWS Lightsail
On LightSail you can choose between over 10 AWS regions. In my case, I choose a European region since my site traffic is primarily distributed between the Americas, and EMEA, and a little from APAC with definite room for growth.
I went with the $10 a-month package that has 2 vCPU 60GB SSD storage and 2GB of RAM I will be monitoring it through the networking panel to add more space or shift to another instance if necessary.
It takes around 2 minutes for the WordPress instance to go live after you deploy it.
When the instance goes live it comes with an ephemeral IP and you need to attach a static IP through the console to avoid losing it. The static IP is free which is good as compared to other cloud providers where you will need to pay an extra charge monthly which adds to your monthly bill.
After the instance has been deployed, there is a need to SSH into the instance to grab the WordPress admin password through the command.
cat bitnami_application_password
If the installation is new you will need to perform initial configuration like SSL certificate & changing default logins to prevent obvious brute force attacks.
After installation, I realized I had encountered the exact problem that I had when performing a similar migration to Google Cloud. The default upload size was set at 50MB which was way smaller than my backup.
I had to SSH again to the instance and change the upload limit to over the backup size. It’s a tricky affair and a lot of mistakes can be made that could ruin your site if you don’t know what you are doing so seek the help of professionals like me if unsure.
After setup, I uploaded my backup to the new WordPress installation and voila I had performed a successful lift and shift in under 1 hr.
Setup of AWS CloudFront CDN
For a site to have millisecond latency and to decrease bounce rate considerably it has run on a global CDN. Cloudfront which runs out of global AWS edge locations was the perfect candidate for this.
The setup is quite simple go to the networking tab and set up a distribution with either an S3 bucket as the backend or your instance.
The setup takes around 10 min to cache your site and distribute across all their points of presence and ensure all your users get the best experience.
setting up snapshots and object versioning
I have enabled daily automatic snapshots on the WordPress instance which provides a replica & a recovery point in case something goes wrong. I am also considering options to manually store backups in a different region in case of an outage but more on that at a later date.
object versioning is also enabled on the S3 bucket that stores media for the site which helps with accidental deletions or overwrites.
Ensuring Security always
Now one of the main reasons I moved to AWS is to take advantage of their top-notch security that comes standard across the environment. However, for anything that is exposed to the internet, there are chances of it being compromised and that falls under your responsibility as a user as part of the shared responsibility model.
Ensure your WordPress admin has MFA enabled and your password is as strong as could be Also ensure that you don’t use admin as the default username as this is the starting point for many brute force attacks.
A good solution for this is
Immediate results I noticed
The site speed has improved immensely and according to page speed insights my site performance is in the 90s which it hasn’t been ever, That is the advantage of the site running on the AWS global Network. results don’t come free but I won’t want to go back to free hosting and receive dismal results.
I would rate the entire installation process to be done with a person with an intermediate knowledge of the cloud this is to ensure security, prevent accidental bills through overprovisioning, and avoid misconfigurations.
if you need such services reach out to me directly at talktome@karaniph.com for a quote I can make a successful install on all major clouds.
