スポーク間ネットワークのパターン

Azure の最も一般的なネットワーク設計パターンでは、1 つまたは複数の Azure リージョンにデプロイされたハブアンドスポーク仮想ネットワーク トポロジが使用されます。 これらのトポロジは、必要に応じて、Azure ExpressRoute 経由またはパブリック インターネット経由のサイト間仮想プライベート ネットワーク (VPN) トンネル経由でオンプレミス ネットワークに接続できます。

ほとんどの設計ガイドでは、内部ネットワーク、オンプレミス ネットワーク内のユーザー、またはインターネットからこれらの仮想ネットワークに流れるアプリケーション トラフィックに焦点を当てています。 この種類のトラフィックは、一般に 南北トラフィックと呼ばれ、ネットワーク ダイアグラムでその垂直表現を反映する用語です。 この記事では、 東西トラフィックで使用できるさまざまなパターンについて説明します。 1 つのリージョン内または複数のリージョンにまたがって、Azure 仮想ネットワークにデプロイされたワークロード間の通信フロー。

ネットワーク設計が東西トラフィックの要件を満たしていることを確認することは、Azure で実行されるアプリケーションにパフォーマンス、スケーラビリティ、回復性を提供するために不可欠です。

考えられるユース ケース

スポーク間トラフィックは、次のシナリオで重要になる場合があります。

• 1 つのアプリケーションの異なるレベルが別々の仮想ネットワークにある。 たとえば、境界仮想ネットワーク内の境界ネットワーク サーバー ( DMZ サーバーとも呼ばれます) は、内部仮想ネットワーク内のアプリケーション サービスと通信します。

• 開発、ステージング、運用など、さまざまな環境のアプリケーション ワークロードは、相互にデータをレプリケートする必要があります。

• さまざまなアプリケーションまたはマイクロサービスが相互に通信する必要がある。

• 障害が発生した場合にビジネス継続性を保証するために、データベースはリージョン間でデータをレプリケートする必要があります。

• ユーザーが Azure 仮想ネットワークの内部にいる。 たとえば、Azure Virtual Desktop を使用しています。

スポーク間通信のパターンとトポロジ

複数の仮想ネットワークをまたがる Azure 設計で使用できる 2 つの主要なトポロジは、 セルフマネージドのハブ アンド スポーク と Azure Virtual WAN です。 Virtual WAN 環境では、Microsoft がハブ仮想ネットワークとそれらの内部のすべてを管理します。 セルフマネージド ハブ アンド スポーク環境では、ユーザーがハブ仮想ネットワークを管理します。

Virtual WAN トポロジとセルフマネージド ハブ アンド スポーク トポロジはどちらも、ワークロードがスポーク仮想ネットワークで実行されるアーキテクチャです。 オンプレミスへの接続は、ハブ仮想ネットワークで一元化されます。 この記事で説明する概念の多くは、セルフマネージドハブアンドスポーク設計と Virtual WAN 設計の両方に適用されます。

スポーク仮想ネットワークを相互に接続するには、主に次の 2 つのパターンがあります。

• スポーク同士が直接接続されます。 仮想ネットワーク ピアリングまたは VPN トンネルがスポーク仮想ネットワーク間に作成され、ハブ仮想ネットワークを通過することなく直接接続できます。

• スポークはネットワーク アプライアンス経由で通信します。 各スポーク仮想ネットワークは、Virtual WAN またはハブ仮想ネットワークとピアリングされます。 アプライアンスは、スポーク間でトラフィックをルーティングします。 アプライアンスは自分で管理することも、Microsoft が管理することもできます。 この管理モデルは、Virtual WAN デプロイでの管理の処理方法と同様に機能します。

パターン 1: スポークが互いに直接接続する

スポーク間の直接接続は、通常、ハブ間のネットワーク仮想アプライアンス (NVA) を経由する接続よりもスループット、待機時間、スケーラビリティが向上します。 NVA 経由でトラフィックを送信すると、NVA が別の可用性ゾーンにあり、トラフィックをハブ経由で送信するときに少なくとも 2 つの仮想ネットワーク ピアリングを通過する必要がある場合、トラフィックの待機時間が追加される可能性があります。 2 つのスポーク仮想ネットワークを相互に直接接続するためのオプションには、仮想ネットワーク ピアリング、Azure Virtual Network Manager、VPN トンネルなどがあります。

• 仮想ネットワーク ピアリング: スポークよりも直接的な仮想ネットワーク ピアリングの利点を考慮してください。

  • 必要な仮想ネットワーク ピアリング ホップが少ないため、コストが削減されます

  • 待機時間や潜在的なボトルネックが発生するネットワーク アプライアンスをトラフィックが走査する必要がないため、パフォーマンスが向上します

  その他のシナリオとしてテナント間接続があります。 ただし、スポーク仮想ネットワーク間のトラフィックを調べる必要がある場合があります。 このプロセスでは、ハブ仮想ネットワーク内の一元化されたネットワーク デバイス経由でトラフィックを送信することが必要になる場合があります。

• サブネット ピアリング: 仮想ネットワーク ピアリングと同様ですが、サブネット ピアリングでは、ピアリングの両側で相互通信を許可するサブネットを指定することで、より細かい粒度を実現できます。

• Virtual Network Manager: 仮想ネットワーク ピアリングの利点に加えて、Virtual Network Manager には、仮想ネットワーク環境を管理し、大規模な接続を作成できる管理サービスが用意されています。 Virtual Network Manager を使用して、サブスクリプション間で 3 種類のトポロジを構築できます。 これらのトポロジは、既存の仮想ネットワークと新しい仮想ネットワークの両方で機能します。

  • スポークが互いに接続されていないハブアンドスポーク。

  • 中央のホップを介さずに、スポーク同士が直接接続されているハブ アンド スポーク構成。

  • 相互接続されている仮想ネットワークのメッシュ グループ。

    

    これらのトポロジには、ハブアンドスポーク、メッシュ、そしてスポーク間の直接接続を備えたハブアンドスポークが含まれます。

    このアーキテクチャの Visio ファイルをダウンロードします。

    スポークが相互に接続されている仮想ネットワーク マネージャーを使用してハブアンドスポーク トポロジを作成すると、同じ ネットワーク グループ 内のスポーク仮想ネットワーク間の直接接続が双方向に自動的に作成されます。 Virtual Network Manager を使用すると、仮想ネットワーク接続を自動的に作成する特定のネットワーク グループのスポーク仮想ネットワーク メンバーを静的または動的に作成できます。

    複数のネットワーク グループを作成して、スポーク仮想ネットワークのクラスターを直接接続から分離できます。 各ネットワーク グループは、スポーク間接続に対して同じリージョンとマルチリージョンのサポートを提供します。 Virtual Network Manager の上限を必ず下回ってください。

• 仮想ネットワークを接続する VPN トンネル: Microsoft VPN ゲートウェイまたは Microsoft 以外の VPN NVA を使用して、スポーク仮想ネットワークに直接接続するように VPN サービスを構成できます。 このオプションの利点は、スポーク仮想ネットワークが、同じクラウド プロバイダーまたはクラウド間の接続プロバイダー内の商用クラウドとソブリン クラウド間で接続することです。 各スポーク仮想ネットワークにソフトウェア定義のワイド エリア ネットワーク NVA がある場合は、Microsoft 以外のプロバイダーのコントロール プレーンと機能セットを使用して、仮想ネットワーク接続を管理できます。

  このオプションは、 Media Access Control Security 暗号化で提供されない単一の Azure データセンター内の仮想ネットワーク間のトラフィックの暗号化に関するコンプライアンス要件を満たすのにも役立ちます。 ただし、このオプションには、インターネット プロトコル セキュリティ トンネルの帯域幅制限 (トンネルあたり 1.25 Gbps) と、ハブとスポークの両方の仮想ネットワークに仮想ネットワーク ゲートウェイを含めるという設計上の制約があるため、独自の課題があります。 スポーク仮想ネットワークに仮想ネットワーク ゲートウェイがある場合、仮想 WAN に接続したり、ハブの仮想ネットワーク ゲートウェイを使用してオンプレミス ネットワークに接続したりすることはできません。

パターン 1a: 単一リージョン

スポーク仮想ネットワークを相互に接続するために使用するテクノロジに関係なく、ネットワーク トポロジは 1 つのリージョンの次の図のようになります。

パターン 1b: 複数リージョン

すべてのスポーク仮想ネットワークを相互に接続する設計は、複数のリージョンにまたがって拡張できます。 このトポロジでは、Virtual Network Manager がさらに重要になります。 これは、多数の接続を維持するために必要な管理オーバーヘッドを減らすのに役立ちます。

完全なメッシュ トポロジでスポーク仮想ネットワークを相互に直接接続する場合は、必要な仮想ネットワーク ピアリングの数が多くなる可能性を考慮する必要があります。 この問題を説明する図を次に示します。 このシナリオでは、仮想ネットワーク接続を自動的に作成できるように、Virtual Network Manager を強くお勧めします。

パターン 2: スポークがネットワーク アプライアンス経由で通信する

スポーク仮想ネットワークを相互に直接接続する代わりに、ネットワーク アプライアンスを使用してスポーク間でトラフィックを転送できます。 ネットワーク アプライアンスは、ディープ パケット検査やトラフィックのセグメント化や監視などの他のネットワーク サービスを提供します。 ただし、適切なサイズに設定されていない場合は、待機時間とパフォーマンスのボトルネックが発生する可能性があります。 これらのアプライアンスは通常、スポークが接続するハブ仮想ネットワークに配置されます。 ネットワーク アプライアンスを使用してスポーク間でトラフィックを転送するには、複数のオプションがあります。

• 仮想 WAN ハブ ルーター: Virtual WAN は Microsoft によって完全に管理されています。 これには、スポークからのトラフィックを引き付け、Virtual WAN に接続されている別の仮想ネットワーク、または ExpressRoute またはサイト間またはポイント対サイト VPN トンネルを介してオンプレミス ネットワークにルーティングする仮想ルーターが含まれています。 Virtual WAN ルーターでは自動的にスケールアップとスケールダウンが行われるため、ユーザーはスポーク間のトラフィック量が Virtual WANの制限内に留まるように確認するだけで十分です。

• Azure Firewall:Azure Firewall は、Microsoft が管理するネットワーク アプライアンスであり、管理するハブ仮想ネットワークまたは Virtual WAN ハブにデプロイできます。 IP アドレス パケットを転送でき、ポリシーで定義されているトラフィックセグメント化ルールを検査して適用することもできます。 ボトルネックにならないように、Azure Firewall の制限まで自動スケールできます。 Azure Firewall には、Virtual WAN で使用する場合にのみ、組み込みのマルチリージョン機能が用意されています。 Virtual WAN を使用しない場合は、リージョン間のスポーク間通信を実現するためにユーザー定義ルートを実装する必要があります。

• Microsoft 以外の NVA: Microsoft パートナーの NVA を使用してルーティングとネットワークのセグメント化を実行する場合は、ハブ アンド スポークまたは Virtual WAN トポロジに NVA をデプロイできます。 詳細については、「高可用性 NVA をデプロイする」または「Virtual WAN ハブの NVA について」を参照してください。 NVA がスポーク間通信によって生成される帯域幅をサポートしていることを確認する必要があります。

• Azure VPN Gateway: VPN ゲートウェイは、ユーザー定義ルートの次ホップの種類として使用できます。 ただし、VPN 仮想ネットワーク ゲートウェイを使用してスポーク間トラフィックをルーティングすることはお勧めしません。 これらのデバイスは、オンプレミスのサイトまたは VPN ユーザーへのトラフィックを暗号化するために設計されています。 たとえば、VPN ゲートウェイがルーティングできるスポーク間の帯域幅は保証されません。

• ExpressRoute: 特定の構成では、ExpressRoute ゲートウェイは、スポーク間通信を引き付けるルートをアドバタイズし、送信先スポークにルーティングされる Microsoft Edge ルーターにトラフィックを送信できます。 このパターンはExpressRoute ヘアピニングと呼ばれることもあり、明示的に有効化する必要があります。 このシナリオでは、Microsoft のバックボーン エッジにトラフィックを送信して戻すことで待機時間が発生するため、このシナリオは強くお勧めしません。 また、単一障害点と広範囲に影響を及ぼす障害範囲も生じさせます。 また、ExpressRoute インフラストラクチャ、特にゲートウェイと物理ルーターに余分な負荷がかけられます。これにより、パケットがドロップする可能性があります。

NVA を一元化したセルフマネージド ハブ アンド スポーク ネットワーク設計では、アプライアンスは通常ハブに配置されます。 ハブアンドスポーク仮想ネットワーク間の仮想ネットワーク ピアリングは、Virtual Network Manager を使用して手動または自動で作成する必要があります。

• 手動の仮想ネットワーク ピアリングまたはサブネット ピアリング: この方法は、スポーク仮想ネットワークの数が少ない場合に十分です。 ただし、大規模な管理オーバーヘッドが発生します。

• Virtual Network Manager: Virtual Network Manager には、仮想ネットワーク環境とピアリングを大規模に管理する機能が用意されています。 ハブアンドスポーク仮想ネットワーク間のピアリング構成は、ネットワーク グループに対して双方向に自動的に構成されます。

  Virtual Network Manager は、スポーク仮想ネットワーク メンバーシップを特定の ネットワーク グループに静的または動的に追加できます。これによって、新しいメンバーのピアリング接続が自動的に作成されます。 ネットワーク グループ内のスポーク仮想ネットワークは、接続にハブ VPN または ExpressRoute ゲートウェイを使用できます。 Virtual Network Manager の上限を必ず下回ってください。

パターン 2a: 単一リージョン

次の図は、ハブ仮想ネットワークにデプロイされている Azure ファイアウォールを介してスポーク間でトラフィックを送信する単一リージョンのハブアンドスポーク トポロジを示しています。 トラフィックは、スポーク サブネットに適用されるユーザー定義ルートを介してハブ内の一元化されたアプライアンスに転送されます。

特定の状況では、スケーラビリティのためにスポーク間トラフィックとインターネット トラフィックを処理する NVA を分離することが有益な場合があります。 この分離を実現するには、次のアクションを実行します。

• 各スポークのルート テーブルを調整して、192.168.0.0/16、172.16.0.0/12、192.168.0.0/16などの RFC 1918 プレフィックスを使用するトラフィックなど、プライベート アドレス トラフィックを NVA に送信します。 このアプライアンスは、Azure から Azure へのトラフィックと Azureto-on-premises トラフィック (多くの場合、 東西トラフィックと呼ばれます) を処理します。

• 0.0.0.0/0 ルートを持つインターネット トラフィックを 2 つ目の NVA に調整します。 この NVA は、Azure からインターネットへのトラフィック ( 南北トラフィックとも呼ばれます) を担当します。

次の図はこの構成を示したものです。

パターン 2b: 複数リージョン

同じ構成を複数のリージョンに拡張できます。 たとえば、Azure Firewall を使用するセルフマネージドハブアンドスポーク設計では、リモート リージョンのスポーク用に各ハブの Azure Firewall サブネットに追加のルート テーブルを適用する必要があります。 この構成により、リージョン間トラフィックを、各ハブ仮想ネットワーク内の Azure ファイアウォール間で確実に転送できます。 スポーク仮想ネットワーク間のリージョン間トラフィックは、その後両方の Azure ファイアウォールを通過します。 詳細については、「 Azure Firewall を使用してマルチハブ とスポークのトポロジをルーティングする」を参照してください。

複数リージョンのハブ アンド スポーク トポロジでは、南北および東西のトラフィック用に個別の Azure ファイアウォールまたは NVA を持つ設計バリエーションも可能です。

Virtual WAN では同様のトポロジを作成し、ルーティングの複雑さを引き受けます。 これは、Microsoft が管理するハブとスポーク内のルーティングを管理します。スポークでは、ルート テーブルを手動で編集しなくてもルートを挿入できます。 ネットワーク管理者は、スポーク仮想ネットワークを Virtual WAN ハブに接続するだけでよく、リージョン間のトラフィックの転送について心配する必要はありません。

混合パターン

一部のシナリオでは、前に説明した 2 つのパターンを組み合わせたハイブリッド アプローチが必要になる場合があります。 この場合、特定のスポーク間のトラフィックは直接接続を経由する必要がありますが、残りのスポークは中央ネットワーク アプライアンスを介して通信します。 たとえば Virtual WAN 環境で、高帯域幅と低待機時間の要件がある 2 つの特定のスポークを直接接続できます。 また、複数のスポーク仮想ネットワークが単一の環境の一部として含まれるシナリオもあります。 たとえば、スポーク開発仮想ネットワークが別のスポーク開発仮想ネットワークに直接接続できる一方で、開発ワークロードと運用ワークロードが中央アプライアンスを介して通信するように強制することができます。

もう 1 つの一般的なパターンは、直接仮想ネットワーク ピアリングまたは Virtual Network Manager 接続グループ を介して 1 つのリージョンのスポークを接続しますが、リージョン間トラフィックが NVA をまたがることができます。 このモデルの主な動機は、通常の場合、アーキテクチャ内の仮想ネットワーク ピアリングの数を減らすことです。 ただし、最初のモデル (スポーク間の直接接続) と比較して、このモデルで発生する欠点の 1 つは、リージョン間トラフィックの仮想ネットワーク ピアリングのホップ数が増えることです。 複数の仮想ネットワーク ピアリングが交差しているため、これらのホップによりコストが増加します。 もう 1 つの欠点は、リージョン間のすべてのトラフィックを処理するためにハブ NVA に余分な負荷がかかることです。

Virtual WAN にも同じ設計が適用されます。 ただし、1 つの考慮事項として、スポーク仮想ネットワーク間の直接接続は、Virtual WAN リソース経由ではなく、仮想ネットワーク自体間で手動で構成する必要があります。 現在、Virtual Network Manager では、Virtual WAN に基づくアーキテクチャはサポートされていません。 次の図について考えてみましょう。

貢献者達

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要な著者:

• Jay Li | シニア プロダクト マネージャー
• Jose Moreno | プリンシパル カスタマー エンジニア
• Alejandra Palacios | シニア Azure インフラストラクチャ カスタマー エンジニア

その他の共同作成者:

• Mick Alberts | テクニカルライター
• Mohamed Hassan | プリンシパル PM マネージャー
• Andrea Michael | プログラム マネージャー
• Yasukuni Morishima | カスタマー エンジニア II
• Jithin PP| カスタマー エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• クラウド導入フレームワーク: ランディング ゾーンのネットワーク トポロジと接続
• Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Azure のネットワーク接続をセキュリティで保護する
• Azure 仮想ネットワークの概要
• 従来の Azure ネットワーク トポロジ

関連リソース

• Azure のハブスポーク ネットワーク トポロジ
• Virtual WAN を使用したハブスポーク ネットワーク トポロジ