将 Amazon API 网关迁移到 Azure API 管理

如果使用 Amazon API 网关并希望将工作负荷迁移到 Azure，本指南可帮助你了解功能映射、最佳做法和迁移过程。 在 Azure 上， Azure API 管理 提供 API 网关功能。 这些功能包括 API 请求和响应路由、授权和访问控制、监视和管理以及 API 版本管理。

你要完成的操作

在本指南中，你将：

• 评估当前的 Amazon API 网关部署。
• 将 Amazon API 网关功能映射到 Azure API 管理功能。
• 为成功迁移准备 Amazon 和 Azure 环境。
• 在最短的停机时间内规划和执行迁移。
• 验证迁移的工作负载是否符合性能和可靠性要求。
• 了解如何在架构上进行迭代，以实现未来的增强功能。

示例场景：多后台健康记录系统

健康服务组织使用 Amazon API 网关访问具有多个后端的健康记录系统。 此示例方案在 Amazon Web Services （AWS） 环境中具有 Amazon API 网关的常见配置。 它显示了与相关 Amazon 服务和多个常见 API 后端的典型集成，包括代理 Lambda 函数和 HTTP 或 REST API。

此体系结构包括：

• 通过 Amazon Cognito 通过 JSON Web 令牌（JWT）进行用户身份验证。

• 在访问 Amazon API 网关之前，通过 Amazon Web 应用程序防火墙（WAF）对请求进行安全筛选。

• Amazon API 网关通过存储在证书管理器中的证书配置了自定义域。

• 通过 Amazon CloudWatch 进行监视。

• 通过 Amazon 虚拟私有云 (VPC) 终端节点与三个私有子网建立私有连接。

• 后端服务，包括：

  • 用于触发患者记录更新的 Lambda 函数。
  • Amazon Elastic Compute Cloud （EC2），它托管应用程序负载均衡器后面的旧服务。
  • Amazon Elastic Kubernetes Service (EKS) 位于应用程序负载均衡器之后，用于通过微服务进行数据处理。

下面是迁移到 Azure 的工作负荷的示例体系结构。 在此方案中，Azure API 管理部署在高级层中。

此体系结构包括：

• 使用 Web 应用程序防火墙（WAF）通过 Azure 应用程序网关保护入口。 防火墙转发附加 JWT 进行身份验证的请求。

• 在虚拟网络中配置的 Azure API 管理。 它使用 Microsoft Entra ID 来验证 JWT。

• 一个内部负载均衡器，用于将流量路由到基于微服务的后端的 Azure Kubernetes 服务（AKS）。

• 通过专用终结点安全连接到 Azure 函数应用和 Microsoft Foundry 后端。

• 监视由 Azure Monitor 处理。

• 通过 Azure Key Vault 和 Azure DNS 区域管理的证书和域名。 还会在应用程序网关上配置证书，以便终止 TLS。

体系结构概述

此体系结构示例展示了 Amazon API 网关和 Azure API 管理中的常见功能。 这些功能包括网络隔离、流量管理和路由到各种后端 API、授权和访问控制以及监视。

这两种体系结构都提供可比的功能：

• 高可用性部署：资源分布在区域中的多个可用性区域以实现容错，通过部署到多个区域提供更高的可用性选项。

• 自定义域和证书：平台支持使用 TLS/SSL 终止的自定义域名进行安全 API 通信。

• 网络隔离：后端 API 的流量在虚拟网络中被隔离。

• 流量筛选：在网络边缘的 Web 应用程序防火墙，能够帮助保护入站流量。

• API 工作负荷支持：网关充当对各种后端系统（包括云服务、基于 Kubernetes 的微服务和自定义后端）的请求的代理。

• API 监控：内置平台服务记录 API 活动并展示服务指标。

• API 调节：服务支持响应缓存、请求配额和速率限制、跨域资源共享（CORS）配置和请求/响应转换。

• API 身份验证和授权：网关支持多种访问方法，包括密钥、基于 OAuth 令牌的访问和基于 API 的策略。

步骤 1：评估

在从 Amazon API 网关迁移到 Azure API 管理之前，请评估现有的基础结构功能、API 工作负载和 API 配置。 确定映射或替换的功能。 此评估有助于确保顺利迁移并维护应用程序的功能。

评估基础结构功能

功能不匹配和策略

• Amazon API 网关中的 WAF 集成在 Azure API 管理中没有直接匹配项。 在 Amazon API 网关中，WAF 规则直接应用于 REST API 阶段。 在 Azure API 管理中，WAF 规则的配置通常需要通过网关部署上游应用程序网关实例、流量转发和 TLS 终止。 或者，对于主动/主动多区域方案，请在 Azure API 管理前面使用 Azure Front Door。
• Azure API 管理支持自定义域。 如果在前面使用应用程序网关和 Azure Web 应用程序防火墙，则还必须在应用程序网关层配置自定义域和 TLS 证书。
• Amazon API 网关中的边缘优化节点支持分布在不同地理位置的客户端。 Azure API 管理中的类似功能需要以额外的成本部署额外的区域网关。

比较 API 工作负载

作为评估的一部分，请考虑是保留还是替换现有服务。 评估迁移是否是实现服务现代化或合并的机会。

功能不匹配和策略

• Amazon API 网关原生支持Lambda 后端，可用作 HTTP API。 Azure API 管理不提供与类似 Azure 函数应用的本地集成。 Azure API 管理必须使用函数密钥或托管标识通过 HTTP 调用函数应用。
• 从 Amazon API 网关 REST API 导出的 OpenAPI 规范包含特定于 Amazon API 网关中前端实现的详细信息，而不是后端服务。 在导入到 Azure API 管理或迁移过程中，需要删除特定于 AWS 的标记并在规范（例如后端服务 URL）中配置详细信息。
• Kubernetes 微服务 后端（如 gRPC API）的处理方式不同：
  • Amazon API 网关连接到 VPC 中的应用程序负载均衡器，进而为 AWS EKS 提供入口。
  • Azure API 管理支持仅通过自托管网关访问的 Kubernetes 群集上的 gRPC API。
  • 使用 gRPC 可防止将应用程序网关用作 WAF。

比较 API 配置

API 配置的迁移方法必须考虑 Amazon API 网关中的配置 范围 。 从总体上看，Amazon API Gateway 到 Azure API Management 的 API 作用域映射关系如下：

下表评估 Amazon API 网关中的 API 配置和 Azure API 管理中的等效配置：

功能不匹配和策略

• 每个 AWS 帐户的 Amazon API 网关设定配额和速率限制。 在 Azure API 管理中，最高范围是每个实例的“所有 API”范围。

• Amazon API 网关中的 API 身份验证和授权方法（例如 IAM 权限和 Lambda 授权者）不会直接映射到 Azure API 管理。 客户可以评估备用身份验证和授权方法，例如使用 Microsoft Entra ID 或外部标识提供者。

• Amazon API 网关中的缓存相关指标不会直接映射到 Azure API 管理指标。 可以在 Azure API 管理中的跟踪日志中计算缓存命中数和未命中数。

审查迁移资源

• Azure API 管理着陆区

• Azure API 管理的体系结构最佳做法

• Azure API 管理中的 API 身份验证和授权

• 面向 AWS 专业人员的 Azure

• Microsoft Copilot 在 Azure 中用于 API 管理策略生成

• AWS 文档 MCP 服务器 和 Microsoft Learn MCP 服务器

此外，对于 API 工作负载：

• 将 AWS Lambda 工作负载迁移到 Azure Functions

• 从 Amazon Elastic Kubernetes 服务迁移到 Azure Kubernetes 服务

步骤 2：准备

在准备阶段，规划 Azure 基础结构，选择适当的 API 管理层进行测试和生产，并全面记录源 API 和集成服务。 导出相关的 AWS 配置并设计分阶段迁移策略，以确保平稳过渡。

规划基础结构设置

规划入口和出口、防火墙、网络隔离以及与应用程序网关、Azure Front Door 或 Azure 流量管理器等网络流量入口点的集成。 了解目标 Azure API 管理系统的专用公开与公开公开的影响，尤其是在 DNS 和可追溯性方面。

查看 Azure API 管理登陆区域加速器 中的指南，并评估可能适合迁移和 API 后端的方案。 考虑一下在何种情况下这些工作负载的独立性已经足够高，从而能够从中受益。

在 Azure 中，可用于初始迁移和开发的基本方案是具有 示例工作负荷的安全基线。

规划测试和生产 API 管理实例

为测试和生产环境选择适当的 Azure API 管理服务层：

• 如果需要对入站和出站流量进行网络隔离，以及通过 Azure Front Door 或应用程序网关的流量输入，我们目前建议使用 Azure API 管理高级层。 如果选择高级层级，则可以使用开发人员层级（不支持服务级别协议）进行概念验证迁移。 开发人员层支持在高级层中也可用的网络功能。 但是，不应将开发人员层用于生产。

• 根据可用性、性能和网络隔离的要求，请考虑标准 v2 或高级 v2 层。 两者都支持与网络隔离后端的集成。 高级 v2 层还支持注入虚拟网络，以隔离入站流量。

• 目前，具有隔离入站流量的功能的高级 v2 层处于预览状态。 可以根据实现时间线，考虑将其用于迁移，具体取决于有关 Premium v2 版本和迁移路径的可用信息。

了解并记录管理中的源 API

捕获 API 配置，包括身份验证和授权流、转换和缓存机制。

确定与 Amazon API 网关集成的所有服务，例如 Lambda 授权者、应用程序负载均衡器、网络负载均衡器和 Kubernetes 工作负载。

若要对管理中的 API 进行编录，请考虑使用 Azure API 中心 并从 Amazon API 网关 同步 API。

尽可能使用发现工具，例如 AWS 资源资源管理器 。 但预计在很大程度上依赖于手动收集的信息、内部文档和清单。

记录数据流、网络拓扑和体系结构关系图，即使它们大致如此。

尽可能导出 AWS 配置

导出配置，例如：

• 后端 API 提供的 OpenAPI 规范;例如，使用 AWS 控制台或 AWS CLI。 如果 API 最初是通过 OpenAPI 定义的，则可能已有这些规范。

• 存储在 AWS 证书管理器中的 SSL/TLS 证书。

• 通过导出到 CloudFormation 来设置 WAF 规则。

捕获可能通过外部工具导出到 Terraform 的工件，包括 CloudFormation 模板。 这些工件有助于映射到 Azure（Bicep、Azure 资源管理器和 Terraform 模板）。

规划分阶段策略

我们建议您规划一个分阶段的迁移策略（逐个 API 或逐个域进行迁移）。 将一组域或 API 终结点更新到 Azure API 管理，而另一组域或 API 终结点仍保留在 AWS 上，然后逐渐移动其余域。 此策略可能需要客户端应用程序处理混合终结点或使用路由层。

步骤 3：评估

如果迁移的系统满足验证条件，并且当 Azure API 管理为所有生产流量提供服务且功能或性能没有显著回归时，迁移会被视为成功。

验证条件包括：

• 验证基础结构：网络基础设施已记录在案，并且仅按预期方式访问。 例如，如果将其注入到内部虚拟网络中，请确认没有公共 IP 会暴露该网络。

  Azure API 管理实例可以访问操作所需的任何网络或依赖项。

• 验证所有端点的 API 功能：所有 API 端点在实际场景中按预期进行操作，包括对有效和无效请求及有效负载的处理。 确保在配置的策略中进行任何请求或响应转换：

  • 为每个 API 确认所有必需的身份验证和授权配置（订阅密钥、OAuth 令牌、证书）。

  • 确认客户端可以像以前一样使用 API，没有任何变更 (如果域名已更改，可能接口 URL 除外)。

  • 确认在适当的范围内配置了速率限制和配额。

• 验证作指标：使用生产负载下的仪表板或其他可观测性工具监视性能。 查看平均延迟和吞吐量等指标，并将其与 Amazon API 网关的历史数据进行比较。 查看容量指标，以确保 Azure API 管理实例得到适当的扩展。

步骤 4：流程

预计迁移过程需要数周或数月，具体取决于服务基础结构的复杂性以及要迁移的 API 的数量和复杂性。

完成基础设置

如果还没有 Azure 租户和核心基础结构（核心网络、入口、安全性），请在迁移 Amazon API 网关和 API 之前生成它们。 可以使用适合迁移的 Azure 登陆区域体系结构来设置环境。

如果 Azure API 管理基础结构即代码登陆区域加速器适用于你的迁移需求，那么请为你的基础 Azure API 管理部署实施一个此类方案。 在 Azure API 管理中包含应用程序网关和内部虚拟网络。 尽管登陆区域加速器使用 Azure API 管理的高级层，我们建议调整模板以使用开发人员层进行概念验证迁移。

创建和分配 Azure 基于角色的访问控制（RBAC）角色，以便只有经过授权的管理员可以管理 Azure API 管理实例和 API。

配置 Azure API 管理平台设置

在新 Azure API 管理实例中，设置类似于 Amazon API 网关中的全局配置：

• 自定义主机名：将自定义域添加到 Azure API 管理，上传 SSL 证书（或使用 Key Vault 引用），并执行验证。 现在或者在生产切换之前执行此任务。 使用应用程序网关（建议）时，请使用自定义域和证书配置侦听器，然后将其指向 Azure API 管理的内部终结点。 配置侦听器简化了配置，因为它不需要域验证。

• 网络和安全性：确保将应用程序网关（或其他 Azure 入口点）配置为将请求转发到 Azure API 管理。 设置网络安全组（NSG）规则或防火墙规则，以便 Azure API 管理可以访问后端服务。 这些服务可以包括你的 Azure 后端，甚至包括你最初指向的源 AWS 后端。

• 托管标识：在 Azure API 管理上启用托管标识以安全方式调用 Azure 服务（例如证书或函数应用的 Key Vault）。

在此阶段结束时，应在 Azure 中拥有 Azure API 管理的工作外壳，其中包含连接性，并且基本框架已准备好开始导入 API。

在 Azure API 管理中导入和重新创建 API

准备好基础结构后，开始迁移 API 定义和配置：

• 从简单的低风险 API 开始：在从 Amazon API 网关重新创建 API 之前，使用具有代表性的 API 在 Azure API 管理中验证基本网关功能。

• 导入 Azure API 管理：使用 Azure 门户或脚本将 OpenAPI 定义从 Amazon API 网关或后端导入为 Azure API 管理中的新 API。 导入期间，Azure API 管理会自动创建 API 和作的结构。 如果在 Amazon API 网关中有多个 API 阶段，请在 Azure API 管理中创建多个 API 版本。

  最初，将每个 API 的后端 URL 设置为指向当前后端。 （目前，当前后端可能仍然是 AWS 终结点或公共终结点。例如，如果 Amazon API 网关转发到 Lambda，则可以将 Azure API 管理后端设置为 Amazon API 网关中的等效 API，如果已迁移，可将 Azure API 管理后端设置为等效的 Azure 函数应用。 （如果将 Azure API 管理后端设置为 Amazon API 网关中的等效 API，则在稍后将 Lambda 函数迁移到 Azure 时，将更改此配置。如果后端是 AWS 应用程序负载均衡器或终结点，Azure API 管理可以通过 Internet 调用它。

  如果有大量 API，可以使用 Azure API 中心对一段时间内迁移到 Azure API 管理的 API 进行编录，以及保留在 Amazon API 网关中的 API。

  在验证基础结构后，请考虑迁移或重构后端服务（例如，作为 Azure 函数应用或 AKS 工作负载）。 请参阅 Azure 迁移中心中的指南。

设置身份验证和授权

• 订阅和产品：如果 API 需要 Amazon API 网关中的 API 密钥（通过 x-api-key 标头），请决定如何在 Azure API 管理中处理该密钥。 一种方法是让只有拥有产品订阅的用户才能访问这些 API。 在 Azure API 管理中创建初始产品，可以与 AWS 使用计划一一对应，或者按逻辑进行重新组织。

• 用户组：在 Azure API 管理中创建用户组，以反映与开发人员共享 API 的方式。

• 命名值：将 Amazon API 网关阶段变量中的任何配置值（如后端服务的终结点或 API 密钥）导入到 Azure API 管理命名值中。 对于敏感值，请使用 Azure Key Vault 集成。

• 令牌检索和验证：对于 API 请求的 JWT 验证，请在 Azure API 管理中配置验证策略，以授权 API 访问。 最初可以使用现有的标识提供者（例如 AWS Cognito），并考虑随时间推移迁移到 Microsoft Entra ID。

  在 Azure API 管理中配置凭据管理器，以管理到 OAuth 后端的令牌。 或者，使用 策略代码片段存储库中的策略设置令牌检索逻辑。

• Azure API 管理中的后端：在 Azure API 管理中配置后端以注册每个后端服务（其 URL、凭据和其他信息）。 此操作提供一个中心位置，用于在后端 URL 发生更改时进行更新。 例如，如果最初指向 AWS 终结点，但后来切换到 Azure 后端，则只需更新 Azure API 管理后端配置。

• 功能奇偶校验检查：浏览每个 API 使用的功能列表，并确保它们得到解决。

  例如，用于处理二进制有效负载（图像和文件）或大型有效负载的测试 API。 确保 Azure API 管理服务为这些方案配置足够的超时、大小或内容验证设置。

  Azure API 管理对所有导入的 API 进行相当统一的处理，以便 Amazon API 网关 HTTP API （较新的轻型类型）与 REST API （经典类型）在 Azure API 管理中一致管理。 在将 API 移至 Azure API Management 后，诸如 HTTP API 中未设置使用计划这类问题就不再重要了，但要确保处理好任何与 Amazon API 网关相关的特定限制条件。

管理数据转换和政策映射

将现有 API 配置作为 Azure API 管理策略进行复制，尤其是在授权和向后兼容性的情况下。

将 Amazon API 网关中的 CORS 配置映射到 Azure API 管理中的 CORS 策略。

逐案处理转换（如架构映射或扩充）。

AI 工具（例如 Azure 门户中的 Azure 中的 Microsoft Copilot）以及 AWS 和 Microsoft 文档的 MCP 服务器，可以帮助进行配置映射或其他转换。 但是，预期在 Azure API 管理中执行手动策略配置和调试。

设置可观测性

若要进行初始监视，请将 Azure Monitor 配置为收集 API 指标和日志。 以后可以分层更多的监视或可观测性解决方案，如 Application Insights。

执行测试

在 Azure API 管理中配置 API 后，彻底的测试至关重要。 预计此阶段将是迭代的。

• 功能测试：对于每个 API，调用新的 Azure API 管理终结点（通过 Azure 门户的测试控制台或客户端工具），并将响应与 Amazon API 网关终结点进行比较。 检查预期的状态代码、标头和正文。 如果发现差异，请相应地调整 Azure API 管理策略或配置。

  注释

  如果 API 管理实例位于内部虚拟网络配置中，则测试控制台将不起作用。 可以使用网络中部署的其他客户端工具或使用 API 管理开发人员门户（如果为实例启用 API）来测试 API。

• 安全测试：验证 API 身份验证和授权是否正常工作。 例如，向 Azure API 管理提供有效的 JWT 或订阅密钥。 确保 Azure API 管理接受请求，并使用正确的错误代码拒绝无效凭据。 如果在迁移期间配置了不同的标识提供者，则传递用于 JWT 验证的令牌的客户端可能需要使用该标识提供者重新授权。 如果使用订阅密钥，请进行两种测试：一种是使用密钥，另一种是不使用密钥。

• 性能基线：使用工具模拟 Azure API 管理终结点上的负载，并验证它们是否可以处理预期的吞吐量。 通过 Azure API 管理将调用的延迟与 Amazon API 网关的延迟进行比较。 开发人员层中的 Azure API 管理的性能低于高级层和单一实例，因此繁重的性能测试可能会等到部署高级层 Azure API 管理实例。

开始产品发布

升级到生产环境中的 Azure API 管理的高级层或其他生产就绪层。 重复或迁移在预生产环境中创建的 API 导入和配置设置。 可以使用 APIOps 进程跨环境发布 API 和管理 API 配置。

在等级较低环境中排练直接转换或使用部分流量。 例如，选择一个非关键 API，并让一个客户端应用程序切换到使用 Azure 终结点。 这种做法可以揭示任何客户端问题或帮助验证 DNS 更改过程。 如果 API 使用者是内部的，可以通过编辑主机文件或使用测试 DNS 区域暂时将域指向 Azure API 管理来模拟更改。

• DNS 切换：最常见的方法是将自定义 Amazon API 网关的 DNS 记录转向新的 Azure 终结点。 例如，如果将域 api.example.com 映射到 Amazon API 网关，请更新其 CNAME 或 A 记录以指向 Azure API 管理主机名或前端（如应用程序网关）域。

• 生存时间 (TTL) 注意事项：提前降低 DNS TTL，以便客户端快速获取更改。 准备就绪后，请更改 DNS。 传播可能需要数分钟到数小时。 在此期间，某些流量可能仍会转到 AWS，而有些流量会转到 Azure。 如果需要立即剪切，可以使用备用方法，例如反向代理。

• 替代切换方法：有时组织使用反向代理或网关切换，而不是 DNS。 例如，组织可能会使公共 DNS 保持不变，但最初有应用程序网关将请求转发到 Amazon API 网关（通过其 URL）。 在翻转过程中，组织会将应用程序网关指向 Azure API Management。 此方法更为复杂，但它可以实现即时切换。 如果使用 Azure Front Door 或流量管理器，则另一种方法是逐步将流量从一个后端（AWS）重新加权到另一个后端（Azure）。

• 切换期间的监控：一旦切换发生，请密切监视对 Azure API 管理实例和 Amazon API 网关的请求。 通过 Azure 门户或设置的任何仪表板实时监视 Azure API 管理指标（请求、延迟、CPU、容量内存）。 此外，使用 Azure Monitor 监测错误峰值，如 4XX/5XX 响应。

• 回滚计划：确定触发回滚的内容。 例如，如果错误率超过特定百分比或关键功能中断，则可以在 30 分钟内还原。 回滚是指撤销你所做的任何更改。 例如，如果交换机是 DNS，请将 DNS 记录还原为指向 Amazon API 网关。 由于 DNS 传播，回滚可能需要一些时间。 回滚时间强调了使用较低的生存时间 (TTL) 以及同时保持两个系统运行的重要性。 如果使用了反向代理，请将其恢复到 AWS。

停用 Amazon API 网关

在收到零流量且 Azure API 管理实例满足验证条件的时间段后，停用 Amazon API 网关。 通常，您会并行运行两个系统，通过至少一个完整的业务周期或高峰流量期，并将所有流量引导至 Azure，以确保新系统能够处理这些流量。

迭代优化

迁移后，请专注于通过缩小功能差距并实施最佳做法来迭代优化 API 管理配置。 此迭代改进过程可确保迁移的工作负荷满足评估步骤期间建立的所有成功条件。 它还可确保迁移的工作负荷遵循 API 管理的体系结构最佳做法。

迭代改进功能缺口

一些 Amazon API 网关功能在 Azure API 管理中没有一对一映射，需要解决方法，如 评估部分前面 所述。 例如：

• Web 应用程序防火墙：Azure API 管理不会自动阻止 AWS WAF 阻止的错误有效负载。 如果设置了 Azure Web 应用程序防火墙，请确保只能通过 WAF 访问 Azure API 管理，并且该 WAF 规则复制 AWS WAF 限制。

• 事件流：如果 CloudWatch 警报或事件绑定到 Amazon API 网关（例如，在某些错误模式上），则在 Azure Monitor for Azure API 管理中设置等效的警报（例如，针对 Azure API 管理 5XX 速率的警报）。

• 自动化：如果有持续集成和持续交付（CI/CD）管道，可将 Azure API 管理集成到其中。 例如，可以使用基础结构即代码方法将 Azure API 管理配置（API 和策略）存储在源代码管理中。 这些方法可能包括 Azure 资源管理器、Bicep 或 Terraform 模板，或 APIOps 方法。 此集成可确保将来对 API 的更改与受控版本控制一致地进行部署。

实现最佳做法

以迭代方式实施最佳做法，包括成本优化、安全强化和运营改进。 查看和实施 Azure API 管理的体系结构最佳做法，并遵循可靠性、安全性、卓越运营、成本管理和性能的支柱。 解决 Azure API Management 实例中的 Azure Advisor 建议。

随着时间的推移，逐渐添加更多功能，例如：

• 外部缓存。
• Azure Monitor 以外的监视功能，例如 Application Insights 或非Microsoft解决方案（如 Datadog）。
• Azure API 管理中的策略在 Amazon API 网关中不可用。

关键结论

将 Amazon API 网关迁移到 Azure 需要仔细规划和系统执行才能获得等效的功能或替代方法。 关键成功因素包括：

• 全面评估：对现有 Amazon API 网关设置进行详细评估，包括所有 API、服务集成和依赖项。 确定 Amazon API 网关与 Azure API 管理之间的功能差距或差异。

• 现代化的机会：利用迁移作为现代化或迁移后端服务或改进 API 设计的机会。

• 全面准备：准备 Azure 环境，包括网络、安全性和基础结构设置。 记录所有配置，并计划对后端服务进行任何必要的更改。

• 增量迁移：规划增量迁移方法，从不太关键的 API 或服务开始。 这种方法能够在您完全承诺切换之前测试和验证新的配置。

• 验证和测试：实施全面的测试和验证过程，以确保 Azure API 管理实例满足所有功能和性能要求。 这项工作包括负载测试、安全测试和用户验收测试。

• 监视和可观测性：为新的 Azure API 管理实例设置可靠的监视和可观测性，以快速识别和解决迁移期间或之后出现的任何问题。

• 迭代优化：迁移后，通过解决功能差距并实施最佳做法来持续优化 Azure API 管理设置。