Migrate from AWS to Google Cloud: Migrate from Amazon EKS to GKE

Last reviewed 2023-09-30 UTC

Google Cloud provides tools, products, guidance, and professional services to migrate from Amazon Elastic Kubernetes Service (Amazon EKS) to Google Kubernetes Engine (GKE). This document helps you to design, implement, and validate a plan to migrate from Amazon EKS to GKE. This document also provides guidance if you're evaluating the opportunity to migrate and want to explore what migration might look like. Besides running on Amazon Elastic Compute Cloud (Amazon EC2), Amazon EKS has a few other deployment options, such as Amazon EKS on AWS outputs and Amazon EKS anywhere. This document focuses on Amazon EKS on EC2.

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 EKS to GKE 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 EKS to GKE.

The assessment phase consists of the following tasks:

  1. Build a comprehensive inventory of your workloads and data.
  2. Catalog your workloads and data according to their properties and dependencies.
  3. Train and educate your teams on 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 your inventories

To scope your migration, you create two inventories: one of your Amazon EKS clusters, and one of the workloads that are deployed in those clusters. After you build these inventories, you assess your deployment and operational processes for deploying workloads in the clusters.

Build the inventory of your Amazon EKS clusters and workloads

To build the inventory of your Amazon EKS clusters, 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 EKS and other AWS resources. Migration Center then recommends relevant Google Cloud services that you can migrate to.

When you build the inventory of your Amazon EKS clusters, you might find that some of the clusters need to be decommissioned as part of your migration. Make sure that your migration plan includes retiring these resources.

The data that Migration Center provides 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, consider the following data points for each Amazon EKS cluster that you want to migrate:

  • Follow the guidance in the Build your inventories section of "Migrating Kubernetes to GKE." That document describes how to build the inventories of your Kubernetes clusters and workloads. It's also applicable to building the inventory of your Amazon EKS environments.
  • Consider Amazon EKS-specific aspects and features for each Amazon EKS cluster, including the following:
    • Private clusters
    • Cluster endpoint access control
    • Secret encryption
    • Managed node groups and self-managed nodes
    • Tags on Amazon EKS resources
    • Amazon Custom AMIs in EKS
    • Usage of Amazon EKS Fargate
    • Usage of Amazon EKS Managed Prometheus
    • OpenID Connect authentication configuration
  • Assess how you're authenticating against your Amazon EKS clusters and how you configured AWS Identity and Access Management (IAM) for Amazon EKS.
  • Assess the networking configuration of your Amazon EKS clusters.
  • Assess any compliance and regulatory requirements, and whether you're meeting these requirements.

Assess your deployment and operational processes

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

Your deployment and operational processes might build the artifacts that your workloads need to function. Therefore, you should gather information about each artifact type. For example, an artifact can be an operating system package, an application deployment package, an operating system image, a container image, or something else.

In addition to the artifact type, consider how you complete the following tasks:

  • Generate the artifacts that you deploy on Amazon EKS. To deploy your workloads on Amazon EKS, you might be generating deployable artifacts, such as container images. Gathering information about how you're generating these artifacts helps you to ensure that the generated artifacts are suitable for deployment in Google Cloud. For example, if you produce artifacts that you store in an artifact registry on AWS, you need to make the artifacts available in your Google Cloud environment. You can do so by employing strategies like the following:
    • Establish a communication channel between the environments: Make the artifacts in your source environment reachable from the target Google Cloud environment. Doing so helps prepare for your eventual use of Artifact Registry.
    • Refactor the artifact build process: Complete a minor refactor of your source environment so that you can store artifacts in both the source environment and the target environment. This approach supports your migration by building infrastructure like an artifact repository before you have to implement artifact build processes in the target Google Cloud environment. You can implement this approach directly, or you can build on the previous approach of establishing a communication channel first.
  • Deploy artifacts on your Amazon EKS clusters. After you generate deployable artifacts, you might be deploying them on Amazon EKS. 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 to understand the effort that will be necessary to eventually refactor the processes. For example, if your deployment processes work with only Amazon EKS, you might need to refactor them to target your Google Cloud environment.
  • Inject runtime configuration. You might be injecting runtime configuration for specific Amazon EKS clusters, runtime environments, or workload deployments. The configuration might initialize environment variables and other configuration values like secrets, credentials, and keys. To help ensure that your runtime configuration injection processes work on Google Cloud, we recommend that you assess how you're configuring the workloads that run on Amazon EKS.

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 to reduce the scope and the risk of your migration.

Complete the assessment

After you build the inventories from your Amazon EKS 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.

Build your foundation on Google Cloud

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

  1. Build a resource hierarchy.
  2. Configure Google Cloud's Identity and Access Management (IAM).
  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 the Plan and build your foundation section in "Migrate containers to Google Cloud: Migrate Kubernetes to GKE."

Migrate your data and deploy workloads

In the deployment phase, you do the following:

  1. Provision and configure your GKE environment.
  2. Configure your GKE clusters.
  3. Migrate data from your source environment to Google Cloud.
  4. Deploy your workloads in your GKE environment.
  5. Validate your workloads.
  6. Expose workloads running on GKE.
  7. Shift traffic from the source environment to the GKE environment.
  8. Decommission the source environment.

For information about how to complete each of these tasks, see the Deploy your workloads section in "Migrate containers to Google Cloud: Migrate Kubernetes to GKE." The following sections integrate the considerations in that document.

Migrate data

The Migrate data section in "Migrate containers to Google Cloud: Migrate Kubernetes to GKE" contains information about migrating data from a generic Kubernetes environment to GKE. The recommendations in that section are applicable to migrating data from Amazon EKS to GKE. To plan your migration, integrate the generic environment information in the linked document with the following sections that are specific to migrating data from Amazon EKS to GKE.

AWS provides several data storage options for Amazon EKS. This document focuses on the following data migration scenarios:

  • Migrate data from Amazon EBS volumes to GKE PersistentVolume resources.
  • Copy data from Amazon EBS volumes to Amazon S3 or to Cloud Storage, and then migrate data to GKE PersistentVolume resources.

Migrate data from Amazon EBS volumes to GKE PersistentVolumes

You can migrate data from Amazon EBS volumes to GKE PersistentVolume resources by using one of the following approaches:

  • Directly copy data from Amazon EBS volumes to Compute Engine persistent disks:
    1. Provision Amazon EC2 instances and attach the Amazon EBS volumes that contain the data to migrate.
    2. Provision Compute Engine instances with empty persistent disks that have sufficient capacity to store the data to migrate.
    3. Run a data synchronization tool, such as rsync, to copy data from the Amazon EBS volumes to the Compute Engine persistent disks.
    4. Detach the persistent disks from the Compute Engine instances.
    5. Decommission the Compute Engine instances.
    6. Configure the persistent disks as GKE PersistentVolume resources.
  • Migrate Amazon EC2 instances and Amazon EBS volumes to Compute Engine:
    1. Provision Amazon EC2 instances and attach the Amazon EBS volumes that contain the data to migrate.
    2. Migrate the Amazon EC2 instances and the Amazon EBS volumes to Compute Engine with Migrate for Virtual Machines.
    3. Detach the persistent disks from the Compute Engine instances.
    4. Decommission the Compute Engine instances.
    5. Configure the persistent disks as GKE PersistentVolume resources.

For more information about migrating Amazon EC2 instances to Compute Engine, see Migrate from AWS to Google Cloud: Migrate from Amazon EC2 to Compute Engine.

For more information about using Compute Engine persistent disks as GKE PersistentVolume resources, see Using pre-existing persistent disks as PersistentVolumes.

Copy data from Amazon EBS volumes to an interim media, and migrate to GKE PersistentVolumes

Instead of migrating from Amazon EBS volumes to GKE PersistentVolume resources directly, you can use an interim media such as an object store:

  1. Upload data from Amazon EBS volumes to an interim media such as an Amazon S3 bucket or a Cloud Storage bucket.
  2. Download the data from the interim media to your GKE PersistentVolume resources.

In certain scenarios, using multiple media can simplify data transfer based on your network and security configurations. For example, you can initially upload the data to an S3 bucket, then copy it from the S3 bucket to a Cloud Storage bucket, and finally download the data to your persistent volumes. Regardless of the approach that you choose, to ensure a smooth transition while taking note of important considerations, we recommend that you review Migrate from AWS to Google Cloud: Migrate from Amazon S3 to Cloud Storage.

Choose a migration option

The best migration option for you depends on your specific needs and requirements, such as the following considerations:

  • The amount of data that you need to migrate.
    • If you have a small amount of data to migrate, such as a few data files, consider tools like rsync to copy the data directly to Compute Engine persistent disks. This option is relatively quick, but it might not be suitable for a large amount of data.
    • If you have a large amount of data to migrate, consider using Migrate to Virtual Machines to migrate the data to Compute Engine. This option is more complex than directly copying data, but it's more reliable and scalable.
  • The type of data that you need to migrate.
  • Your network connectivity between the source and the target environments.
    • If you can't establish direct network connectivity between your AWS EC2 and Compute Engine instances, you might want to consider using Amazon S3 or Cloud Storage to store the data temporarily while you migrate it to Compute Engine. This option might be less expensive because you won't have to keep your EC2 and Compute Engine instances running simultaneously.
  • Your migration timeline.
    • If you have limited network bandwidth or a large amount of data, and your timeline isn't tight, you can also consider using a Transfer Appliance to move your data from AWS to Google Cloud.

No matter which option you choose, it's important that you test your migration before you make it live. Testing will help you to identify any potential problems and help to ensure that your migration is successful.

Optimize your environment after migration

When you complete all of the migration phases, the migration is considered done. However, your GKE environment might need further optimizations. For more information, see Migrate Kubernetes to GKE: Optimize your environment.

What's next