この記事では、複数のリージョン間Azureワークロードを接続し、アマゾン ウェブ サービス (AWS) や Google Cloud などの他のクラウド プロバイダーへの接続を拡張するのに役立ちます。
この記事の内容
この記事では、リージョン間で仮想ネットワーク (VNet) Azure接続し、他のクラウドで実行されているワークロードへのネットワーク パスを確立するための設計上の決定について説明します。 グローバル VNet ピアリング、Virtual WAN、ExpressRoute Global Reach、サイト間 VPN、Azure Route Serverをリージョン間およびマルチクラウドのシナリオで使用するタイミングについて説明します。
この記事が必要なユーザー
これらの条件の 1 つ以上が該当する場合は、この記事をお読みください。
- アーキテクチャは複数のAzureリージョンにまたがるので、それらの間にプライベート接続が必要です。
- Azureワークロードを AWS、Google Cloud、または別の外部ネットワークに接続する必要があります。
- グローバル VNet ピアリング、Virtual WAN、ExpressRoute Global Reach、サイト間 VPN、またはAzure Route Serverを比較する必要があります。
- ディザスター リカバリー、グローバル拡張、またはマルチクラウド操作用に回復性のある接続を設計する必要があります。
Tip
シナリオパスに従っていますか? カスタマイズされたガイダンスについては、ページの上部にあるシナリオを選択してください。 以下の主要なガイダンスは、すべての読者に適用されます。
リフトアンドシフトフォーカス:移行が複数のAzureリージョンにまたがる場合、または別のクラウドに接続する場合にのみ、この記事を読み取りパスに含めます。 ほとんどのリフト アンド シフト プロジェクトは、1 つのリージョンから始まり、ディザスター リカバリーまたは地理的な拡張が優先されるときに、リージョン間接続を後で追加します。
最新化の焦点: モダン化に 、複数 リージョンの記事で説明されている範囲を超える明示的なリージョン間プライベート接続が必要な場合は、この記事を含めます。 このガイダンスは、異なるリージョンのスポークで直接通信パスが必要な場合、またはアクティブ/アクティブデプロイでリージョン ハブ間のプライベート ピアリングが必要な場合に必要です。
クラウド間のフォーカス: この記事は、設計上の中心的な決定事項です。 クラウド間のトランジット アーキテクチャのハブスポークとVirtual WANを選択する前に、これを読んでください。 この記事では、既存のマルチクラウド トポロジを検出し、AWS または Google Cloud と Azure の間でサービスをマップし、移行中に他のクラウドに残っているワークロードAzure接続する方法を定義します。
Azureサービスと機能
Azureでは、リージョン間接続とマルチクラウド接続のための複数のサービスが提供されます。 各サービスは、さまざまなスケール、帯域幅、および管理の要件に対応します。
| サービス | 提供される内容 | いつ使用するか |
|---|---|---|
| グローバル VNet ピアリング | 異なるAzure リージョン内の VNet 間の待機時間の短いプライベート接続。 トラフィックは Microsoft バックボーンに残ります。 帯域幅は、ゲートウェイではなく、仮想マシン (VM) SKU によってのみ制限されます。 | ゲートウェイ アプライアンスのない異なるリージョンの 2 つの VNet 間の直接通信。 |
| Azure Virtual WAN (Standard レベル) | Microsoft管理されたグローバル トランジット ハブ。すべてのリージョンで VNet、ブランチ、リモート ユーザーを接続します。 接続されているすべてのネットワーク間で推移的なルーティングを提供します。 | 個々のピアリング接続を管理することなく、任意の拠点間接続を必要とする多数のリージョンや支社を抱える組織。 |
| Cloud Exchange 経由の ExpressRoute | サードパーティの交換プロバイダー (Equinix や Megaport など) を介した専用のクラウド間接続。 AWS または Google Cloud へのプライベートで高帯域幅の接続を提供します。 | トラフィックがパブリック インターネットを通過してはならない帯域幅 SLA 要件を持つマルチクラウド アーキテクチャ。 |
| 他のクラウドへのサイト間 VPN | Azure VPN Gatewayと別のクラウド プロバイダーの VPN ゲートウェイ (AWS Virtual Private Gateway または Google Cloud VPN) 間の暗号化された IPsec トンネル。 | 専用回線が正当化されないテスト、開発、または運用シナリオ向けのマルチクラウド接続。 |
| Azure Route Server | VNet とネットワーク仮想アプライアンス (NVA) 間の動的 BGP ルート交換を有効にします。 NVA で学習されたルートを Azure SDN ルーティング ファブリックに挿入します。 | ハブ VNet 内のサードパーティ製 NVA を使用したカスタム ルーティング、または Azure に接続されたネットワークへの BGP 伝播を必要とする複雑なマルチクラウド ルーティング。 |
グローバル VNet ピアリングのしくみ
グローバル VNet ピアリングは、異なるAzure リージョン内の 2 つの仮想ネットワーク間に直接リンクを作成します。 リンクは完全にMicrosoftバックボーン経由で実行され、パブリック インターネットを経由することはありません。 ピアリング関係を構成した後、各 VNet 内のリソースは、プライベート IP アドレスを使用して、同じネットワーク内にあるかのように通信できます。
ゲートウェイ ベースのアプローチとは異なり、ピアリングでは単一のチョーク ポイントは導入されません。 ピアリングされた VNet 間の帯域幅は、両側の VM SKU に応じてスケーリングされます。 スループットを制限する専用ゲートウェイ アプライアンスはありません。 この設計により、グローバル VNet ピアリングは、少数の VNet 間のリージョン間通信の待機時間が最も短いオプションになります。
ただし、ピアリングは設計上、推移性がありません。 VNet A が VNet B とピアリングされ、VNet B が VNet C とピアリングされている場合、VNet A からのトラフィックは VNet B 経由で VNet C に到達できません。直接通信を必要とする VNet の各ペアには、独自のピアリング リンクが必要です。 ハブ スポーク モデルでは、通常、リージョン ハブ VNet を相互にピアリングし、ユーザー定義ルート (UDR) または NVA を使用して、ハブを介してリージョン間でスポーク間トラフィックを転送することを意味します。
Virtual WAN のグローバル トランジット
Azure Virtual WAN (Standard レベル) では、リージョン ハブ間のピアリングを手動で構成する必要がなくなります。 Virtual WAN ハブを複数のリージョンにデプロイすると、Microsoftはバックボーン経由でハブ間接続を自動的に確立します。 1 つのハブで学習されたルートは、他のすべてのハブに伝達され、任意の転送ファブリックが作成されます。
この自動ルーティングは、米国東部のハブに接続されているスポーク VNet が、追加のピアリングまたはルート テーブル構成なしで西ヨーロッパのハブに接続されているスポーク VNet に到達できることを意味します。 Virtual WAN、この推移性は、ブランチ オフィス (サイト間 VPN または ExpressRoute 経由で接続) とリモート ユーザー (ポイント対サイト VPN 経由で接続) にも拡張されます。 その結果、完全にメッシュ化されたグローバル Microsoft マネージド ネットワークになります。
リージョン間のトラフィック検査の場合は、セキュリティで保護された仮想ハブで ルーティングインテント を有効にします。 ルーティングインテントは、ハブ間トラフィックをAzure Firewall経由させます。これにより、各ハブに個々の NVA をデプロイおよび管理することなく、すべてのリージョンで一元的な可視性とポリシーの適用が可能になります。
選択する方法
次のデシジョン テーブルを使用して、シナリオに適した接続方法を選択します。
リージョン間接続オプション
| あなたのシナリオ | 推奨される方法 | なぜでしょうか |
|---|---|---|
| 異なるリージョンの 2 つの VNet に直接通信が必要 | グローバル VNet ピアリング | インターネット パスに対する待機時間が最も短く、ゲートウェイのボトルネックがなく、構成が簡単です。 帯域幅は VM SKU を使用してスケーリングされます。 |
| 多数のリージョン、多数のブランチ、マネージド トランジットが必要です | Azure Virtual WAN (Standard レベル) | 接続されているすべてのハブ間で推移的な任意のルーティングを提供します。 Microsoftはルーティング インフラストラクチャを管理します。 |
| Azureを使用してオンプレミス サイトを相互に接続する | ExpressRoute Global Reach | オンプレミスのトラフィックが Microsoft バックボーンを通過するように、2 つの ExpressRoute 回線をリンクします。 Azure VNet を経由して迂回する必要はありません。 |
| リージョナル ハブでのカスタム ルーティングまたはサードパーティ製 NVA | Azure Route Server | NVA とAzureの間の動的 BGP ピアリングを有効にします。 NVA によって学習されたルートは、スポーク VNet に自動的に挿入されます。 |
マルチクラウド接続オプション
| あなたのシナリオ | 推奨される方法 | なぜでしょうか |
|---|---|---|
| クラウド間トラフィックに必要な高帯域幅と SLA | クラウド Exchange プロバイダー経由の ExpressRoute | 予測可能な待機時間で専用容量を提供します。 Exchange プロバイダーは、ExpressRoute 回線を他のクラウドの直接接続サービスに接続します。 |
| 予算の制約、テスト、または低スループットのワークロード | 拠点間 VPN | 回線コストなしで既存のインターネット接続を使用します。 帯域幅の要件が小さい場合に適しています。 |
| ハイブリッドとマルチクラウド (オンプレミス、Azure、その他のクラウド) | ExpressRoute Global Reach + Cloud Exchange | Global Reach for on-premises-to-Azure transit とクラウド交換を組み合わせて、Azureから他のクラウドへの接続を実現し、統合されたプライベート バックボーンを作成します。 |
設計上の考慮事項
ほとんどのリフトアンドシフト移行では、リージョン間接続は、1 日の要件ではなく、将来の拡張の考慮事項です。 最初のデプロイでは、1 つのAzure リージョンをターゲットにしている可能性があります。
今後の拡張を計画する場合:
- グローバル VNet ピアリング:2 つ目の Azure リージョンを追加するときは、リージョン ハブ VNet 間のグローバル VNet ピアリングを使用します。 この方法では、ゲートウェイ アプライアンスをデプロイすることなく、待機時間の短いプライベート接続を実現できます。 トラフィックはMicrosoftバックボーンにとどまり、VM SKU に応じてスケーリングされます。
- 遅延の複雑さ:資産が 2 つのリージョンを超えて拡大するか、ブランチ接続の要件を追加するまで、Virtual WANまたは ExpressRoute Global Reach のデプロイは避けてください。
- DR の準備: 現在、リージョン間接続が必要ない場合でも、ディザスター リカバリーが必要なワークロードを文書化し、必要に応じて迅速にデプロイできるように、ピアリング トポロジを事前に計画します。
モダナイズされたアーキテクチャでは、複数のリージョンにまたがるアクティブ/アクティブ構成を採用しています。 リージョン間ピアリングを使用すると、アプリケーションの各層が複数のリージョンにまたがる場合でも、スポーク同士で直接通信できるようになります。
最新化のための主要な設計上の決定:
- アクティブ/アクティブのリージョン間ピアリング: プライマリとバックアップリージョンのハブ VNet をピアリングして、双方向トラフィック フローを有効にします。 ContosoBiz スポークと ContosoCare スポークのアプリケーション チームは、ハブ ピアリング パスを使用して、いずれかのリージョンのリソースに到達できます。
- ハブ経由のルーティング:グローバル VNet ピアリングは推移的ではないので、リージョンハブ NVA またはAzure Firewallを介してリージョン間のスポーク トラフィックをルーティングします。 ユーザー定義ルート (UDR) を使用して、ハブ ファイアウォールを経由してスポーク間のリージョン間トラフィックを検査します。
- 選択的ピアリング: すべてのスポークでリージョン間接続が必要なわけではありません。 ハブ VNet のみをピアリングし、ルート伝播を使用して、アクティブ-アクティブ ワークロードに参加する特定のスポーク VNet に到達できるようにします。
この記事では、マルチクラウド接続アーキテクチャを設計します。 インフラストラクチャAzure計画する前に、既存のクラウド トポロジを検出し、プロバイダー間でサービスをマップする必要があります。
クラウド間探索ワークフロー
- 既存のトポロジを検出します。 AWS と Google Cloud Network Intelligence Center の Workload Discovery を使用して、現在の Virtual Private Cloud (VPC) トポロジ、ピアリング関係、トラフィック フロー パターンをマップします。
- トラフィック フローを特定する: AWS または Google Cloud 環境での VPC 間通信、インターネットの受信パスと送信パス、ブランチからクラウドへの接続を文書化します。
- サービスを同等のAzureにマップする: 接続設計の主要なマッピングは次のとおりです。
| AWS / Google クラウド サービス | Azure の同等品 |
|---|---|
| トランジット ゲートウェイ | Azure Virtual WAN |
| VPC / VPC ネットワーク | Azure 仮想ネットワーク |
| セキュリティ グループ/ファイアウォール規則 | ネットワーク セキュリティ グループ (NSG) |
AWS 間の完全なAzureと Google Cloud-to-Azure サービスマッピングについては、クロスクラウド検出チェックリストを参照してください。
接続アーキテクチャの決定
検出とサービスのマッピングが完了したら、次の内容を決定します。
- トランジット モデル:複数の VPC、ブランチ、リージョン、またはクラウド エッジがある場合は、Virtual WANを選択します。 Virtual WAN は、マネージドな any-to-any ルーティングを備えた、Azure における AWS Transit Gateway に相当するサービスを提供します。
- クロスクラウド VPN:Virtual WAN ハブ (またはハブ VNet) から AWS Virtual Private Gateway と Google Cloud VPN へのVPN Gateway接続をデプロイします。 暗号化されたクラウド間通信には IPsec トンネルを使用します。
- 残っているアプリケーション: 移行中に AWS または Google Cloud に残っているワークロードを特定します。 これらのワークロードには、移行が完了するまで、クラウド間 VPN トンネルを介した永続的な接続が必要です。
Prerequisites
リージョン間接続またはマルチクラウド接続を実装する前に、次の要件を確認します。
- VNet がデプロイされた 2 つ以上のAzure リージョン: ワークロードは、複数のリージョンに既に存在している (または計画されている) 必要があります。 VNet 計画ガイダンスについては、 VNet とサブネットに関する記事 を参照してください。
- ハブ スポークまたはVirtual WAN トポロジ: リージョン間の設計は、各リージョンで確立されたトポロジに基づいて構築されます。 ハブスポークの記事またはVirtual WAN記事を参照してください。
- ExpressRoute 回線 (Global Reach の場合): オンプレミス サイトに接続する予定の場合は、各場所に既存の ExpressRoute 回線が必要です。 ハイブリッド接続に関する記事を参照してください。
- クラウド間アカウント アクセス: マルチクラウド VPN または交換接続の場合、接続のリモート側を構成するには、他のクラウド プロバイダーのネットワーク コンソールへの管理アクセスが必要です。
セキュリティに関する考慮事項
リージョン間接続とマルチクラウド接続では、単一リージョンのデプロイには存在しない特定のセキュリティ上の問題が発生します。
リージョン間のトラフィック検査
グローバル VNet ピアリングは推移的ではない。 ピアリングされた VNet 間のトラフィックは、ファイアウォールまたは検査ポイントを通過せずに直接フローします。 リージョン間トラフィックを検査する必要がある場合は、ネットワーク仮想アプライアンス (NVA) または各リージョン ハブのAzure Firewall経由でルーティングします。
Virtual WANの場合は、セキュリティで保護された仮想ハブでプライベート トラフィック ポリシーを使用してルーティングインテントを有効にします。 ルーティング インテントは、ハブ間トラフィックを Azure Firewall Manager マネージド ファイアウォール経由で強制的に通過します。これにより、リージョン間のトラフィック検査が一元化されます。 この構成には、Standard Virtual WAN レベルが必要です。
クラウド間接続を暗号化する
他のクラウドへのサイト間 VPN トンネルは、既定で暗号化されます (IPsec/IKE)。 ただし、クラウド交換を介した ExpressRoute 接続はプライベートですが、ネットワーク レイヤーでは暗号化されません。 ExpressRoute 経由での暗号化が必要な場合は、ExpressRoute Direct 回線に MACsec をデプロイするか、アプリケーション層 TLS 暗号化を使用します。
VPN オーバーレイなしでクラウド交換を通過するクラウド間トラフィックの場合は、ExpressRoute パス内に NVA ベースの IPsec トンネルをデプロイすることを検討してください。 この方法では、専用回線の帯域幅と待機時間の利点を損なうことなく、暗号化が追加されます。 または、アプリケーション層で相互 TLS (mTLS) を使用して、各サービス エンドポイントが ID を検証し、基になるトランスポートに関係なくデータを暗号化するようにします。 選択は、ネットワーク層 (すべてのトラフィック) 暗号化が必要か、アプリケーションレイヤーで暗号化を適用できるかによって異なります。
コストに関する考慮事項
すべてのリージョン間接続では、データ転送料金が発生します。 グローバル VNet ピアリング、Virtual WAN のハブ間トラフィック、VPN Gateway のリージョン間トンネルは、いずれもエグレス ベースの料金が適用されます。 レートはゾーン ペアによって異なります。
- 大陸内 (米国東部から米国西部など): GB あたりのレートが低く、通常はリージョンの標準的なエグレス価格の範囲内です。
- 大陸間 (たとえば、米国東部から西ヨーロッパ): バックボーンの距離が長く、大陸間の容量が多いため、GB あたりのレートが高くなります。
Virtual WANは、ハブに接続されている各スポーク VNet またはブランチの接続ユニット料金と、Azure Firewallを実行しているセキュリティで保護されたハブを通過するトラフィックのデータ処理料金を追加します。 この階層化された価格は、Virtual WAN少数のリージョンと少数のスポークを持つアーキテクチャでは、単純なグローバル VNet ピアリングよりもコストがかかる可能性がありますが、数十のブランチとリージョンが接続すると、大規模な単位経済性が向上することを意味します。
マルチクラウド接続の場合、クラウド交換を介した ExpressRoute では、Exchange プロバイダーからのポート料金とクロス接続料金に加えて、Azure ExpressRoute回線料金と他のクラウドの直接接続料金が発生します。 サイト間 VPN は回線コストを回避しますが、Azureからデータを離れる場合は標準のエグレス料金が発生します。
指導： 可能な場合は、高トラフィックのワークロードを同じリージョンに併置します。 コントロール プレーン同期、非同期レプリケーション、ディザスター リカバリー フェールオーバー (通常は低ボリューム フロー) のリージョン間パスを予約します。
ディザスター リカバリー パターン
リージョン間接続は、ディザスター リカバリー (DR) の基礎となります。 選択するパターンによって、目標復旧時間 (RTO) と目標復旧ポイント (RPO) が決まります。
Active-active
両方のリージョンが運用環境のトラフィックを同時に処理します。 グローバル ロード バランサー (Azure Front DoorやAzure Traffic Managerなど) は、リージョン間で要求を分散します。 1 つのリージョンで障害が発生した場合、トラフィックは中断を最小限に抑えて存続リージョンに移行します。 このパターンでは、最も低い RTO (秒から分) が提供されますが、リージョンと双方向データ同期の両方で完全なインフラストラクチャが必要であるため、コストと複雑さが増します。
Active-passive
1 つのリージョンは運用トラフィックを処理し、2 番目のリージョンは事前デプロイ済みの (ただしスケールダウンされる可能性がある) インフラストラクチャでスタンバイ状態のままです。 レプリケーションは、パッシブ リージョンのデータを最新の状態に保ちます。 障害が発生した場合は、パッシブ リージョンを昇格させ、トラフィックをリダイレクトします。 RTO は、パッシブ リソースをスケールアップし、DNS またはロード バランサーのフェールオーバーを完了する速度 (通常は数分から数十分) に依存します。
パイロットライト
アクティブなコンピューティングがないセカンダリ リージョン (レプリケートするデータベース、デプロイされたコア ネットワーク) 内の最小フットプリント。 フェールオーバー時に、アプリケーション コンピューティングをデプロイまたはスケーリングし、トラフィックを切り替えます。 このパターンでは、安定状態のコストは最小限に抑えられますが、リージョンがトラフィックを処理する前にコンピューティング リソースを開始する必要があるため、RTO が増加します。
すべてのパターンで、リージョン間接続 (グローバル VNet ピアリングまたはハブ間Virtual WAN) によって、レプリケーション トラフィックのプライベート データ パスが提供されます。 DR Runbook でルート伝達の遅延が考慮されていることを確認し、セカンダリ リージョンのネットワーク セキュリティ グループ (NSG) 規則でフェールオーバー トラフィックが許可されていることを確認します。
キー制約
| 制約 | 影響 |
|---|---|
| グローバル VNet ピアリングは推移的ではない | VNet B にピアリングされた VNet A と VNet B が VNet C にピアリングされている場合、A が C に到達できるわけではありません。A と C を直接ピアリングするか、Virtual WANなどのトランジット ソリューションを使用する必要があります。 |
| Virtual WAN Basic レベルに推移性がない | Basic Virtual WAN では、VNet 間の推移的な接続はサポートされていません。 リージョン間の転送には Standard レベルを使用します。 |
| ExpressRoute Global Reach では、地理的な接続に Premium SKU が必要です | 異なる地政学的リージョン (米国やヨーロッパなど) の回線には、Premium アドオンが必要です。 Standard SKU 回線は、同じ地政学的境界内でのみ接続します。 |
| AWS 向けに推奨されるアクティブ-アクティブ VPN ゲートウェイ | AWS Virtual Private Gateway は、VPN 接続ごとに 2 つのトンネルを作成します。 アクティブ/アクティブ モードでAzure VPN Gatewayを構成して、使用可能なすべてのトンネルを使用し、非対称ルーティングを回避します。 |
関連資料
- VNet とサブネット: この記事で参照されている VNet 計画の基礎。
- ハイブリッド接続: リージョン間接続の基盤となる ExpressRoute とVPN Gateway基盤。
- ハブスポーク トポロジ: マルチリージョン アーキテクチャに拡張されるリージョンハブスポーク設計パターン。
- Virtual WAN トポロジ: Virtual WAN ハブを使用したマネージド グローバルトランジット。
- 一元化されたネットワーク管理: リージョン間で大規模なピアリングを管理するためのAzure Virtual Network Manager。
詳細情報
- 仮想ネットワーク ピアリングの概要: グローバル VNet ピアリング機能、帯域幅の動作、構成が含まれます。
- Virtual WANグローバル トランジット アーキテクチャ: リージョン間の任意の転送をVirtual WANで有効にする方法。
- ExpressRoute Global Reach: ExpressRoute 回線を介してオンプレミス ネットワークを接続します。
- BGP VPN を使用して AWS にAzureを接続する: マルチクラウド VPN から AWS へのステップ バイ ステップ チュートリアル。
- Azure Route Serverの概要: Azureの NVA を使用した動的 BGP ルーティング。
- Virtual WAN価格の概念: ハブ間およびリージョン間のデータ転送料金について説明します。
次のステップ
Tip
あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。
リフトアンドシフト体験の次の手順:
マルチリージョン ネットワーク: 移行が 1 つのリージョンを超えて拡張される場合は、マルチリージョン接続とフェールオーバーを計画します。
次に、最新化の取り組みを行います。
ネットワークの監視と可観測性: 運用環境の準備のためにリージョン間で可観測性を有効にします。
マルチクラウドへの移行における次のステップ:
Virtual WAN トポロジ: マルチクラウドとマルチブランチ接続のトランジット ハブとしてVirtual WANを使用します。