Migrate from AWS to Google Cloud: Migrate from Amazon EC2 to Compute Engine

Last reviewed 2023-10-13 UTC

Google Cloud provides tools, products, guidance, and professional services to migrate virtual machines (VMs) along with their data from Amazon Elastic Compute Cloud (Amazon EC2) to Compute Engine. This document discusses how to design, implement, and validate a plan to migrate from Amazon EC2 to Compute Engine.

The discussion in this document is intended for cloud administrators who want details about how to plan and implement a migration process. It's also intended for decision-makers who are evaluating the opportunity to migrate and who want to explore what migration might look like.

This document is part of a multi-part series about migrating from AWS to Google Cloud that includes the following documents:

This series assumes that you've read and are familiar with the following documents:

The following diagram illustrates the path of your migration journey. For migration scenarios, the Deploy phase is equivalent to performing a migration process.

Migration path with four phases.

You might migrate from Amazon EC2 to Compute Engine in a series of iterations—for example, you might migrate some workloads first and others later. For each separate migration iteration, you follow the phases of the general migration framework:

  1. Assess and discover your workloads and data.
  2. Plan and build a foundation on Google Cloud.
  3. Migrate your workloads and data to Google Cloud.
  4. Optimize your Google Cloud environment.

For more information about the phases of this framework, see Migrate to Google Cloud: Get started.

Assess the source environment

In the assessment phase, you determine the requirements and dependencies of the resources that you want to migrate from Amazon EC2 to Compute Engine.

The assessment phase consists of the following tasks:

  1. Build a comprehensive inventory of your workloads.
  2. Catalog your workloads according to their properties and dependencies.
  3. Train and educate your teams about Google Cloud.
  4. Build experiments and proofs of concept on Google Cloud.
  5. Calculate the total cost of ownership (TCO) of the target environment.
  6. Decide on the order and priority of the workloads that you want to migrate.

For more information about the assessment phase and these tasks, see Migrate to Google Cloud: Assess and discover your workloads. The following sections are based on information in that document.

Build an inventory of your Amazon EC2 instances

To scope your migration, you create an inventory of your Amazon EC2 instances. You can then use the inventory to assess your deployment and operational processes for deploying workloads on those instances.

To build the inventory of your Amazon EC2 instances, we recommend that you use Migration Center, Google Cloud's unified platform that helps you accelerate your end-to-end cloud journey from your current environment to Google Cloud. Migration Center lets you import data from Amazon EC2 and other AWS resources. Migration Center then recommends relevant Google Cloud services that you can migrate to.

After assessing your environment using Migration Center, we recommend that you generate a technical migration assessment report by using the Migration Center discovery client CLI. For more information, see Collect guest data from Amazon EC2 instances for offline assessment.

The data that Migration Center and the Migration Center discovery client CLI provide might not fully capture the dimensions that you're interested in. In that case, you can integrate that data with the results from other data-collection mechanisms that you create that are based on AWS APIs, AWS developer tools, and the AWS command-line interface.

In addition to the data that you get from Migration Center and the Migration Center discovery client CLI, consider the following data points for each Amazon EC2 instance that you want to migrate:

  • Deployment region and zone.
  • Instance type and size.
  • The Amazon Machine Image (AMI) that the instance is launching from.
  • The instance hostname, and how other instances and workloads use this hostname to communicate with the instance.
  • The instance tags as well as metadata and user data.
  • The instance virtualization type.
  • The instance purchase option, such as on-demand purchase or spot purchase.
  • How the instance stores data, such as using instance stores and Amazon EBS volumes.
  • The instance tenancy configuration.
  • Whether the instance is in a specific placement group.
  • Whether the instance is in a specific autoscaling group.
  • The security groups that the instance belongs to.
  • Any AWS Network Firewall configuration that involves the instance.
  • Whether the workloads that run on the instance are protected by AWS Shield and AWS WAF.
  • Whether you're controlling the processor state of your instance, and how the workloads that run on the instance depend on the processor state.
  • The configuration of the instance I/O scheduler.
  • How you're exposing workloads that run on the instance to clients that run in your AWS environment (such as other workloads) and to external clients.

Assess your deployment and operational processes

After you build the inventory of your Amazon EC2 instances, we recommend that you assess your deployment and operational processes. It's vital to have a clear understanding of how your deployment and operational processes work. These are a fundamental part of the practices that prepare and maintain your production environment and the workloads that run there.

Consider how you complete the following tasks:

  • Provision and configure your AWS resources. To prepare your AWS environment, you might have designed and implemented processes that provision and configure resources. For example, you might be using AWS CloudFormation or Terraform along with configuration management tools to provision and configure your AWS cloud resources.
  • Generate AMIs for your Amazon EC2 instances. It's important to assess how you're generating AMIs and what kind of customization you apply to these AMIs. This information helps you ensure that you provide a suitable runtime environment for your workloads. For example, you might be installing operating system (OS) packages or tuning the configuration of the OS.
  • Generate the artifacts that you deploy on your Amazon EC2 instances. To deploy your workloads on Amazon EC2, you might be generating deployable artifacts such as packaged workloads and container images. Gathering information about how you're generating these artifacts helps you ensure that the generated artifacts are suitable for deployment on Google Cloud. For example, if you're producing artifacts that you store in an artifact registry on AWS, you must consider how to make these artifacts available in your Google Cloud environment.
  • Deploy artifacts on your Amazon EC2 instances. After you generate deployable artifacts, you might deploy them on Amazon EC2. We recommend that you assess each deployment process. The assessment helps ensure that your deployment processes are compatible with Google Cloud. It also helps you understand the effort that will be necessary to eventually refactor the processes. For example, if your deployment processes work only with Amazon EC2, you might need to refactor them to target your Google Cloud environment.
  • Inject runtime configuration. You might be injecting runtime configuration for your instances, such as initializing environment variables and other configuration values for specific Amazon EC2 instances, runtime environments, or workload deployments. To help ensure that your runtime configuration injection processes work on Google Cloud, we recommend that you assess how you have the workloads configured on Amazon EC2.

After you assess your deployment and operational processes, we also recommend that you assess how these processes can facilitate your migration to Google Cloud and how they help you reduce the scope and the risk of your migration. For example, you might refactor your artifact-build processes to store artifacts in both AWS and in Google Cloud while the migration is underway. Having artifacts in both environments lets you focus on migrating Amazon EC2 instances without having to implement artifact-build processes in the target Google Cloud environment at the start of the migration process.

Complete the assessment

After you build the inventories from your Amazon EC2 environment, complete the rest of the activities of the assessment phase as described in Migrate to Google Cloud: Assess and discover your workloads.

Plan and build your foundation

In the plan and build phase, you provision and configure the infrastructure to do the following:

  • Support your workloads in your Google Cloud environment.
  • Connect your AWS environment and your Google Cloud environment to complete the migration.

The plan and build phase is composed of the following tasks:

  1. Build a resource hierarchy.
  2. Configure identity and access management.
  3. Set up billing.
  4. Set up network connectivity.
  5. Harden your security.
  6. Set up logging, monitoring, and alerting.

For more information about each of these tasks, see Migrate to Google Cloud: Build your foundation.

Migrate your workloads

To migrate your workloads from Amazon EC2 to Compute Engine, you do the following:

  1. Migrate VMs from Amazon EC2 to Compute Engine.
  2. Expose workloads that run on Compute Engine to clients.
  3. Refactor deployment and operational processes to target Google Cloud instead of targeting Amazon EC2.

The following sections provide details about each of these tasks.

Migrate your VMs to Compute Engine

To migrate VMs from Amazon EC2 to Compute Engine, we recommend that you use Migrate to Virtual Machines, which is a fully managed service. For more information, see Migration journey with Migrate to VMs.

As part of the migration, Migrate for VMs migrates Amazon EC2 instances in their current state, apart from required configuration changes. If your Amazon EC2 instances run customized Amazon EC2 AMIs, Migrate for VMs migrates these customizations to Compute Engine instances. However, if you want to make your infrastructure reproducible, you might need to apply equivalent customizations by building Compute Engine operating system images as part of your deployment and operational processes, as explained later in this document. You can also import your Amazon EC2 AMIs into Compute Engine.

Expose workloads that run on Compute Engine

After you migrate your Amazon EC2 instances to Compute Engine instances, you might need to provision and configure your Google Cloud environment to expose the workloads to clients.

Google Cloud offers secure and reliable services and products for exposing your workloads to clients. For workloads that run on your Compute Engine instances, you configure resources for the following categories:

  • Firewalls
  • Traffic load balancing
  • DNS names, zones, and records
  • DDoS protection and web application firewalls

For each of these categories, you can start by implementing a baseline configuration that's similar to how you configured AWS services and resources in the equivalent category. You can then iterate on the configuration and use additional features that are provided by Google Cloud services.

The following sections explain how to provision and configure Google Cloud resources in these categories, and how they map to AWS resources in similar categories.

Firewalls

If you configured AWS security groups and AWS Network Firewall policies and rules, you can configure Cloud Next Generation Firewall policies and rules. You can also provision VPC Service Controls rules to regulate network traffic inside your VPC. You can use VPC Service Controls to block unwanted network connections to your Compute Engine instances, and to help mitigate the risk of data exfiltration.

For example, if you use AWS security groups to allow or deny connections to your Amazon EC2 instances, you can configure similar Virtual Private Cloud (VPC) firewall rules that apply to your Compute Engine instances.

Traffic load balancing

If you've configured Elastic Load Balancing (ELB) in your AWS environment, you can configure Cloud Load Balancing to distribute network traffic to help improve the scalability of your workloads in Google Cloud. Cloud Load Balancing supports several global and regional load balancing products that work at different layers of the OSI model, such as at the transport layer and at the application layer. You can choose a load balancing product that's suitable for the requirements of your workloads.

Cloud Load Balancing also supports configuring Transport Layer Security (TLS) to encrypt network traffic. When you configure TLS for Cloud Load Balancing, you can use self-managed or Google-managed TLS certificates, depending on your requirements.

DNS names, zones, and records

If you use Amazon Route 53 in your AWS environment, you can use the following in Google Cloud:

For example, if you registered a domain by using Amazon Route 53, you can transfer the domain registration to Cloud Domains. Similarly, if you configured public and private DNS zones using Amazon Route 53, you can migrate that configuration to Cloud DNS.

DDoS protection and web application firewalls

If you configured AWS Shield and AWS WAF in your AWS environment, you can use Google Cloud Armor to help protect your Google Cloud workloads from DDoS attacks and from common exploits.

Refactor deployment and operational processes

After you migrate your VMs to Compute Engine, you refactor your processes to do the following:

  • Provision and configure resources in your Google Cloud environment instead of provisioning AWS resources such as Amazon EC2 instances and Amazon EC2 AMIs.
  • Build, deploy, and configure workloads in Compute Engine instead of deploying workloads in Amazon EC2.

You gathered information about these processes during the assessment phase earlier in this process.

The type of refactoring that you need to consider for these processes depends on how you designed and implemented them. The refactoring also depends on what you want the end state to be for each process. For example, consider the following:

  • You might have implemented these processes in your AWS environment and you intend to design and implement similar processes in Google Cloud.
  • You might have implemented these processes in another, third-party environment outside your AWS environment. In this case, you need to refactor these processes to target your Google Cloud environment instead of your AWS environment.
  • A combination of the previous approaches.

Refactoring deployment and operational processes can be complex and can require significant effort. If you try to perform these tasks as part of the VM migration, the migration can become complex, and it can expose you to risks. After you assess your deployment and operational processes, you likely have an understanding of their design and complexity. If you estimate that you require substantial effort to refactor your deployment and operational processes, we recommend that you consider refactoring these processes as part of a separate, dedicated project.

For more information about how to design and implement deployment processes on Google Cloud, see the following documents:

Optimize your environment after migration

When you complete all of the migration phases, the migration is considered done. However, your Google Cloud environment might need further optimizations. For more information, see Migration journey with Migrate to VMs: Optimize your environment.

What's next