ランディング ゾーン リージョン
この記事では、ランディング ゾーンがどのように Azure リージョンを使用するかについて説明します。 Azure ランディング ゾーン アーキテクチャはリージョンに依存しませんが、Azure ランディング ゾーン アーキテクチャをデプロイするには Azure リージョンを指定する必要があります。 次のガイダンスで、既存のランディング ゾーンにリージョンを追加する方法を説明し、また、Azure 資産を別のリージョンに移行するときのいくつかの考慮事項についても説明します。
場合によっては、高可用性とディザスター リカバリーのビジネス要件をサポートするために、複数の Azure リージョンにアプリケーションをデプロイする必要があります。 複数リージョンのアプリケーションがすぐに必要になるわけではありませんが、特に接続、ID、および管理サービス用に、複数のリージョンをサポートするように Azure ランディング ゾーン プラットフォームを設計する必要があります。 複数リージョンのアプリケーション ランディング ゾーンをすばやく有効にしてサポートできることを確認します。
詳細については、「Azure リージョンの選択」を参照してください。
ランディング ゾーンと Azure リージョン
Azure ランディング ゾーンは、一連のリソースと構成から成ります。 管理グループ、ポリシー、ロールの割り当てなどのこれらの項目の一部は、Azure ランディング ゾーン アーキテクチャ内のテナント レベルまたは管理グループ レベルのどちらかに保存されます。 これらのリソースは、特定のリージョンに デプロイ されず、代わりにグローバルにデプロイされます。 ただし、Azure はリージョン メタデータ ストア内のリソース メタデータの一部を追跡するため、デプロイ リージョンを指定する必要があります。
その他のリソースは、リージョンにデプロイされます。 独自のランディング ゾーンの構成によっては、次に示すリージョンにデプロイされたリソースの一部またはすべてが存在する場合があります。
- 選択したソリューションを含む Azure Monitor ログ ワークスペース
- Azure Automation アカウント
- その他のリソース用のリソース グループ
ネットワーク トポロジをデプロイする場合は、ネットワーク リソースのデプロイ先の Azure リージョンを選択する必要もあります。 このリージョンは、上の一覧に示したリソースに使用するリージョンとは異なる可能性があります。 選択するトポロジによっては、デプロイするネットワーク リソースには次のものが含まれる場合があります。
- Virtual WAN ハブを含む、Azure Virtual WAN
- Azure 仮想ネットワーク
- VPN Gateway
- Azure ExpressRoute ゲートウェイ
- Azure Firewall
- Azure DDoS Protection プラン
- Azure Private Link 用のゾーンを含む Azure プライベート DNS ゾーン
- 前述のリソースを含むリソース グループ
Note
リージョン停止の影響を最低限に抑えるために、リソース グループと同じリージョンにリソースを配置することをお勧めします。 詳細については、「リソース グループの場所の配置」を参照してください。
既存のランディング ゾーンに新しいリージョンを追加する
クラウド体験の開始時から、または Azure ランディング ゾーン アーキテクチャの初期展開が完了した後でより多くの Azure リージョンに拡張することで、マルチリージョン戦略を検討する必要があります。 たとえば、Azure Site Recovery を使用して仮想マシンのディザスター リカバリーを有効にした場合、それらを別の Azure リージョンに複製することをお勧めします。 Azure ランディング ゾーン アーキテクチャ内に Azure リージョンを追加するには、次の推奨事項を考慮してください:
| 面グラフ | 推奨 |
|---|---|
| 管理グループ | 対処不要です。 管理グループがリージョンに関連付けられていません。 リージョンに基づいて管理グループ構造を作成しないでください。 |
| サブスクリプション | サブスクリプションはリージョンに関連付けられません。 |
| Azure Policy | "許可されている" Azure リージョンの一覧を指定して、すべてのリージョンへのリソースのデプロイを拒否するポリシーを割り当てた場合は、Azure Policy で変更を行います。 これらの割り当てを更新して、有効にしたい新しいリージョンにリソースをデプロイできます。 |
| ロールベースのアクセス制御 (RBAC) | 対処不要です。 Azure RBAC はリージョンに関連付けられていません。 |
| 監視およびログ記録 | すべてのリージョンに単一の Azure Monitor Log ワークスペースを使用するか、さまざまな地理的リージョンをカバーする複数のワークスペースを作成するかを決定します。 リージョン間ネットワーク料金の可能性などを含め、各アプローチには長所と短所があります。 詳しくは、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。 |
| ネットワーク | ネットワーク トポロジ、Virtual WAN、または 従来のハブ アンド スポーク をデプロイした場合は、ネットワークを新しい Azure リージョンに拡張します。 必要なネットワーク リソースを新しい Azure リージョンの既存の接続サブスクリプションにデプロイして、別のネットワーク ハブを作成します。 Azure Virtual Network Manager を使用すると、複数のリージョンで大規模な仮想ネットワークを簡単に拡張および管理できます。 ドメイン ネーム システム DNS の観点から、それらを使用する場合、フォワーダーを新しい Azure リージョンにデプロイすることもできます。 解決するには、新しいリージョンのスポーク仮想ネットワークにフォワーダーを使用します。 Azure DNS ゾーンはグローバル リソースであり、単一の Azure リージョンに関連付けられていないため、アクションは必要ありません。 |
| ID | Active Directory Domain Services または Microsoft Entra Domain Services を ID サブスクリプションまたはスポークにデプロイした場合は、新しい Azure リージョンにサービスを展開します。 |
Microsoft Cloud for Sovereignty には、サービスとリージョンを制限するためのガイドラインがあります。 これらのガイドラインを使用して、顧客がデータ所在地のニーズを満たすのに役立つサービス構成を適用できます。
上位レベルのアプローチ
Azure ランディング ゾーンを新しいリージョンに拡張する場合は、これらのセクションの手順に従ってください。 開始する前に、拡張する新しい Azure リージョンまたは複数の Azure リージョンを決定する必要があります。
ネットワーク
従来のハブ アンド スポーク アーキテクチャ
ヒント
「従来のハブ アンド スポーク アーキテクチャ」をご覧ください。
新しいプラットフォーム ランディング ゾーン サブスクリプションが必要かどうかを決定します。 ほとんどのお客様は、複数のリージョンを使用している場合でも、既存の Connectivity サブスクリプションを使用することをお勧めします。
サブスクリプション内で、新しいターゲット リージョンに新しいリソース グループを作成します。
新しいターゲット リージョンに新しいハブ仮想ネットワークを作成します。
該当する場合は、Azure Firewall またはネットワーク仮想アプライアンス (NVA) を新しいハブ仮想ネットワークにデプロイします。
該当する場合は、VPN または ExpressRoute 接続用の仮想ネットワーク ゲートウェイをデプロイし、接続を確立します。 ExpressRoute 回線とオンプレミスの場所が、Microsoft の回復性に関する推奨事項に従っていることを確認してください。 詳細については、「ExpressRoute プライベート ピアリングを使用したディザスター リカバリーの設計」を参照してください。
新しいハブ仮想ネットワークと他のハブ仮想ネットワークの間に仮想ネットワーク ピアリングを確立します。
Azure Route Server やユーザー定義ルートなど、必要なルーティングを作成して構成します。
必要に応じて、新しいターゲット リージョンの DNS フォワーダーをデプロイし、任意のプライベート DNS ゾーンにリンクすることで、名前解決を有効にします。
- 一部のお客様は、 ID プラットフォーム ランディング ゾーン サブスクリプション内の Windows Server Active Directory ドメイン コントローラーで名前解決を構成できます。
ワークロードをホストするために、仮想ネットワーク ピアリングを使用して、アプリケーション ランディング ゾーン スポークを新しいリージョンの新しいハブ仮想ネットワークに接続できます。
ヒント
Virtual Network Manager を使用すると、複数のリージョンで大規模な仮想ネットワークを簡単に拡張および管理できます。
Virtual WAN アーキテクチャ
ヒント
「Virtual WAN アーキテクチャ」を参照してください。
既存の仮想 WAN 内で、新しいターゲット リージョンに新しい仮想ハブを作成します。
Azure Firewall またはその他のサポートされているネットワーク仮想アプライアンス (NVA) を新しい仮想ハブにデプロイします。 新しいセキュリティ保護付き仮想ハブを介してトラフィックをルーティングするように、Virtual WAN ルーティング インテントとルーティング ポリシー を構成してください。
該当する場合は、VPN や ExpressRoute 接続用の仮想ネットワーク ゲートウェイを新しい仮想ハブにデプロイし、接続を確立します。 ExpressRoute 回線とオンプレミスの場所が、Microsoft の回復性に関する推奨事項に従っていることを確認してください。 詳細については、「ExpressRoute プライベート ピアリングを使用したディザスター リカバリーの設計」を参照してください。
仮想ハブの静的ルートなど、必要な他のルーティングを作成して構成します。
該当する場合は、新しいターゲット リージョンの DNS フォワーダーをデプロイし、任意のプライベート DNS ゾーンにリンクして解決を有効にします。
一部のお客様は、 ID プラットフォーム ランディング ゾーン サブスクリプション内の Active Directory ドメイン コントローラーで名前解決を構成できます。
Virtual WAN デプロイでは、これは仮想ネットワーク接続を介して仮想ハブに接続されているスポーク仮想ネットワーク内にある必要があり、仮想ハブ拡張機能パターン に従います。
ワークロードをホストするために、仮想ネットワーク ピアリングを使用して、アプリケーション ランディング ゾーン スポークを新しいリージョンの新しいハブ仮想ネットワークに接続できます。
ID
ヒント
ID とアクセスの管理のための Azure ランディング ゾーン設計領域を確認します。
新しいプラットフォーム ランディング ゾーン サブスクリプションが必要かどうかを決定します。 ほとんどのお客様は、複数のリージョンを使用している場合でも、既存の ID サブスクリプションを使用することをお勧めします。
新しいターゲット リージョンに新しいリソース グループを作成します。
新しいターゲット リージョンに新しい仮想ネットワークを作成します。
Connectivity サブスクリプションで、新しく作成されたリージョン ハブ仮想ネットワークへの仮想ネットワーク ピアリングを確立します。
Active Directory ドメイン コントローラー仮想マシンなどの ID ワークロードを新しい仮想ネットワークにデプロイします。
次の構成手順のように、一度プロビジョニングしたら、ワークロードのセットアップをさらに行う必要がある場合があります:
Active Directory ドメイン コントローラーの仮想マシンを既存の Active Directory ドメインに昇格させます。
新しい Active Directory サイトとサブネットを作成します。
条件付きフォワーダーなどの DNS サーバー設定を構成します。
Azure 資産を新しいリージョンに移動する
場合によっては、Azure 資産全体を別のリージョンに移動することが必要になる場合があります。 たとえば、ランディング ゾーンとワークロードを近隣の国やリージョンの Azure リージョンにデプロイした後、ご自分の国やリージョンで新しい Azure リージョンが開始されたと想定してください。 お客様は通信の待機時間を短縮したり、データ所在地の要件に準拠したりするために、すべてのワークロードを新しいリージョンに移動することを選択するかもしれません。
Note
この記事では、資産のランディング ゾーン コンポーネントの移行に関する情報を提供します。 詳細については、「クラウド ワークロードの再配置」を参照してください。
グローバル ランディング ゾーンの構成
グローバルにデプロイされたランディング ゾーン構成のほとんどは、通常、リージョンを移動するときに変更する必要はありません。 ただし、リージョンのデプロイを制限するポリシー割り当てがないか確認し、新しいリージョンへのデプロイを許可するようにポリシーを更新するようにしてください。
リージョン ランディング ゾーンのリソース
リージョン固有のランディング ゾーン リソースでは、一部の Azure リソースをリージョン間で移動できないため、多くの場合、より多くの考慮事項が必要になります。 次のアプローチを検討します。
ランディング ゾーンへの追加リージョンとしての移転先リージョンの追加: 詳細については、「既存のランディング ゾーンに新しいリージョンを追加する」を参照してください。
移転先リージョンに一元化されたコンポーネントをデプロイする: たとえば、ワークロードの移行後にワークロードで新しいコンポーネントの使用を開始できるように、移行先リージョンに新しい Azure Monitor ログ ワークスペースをデプロイします。
ソース リージョンのワークロードを移転先リージョンに移行させる: ワークロード移行プロセス中に、リソースが移行先リージョンのネットワーク コンポーネント、ID コンポーネント、Azure Monitor Logs ワークスペース、およびその他のリージョン リソースを使用するように再構成を行います。
移行が完了した後、ソース リージョン内のリソースの使用を停止します。
ランディング ゾーン リソースをリージョンをまたいで移行する際は、次のヒントを考慮してください:
コードとしてのインフラストラクチャを使用する: Azure Firewall のルールなどの複雑な構成は、Bicep、Azure Resource Manager テンプレート (ARM テンプレート)、Terraform、スクリプト、または類似の方法を使用して、エクスポートおよび再インポートします。
Automation: リージョン間で Automation リソースを移行するには、スクリプト を使用します。
ExpressRoute: 移行先リージョンで ExpressRoute Local SKU を使用できるかどうかを検討します。 オンプレミス環境が Azure リージョンと同じ都市圏内にある場合、ExpressRoute Local が、他の ExpressRoute SKU と比較してより低コストのオプションを提供する可能性があります。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示