I Migrated Onprem Wordpress Application to AWS. I have documented my work. This project provides comprehensive documentation for the process of migrating an application to the Amazon Web Services (AWS) cloud platform. I followed the steps outlined below for Migrating Onprem Wordpress Application to AWS.
This document outlines the steps and best practices for migrating your application to AWS. AWS provides a range of services and tools that can help you seamlessly migrate your application to the cloud. By following this guide, you will ensure a smooth transition while taking advantage of AWS's scalability, reliability, and cost-effectiveness.
- Current Environment consist of a three tier e-commerce application (Unicorn Store Application); a webserver running ubuntu with apache, PHP, Wordpress/ WooCommerce and a database server running Ubuntu with MySQL version 5.7.
- The Onprem application has a webserver and database running on server. I will replatform database with AWS Database Migration Service. I will Rehost (lift-and-shift) my webserver to AWS using AWS's leading migration service Application Migration Service (AWS MGN).
in this migration, My strategy is to rehost Wordpress application on EC2 instance and Migrate onprem Mysql database to AWS managed Mysql RDS. this is lift and shift strategy.
- I will rehost the webserver with AWS Application Migration Service. I will migrate Source database using AWS Database Migration service.
- I will follow AWS Well Architected Framework to improve Operation Excellence, Security, Performance Efficency and Cost Optimization for My application in AWS.
-
Configure AWS Identity and Access Management (IAM) roles and permissions for IAM user needed for this migration.
-
AWS IAM user has been created with Administrator access permission added. Logged into AWS using IAM User.
I Uploaded AWS cloud formation template which will create a source environment and target environment as required for this project.
click on next
I entered the details of the stack
once stack is submitted the required resource will be created. you can check the output of stack to see the output. both source and target environment is craeted.
- The following target Amazon Virtual private cloud (VPC) is deployed during the environment preparation.
The VPC consists of 6 subnets (x2 public, x2 private for webservers and x2 private for database) across two availability zones. nat gateway is deployed in two public subnets in AZs and internet gateway is deployed using this cloud formation template.
I will migrate Source Datbase hosted on EC2 instance to AWS managed MySQL RDS
I will migrate Source database to Target database using DMS replication instance. DMS replication instance will need to connect to source database over public internet, while to the target database over private network. I will setup required networking before creating replication instance and Target database
I created a security group for allowing outbound traffic from DMS Replication instace
I created a security group to allow inbound traffic from DMS Replication instance Security Group (RI-SG). Create a rule to allow inbound traffic from DMS Replication instance Security group.
I will create a subnet group where target RDS will be deployed. I will install RDS in private subnet in Target VPC
I selected databases from the menu and on the left click create database. select Mysql as engine options and Engine version MySQL 5.7.41
For this project I selected Free tier as I want to keep cost low.
In settings section I configured DB Instance identifier, then Master username and password for new database
In storage section, I selected db.t3.micro from the Burstable DB instance vclass and allocated 20 GB of storage for this database.
In connectivity section, I selected target VPC, in VPC security group select DB-SG. make sure subnet group we craeted is auto populated.
In Database authentication select password authentication
In additional configuration select Enable encryption and untick Enable automated backups to reduce cost.
Click on Craete a database.
One of the pre-requisites for using of AWS DMS is having configured a subnet group, which is a collection of public subnets that will be used by the DMS Replication Instance.
Go to AWS Console > Services > Migration & Transfer > Database Migration Service > Subnet groups and click on Create subnet group button.
give a name for subnet group and select Target VPC and add Two public subnets for Replication instance to launch so that they can communicate with source server on public network.
In this Step, we will create DMS replication instance.
Inside AWS Console, go to Services and Database Migration Service. Click on Replication instances and then on the Create replication instance button.
On the Create replication instance screen I configured a new replication instance with values
I selected the values as needed for my migration.
Click on Create instance
I made changes to Source database security group and allowed all traffic from internet for Repliation Instance to reach Source database.
For AWS DMS continuous replication from MySQL database, you'll need to enable the binary log and make configuration changes on the source database. Please see the configuration changes made on source database
I tested the changes to make sure update in /etc/mysql/my.cnf took effect, by running the following commans
In AWS console search for WS Database Migration Service, click on Endpoints and Create endpoint button.
Create Target Endpoint
Will test target Endpoint connect my selecting Target VPC and replication instance we just created. please see image below.
Create Source Endpoint and run connection test
In AWS DMS console, go to Database migration tasks and click the Create Task button.
In Create database migration task screen fill with the required information
In Task Setting Wizard enter the following values
Parameter Value
- Target table preparation mode: Do nothing
- Validation:Turn on
- Task Logs:Turn on
In the Table mappings panel select Wizard mode, press the Add new selection rule button and select wordpress-db in the Schema drop-down.
In the Migration task startup configuration, select Automatically on create then Scroll to the bottom of the screen and click the Create task button to create the task and start the data replication.
Monitor the task until the status is changed to Load complete, replication ongoing and the progress is 100%
After succesfully migrating database to AWS. I am migrating Onprem webserver to AWS. This is straight lift and shift migration. in this I am only rehosting the application
-
Go to AWS Application Migration Service console .
-
Click on Get started button, and then Set up service. This will create the necessary IAM resources and also the default templates.
-
At the MGN console, go to Replication template menu at Settings section and edit the default template to change the staging area's subnet.
Click on Set up service
Template gets created and click on edit template
select public subnet and save template
AWS Application Migration Service replicates data to AWS using agent that must be installed on the source server.
For the Application Migration Service agent to replicate data, you need to have an AWS IAM User with proper privileges created in your target AWS account. I created them in the cloud formation stack.
Connect to the source server using ssh key.
I ran the following commands
cd ~ wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py sudo python3 aws-replication-installer-init.py
Provide AWS region and AWS credentials
When prompted provide AWS Region (us-west-2), then AWS Access Key ID and AWS Secret Access Key from cloudformation template. Provide AWS region and AWS credentials
Replication starts
Click on Source Server name and it will take yo to following page. on this page I monitor replication progress.
In Server Info we can find retrived information about source server. We can view disk settings, launch settings.
In Lifecycle, clikc on launch settings and click on Edit.
On launch settings page change instance type right sizing to off and then click on Save.
Modify EC2 launch Template. click on Modify EC2 launch template section and confirm by clicking on Modify.
Scroll to the instance type and change to T3.micro.
Scroll down to network settings and select TargetVPC-public-a as the Subnet - this is where we want our webserver to run after the migration.
In network settings, create security group. create new SG and allow all HTTP and HTTPS traffic.
Then expand the Advanced network configuration section, and for the first Network interface, set Auto-assign public IP to Enable to make sure webserver will be accessible over public IP.
In the Resource tags section change the Name tag value to Webserver, like on the screenshot below.
Finally in the Advanced details section, select the following role as IAM Instance profile: AWSApplicationMigrationLaunchInstanceWithSsmRole.
Scroll down and click on create template version.
update default EC2 version in Launch template. In the lversion tab slect the latest version and set it as default version. This template will be used to launch our new Migrated Web Server.
You will see following message
Now my source server is ready for test.
I will launch a test instance by clicking on launch test instance by clikcing on test and cutover button
Wait for the Completed Status (it should take ~10-15 minutes).
Once testing is completed look for the events
you will see succesfully launched test/cutover ec2 instance. This process validates conversion of boot volume and target server network configuration.
In souce server, click on your server Hostname, then Test and Cutover -> Mark as "ready for cutover".
Continue on the popup to confirm that the testing went succesful and testing instance can be terminated.
Select hostname of the Source server and click on Launch cutover instances.
you will get following popup. please click on launch
This will trigger the cutover job (it will take ~10-15 minutes), you can find its details after clicking on Cutover Job ID in the Lifecycle section.
Wait for the Launch status to change from Waiting to Launched / First boot: Started. At this stage Webserver will be visible and Running in the EC2 Console.
On source server click on finalize cutover. this will stop replication and terminate source server assoiciated with migration.
When the Cutover is finished and Application Migration Service has created a running instance of the Webserver in my AWS account, it's time to update the web application configuration to use replicated AWS RDS database (created in the Database Migration step).
Will update Webserver security group to accept traffic from anywhere to Port 80, 443 and 22.
Click Edit inbound rules. Make sure traffic from anywhere to port 80 (HTTP) is allowed. Add rule to allow SSH from anywhere to port 22 (SSH). Finally click Save rules.
Go to Networking tab and make a note of Public DNS (IPv4) address and Private IP
Connect via SSH to the Webserver created by the Application Migration Service
Modified wordpress configuration and add the following two lines, replacing TARGET_WEBSERVER_PUBLIC_DNS with your Target Webserver EC2 Public DNS (IPv4), to make sure links in your wordpress site point to the new webserver.
define('WP_SITEURL', 'http://ec2-54-244-168-116.us-west-2.compute.amazonaws.com');
define('WP_HOME', 'http://ec2-54-244-168-116.us-west-2.compute.amazonaws.com');
Update the RDS instance VPC security group to allow inbound traffic from Webserver
a. Go to AWS Console > Services > EC2 > Security Groups and select your RDS VPC security group (DB-SG) b. Go to the Inbound tab and click the Edit button c. Add inbound rule that allows traffic from the Webserver (using its Private IP or the security group it belongs to) on port 3306 (MySQL port)
Validate the migration
Open the Webserver Public DNS (IPv4) name in your web browser, will see a unicorn store.
This is how I performed life and shift migration of my wordpress unicorn store application.