We are moving some of our websites from Google Cloud Platform (GCP) hosting to Amazon’s AWS cloud platform. Rookies may consider downloading files to their desktop and manually uploading them to the new server via FTP. Old school gurus would probably scp between two remote servers. In this article, we will review the Application Migration Service provided by AWS which makes the process a bit simpler.
The process is technical and so this article will focus on that point of view. However, rather than a step by step manual, we will provide an introduction using high level concepts. We will be talking about specific Google and Amazon cloud features.
Let’s start by saying yes, we continue to use both Google Cloud Platform and Amazon Web Services. The reasons for using each may vary; however, in our case the story is simple. We have acquired some free AWS credits and have existing expertise using the platform. So without further delay, let’s discuss migrating a few web servers from GCP to AWS.
For details about this project like participants, risks, and lessons learned review our FolioProjects link. Better than a case study, FolioProjects will provide the most details about this project including feedback from artificial intelligence.
MIGRATING BETWEEN REMOTE SERVERS
At it’s root, we are simply transferring websites from one server to the other. These servers just happen to be managed by different companies. The servers also have different hardware and exist in different locations. However, none of that affects the difficulty level of our goal.
We would like to transfer all of the applications that were installed on the server, their logs, and configurations. We would also like to transfer all files related to the websites. Sounds easy at first; however, the typical web server today is likely to hold gigs of data and quite a few applications. Each of the applications can be customized, including where they are installed, further complicating the process.
AWS isn’t rocket science to a group of nerds like us. However, no one on the team has ever utilized the Application Migration Service feature provided by AWS. Aspects portrayed as optional in documentation quickly became mandatory, increasing our learning curve.
TECHNICAL ASPECTS
We are moving a GCP e2-medium server to AWS using the AWS Application Migration Service. We could start the conversation on why anyone would use the e2 class of servers for live websites or we can stick to the topic.
You will need to understand a few AWS features including:
- IAM
- EC2 Launch Templates
- EC2 Key Pairs
- EC2 Security Groups
- Application Migration Service
In addition to the concepts, you should have a plan for the size of the server and the region. You should also have a plan for connecting to the server via SSH to assist with your testing e.g. creating public and private keys. Obviously, you will also need to know a few server management and GCP features. Specifically, you will need to SSH onto your GCP server to install the AWS MGN replication agent which transfers your server to AWS.
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.pyTHINGS TO NOTE
There were some aspects that took us by surprised and ended up wasting lots of time. We have condensed those hard lessons into a few points that you should remember about the process as it’s currently setup.
A new launch template is created for each migrated server. We have seen 1 template automatically setup for test and launch servers, as well as 2 different templates. Since we were testing web servers, we absolutely needed to edit the launch templates vs this being an optional step. They are not configured for remote access by default. Notice in the following screen shot that we have configured our launch template to have a public IP so we can communicate with it before and after testing.
Also note that at least 1 security group is going to be required. The migration process creates it’s own security group which does not facilitate access. You will need to create your own security group to open port 80, 443, and any other port you need.
As you cycle through ready for test, testing, and back to ready to test you will see many EC2 instances being started and stopped. You want to monitor these, since jumping through steps will result in an error if the previous step is not done its work. We have seen the dashboard saying a server is ready, just to find out that it’s actually being restarted.
The replication process took 4hrs for 75gigs. This is a lot of waiting time but not unreasonable considering the “set it and forget it” scenario. It’s easy, just keep the time in mind when planning this type of migration
RESULTS
We measured the website page load speed of 2 websites before being transferred from Google Cloud to Amazon AWS. We also let Amazon pick the appropriate server size needed to accommodate the setup we had in Google Cloud. The result was a website that loaded under a second faster on AWS in every case. This could have been the servers simply being closer to the testing center, or was it? You make up your own mind on this one.
We did not discuss price. Obviously, since we got free credits, that wasn’t a deciding factor. However, we will monitor the price differences and discuss them in future blog posts, so subscribe to our newsletter to stay updated.
Our launch templates were configured to auto resize on AWS based on what their algorithms deemed an appropriate comparison for our setup on GCP. You may want to be more specific, especially if the server on GCP was the wrong size and configuration to start with.
The entire process took our team 5hrs to complete the second migration, after learning from the first server. In the best cast scenario, we would estimate approximately 2 days to complete the same cycle manually including testing. However, note that we were moving our own server which we knew extensively.
CONCLUSION
Utilizing the built in AWS Application Migration Service to transfer our websites from Google Cloud was ultimately a smart move for us. Considering the existing solutions for migrations, this package by AWS seems comprehensive with minimal chances of mistakes.
Also note that Google Cloud Platform has their own cloud migration service which we will cover in another post. Ultimately, cloud server hosting providers know that customers utilize multiple providers for a range of reasons and they are making that process easier.
If you need help with Google Cloud Platform or Amazon Web Services, contact us. Our team of cloud server managers can help you to achieve your goals.
