既存の Azure 環境を Azure ランディング ゾーンの概念アーキテクチャに移行する

  • [アーティクル]

多くの組織には、既存の Azure 占有領域と 1 つ以上のサブスクリプションがあり、既存の管理グループの構造を持っている可能性があります。 ビジネス要件とシナリオによっては、ハイブリッド接続用の Azure VPN Gateway や Azure ExpressRoute などの Azure リソースがデプロイされている場合があります。

この記事では、Azure ランディング ゾーンの概念アーキテクチャへの切り替えを行っている既存の Azure 環境に基づいて、組織が変更に対処するのに役立つ推奨事項を提供します。 この記事では、既存の管理グループから別の管理グループにサブスクリプションを移動するなど、Azure 内のリソースを移動する際の考慮事項についても説明します。 既存の Azure 環境の切り替えを評価して計画するために、次の推奨事項を考慮してください。

Azure 内でリソースを移動する

作成後に Azure 内の一部のリソースを移動できます。 スコープ内およびスコープ全体でのユーザーの Azure ロールベースのアクセス制御 (RBAC) アクセス許可の対象となるさまざまな方法があります。 次の表に、移動できるリソース、対象スコープ、各リソースに関連する長所と短所を示します。

Scope 宛先 良い点 悪い点
リソース グループ内のリソース。 同じまたは別のサブスクリプション内の新しいリソース グループに移動できます。 デプロイ後にリソース グループ内のリソース構成を変更できます。 すべての resourceType でサポートされているわけではありません。

一部の resourceType には特定の制限または要件があります。

resourceId が更新されるため、既存の監視、アラート、コントロール プレーンの操作に影響を及ぼします。

移動期間中、リソース グループはロックされます。

移動操作の前後にポリシーと RBAC を評価する必要があります。
テナント内のサブスクリプション。 別の管理グループに移動できます。 resourceId 値は変更されないため、サブスクリプション内の既存のリソースには影響しません。 移動操作の前後にポリシーと RBAC を評価する必要があります。

どの移動戦略を使用すべきか決定するには、次の例を検討してください。

サブスクリプションの移動

通常は、サブスクリプションを移動して管理グループに整理するか、サブスクリプションを新しい Microsoft Entra ID テナントに転送します。 サブスクリプションを新しいテナントに移動するのは、主に課金所有権を移転するためです。 同じテナント内の管理グループ間でサブスクリプションを移動する方法の詳細については、「管理グループとサブスクリプションの移動」を参照してください。

Azure RBAC の要件

移動前にサブスクリプションを評価するには、ユーザーが適切な Azure RBAC を持っている必要があります。 ユーザーはサブスクリプションの所有者 (直接的なロールの割り当て) であり、ターゲット管理グループに対する書き込みアクセス許可を持っている可能性があります。 ターゲット管理グループに対する書き込みアクセス許可をサポートする組み込みロールは、所有者ロール、共同作成者ロール、管理グループ共同作成者ロールです。

ユーザーがサブスクリプションに対して既存の管理グループから継承された所有者ロールのアクセス許可を持っている場合、そのユーザーに所有者ロールが割り当てられている管理グループにのみサブスクリプションを移動できます。

ポリシー

既存のサブスクリプションは、直接的に割り当てられているか、現在配置されている管理グループで割り当てられている Azure ポリシーの対象となる場合があります。 現在のポリシーと、新しい管理グループまたは管理グループの階層に存在する可能性があるポリシーを評価することが重要です。

Azure Resource Graph を使用して、既存のリソースのインベントリを実行し、その構成を移動先に存在するポリシーと比較できます。

既存の Azure RBAC とポリシーが設定された管理グループにサブスクリプションを移動したら、次のオプションを検討します。

  • 移動したサブスクリプションに継承された Azure RBAC の場合、管理グループ キャッシュ内のユーザー トークンの更新には最大 30 分かかる場合があります。 このプロセスを迅速に処理するには、サインアウトしてからサインインしてトークンを更新するか、新しいトークンを要求します。

  • 移動したサブスクリプションが割り当てスコープに含まれているポリシーは、既存のリソースに対してのみ監査を実行します。 次の影響を受けるサブスクリプション内の既存リソース:

    • DeployIfNotExists ポリシー結果は非準拠として表示され、自動的には修復されません。 ユーザーは、修復を手動で実行する必要があります。

    • Deny ポリシー結果は非準拠として表示され、拒否されません。 ユーザーは、必要に応じてこの結果を手動で軽減する必要があります。

    • Append と Modify のポリシー結果は非準拠として表示され、ユーザーは軽減する必要があります。

    • Audit と AuditIfNotExist のポリシー結果は非準拠として表示され、ユーザーは軽減する必要があります。

  • 移動したサブスクリプション内のリソースへの新しい書き込みはすべて、通常と同様に、割り当てられたポリシーにリアルタイムで適用されます。

リソースの移動

通常、リソースが同じライフサイクルを共有している場合、リソースを同じリソース グループに統合する場合は、リソースを移動します。 または、コスト、所有権、または Azure RBAC の要件により、リソースを別のサブスクリプションに移動する場合。

リソースを移動する場合、移動操作中にソース リソース グループとターゲット リソース グループがロックされます。 リソース グループ内のリソースを追加、更新、または削除することはできません。 リソースの移動操作でリソースの場所が変更されることはありません。

同じテナント内のリソース グループとサブスクリプション間でリソースを移動する方法の詳細については、「リソースを新しいリソース グループまたはサブスクリプションに移動する」を参照してください。

ヒント

リージョン停止の影響を最低限に抑えるために、リソース グループと同じリージョンにリソースを配置することをお勧めします。 詳細については、「リソース グループの場所の配置」を参照してください。

同じリソース グループ内の異なるリージョンにリソースがある場合は、リソースを新しいリソース グループまたはサブスクリプションに移動することを検討してください。

リソースが別のリソース グループへの移行をサポートしているかどうかを判断するには、リソースを相互参照して一覧を作成します。 適切な前提条件を満たしていることを確認してください。

リソースを移動する前に

移動操作の前に、リソースがサポートされていることを確認し、その要件と依存関係を評価する必要があります。 たとえば、ピアリングされた仮想ネットワークを移動する場合は、最初に仮想ネットワーク ピアリングを無効にし、移動操作が完了した後にピアリングを再度有効にする必要があります。 仮想ネットワークに接続されている可能性のある既存のワークロードへの影響を理解できるように、依存関係の無効化と再有効化を事前に計画してください。

リソースの移動後

リソースを同じサブスクリプション内の新しいリソース グループに移動しても、管理グループまたはサブスクリプションから継承された Azure RBAC とポリシーは引き続き適用されます。 これは、サブスクリプションが他の Azure RBAC とポリシー割り当ての対象となる可能性がある新しいサブスクリプションのリソース グループに移動する場合にも適用されます。 リソースのコンプライアンスとアクセス制御を検証する必要があります。

シナリオ

次のシナリオでは、既存の環境を Azure ランディング ゾーンの概念アーキテクチャに移行して切り替える方法について説明します。

ターゲット アーキテクチャへのユーザー体験