シナリオ: リージョンの組織環境を Azure ランディング ゾーンの概念アーキテクチャに切り替える
この記事では、Azure 環境を Azure ランディング ゾーンの概念アーキテクチャに移行して切り替える方法に関する考慮事項と手順について説明します。 このシナリオでは、開発、テスト、運用 (開発/テスト/運用) 環境に分離された管理グループを持つ地域組織について説明します。
このシナリオでは、顧客は Azure に大きなメモリ占有領域を持っています。 彼らは、開発/テスト/運用環境別、そしてリージョン別に編成された管理グループ階層を所有しています。 現在の実装では、スケーラビリティと拡張が制限されています。 世界中にアプリケーションがデプロイされています。 中央の IT チームが各リージョンを管理します。 このシナリオでは、リージョンはアメリカ、ヨーロッパ、中東およびアフリカ (EMEA)、アジア太平洋 (APAC) です。
顧客は、既存の環境から Azure ランディング ゾーンの概念アーキテクチャに移行したいと考えています。 このアプローチでは、同社の "クラウド ファースト" 戦略がサポートされ、オンプレミス データセンターを廃止したときにスケーリングできる堅牢なプラットフォームも備えられています。
現在の状態
このシナリオでは、お客様の Azure 環境の現在の状態は、次のもので構成されています。
- 複数の管理グループ。
- 第 1 レベルでは開発/テスト/運用環境に基づき、第 2 レベルでは地理に基づいている管理グループ階層。
- 各地域とアプリケーション環境 (開発/テスト/運用など) 向けの Azure サブスクリプション。このサブスクリプションは、開発者にテストとイノベーションのためのリラックスした環境を提供するために必要です。
- 開発/テスト/運用全体で同じガバナンス モデルを必要とし、顧客にガバナンスの課題を生み出す場合があるいくつかの重要なワークロード。
- 均一ではないリソース分布。 1 つの環境のプラットフォーム リソースとワークロード リソースは、同じ Azure サブスクリプションにデプロイされています。
- リージョンと環境の分類 (開発/テスト/運用など) に基づいて、それぞれのサブスクリプションにデプロイされるアプリケーション。
- 管理グループとサブスクリプション レベルで割り当てられる監査効果と拒否効果を含むポリシーの割り当て。
- 同じリージョンおよび同じ環境の種類のすべてのアプリケーションに適用される同じ Azure ポリシーのセット。
- 各サブスクリプションとリソース グループのロールベースのアクセス制御ロールの割り当て。
- ハイブリッド接続用のハブ仮想ネットワーク (Azure VPN Gateway や Azure ExpressRoute など)。
- 各アプリケーション環境の仮想ネットワーク。
- 各リージョンのそれぞれの管理グループを制御および運用する中央 IT チーム。 一部のアプリケーションが複数のリージョンにデプロイされるため、ポリシー、アクセス制御、プラットフォーム リソースの構成、セキュリティ コンプライアンスに関して、チームは、一貫性、構成、コンプライアンスの課題に直面しています。
次の図は、このサンプル シナリオの現在の状態を示しています。
Azure ランディング ゾーンの概念アーキテクチャへの移行
この方法を実装する前に、Azure ランディング ゾーンの概念アーキテクチャ、Azure ランディング ゾーンの設計原則、Azure ランディング ゾーンの設計領域に関する記事を確認してください。
このシナリオの現在の状態を Azure ランディング ゾーンの概念アーキテクチャに切り替えるには、次のアプローチを使用してください。
Azure ランディング ゾーン アクセラレータを、現在の環境と並行して同じ Microsoft Entra ID テナントにデプロイしてください。 この方法により、アクティブなワークロードの中断を最小限に抑えながら、新しいランディング ゾーン アーキテクチャにスムーズかつ段階的に切り替えることができます。
このデプロイによって新しい管理グループ構造が作成されます。 この構造は、Azure ランディング ゾーンの設計原則と推奨事項に沿っています。 また、既存の環境がこれらの変更の影響を受けないことが保証されます。
詳細については、開発/テスト/運用ワークロード ランディング ゾーンを処理する方法に関するセクションを参照してください。
サンドボックス管理グループ階層を使用して、開発者が他の環境に影響を与えずにテストおよび実験できるようにする方法については、Azure ランディング ゾーン サンドボックス環境のガイダンスを参照してください。
移行中にアプリケーションとサービスの中断を最小限に抑える方法については、ポリシー主導のガードレールの採用のガイダンスを参照してください。
(省略可能) アプリケーション チームまたはサービス チームと協力して、元のサブスクリプションにデプロイされたワークロードを新しい Azure サブスクリプションに移行してください。 詳しくは、「既存の Azure 環境を Azure ランディング ゾーンの概念アーキテクチャに移行する」をご覧ください。 ワークロードを、新しくデプロイされた Azure ランディング ゾーンの概念アーキテクチャ管理グループ階層の適切な管理グループ (次の図の corporate や online など) の下に配置できます。
移行時のリソースへの影響の詳細については、「ポリシー」を参照してください。
最終的に、既存の Azure サブスクリプションを取り消して、使用が停止された管理グループに配置できます。
Note
既存のアプリケーションまたはサービスを、必ずしも新しいランディング ゾーン (Azure サブスクリプション) に移行する必要はありません。
新しい Azure サブスクリプションを作成して、新しいアプリケーションとワークロードをサポートできるランディング ゾーンを提供してください。 これらを適切な管理グループ (次の図の corporate や online など) の下に配置してください。
詳細については、移行のためのランディング ゾーンの準備に関するガイダンスを参照してください。
次の図は、このシナリオの移行中の状態を示しています。
まとめ
このシナリオでは、顧客は、既存の環境と並行して Azure ランディング ゾーンの概念アーキテクチャをデプロイして、Azure でのワークロードの成長とスケーリング計画をサポートするために必要な基盤を確立しました。