从 AWS 迁移到 Google Cloud：从 Amazon EC2 迁移到 Compute Engine

Last reviewed 2023-10-13 UTC

Google Cloud 提供了将虚拟机 (VM) 及其数据从 Amazon Elastic Compute Cloud (Amazon EC2) 迁移到 Compute Engine 的工具、产品、指导和专业服务。本文档介绍如何设计、实现和验证从 Amazon EC2 迁移到 Compute Engine 的计划。

本文档中的讨论适用于希望详细了解如何规划和实现迁移过程的云管理员。它还适用于正在评估迁移机会和想要探索迁移可能是什么样子的决策者。

本文档是关于从 AWS 迁移到 Google Cloud 的系列文章中的一篇，该系列文章包括以下文档：

本系列假定您已阅读并熟悉以下文档：

下图说明了迁移过程的路径。 对于迁移场景，部署阶段等同于执行迁移过程。

迁移路径包含四个阶段。

您可能会在一系列迭代中从 Amazon EC2 迁移到 Compute Engine，例如，您可能会先迁移一些工作负载，然后再迁移其他工作负载。对于每个单独的迁移迭代，您需要遵循一般迁移框架的各个阶段：

  1. 评估和发现工作负载和数据。
  2. 在 Google Cloud 上规划和构建基础。
  3. 将工作负载和数据迁移到 Google Cloud。
  4. 优化您的 Google Cloud 环境。

如需详细了解此框架的各个阶段，请参阅迁移到 Google Cloud：使用入门。

评估来源环境

在评估阶段，您需要确定要从 Amazon EC2 迁移到 Compute Engine 的资源的要求和依赖项。

评估阶段包括以下任务：

  1. 构建一个完整的工作负载清单。
  2. 根据工作负载的属性和依赖项对工作负载进行分类。
  3. 为您的团队开展 Google Cloud 培训和指导
  4. 在 Google Cloud 上构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 确定要迁移的工作负载的顺序和优先级。

如需详细了解评估阶段和这些任务，请参阅迁移到 Google Cloud：评估和发现工作负载。以下部分基于该文档中的信息。

构建 Amazon EC2 实例的清单

如需确定迁移范围，请创建 Amazon EC2 实例的清单。然后，您可以使用清单评估在这些实例上部署工作负载的部署和操作流程。

如需构建 Amazon EC2 实例的清单，我们建议您使用 Migration Center，这是 Google Cloud 的统一平台，可帮助您加快从当前环境到 Google Cloud 的端到端云之旅速度。 借助 Migration Center，您可以从 Amazon EC2 和其他 AWS 资源导入数据。然后，Migration Center 会推荐您可以迁移到的相关 Google Cloud 服务。

使用 Migration Center 评估您的环境后，我们建议您使用 Migration Center 资产识别客户端 CLI 生成技术迁移评估报告。如需了解详情，请参阅从 Amazon EC2 实例收集客机数据以进行离线评估。

Migration Center 和 Migration Center 资产识别客户端 CLI 提供的数据可能无法完全捕获您感兴趣的维度。在这种情况下，您可以将该数据与您创建的基于 AWS API、AWS 开发者工具和 AWS 命令行界面的其他数据收集机制的结果集成。

除了从 Migration Center 和 Migration Center 资产识别客户端 CLI 获取的数据之外，还请考虑您要迁移的每个 Amazon EC2 实例的以下数据点：

  • 部署区域和可用区。
  • 实例类型和大小。
  • 启动实例的 Amazon 机器映像 (AMI)。
  • 实例主机名，以及其他实例和工作负载如何使用此主机名与该实例进行通信。
  • 实例标记以及元数据和用户数据。
  • 实例虚拟化类型。
  • 实例购买选项，例如按需购买或现货购买。
  • 实例如何存储数据，例如使用实例存储和 Amazon EBS 卷。
  • 实例租户配置。
  • 实例是否在特定的放置群组中。
  • 实例是否在特定的自动扩缩群组中。
  • 实例所属的安全群组。
  • 任何涉及实例的 AWS 网络防火墙配置。
  • 在实例上运行的工作负载是否受 AWS Shield 和 AWS WAF 保护。
  • 您是否控制实例的处理器状态，以及实例上运行的工作负载如何取决于处理器状态。
  • 实例 I/O 调度器的配置。
  • 如何将在实例上运行的工作负载公开给在 AWS 环境中运行的客户端（例如其他工作负载）和外部客户端。

评估您的部署和运营流程

构建 Amazon EC2 实例的清单后，我们建议您评估部署和操作流程。请务必清楚了解部署和运营流程的工作原理。这些是准备和维护生产环境以及在其中运行的工作负载的做法的基本组成部分。

请考虑如何完成以下任务：

  • 预配和配置您的 AWS 资源。为了准备 AWS 环境，您可能已设计和实现了预配和配置资源的流程。例如，您可能使用 AWS CloudFormation 或 Terraform 以及配置管理工具来预配和配置 AWS 云资源。
  • 为 Amazon EC2 实例生成 AMI。请务必评估您生成 AMI 的方式以及您对这些 AMI 应用的自定义类型。此信息可帮助您确保为工作负载提供合适的运行时环境。例如，您可能正在安装操作系统 (OS) 软件包或调整操作系统配置。
  • 生成您在 Amazon EC2 实例上部署的工件。如需在 Amazon EC2 上部署工作负载，您可能会生成可部署的工件，例如打包的工作负载和容器映像。收集有关生成这些工件的信息有助于确保生成的工件适合在 Google Cloud 上部署。例如，如果您要生成存储在 AWS 上的 Artifact Registry 中的工件，则必须考虑如何在 Google Cloud 环境中提供这些工件。
  • 在 Amazon EC2 实例上部署工件。生成可部署的工件后，您可以将其部署到 Amazon EC2 上。我们建议您评估每个部署流程。评估有助于确保您的部署流程与 Google Cloud 兼容。它还有助于您了解最终重构流程所需的工作量。例如，如果您的部署流程仅适用于 Amazon EC2，则可能需要重构它们以定位您的 Google Cloud 环境。
  • 注入运行时配置。您可能正在为您的实例注入运行时配置，例如初始化环境变量和其他特定 Amazon EC2 实例、运行时环境或工作负载部署的其他配置值。为帮助确保您的运行时配置注入过程在 Google Cloud 上正常运行，我们建议您评估如何在 Amazon EC2 上配置工作负载。

在评估部署和操作流程后，我们还建议您评估这些流程如何帮助您迁移到 Google Cloud，以及它们如何帮助您缩小迁移范围和风险。例如，您可以重构工件构建流程，以便在迁移过程中将工件存储在 AWS 和 Google Cloud 中。在两个环境中都有工件让您可以专注于迁移 Amazon EC2 实例，而无需在迁移过程开始时在目标 Google Cloud 环境中实现工件构建流程。

完成评估

从 Amazon EC2 环境构建清单后，请完成评估阶段的其余活动，如迁移到 Google Cloud：评估和发现您的工作负载中所述。

规划和构建基础

在规划和构建阶段，您需要预配和配置基础架构以执行以下操作：

  • 在 Google Cloud 环境中支持您的工作负载。
  • 连接 AWS 环境和 Google Cloud 环境以完成迁移。

规划和构建阶段由以下任务组成：

  1. 构建资源层次结构。
  2. 配置身份和访问权限管理。
  3. 设置结算功能。
  4. 设置网络连接。
  5. 强化安全性。
  6. 设置日志记录、监控和提醒。

如需详细了解这些任务，请参阅迁移到 Google Cloud：构建您的基础。

迁移工作负载

如需将工作负载从 Amazon EC2 迁移到 Compute Engine，请执行以下操作：

  1. 将虚拟机从 Amazon EC2 迁移到 Compute Engine。
  2. 将 Compute Engine 上运行的工作负载公开给客户端。
  3. 重构部署和运营流程，以定位 Google Cloud 而不是定位 Amazon EC2。

以下各部分详细介绍了这些任务。

将虚拟机迁移到 Compute Engine

如需将虚拟机从 Amazon EC2 迁移到 Compute Engine，我们建议您使用 Migrate to Virtual Machines（一项全代管式服务）。如需了解详情，请参阅使用 Migrate to VMs 进行迁移的过程。

在迁移过程中，除了所需的配置更改之外，Migrate for VM 还会迁移处于当前状态的 Amazon EC2 实例。如果 Amazon EC2 实例运行自定义的 Amazon EC2 AMI，Migrate for VMs 会将这些自定义设置迁移到 Compute Engine 实例。但是，如果您想使您的基础架构可重现，您可能需要通过构建 Compute Engine 操作系统映像作为部署和操作流程的一部分来应用等效的自定义，如前所述在本文档的后面。您还可以将 Amazon EC2 AMI 导入 Compute Engine。

公开在 Compute Engine 上运行的工作负载

将 Amazon EC2 实例迁移到 Compute Engine 实例后，您可能需要预配和配置 Google Cloud 环境以将工作负载公开给客户端。

Google Cloud 提供了安全可靠的服务和产品，用于将您的工作负载公开给客户端。对于在 Compute Engine 实例上运行的工作负载，您可以为以下类别配置资源：

  • 防火墙
  • 流量负载均衡
  • DNS 名称、区域和记录
  • DDoS 防护和 Web 应用防火墙

对于这些类别中的每一个，您可以首先实现一个基线配置，该配置类似于您在等效类别中配置 AWS 服务和资源的方式。然后，您可以迭代配置并使用 Google Cloud 服务提供的其他功能。

以下部分介绍了如何预配和配置这些类别中的 Google Cloud 资源，以及它们如何映射到类似类别中的 AWS 资源。

防火墙

如果您配置了 AWS 安全组以及 AWS 网络防火墙政策和规则，则可以配置 Cloud 新一代防火墙政策和规则。您还可以预配 VPC Service Controls 规则以监管 VPC 内的网络流量。您可以使用 VPC Service Controls 阻止与 Compute Engine 实例的不需要的网络连接，并帮助降低数据渗漏的风险。

例如，如果您使用 AWS 安全组来允许或拒绝与您的 Amazon EC2 实例的连接，您可以配置适用于您的 Compute Engine 实例的类似 Virtual Private Cloud (VPC) 防火墙规则。

流量负载均衡

如果您已在 AWS 环境中配置 Elastic Load Balancing (ELB)，则可以配置 Cloud Load Balancing 以分配网络流量，以帮助提高工作负载的可扩缩性。Cloud Load Balancing 支持多个全球和区域负载均衡产品，这些产品在 OSI 模型的不同层工作，例如传输层和应用层。您可以选择适合工作负载要求的负载均衡产品。

Cloud Load Balancing 还支持配置传输层安全协议 (TLS) 来加密网络流量。为 Cloud Load Balancing 配置 TLS 时，您可以根据自己的要求使用自行管理或 Google 管理的 TLS 证书。

DNS 名称、区域和记录

如果您在 AWS 环境中使用 Amazon Route 53，则可以在 Google Cloud 中使用以下内容：

例如，如果您使用 Amazon Route 53 注册网域，则可以将域名注册转移到 Cloud Domains。同样，如果您使用 Amazon Route 53 配置了公共和专用 DNS 区域，则可以将该配置迁移到 Cloud DNS。

DDoS 防护和 Web 应用防火墙

如果您在 AWS 环境中配置了 AWS Shield 和 AWS WAF，则可以使用 Google Cloud Armor 保护您的 Google Cloud 工作负载免受 DDoS 攻击和常见漏洞攻击。

重构部署和操作流程

将虚拟机迁移到 Compute Engine 后，您可以重构流程以执行以下操作：

  • 在 Google Cloud 环境中预配和配置资源，而不是预配 Amazon EC2 实例和 Amazon EC2 AMI 等 AWS 资源。
  • 在 Compute Engine 中构建、部署和配置工作负载，而不是在 Amazon EC2 中部署工作负载。

您在此过程早期的评估阶段收集了有关这些流程的信息。

您需要为这些流程考虑的重构类型取决于您如何设计和实现它们。重构还取决于您希望每个流程的最终状态是什么。例如，应该考虑以下事项：

  • 您可能已经在 AWS 环境中实现了这些流程，并打算在 Google Cloud 中设计和实现这些流程。
  • 您可能已在 AWS 环境之外的其他第三方环境中实现这些流程。在这种情况下，您需要重构这些流程，以定位您的 Google Cloud 环境，而不是 AWS 环境。
  • 之前方法的组合。

重构部署和运营流程可能很复杂，并且可能需要花费大量精力。如果您尝试将这些任务作为虚拟机迁移的一部分执行，则迁移可能会变得复杂，并可能使您面临风险。评估部署和操作流程后，您可能了解其设计和复杂性。如果您估计重构部署和操作流程需要大量工作，我们建议您考虑将重构这些流程作为单独的专用项目的一部分。

如需详细了解如何在 Google Cloud 上设计和实现部署流程，请参阅以下文档：

迁移后优化您的环境

完成所有迁移阶段后，迁移就被视为完成。但是，您的 Google Cloud 环境可能需要进一步优化。如需了解详情，请参阅使用 Migrate to VMs 进行迁移的过程：优化您的环境。

后续步骤