案例：將區域組織環境轉換為 Azure 登陸區域概念架構
本文說明將 Azure 環境移轉至 Azure 登陸區域概念架構的考慮和指示。 此案例涵蓋一個區域性組織，其管理群組會分成開發、測試和生產環境（開發/測試/生產環境）。
在此案例中，客戶在 Azure 上的使用量很大。 他們有一個管理群組階層，由開發/測試/生產環境組織，然後依區域組織。 其目前的實作會限制其延展性和成長性。 它們已在全球部署應用程式。 中央 IT 小組會管理每個區域。 在此案例中，區域為美國;歐洲、中東和非洲（EMEA）：和亞太地區（APAC）。
客戶想要從現有的環境移至 Azure 登陸區域概念架構。 此方法支援其 雲端優先 策略，且具有強大的平臺，可隨著客戶淘汰其內部部署資料中心而進行調整。
目前狀態
在此案例中，客戶的 Azure 環境目前狀態包含：
- 多個管理群組。
- 以第一層開發/測試/生產環境為基礎的管理群組階層，然後根據第二層的地理位置。
- 每個地理位置和應用程式環境的 Azure 訂用帳戶，例如開發/測試/生產環境。需要此訂用帳戶，才能為開發人員提供輕鬆的測試和創新環境。
- 在開發/測試/生產環境中需要相同治理模型的一些重要工作負載，可為客戶建立治理挑戰。
- 非統一資源散發。 單一環境的平臺和工作負載資源會部署在相同的 Azure 訂用帳戶中。
- 根據其區域和環境分類，部署到個別訂用帳戶的應用程式，例如開發/測試/生產。
- 在管理群組和訂用帳戶層級指派的原則指派，例如稽核效果和拒絕效果。
- 相同的一組 Azure 原則會套用至相同區域和相同環境類型中的所有應用程式。
- 每個訂用帳戶和資源群組的角色型存取控制角色指派。
- 用於混合式連線的中樞虛擬網路，例如 Azure VPN 閘道或 Azure ExpressRoute。
- 每個應用程式環境的虛擬網路。
- 控制及操作每個區域的個別管理群組的中央 IT 小組。 小組在原則、存取控制、平臺資源設定和安全性合規性方面面臨一些一致性、設定和合規性挑戰，因為某些應用程式會部署到多個區域。
下圖顯示此範例案例的目前狀態。
轉換至 Azure 登陸區域概念架構
在實作此方法之前，請先檢閱 Azure 登陸區域概念架構 、 Azure 登陸區域設計原則 ，以及 Azure 登陸區域設計區域 。
若要從此案例的目前狀態轉換為 Azure 登陸區域概念架構，請使用此方法：
將 Azure 登陸區域加速器 部署至與目前環境平行的相同 Microsoft Entra ID 租使用者。 此方法提供順暢且分階段的轉換至新的登陸區域架構，且對作用中工作負載的中斷最少。
此部署會建立新的管理群組結構。 此結構與 Azure 登陸區域設計原則和建議一致。 它也可確保這些變更不會影響現有的環境。
如需詳細資訊，請參閱 如何處理開發/測試/生產工作負載登陸區域 。
如需使用沙箱管理群組階層來讓開發人員在不影響其他環境的情況下進行測試和實驗的相關資訊，請參閱 Azure 登陸區域沙箱環境指引 。
如需在移轉期間將應用程式和服務中斷降到最低的資訊，請參閱 採用原則驅動的護欄指引 。
（選擇性）請與應用程式或服務小組合作，將原始訂用帳戶中部署的工作負載移轉至新的 Azure 訂用帳戶。 如需詳細資訊，請參閱 將現有的 Azure 環境轉換為 Azure 登陸區域概念架構 。 您可以將工作負載放入新部署的 Azure 登陸區域概念架構管理群組階層中，位於正確的管理群組之下，例如 公司 或 線上 圖表。
如需移轉時對資源影響的詳細資訊，請參閱 原則 。
最後，您可以取消現有的 Azure 訂用帳戶，並將它放在已解除委任的管理群組中。
注意
您不一定必須將現有的應用程式或服務移轉至新的登陸區域或 Azure 訂用帳戶。
建立新的 Azure 訂用帳戶，以提供可支援新應用程式和工作負載的登陸區域。 將它們放在適當的管理群組底下，例如 公司 或 線上 ，如下圖所示。
如需詳細資訊，請參閱 準備登陸區域以進行移轉指引 。
下圖顯示移轉期間此案例的狀態。
摘要
在此案例中，客戶建立了必要的基礎，藉由平行部署 Azure 登陸區域概念架構 ，以支援其在 Azure 中工作負載的成長和調整計畫。