スポーク間ネットワーク

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

ほとんどの設計ガイドでは、内部のオンプレミス ネットワークのユーザーから、またはインターネットからそれらの仮想ネットワークへのアプリケーション トラフィックに焦点を当てています (ネットワーク図では垂直線で表されることが多いため、業界では通常 "南北トラフィック" と表現されています)。 この記事では、"東西トラフィック" 用に使用できるさまざまなパターンについて焦点を当てます。 つまり、1 つのリージョン内または異なるリージョンのいずれかで、Azure 仮想ネットワークにデプロイされたワークロード間の通信フローのことです。

ネットワーク設計が東西トラフィックの要件を満たすことの確認は、Azure で実行されるアプリケーションにパフォーマンス、スケーラビリティ、および回復性をもたらすために非常に重要です。

考えられるユース ケース

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

• 1 つのアプリケーションの異なるレベルが別々の仮想ネットワークにある。 たとえば、境界仮想ネットワーク内の境界ネットワーク サーバー ("DMZ サーバー" とも呼ばれます) は、内部仮想ネットワーク内のアプリケーション サービスと通信します。
• 異なる環境 (開発、ステージング、運用) のアプリケーション ワークロードがデータを互いにレプリケートする必要がある。
• さまざまなアプリケーションまたはマイクロサービスが相互に通信する必要がある。
• 障害が発生した場合にビジネス継続性を保証するために、データベースがリージョン間でデータをレプリケートする必要がある。
• ユーザーが Azure 仮想ネットワークの内部にいる。 たとえば、Azure Virtual Desktop を使用しています。

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

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

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

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

• スポークが相互に直接接続される。 仮想ネットワーク ピアリングまたは VPN トンネルがスポーク仮想ネットワーク間に作成され、ハブ仮想ネットワークを通過することなく直接接続できます。
• スポークがネットワーク アプライアンス経由で通信する。 各スポーク仮想ネットワークは、Virtual WAN またはハブ仮想ネットワークにピアリングされます。 アプライアンスは、スポークからスポークへのトラフィックをルーティングします。 アプライアンスは、 (Virtual WAN と同様に) Microsoft が管理するか、ユーザーが管理することができます。

パターン 1: スポークが相互に直接接続される

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

• 仮想ネットワーク ピアリング。 スポークに対する直接仮想ネットワーク ピアリングの利点は次のとおりです。

  • 必要な仮想ネットワーク ピアリングのホップ数が少なくなるため、コストが削減されます。
  • 待機時間や潜在的なボトルネックを引き起こすネットワーク アプライアンスをトラフィックが通過する必要がないため、パフォーマンスが向上します。

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

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

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

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

  • 相互に直接接続され、中間にホップのないスポークを備えたハブアンドスポーク。

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

    

    この記事 のすべての Visio 図面をダウンロードします 。

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

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

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

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

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

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

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

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

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

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

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

• Virtual WAN ハブ ルーター。 Microsoft によって完全に管理される Virtual WAN には仮想ルーターが含まれています。これにより、スポークからトラフィックを引き付け、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 パートナーのネットワーク仮想アプライアンスを使用してルーティングとネットワークのセグメント化を実行する場合は、ハブアンドスポークまたは Virtual WAN のいずれかのトポロジにネットワーク仮想アプライアンスをデプロイできます。 詳細については、「Virtual WAN ハブに高可用性 NVA または NVA をデプロイする」を参照してください。 ネットワーク仮想アプライアンスによって、スポーク間通信で生成される帯域幅がサポートされることを確認する必要があります。

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

• 作成できません。 ExpressRoute ゲートウェイは特定の構成で、スポーク間通信を引き付けるルートをアドバタイズし、Microsoft エッジ ルーターにトラフィックを送信し、そこで送信先スポークにルーティングできます。 このパターンは ExpressRoute ヘアピニングとも呼ばれ、ExpressRoute 経由の VNet 間または VNet から Virtual WAN へのトラフィックを有効または無効にする手順に従って明示的に有効にする必要があります。 このシナリオでは、Microsoft バックボーン エッジにトラフィックを送信して戻すことで待機時間が発生するため、Microsoft ではこのシナリオを使用しないことを強くお勧めします。 さらに、単一障害点と大きな爆発半径のため、Microsoft ではこの方法をお勧めしません。 このシナリオでは、ExpressRoute インフラストラクチャ (ゲートウェイと物理ルーター) に余分な負荷がかかることによって発生する複数の問題も発生します。 この追加の負荷により、パケットの破棄が発生する可能性があります。

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

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

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

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

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

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

特定の状況では、スケーラビリティを得るために、スポーク間トラフィックとインターネット トラフィックを処理するネットワーク仮想アプライアンスを分離すると便利な場合があります。 この分離を行うには、次の操作を行います。

• スポーク内のルーティング テーブルを調整して、プライベート アドレス (RFC 1918 プレフィックスのルートを持つアドレス) を、Azure から Azure へのトラフィックと Azure からオンプレミスへのトラフィック ("東西トラフィック" とも呼ばれます) を担当する NVA に送信します。
• インターネット トラフィック (0.0.0.0.0/0 のルートを持つ) を 2 つ目の NVA に調整します。 この NVA は、Azure からインターネットへのトラフィック ("南北トラフィック" とも呼ばれます) を担当します。

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

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

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

南北トラフィックと東西トラフィック用に別々の Azure ファイアウォールまたはネットワーク仮想アプライアンスを使用した設計バリエーションも、複数リージョンのハブアンドスポーク トポロジで実現できます。

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

混合パターン

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

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

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

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• ジェイ・リー |シニア プロダクト マネージャー
• ホセ・モレノ |プリンシパル カスタマー エンジニア
• アレハンドラ パラシオス |シニア Azure インフラストラクチャ カスタマー エンジニア

その他の共同作成者:

• Mick Alberts | テクニカルライター
• ムハンマド・ハッサン |プリンシパル PM マネージャー
• アンドレア・マイケル |プログラム マネージャー
• 森島 康邦 |カスタマー エンジニア II
• Jithin PP| カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

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

関連リソース

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