AWS to GCP Migration [200+ EC2 VMs]:- Migrate to Containers Service or Rehost/Lift&Shift to GCE?

I have a use case to migrate 200+ EC2 VMs (all similar machines running WP, OS is Debian) from AWS to GCP and evaluating the below 2 options from both a cost perspective and complexity in replatform

1. Rehost:- Lift and Shift to GCE

2. Replatform:- Use Migrate to containers service  to setup them up as containers in GCP with Anthos/GKE. Want to hear pros and cons in terms of costs and migration complexity.

Solved Solved
5 12 294
1 ACCEPTED SOLUTION

Hello @dheerajpanyam  ,Welcome on Google Cloud Community.

===Rehost==
Always lift&shift will be faster solutions. More about VM migration here: https://cloud.google.com/migrate/virtual-machines/docs/5.0/migrate/create-an-aws-source. 
Cons:
- Fast migration
- Easy migration ( step-by-step tutorial )
- Easy management ( Managing GCE is similar to EC2 on AWS, so you don't have to deal with upskilling people )
Pros:
- Basically you are not improving your infra thus  application will also stay as it is. More work with improving in feature 

In term of costs, use Pricing Calculator : https://cloud.google.com/products/calculator?hl=en

==Replatform==

Cons:
- You can utilize GKE Enterprise to manage you fleet ( paid option ).
- You can utilize autoscaling, so add/remove VM depends on load
- It's move and improve so basically more advantages in terms of migration

Pros:
- If you don't have skilled GKE / K8S engineers, it might be more challenging use case, as in fact you will migrate load ( because of step-by-step instructions) but managing clusters fleet will be more challenging that with standard VMs
- Depends which application is on your EC2, you must prepare target VM for handle this application. 

Migrate to container service is nice if you have EC2 split as microservices ( 4 VMs for SQL, 5VMs for tomcat etc) because it would be better in logical way to migrate app by app. However the complexity of this approach is much more high that simple VM migration

Basically imho approach here depends on AWS EC2 complexity. If you have 200+ EC2 VMs, i think that better would be move them with rehost approach as it might be possible that you will forget something regarding configuration in replatform option thus troubleshooting will be more challenging.

3rd option : 
Migrate load as it is, and then plan improving GCE load with GKE / MIGs approach ( split improvements with waves ). It will ensure that you will have more control over migration and improvement as well as workload work continuity will be achieved.

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

 

 

View solution in original post

12 REPLIES 12

Hello @dheerajpanyam  ,Welcome on Google Cloud Community.

===Rehost==
Always lift&shift will be faster solutions. More about VM migration here: https://cloud.google.com/migrate/virtual-machines/docs/5.0/migrate/create-an-aws-source. 
Cons:
- Fast migration
- Easy migration ( step-by-step tutorial )
- Easy management ( Managing GCE is similar to EC2 on AWS, so you don't have to deal with upskilling people )
Pros:
- Basically you are not improving your infra thus  application will also stay as it is. More work with improving in feature 

In term of costs, use Pricing Calculator : https://cloud.google.com/products/calculator?hl=en

==Replatform==

Cons:
- You can utilize GKE Enterprise to manage you fleet ( paid option ).
- You can utilize autoscaling, so add/remove VM depends on load
- It's move and improve so basically more advantages in terms of migration

Pros:
- If you don't have skilled GKE / K8S engineers, it might be more challenging use case, as in fact you will migrate load ( because of step-by-step instructions) but managing clusters fleet will be more challenging that with standard VMs
- Depends which application is on your EC2, you must prepare target VM for handle this application. 

Migrate to container service is nice if you have EC2 split as microservices ( 4 VMs for SQL, 5VMs for tomcat etc) because it would be better in logical way to migrate app by app. However the complexity of this approach is much more high that simple VM migration

Basically imho approach here depends on AWS EC2 complexity. If you have 200+ EC2 VMs, i think that better would be move them with rehost approach as it might be possible that you will forget something regarding configuration in replatform option thus troubleshooting will be more challenging.

3rd option : 
Migrate load as it is, and then plan improving GCE load with GKE / MIGs approach ( split improvements with waves ). It will ensure that you will have more control over migration and improvement as well as workload work continuity will be achieved.

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

 

 

First of all thank you so much @DamianS for the detailed response. I truly understand the pros and cons of each. In my case we are talking about a WP hosting provider that has around 200+ VMs that have standard bitnami WP image installed on each of these EC2 VMs , 1 per customer. Probably I will choose the option. 

@DamianS  Another important question. Is there any pre requisite to setup private connectivity between AWS and GCP like Cross Cloud Interconnect or does it use the public internet for the transfer by default? I would like to go the route of private connection for faster migration.

As per documentation[1.] "An AWS VPC Subnet with VPN connectivity to Google Cloud. For detailed information, see Network access requirements on firewall, routing, and network tag considerations for your Migrate for Compute Engine deployment." According to that, yes, VPN must be configures, so [2].HA VPN : 

[1.]https://cloud.google.com/migrate/compute-engine/docs/4.10/how-to/migrate-aws-to-gcp/aws-prerequisite...

[2] https://cloud.google.com/network-connectivity/docs/vpn/tutorials/create-ha-vpn-connections-google-cl...

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

@DamianS  The 1st link that you mentioned is using Migrate for Virtual Machines 4.10 which seems to be outdated, I guess the current version is 5.0. Having said that I do not see the same prerequisites mentioned in the 5.0 version. Please see the blue header at the top. When i navigate to the current version which i am assuming is 5.0 i don't see the prerequisites or rather I don't know how to navigate there.

Screenshot 2024-05-13 at 12.45.11 PM.png

 

Oh, you are right ! I see that you can switch to 4.x version, but I didn't found any info for VPN in version v5

DamianS_0-1715586187545.png

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost

So the question really is does Migrate to Virtual Machines 5.0  support Cross Cloud Interconnect for EC2 migrations and if so what are the steps to configure private google access for EC2 machines similar to configuring google access for on-premises hosts?

I found this https://cloud.google.com/migrate/virtual-machines/docs/5.0/get-started/hybrid_subnets

But this is related with VMware, however configuration might be the same. Didn't testes TBH. 

Okay, I'm migrating EC2 without publicIP, so I believe that this is somehow connect via API with AWS credentials. 

Is this without any private connection meaning using your internet?

I've created simple Ubuntu VM without ExternalIP ( only internal one,, taken from AWS AZ). It looks like it's via AWS_KEYS reaching out AWS API and getting information in this way. 

PS: I didn't created any VPN or Interconnect between GCP and AWS btw

@dheerajpanyam 
I'm trying to make an migration for EC2 with PublicIP. So far it's going good

DamianS_0-1715590485815.png

Once source will be updated, I will try also EC2 without PublicIP

--
cheers,
DamianS
LinkedIn medium.com Cloudskillsboost