如果您使用 Amazon API Gateway 並想要將工作負載遷移到 Azure，本指南可協助您了解功能對應、最佳實務和遷移程序。 在 Azure 上， Azure API 管理 提供 API 閘道功能。 這些功能包括 API 請求和回應路由、授權和存取控制、監控和治理，以及 API 版本管理。
您將完成的作業
在本指南中，您會：
- 評估您目前的 Amazon API Gateway 部署。
- 將 Amazon API 閘道功能對應至 Azure API 管理 功能。
- 準備您的 Amazon 和 Azure 環境以成功移轉。
- 規劃和執行移轉，將停機時間降至最低。
- 驗證您移轉的工作負載是否符合效能和可靠性需求。
- 學習如何在架構上進行迭代來促成未來的改進。
範例案例：多個後端健康記錄系統
健康服務組織使用 Amazon API Gateway 存取具有多個後端的健康記錄系統。 此範例案例具有 Amazon Web Services （AWS） 環境中 Amazon API Gateway 的常見組態。 它顯示了與相關 Amazon 服務和數個常見 API 後端的典型整合，包括代理 Lambda 函數和 HTTP 或 REST API。
此架構包括：
透過 Amazon Cognito 使用 JSON Web 權杖 （JWT） 進行使用者驗證。
在請求到達 Amazon API Gateway 之前，透過 Amazon Web Application Firewall （WAF） 對請求進行安全篩選。
Amazon API Gateway 透過存放在 Certificate Manager 中的憑證設定自訂網域。
透過 Amazon CloudWatch 監控。
透過 Amazon Virtual Private Cloud (VPC) 端點連向三個私人子網路的私人連線。
後端服務，包括：
- Lambda 函數用於觸發病患記錄的更新。
- Amazon Elastic Compute Cloud（EC2），在應用負載平衡器後面託管舊版服務。
- Amazon Elastic Kubernetes Service (EKS)，位於應用程式負載平衡器後面，可透過微服務進行資料處理。
以下是移轉至 Azure 之工作負載的範例架構。 在此案例中，Azure API 管理 會部署在進階層中。
此架構包括：
透過 Azure 應用程式閘道與 Web 應用程式防火牆 （WAF） 進行安全進入。 防火牆會轉送添加 JWT 以進行身份驗證的請求。
在虛擬網路內設定的 Azure API 管理。 它會使用 Microsoft Entra ID 來驗證 JWT。
內部負載平衡器，將流量路由至 Azure Kubernetes Service （AKS），以支援微服務型後端。
透過私有端點與 Azure 函式應用及 Microsoft Foundry 後端的安全連線。
由 Azure Monitor 進行的監控。
憑證和網域會透過 Azure 金鑰保存庫和 Azure DNS 區域管理。 也會在應用程式閘道上設定憑證以終止 TLS。
架構概觀
此架構範例展示 Amazon API Gateway 和 Azure API 管理中的常見功能。 這些功能包括網路隔離、流量管理和路由到各種後端 API、授權和存取控制以及監控。
兩種架構都提供類似的功能：
高可用性部署：資源會分散在區域中的多個可用性區域，以實現容錯，並可選擇部署至多個區域，以取得更高的可用性。
自訂網域和憑證：這些平台支援具有 TLS/SSL 終止的自訂網域名稱，以實現安全的 API 通訊。
網路隔離：後端 API 的流量會隔離在虛擬網路中。
流量過濾：邊緣的 Web 應用程式防火牆會過濾並協助保護傳入流量。
API 工作負載支援：閘道充當對各種後端系統請求的代理，包括雲端運算服務、基於 Kubernetes 的微服務和自訂後端。
API 監控：內建平台服務記錄 API 活動並公開服務指標。
API 調製：服務支援回應快取、請求配額和速率限制、跨來源資源共用 （CORS） 設定以及請求/回應轉換。
API 身份驗證和授權：網關支援多種存取方法，包括金鑰、基於 OAuth 令牌的存取和基於 API 的策略。
步驟 1：評估
從 Amazon API Gateway 移轉至 Azure API 管理之前，請評估現有的基礎結構功能、API 工作負載和 API 組態。 識別要對應或取代的功能。 此評估有助於確保順利遷移並維護應用程式的功能。
備註
Amazon API Gateway 功能可能會有所不同，具體取決於您是將 API 公開為 REST API 還是 HTTP API 產品類型。 在 Azure API 管理 中，功能會因服務層級而異，而不是依 API 類型指定而有所不同。
評估基礎結構功能
| Amazon API Gateway 功能 | Azure API 管理 等效產品 | 移轉方法 |
|---|---|---|
| 私有 VPC 端點 |
Azure API 管理 部署至內部虛擬網路 將 API 管理與私人虛擬網路整合以建立輸出連線 |
在插入或整合 Azure API 管理 服務的虛擬網路中設定後端的專用子網，或透過 Azure Private Link 連線到後端。 |
| AWS Web 應用程式防火牆 | Azure Web 應用程式防火牆;例如，在 Azure 應用程式閘道 （區域服務） 或 Azure Front Door （全域服務） 中 | 將 Amazon API Gateway 中 API 階段套用的 WAF 規則對應至 Azure Web 應用程式防火牆中的服務層級規則。 |
| 自訂網域 | 在 Azure API 管理 中設定的自訂網域和上游進入點，例如應用程式閘道或 Azure Front Door | 使用相同的網域名稱和現有憑證，搭配外部網域名稱系統 (DNS) 完全移轉。 如果移轉使用不同的網域名稱，則需要取得新的憑證。 |
| 邊緣最佳化端點 | 多區域部署 | 根據用戶端存取的需求，在多個區域中設定 Azure API 管理 閘道。 此拓撲通常會與 Azure Front Door 中的全域存在點配對。 |
| 預設的可用區域 | 預設的可用性區域 （進階層） | 在支援可用性區域的地區，部署 Azure API 管理於高級階層。 使用可用性區域的預設自動組態。 |
| CloudWatch 指標 | Azure 監視器計量 | 設定閘道要求計量，以支援將 Azure API 管理 效能與 Amazon API Gateway 中的基準進行比較。 |
| CloudWatch 日誌 和 CloudTrail 日誌 | Azure 監視器記錄 | 設定診斷設定，將 Azure API 管理 記錄傳送至 Log Analytics 工作區，以進行內建分析和自訂分析。 請考慮部署 Application Insights 或其他 可觀測性工具 ，以新增作業監視。 |
備註
在移轉之前，請從 Amazon API Gateway 建立基準指標。 使用這些基準來比較移轉之後的 Azure API 管理 效能，並確認它符合或超過預期。
功能不相符和策略
- Amazon API Gateway 中的 WAF 整合於 Azure API 管理中沒有直接對應項目。 在 Amazon API Gateway 中，WAF 規則會直接套用至 REST API 階段。 在 Azure API 管理 中，WAF 規則的設定通常需要部署上游應用程式閘道執行個體、流量轉送，以及透過閘道終止 TLS。 或者，若為主動/主動多區域案例，請在 Azure APIM 前使用 Azure Front Door。
- Azure API 管理 支援自訂網域。 如果您在前面使用應用程式閘道和 Azure Web 應用程式防火牆，您也必須在應用程式閘道層設定自訂網域和 TLS 憑證。
- Amazon API Gateway 中的邊緣最佳化端點支援地理上分散的用戶端。 Azure API 管理 中的類似功能需要以額外成本部署額外的區域閘道。
比較 API 工作負載
作為評估的一部分，請考慮是否保留或取代現有服務。 評估移轉是否是現代化或整合服務的機會。
| Amazon API Gateway 工作負載 | Azure API 管理 等效產品 | 移轉方法 |
|---|---|---|
|
Lambda Proxy 整合 (英文) Lambda 非代理（自訂）整合 使用 Amazon API Gateway 端點叫用 Lambda |
Azure 函式應用程式 API 類型 | 考慮是否要保留或取代現有的 Lambda 函數 （例如，使用 Azure 函數或容器）。 |
|
REST API HTTP API |
匯入 OpenAPI 規格 | 從 Amazon API Gateway 匯出 REST API ，並將其匯入 Azure API 管理。 或者，手動存取 Amazon API 閘道中的 API 設定，並在 Azure API 管理 中重新建立它。 |
| WebSocket API | WebSocket API 類型 | 手動存取 Amazon API Gateway 中的 API 設定，並在 Azure API 管理 中重新建立它。 |
功能不相符和策略
- Amazon API Gateway 原生支援 Lambda 後端作為 HTTP API。 Azure API 管理 不提供與類似 Azure 函式應用程式的原生整合。 Azure API 管理 必須使用函式金鑰或受控識別，透過 HTTP 呼叫函式應用程式。
- 從 Amazon API Gateway REST API 匯出的 OpenAPI 規格包含 Amazon API Gateway 中前端實作的特定詳細資訊，而不是後端服務。 您必須先移除 AWS 特定的標籤，並在規格中設定詳細數據 （例如後端服務 URL），才能匯入至 Azure API 管理 或移轉程式期間。
-
Kubernetes 微服務 後端 （例如 gRPC API） 的處理方式不同：
- Amazon API Gateway 連線至 VPC 中的應用程式負載平衡器，進而提供對 AWS EKS 的輸入。
- Azure API 管理支援 Kubernetes 叢集上的 gRPC API，並且僅能透過自我託管閘道存取。
- 使用 gRPC 可防止將應用程式閘道用作 WAF。
比較 API 設定
API 組態的移轉方法必須考慮 Amazon API Gateway 中的組態 範圍 。 從高層次來看，Amazon API Gateway 與 Azure APIM 之間的 API 範圍對應如下：
| Amazon API Gateway API 範圍 | Azure API 管理 等效產品 |
|---|---|
| API 資源 | API |
| API 階段 | API 版本 |
| API 方法 | API 作業 |
| 使用計劃 | Product |
下表評估 Amazon API Gateway 中的 API 組態，以及 Azure API 管理 中的對等組態：
| Amazon API Gateway API 組態 | Azure API 管理 等效產品 | 移轉方法 |
|---|---|---|
| 階段變數 | 具名值 | 在 Azure API 管理 的服務層級設定具名值 （名稱/值組）。 |
| 回應快取 | 回應快取 | 在對應的範圍內設定快取原則，如上表所示。 或者，配置外部 Redis 相容快取以獲得更好的控制和可靠性。 |
| 使用方案和 API 金鑰 | 產品 和 訂閱 | 記錄 Amazon API 閘道設定，並在 Azure API 管理 中重新建立它們。 |
| 節流和配額 | 流量限制和配額策略 | 在對應的範圍內設定速率限制和配額原則，如上表所示。 |
| CORS | CORS 原則 | 在對應的範圍使用允許的標頭和來源設定 CORS 原則，如上表所示。 |
|
資源原則 VPC 端點政策 Cognito 使用者集區 mTLS 驗證 |
驗證和授權原則 認證管理員 |
手動映射。 考慮搭配 Azure 中的 Microsoft Copilot 等工具使用 AI 協助。 |
| 對應範本 | 轉型政策 | 手動映射。 考慮搭配 Azure 中的 Microsoft Copilot 等工具使用 AI 協助。 |
| API 階段 | API 版本 | 在 Azure API 管理 中建立 API 版本。 |
功能不相符和策略
配額和節流限制 由 Amazon API Gateway 針對每個 AWS 帳戶施加。 在 Azure API 管理 中，最高範圍是每個執行個體的「所有 API」範圍。
Amazon API Gateway 中的 API 驗證和授權方法 （例如 IAM 許可和 Lambda 授權者） 不會直接對應至 Azure API 管理。 客戶可以評估替代驗證和授權方法，例如使用 Microsoft Entra ID 或外部身分識別提供者。
Amazon API Gateway 中的快取相關計量不會直接對應至 Azure API 管理 計量。 在 Azure APIM 中，可以在追蹤記錄中計算快取命中和快取遺漏次數。
檢閱移轉資源
Azure 中的 Microsoft Copilot 用於產生 API 管理 原則
此外，針對 API 的工作負載：
步驟 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 或 Premium v2 等級。 兩者都支援與網路隔離後端的整合。 Premium v2 層也支援注入虛擬網路以隔離入站流量。
目前，具有隔離傳入流量功能的進階版 v2 層處於預覽階段。 您可以考慮將其用於遷移，這取決於您的實作時間表與 Premium v2 發行版本以及遷移路徑的可用資訊之間的關係。
瞭解並記錄所管理的來源 API
擷取 API 組態，包括驗證和授權流程、轉換和快取機制。
識別與 Amazon API Gateway 整合的所有服務，例如 Lambda 授權者、應用程式負載平衡器、網路負載平衡器和 Kubernetes 工作負載。
若要對管理下的 API 進行編目，請考慮使用 Azure API Center 並 同步 Amazon API Gateway 的 API。
盡可能使用探索工具，例如 AWS Resource Explorer 。 但預計會嚴重依賴手動收集的資訊、內部文件和清單。
記錄資料流程、網路拓撲和架構圖，即使它們是近似值。
盡可能匯出 AWS 組態
匯出設定，例如：
來自後端 API 的 OpenAPI 規範;例如，使用 AWS 主控台或 AWS CLI。 如果 API 最初是透過 OpenAPI 定義的，您可能已經擁有這些規格。
存放在 AWS Certificate Manager 中的 SSL/TLS 憑證。
WAF 規則，匯出至 CloudFormation。
擷取可能透過外部工具匯出至 Terraform 的成品 (包括 CloudFormation 範本 (英文))。 這些構件可協助對應至 Azure （Bicep、Azure Resource Manager 和 Terraform 範本）。
規劃分階段策略
建議您規劃分「階段式移轉」(逐個 API 或逐個網域進行移轉)。 將一組網域或 API 端點更新至 Azure API 管理，而其他網域或 API 端點則保留在 AWS 上，然後逐步移動其餘部分。 此策略可能需要您的用戶端應用程式處理混合端點或使用路由層。
步驟 3：評估
當移轉的系統符合驗證準則，且 Azure API 管理 提供所有生產流量，且功能或效能沒有顯著迴歸時，移轉會被視為成功。
驗證標準包括：
驗證基礎結構：網路基礎結構已記錄，並且只能按預期存取。 例如，如果其插入到內部虛擬網路中，請確認沒有公用 IP 將其公開。
Azure API 管理 執行個體可以連線到作業所需的任何網路或相依性。
驗證所有端點的 API 功能：所有 API 端點都會在實際案例中如預期般執行，包括有效和無效的請求和承載。 請確定已設定原則中的任何要求或回應轉換都會發生：
確認每個 API 的所有必要驗證和授權設定 （訂閱金鑰、OAuth 權杖、憑證）。
確認用戶端可以像以前一樣使用API，沒有任何變更（如果網域名稱已變更，則可能的端點URL除外）。
確認速率限制和配額已設定到適當範圍內。
驗證作業指標：在生產負載下使用儀表板或其他可觀察性工具來監控效能。 檢閱平均延遲和輸送量等指標，並將其與 Amazon API Gateway 的歷史資料進行比較。 檢查容量度量，確保 Azure API 管理執行個體已適當擴展。
步驟 4：程序
預計移轉程序需要數週或數月的時間，視服務基礎結構的複雜性，以及要移轉的 API 數量和複雜性而定。
完整的基礎設置
如果您尚未準備好 Azure 租戶和核心基礎設施 （核心聯網、輸入、安全性），請在移轉 Amazon API Gateway 和 API 之前建置它們。 您可以使用適合您移轉的 Azure 登陸區域架構來設定環境。
如果 Azure API 管理 基礎架構即程式碼 登陸區加速器 適合您的移轉，請針對您的 Azure API 管理 基礎部署實作一個加速器。 在 Azure API 管理 中包含應用程式閘道和內部虛擬網路。 雖然「登陸區加速器」使用 Azure API 管理的 Premium 層級，但我們建議您調整範本，以便在概念驗證階段使用開發者層級進行遷移。
建立並指派 Azure 角色型存取控制 （RBAC） 角色，以便只有授權的系統管理員才能管理 Azure API 管理 執行個體和 API。
設定 Azure API 管理 平台設定
在新的 Azure API 管理 執行個體中，設定類似於 Amazon API Gateway 中的全域設定：
自訂主機名稱：將自訂網域新增至 Azure API 管理、上傳 SSL 憑證 （或使用 Key Vault 參考），然後執行驗證。 現在或在生產切換之前執行此任務。 當您使用應用程式閘道 （建議） 時，請使用自訂網域和憑證設定接聽程式，然後將它指向 Azure API 管理 的內部端點。 設定接聽程式可簡化設定，因為它不需要網域驗證。
網路和安全性：請確定應用程式閘道 （或其他 Azure 進入點） 已設定為將要求轉送至 Azure API 管理。 設定網路安全性群組 （NSG） 規則或防火牆規則，讓 Azure API 管理 可以連線到後端服務。 這些服務可以包含您的 Azure 後端，甚至是原始的 AWS 後端（如果您最初是指向這些後端的話）。
受控識別：在 Azure API 管理 上啟用受控識別，以安全地呼叫 Azure 服務 （例如憑證或函式應用程式的金鑰保存庫）。
在此階段結束時，您應該在 Azure 中擁有 Azure API 管理 的工作殼層，並具有連線能力，以及基本架構，可開始匯入 API。
在 Azure API 管理 中匯入和重新建立 API
基礎結構準備就緒後，開始移轉 API 定義和組態：
從簡單、低風險的 API 開始：在從 Amazon API Gateway 重新建立 API 之前，先使用代表性 API 來驗證 Azure API 管理 中的基本閘道功能。
匯入至 Azure API 管理：使用 Azure 入口網站或腳本，從 Amazon API 閘道或後端匯入 OpenAPI 定義，做為 Azure API 管理中的新 API。 在匯入期間，Azure API 管理 會自動建立 API 和作業的結構。 如果您在 Amazon API Gateway 中有多個 API 階段，請在 Azure API 管理 中建立多個 API 版本。
首先，將每個 API 的後端 URL 設定為指向目前的後端。 （目前，目前的後端可能仍是 AWS 端點或公有端點。例如，如果 Amazon API Gateway 轉送至 Lambda，您可以將 Azure API 管理 後端設定為 Amazon API Gateway 中的對等 API，或設定為對等的 Azure 函式應用程式 （如果已移轉）。 （如果您將 Azure API 管理 後端設定為 Amazon API Gateway 中的對等 API，如果您將 Lambda 函式移轉至 Azure，稍後會變更此設定。如果後端是 AWS 應用程式負載平衡器或端點，Azure API 管理 可以透過因特網呼叫它。
如果您有大量 API，您可以使用 Azure API Center 來編目隨時間移轉至 Azure API 管理 的 API，以及保留在 Amazon API Gateway 中的 API。
請考慮在驗證基礎結構之後移轉或重構後端服務 （例如，作為 Azure 函式應用程式或 AKS 工作負載）。 請參閱 Azure 移轉中樞中的指引。
設定驗證和授權
訂用帳戶和產品：如果您的 API 需要 Amazon API Gateway 中的 API 金鑰 （透過
x-api-key標頭），請決定如何在 Azure API 管理 中處理該金鑰。 其中一種方法是讓這些 API 只有訂閱產品的使用者才能存取。 在 Azure API 管理中建立初始產品，可以直接與 AWS 的使用計劃一對一對應，或者以更符合邏輯的方式進行重組。使用者群組：在 Azure API 管理 中建立使用者群組，以鏡像您與開發人員共用 API 的方式。
具名值：將 Amazon API Gateway 階段變數中的任何設定值 （例如後端服務的端點或 API 金鑰） 匯入 Azure API 管理 具名值。 針對敏感性值，請使用 Azure 金鑰保存庫整合。
權杖擷取和驗證：針對 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 管理之後，HTTP API 中缺少使用方案等差異就不再重要，但請確保已解決任何 Amazon API Gateway 特定的限制。
管理轉換和政策映射
在適用的情況下，將現有的 API 設定複寫為 Azure API 管理 原則，特別是授權和回溯相容性。
將 Amazon API Gateway 中的 CORS 設定對應至 Azure API 管理 中的 CORS 原則。
逐案處理轉換作業（例如結構映射或豐富化）。
AI 工具，例如 Azure 入口網站中 Azure 中的 Microsoft Copilot，以及適用於 AWS 和 Microsoft 檔的 MCP 伺服器，可以協助進行組態對應或其他轉換。 不過，預期會在 Azure API 管理 中執行手動原則設定和偵錯。
設定可檢視性
針對初始監視，請設定 Azure 監視器以收集 API 計量和記錄。 稍後可以分層更多監視或可觀測性解決方案，例如 Application Insights。
執行測試
在 Azure API 管理 中設定 API 時，徹底的測試至關重要。 預期此階段會是反覆的。
功能測試：針對每個 API，呼叫新的 Azure API 管理 端點 （透過 Azure 入口網站的測試主控台或用戶端工具），並比較 Amazon API 閘道端點的回應。 檢查預期的狀態碼、標頭和內文。 如果您發現差異，請據以調整 Azure 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 Gateway 網域的 DNS 項目切換為指向新的 Azure 端點。 例如，如果您將網域 api.example.com 對應至 Amazon API Gateway，請更新其 CNAME 或 A 記錄，以指向 Azure API 管理 主機名稱或前端 （例如應用程式閘道） 網域。
存留時間 （TTL） 考量：事先降低 DNS TTL，以便用戶端快速擷取變更。 準備好後，請變更 DNS。 傳播可能需要幾分鐘到幾小時。 在此期間，部分流量可能仍會前往 AWS，而有些流量會移至 Azure。 如果您需要立即切換，可以使用替代方法，例如反向 Proxy。
替代切換方法：有時候，組織會使用反向代理或閘道翻轉，而不使用 DNS。 例如，組織可能會保持公用 DNS 相同，但一開始會讓應用程式閘道將要求轉送至 Amazon API Gateway （透過其 URL）。 在切換過程中，組織會在內部將應用程式閘道指向 Azure APIM。 這種方式比較複雜，但可以實現瞬時切換。 如果您使用 Azure Front Door 或流量管理員，另一種方法是逐步將流量從一個後端 （AWS） 重新加權到另一個後端 （Azure）。
切換期間的監控：一旦發生切換，請密切監控對 Azure API 管理執行個體和 Amazon API 閘道的請求。 透過 Azure 入口網站或您設定的任何儀錶板，即時監視 Azure API 管理 計量 （要求、延遲、CPU、容量記憶體）。 此外，請使用 Azure Monitor 來監控錯誤的尖峰情況，例如 4XX/5XX 回應。
復原計劃：決定觸發復原的因素。 例如，如果錯誤率超過特定百分比或關鍵功能中斷，您可能會在 30 分鐘內還原。 回復原狀意味著撤銷您所做的任何變更。 例如，如果切換的是 DNS，請恢復 DNS 記錄以重新指向 Amazon API Gateway。 由於 DNS 傳播，復原可能需要一些時間。 復原時間凸顯了低 TTL 的重要性，並可能需要同時保持兩個系統在執行。 如果您使用反向代理，請將其翻轉回 AWS。
停用 Amazon API Gateway
在 Amazon API 閘道接收不到流量且 Azure API 管理執行個體符合驗證準則後的一段時間內，停用 Amazon API 閘道。 一般而言，您會在至少一個完整的商務週期或尖峰流量期間平行執行兩者 （Azure 採用所有流量），以確保新系統能夠處理它。
反覆式最佳化
移轉之後，請專注於藉由縮小功能差距和實作最佳做法，以反覆優化 API 管理 設定。 此反覆改進程序可確保移轉的工作負載符合您在評估步驟期間建立的所有成功準則。 它也可確保移轉的工作負載遵循 API 管理 的架構最佳做法。
反覆分析並完善功能差距
某些 Amazon API 閘道功能在 Azure API 管理 中沒有一對一對應，而且需要因應措施，如 先前的評量 一節所述。 例如：
Web 應用程式防火牆：Azure API 管理 不會自動封鎖 AWS WAF 封鎖的不良承載。 如果您設定 Azure Web 應用程式防火牆，請確定 Azure API 管理 只能透過 WAF 存取，而且 WAF 規則會複寫 AWS WAF 限制。
事件流：如果 CloudWatch 警示或事件系結至 Amazon API Gateway（例如，針對某些錯誤模式），請在適用於 Azure API 管理的 Azure 監視器中設定相應的警示（例如，針對 Azure API 管理 5XX 錯誤率的警示）。
自動化：如果您有持續整合和持續傳遞 （CI/CD） 管線，請將 Azure API 管理 整合到其中。 例如，您可以使用基礎結構即程式碼方法，將 Azure API 管理 設定 （API 和原則） 儲存在原始檔控制中。 這些方法可能包括 Azure Resource Manager、Bicep 或 Terraform 範本，或 APIOps 方法。 此整合可確保未來對 API 的變更可以與受控版本設定一致地部署。
實作最佳實務
反覆實作最佳實務，包括成本最佳化、安全性強化和營運改善。 檢閱並實施 Azure API 管理的最佳架構實踐，涵蓋可靠性、安全性、卓越運營、成本管理和效能這些層面。 解決 Azure API 管理實例的 Azure Advisor 建議。
隨著時間的推移，逐步增加更多功能，例如：
- 外部快取。
- Azure 監視器以外的監視功能，例如 Application Insights 或非 Microsoft 解決方案，例如 Datadog。
- Azure API 管理 中 Amazon API Gateway 中無法使用的原則。
重點摘要
將 Amazon API Gateway 遷移到 Azure 需要仔細規劃和系統執行，以獲得同等的功能或替代方法。 關鍵成功因素包括：
全面評估：對現有的 Amazon API Gateway 設定進行詳細評估，包括所有 API、服務整合和相依性。 識別 Amazon API Gateway 與 Azure API 管理 之間的功能差距或差異。
現代化的機會：使用移轉作為機會，將後端服務現代化或移轉，或改善 API 設計。
全面準備：準備 Azure 環境，包括網路、安全性和基礎結構設定。 記錄所有組態，並規劃對後端服務進行任何必要的變更。
累加式移轉：規劃增量移轉方法，從不太重要的 API 或服務開始。 此方法允許您在完全投入新系統之前測試和驗證新設定。
驗證和測試：實作完整的測試和驗證程式，以確保 Azure API 管理 執行個體符合所有功能和效能需求。 這項工作包括負載測試、安全測試和使用者驗收測試。
監視和可觀察性：為新的 Azure API 管理 實例設定健全的監視和可觀察性，以快速識別和解決移轉期間或之後發生的任何問題。
反覆優化：移轉之後，透過解決功能差距和實作最佳做法，持續優化 Azure API 管理 設定。