ハブアンドスポークネットワークトポロジ

この記事では、Azureでハブアンドスポークネットワークを設計する方法について説明します。中央ハブ仮想ネットワークは共有サービスをホストし、分離されたスポーク仮想ネットワークは個々のワークロードをホストします。

この記事の内容

この記事では、ハブ仮想ネットワーク共有サービス、スポークの分離、ルーティングパターン (標準、ダイレクトピアリング、スタンプベース) について説明します。また、ハイブリッド接続のゲートウェイ転送と、Azure Virtual Network Managerを使用したハブスポークトポロジのスケーリングについても説明します。

この記事が必要なユーザー

これらの条件の 1 つ以上が該当する場合は、この記事をお読みください。

複数のワークロードに対して、ファイアウォール、DNS、Bastion、VPN Gateway、ExpressRoute などの共有ネットワークサービスが必要です。
すべての VNet でこれらのサービスを繰り返すのではなく、トラフィック検査、ルーティング制御、または管理を一元化する必要があります。
共有プラットフォームサービスをワークロード VNet から分離するための反復可能なトポロジが必要です。
トポロジを標準化する前に、ハブアンドスポークを他のトランジットモデルと比較する必要があります。

共有サービス要件のない単一のワークロードがある場合は、代わりにフラットネットワークトポロジから始めます。

Tip

シナリオパスに従っていますか? カスタマイズされたガイダンスについては、ページの上部にあるシナリオを選択してください。以下の主要なガイダンスは、すべての読者に適用されます。

リフトアンドシフトフォーカス:オンプレミスのワークロードをAzureに移行し、複数のスポーク VNet 間で一元化された共有サービス (DNS、ファイアウォール、VPN Gateway) が必要な場合は、この記事をお読みください。ハブアンドスポークは、1 つのハブで共有インフラストラクチャを必要とする複数ワークロードのリフトアンドシフト移行の既定のトポロジです。

最新化の焦点: 複数のリージョンに PaaS サービスをデプロイしていて、IT 所有のハブとアプリチームが所有するスポークを使用するデュアルハブトポロジが必要な場合は、この記事をお読みください。ハブアンドスポークモデルは、プラットフォームサービスとアプリケーションワークロードの個別のサブスクリプション境界をサポートするようにスケーリングされます。

クラウド間のフォーカス:クラウド間転送のハブアンドスポークとVirtual WANを評価する場合は、この記事をお読みください。クロスクラウド資産がVirtual WANが正当化されないほど小さい場合、従来のハブアンドスポークと他のクラウドへのVPN Gateway接続により、より簡単な開始点が提供されます。

Azureサービスと機能

次の表に、ハブアンドスポークトポロジをサポートするAzureサービスと機能を示します。

サービスまたは機能	ハブアンドスポークにおける役割	詳細情報
Azure 仮想ネットワーク	ハブアンドスポーク型仮想ネットワークを提供します	仮想ネットワークの概要
仮想ネットワークピアリング	各スポークをハブに接続します	仮想ネットワークピアリング
Azure Firewall	ハブでの中央トラフィックの検査とフィルター処理	Azure Firewall の概要
VPN Gatewayまたは ExpressRoute ゲートウェイ	すべてのスポークで共有されるハイブリッド接続	VPN Gatewayの概要
Azure Bastion	ピアリングされたスポーク間で VM へのリモートアクセスをセキュリティで保護する	Azure Bastion の概要
Azure プライベート DNS リゾルバー	Azureとオンプレミスの間の DNS 転送	プライベート DNS リゾルバーの概要
Azure DDoS Protection	スポークパブリック IP をカバーする共有 DDoS プラン	DDoS Protection の概要
Azure Virtual Network Manager (AVNM)	スポークピアリングの自動化、UDR の管理、大規模環境でのネットワークグループ	AVNM の概要

どのように機能するのか

ハブアンドスポークトポロジの場合:

ハブ仮想ネットワークは、接続の中心点として機能します。これには、ファイアウォール、ゲートウェイ、Bastion ホストなどの共有ネットワークサービスが含まれています。
スポーク仮想ネットワークは ハブにピアリングされます。各スポークは、ワークロード (アプリケーション、チーム環境、または分離されたサービス) をホストします。
VNet ピアリングは 推移的ではない。スポークはハブに到達できますが、スポーク間のルーティングまたは直接ピアリングを構成しない限り、ハブを介して直接スポークが相互に到達することはできません。

ハブ仮想ネットワークの内容

次の表を使用して、ハブに配置するサービスを決定します。

サービス	含めますか?	メモ
Azure Firewall	推奨	すべての東西トラフィックに対して一元的なトラフィック検査を提供します。正確に `AzureFirewallSubnet`という名前のサブネットが必要です。
VPN または ExpressRoute ゲートウェイ	ハイブリッド接続が必要な場合	すべてのスポークは、ゲートウェイトランジットを介して単一のゲートウェイを共有します。正確に `GatewaySubnet` (最小 /27) という名前のサブネットが必要です。
Azure Bastion	推奨	ハブ内の 1 つの Bastion ホストが、すべてのピアリングされたスポーク仮想ネットワーク内の VM に到達します。 Basic SKU 以上が必要です。開発者 SKU では、クロス VNet ピアリングアクセスはサポートされていません。
プライベート DNS リゾルバー	カスタム DNS が必要な場合	Azureホストされているプライベート DNS ゾーンとオンプレミス DNS サーバーの間で DNS クエリを転送します。
Azure DDoS Protection プラン	DDoS 保護が有効になっている場合	1 つのプランで、ハブサブスクリプションにリンクされているすべてのスポーク仮想ネットワークのパブリック IP アドレスを保護できます。

Important

アプリケーションワークロードをハブから除外します。ハブは、共有インフラストラクチャサービス (ファイアウォール、ゲートウェイ、Bastion、DNS) のみをホストします。アプリケーション VM、コンテナー、および PaaS リソースは、スポーク仮想ネットワークに属します。この分離により、ハブがクリーンに保たれ、ピアリングが簡素化され、プラットフォームチームはアプリケーションチームとは別に共有サービスを管理できます。

ハブサブネットのレイアウト

適切に設計されたハブ仮想ネットワークには、通常、次のサブネットが含まれます。

サブネット名	Purpose	最小サイズ
`AzureFirewallSubnet`	Azure Firewall のデプロイ	/26
`AzureFirewallManagementSubnet`	強制トンネリング用の管理 NIC (Standard/Premium のみ)	/26
`GatewaySubnet`	VPN および ExpressRoute ゲートウェイ	/27
`AzureBastionSubnet`	Azure Bastion	/26
DNS リゾルバーの受信サブネット	プライベート DNS リゾルバーの受信エンドポイント	/28
DNS リゾルバーのアウトバウンドサブネット	プライベート DNS リゾルバーの送信エンドポイント	/28

サブネットのサイズ設定に関する詳細なガイダンスについては、 VNet とサブネットに関するページを参照してください。

バリアントを選択する方法

ハブアンドスポークには、3 つの一般的なバリエーションがあります。分離と通信の要件に基づいて選択します。

Variant	トラフィックパス	いつ使用するか
標準のハブアンドスポーク	すべてのスポーク間トラフィックは、ハブファイアウォールを経由します	一元的なトラフィック検査が必要です。スポークでは、直接ピアツーピア通信は必要ありません。
直接ピアリングを伴うハブアンドスポーク	特定のスポークペアも互いに直接ピアリングする	緊密に結合されたワークロードでは、ファイアウォールを通過することなく、低遅延のスポーク間通信が必要です。
スタンプ (完全に分離)	ハブなし。各仮想ネットワークは完全に独立しています。	厳密なブラスト半径分離、コンプライアンス駆動型分離、または独立したスタックを備えたマルチテナント SaaS。

標準のハブアンドスポーク

このバリアントが最も一般的です。すべてのスポーク間トラフィックは、検査のためにハブファイアウォールを通過します。スポーク同士はハブを介してのみ通信し、直接通信することはありません。

ルーティングパターン: ハブファイアウォールのプライベート IP アドレスを指す既定のルート (0.0.0.0/0) を使用して、各スポークサブネットにユーザー定義ルート (UDR) を適用します。これにより、スポーク間を含むすべての送信トラフィックが、ログ記録とフィルター処理のためにファイアウォールを通過します。

ピアリングの制限: 1 つのハブ仮想ネットワークでは、最大 500 のピアリング接続 (標準プラットフォーム制限) がサポートされます。ハブスポーク接続構成で Azure Virtual Network Manager (AVNM) を使用する場合、制限は 1,000 スポークに増加します。

直接ピアリングを伴うハブアンドスポーク型

一部のアーキテクチャでは、特定のスポークペアでは、ハブファイアウォールを通過せずに待機時間の短い通信が必要です。このような場合は、スポークペア間に直接 VNet ピアリングを追加するか、AVNM 接続グループを使用します。

次の場合は、直接スポークピアリングを使用します。

2 つのワークロードは、高スループットのデータ (たとえば、スポーク間のデータベースレプリケーション) を交換します。
ファイアウォールホップからの待機時間は、特定のデータパスでは許容できません。
直接ピアリングされたトラフィックが中央ファイアウォール検査をバイパスすることを受け入れます。

Note

スポーク間でピアリングを行っても、ハブの必要性がなくなるわけではありません。ハブバインドトラフィック (エグレス、ハイブリッド接続、共有サービス) は、引き続きハブファイアウォールを経由します。

スタンプパターン（完全に独立）

スタンプパターンは、厳密なブラスト半径分離を必要とするシナリオの代替手段です。各ワークロードは、ハブがなく、他のワークロードとのピアリングも行われず、完全に独立した仮想ネットワークにデプロイされます。

スタンプを使用する場合:

規制コンプライアンスでは、ワークロード間のネットワークパスは必要ありません。
各テナントに独立したスタックがあるマルチテナント SaaS。
最大障害分離: 1 つのスタンプの障害を他のスタンプに伝達することはできません。

例: マルチテナント SaaS 分離

SaaS プロバイダーは、各エンタープライズ顧客を専用のスタンプでホストします。各スタンプには、独自の VNet (10.x.0.0/16)、アプリケーションゲートウェイ、コンピューティングレベル、およびデータベースが含まれています。スタンプ間に VNet ピアリングが存在しないため、間違って構成された NSG またはテナント A のスタンプ内の侵害されたワークロードは、ネットワーク経由でテナント B のリソースに到達できません。プロバイダーは、Azure Resource Manager テンプレートを使用してスタンプを管理し、それらを個別のリソースグループまたは大規模なテナント用の個別のサブスクリプションにデプロイします。必要に応じて、テナント間のデータ交換では、共有Azure Service Bus名前空間が使用されます。各スタンプは、プライベートエンドポイントを介してこの名前空間にアクセスします。

トレードオフ:

共有サービスはありません。各スタンプには、それぞれ専用のファイアウォール、ゲートウェイ、および必要に応じて Bastion ホストが必要になるため、コストが増加します。
プライベートネットワーク経由のワークロード間通信はありません。
一元化されたインフラストラクチャではなく、独立したネットワークを管理するため、運用オーバーヘッドが増加します。
共有サービスの節約は適用されないため、スタンプ数によってコストは直線的に増加します。

ワークロードで共有サービスまたはワークロード間通信が必要な場合は、代わりに標準のハブアンドスポークバリアントを使用します。

スポーク間通信パターン

VNet ピアリングは推移的ではないので、スポーク間通信には明示的なルーティングが必要です。このセクションでは、ハブファイアウォールを使用してスポーク間でトラフィックがどのように流れるかについて説明します。

トラフィックフロー: ハブファイアウォールを介してスポーク A からスポーク B へ

次のシーケンスでは、パケットがスポーク A (10.1.0.4) の VM からスポーク B の VM (10.2.0.4) に送信される方法について説明します。

スポーク VM は、10.2.0.4宛てのパケットを送信します。 VM の有効なルートテーブルには、0.0.0.0/0 → 10.0.1.4 (Azure Firewall プライベート IP) を持つ UDR が含まれています。
パケットは、スポーク A からハブ VNet への VNet ピアリングリンクを通過します。ピアリングにより、トラフィックはファイアウォールのサブネットに到達できます。
Azure Firewallは、その内部インターフェイスでパケットを受信します。パケットは、ネットワークルールとアプリケーションルールに対して優先度順に評価されます。
ルールでフローが許可されている場合、ファイアウォールはパケットを 10.2.0.4に転送します。パケットはハブと Spoke-B の間のピアリングリンクを通過します。
スポーク B VM がパケットを受信します。 リターントラフィックは、逆の同じパスに従います。スポーク B の UDR は、ファイアウォールを介して応答を返します。

ルートテーブルの構成

上記のパターンを有効にするには、次のルートテーブルを適用します。

スポークサブネットのルートテーブルを作成します。オンプレミスのルートが UDR をオーバーライドできないようにする場合は、BGP ルートの伝達をオフにします。
次ホップの種類が0.0.0.0/0で、次ホップアドレスが Azure Firewall プライベート IP に設定されている既定のルート (VirtualAppliance) を追加します。
ルートテーブルを、他の スポークまたはインターネットに到達する必要がある各スポークサブネットに関連付けます。
特定のスポーク間トラフィックを許可するファイアウォールネットワーク規則を作成します。たとえば、ポート 443 とポート 1433 で 10.1.0.0/16 → 10.2.0.0/16 を許可します。

Tip

Azure Firewallの IP グループを使用して、スポークアドレス範囲を整理します。これにより、スポークを追加する際のルール管理が簡略化されます。

代替案: スポーク間を直接接続するための AVNM 接続グループ

特定のスポーク間のファイアウォール検査が必要ない場合は、AVNM 接続グループによってメッシュ接続モデルが提供されます。同じ接続されたグループ内のスポークは、ハブを通過することなく直接通信します。これにより、待機時間とファイアウォールのスループット要件が削減されますが、一元的な検査はバイパスされます。

Important

(インターネットにバインドされたトラフィックをオンプレミスアプライアンスにルーティングするために) Azure Firewallで強制トンネリングを有効にする場合は、Standard レベルまたは Premium レベルが必要です。強制トンネリングには、管理サブネット (AzureFirewallManagementSubnet) も必要であり、DNAT 規則をオフにします。

ゲートウェイトランジット

ゲートウェイ転送を使用すると、すべてのスポークがハブにデプロイされた単一の VPN または ExpressRoute ゲートウェイを共有できます。ゲートウェイ転送がない場合、各スポークはオンプレミスネットワークに到達するために独自のゲートウェイを必要とします。

コンフィギュレーションの手順

GatewaySubnetします。
ハブ側ピアリング接続 (ハブ → スポーク): ゲートウェイ転送を許可を有効にします。
スポーク側ピアリング接続 (スポーク → ハブ): [リモートゲートウェイの使用] を有効にします。
ルート伝達を確認します。 構成後、スポーク VM NIC 上の有効なルートを確認します。ルートテーブルには、次ホップのタイプが VNetGlobalPeering または VNetPeering である、ハブゲートウェイ経由で学習されたオンプレミスプレフィックスが表示されます。

構成すると、ハブゲートウェイによって学習されたルート (ExpressRoute のオンプレミスプレフィックスなど) がスポークルーティングテーブルに自動的に伝達されます。

ゲートウェイ転送の制限事項

ゲートウェイ転送は、Basic レベルを除くすべてのVPN Gateway層で動作します。 Basic VPN Gatewayを使用する場合、ピアリングされた仮想ネットワークと共有することはできません。
スポーク仮想ネットワークで使用できるリモートゲートウェイは 1 つだけです。複数のハブとピアリングするスポークで Use remote gateways を有効にすることはできません。
UDR を使用してファイアウォールを通過するトラフィックを強制する場合は、UDR がゲートウェイで伝達されたオンプレミスルートを意図せずにオーバーライドしないようにします。必要に応じて、オンプレミスプレフィックスのより具体的なルートを設定します。

Note

ExpressRoute をゲートウェイトランジットと共に使用する場合は、スポークピアリングを確立する前に Allow gateway transit を有効にします。ゲートウェイが存在し、最初にプロビジョニングされている必要があります。

大規模環境向けの Azure Virtual Network Manager

環境が少数のスポークを超えて拡張されると、ピアリング接続とルートテーブルを手動で管理することは複雑になります。 AVNM は、ハブスポークトポロジの自動化を提供します。

AVNM 機能	それが何をするか
ハブスポーク接続の構成	ハブとネットワークグループ内のすべてのスポークの間にピアリングが自動的に作成され、維持されます。ハブあたり最大 1,000 スポークをサポートします。
接続されているグループ	手動でピアリングすることなく、スポーク間の直接接続を有効にします。既定の制限: グループあたり 250 の仮想ネットワーク (要求によって 1,000 に拡張可能)。
動的メンバーシップを持つネットワークグループ	Azure Policy条件を使用して、タグ、名前付け、またはサブスクリプションに基づいてグループに仮想ネットワークを自動的に追加します。
UDR 管理	複数のハブスポークトポロジ間でのルートテーブルのデプロイを自動化します。

AVNM は、複数のリージョン間でハブスポークトポロジを管理する場合や、新しいスポーク仮想ネットワークがオンラインになったときに動的メンバーシップが必要な場合に特に役立ちます。

スケーリングに関する考慮事項

ハブスポークトポロジが拡大するにつれて、次のプラットフォーム制限と組織パターンを計画します。

ピアリングと接続の制限

ディメンション	Standard の制限	AVNM を使用する	メモ
仮想ネットワークあたりの VNet ピアリング	500	1,000 (ハブスポーク構成)	各スポークとハブ間のピアリングは、両側で 1 つのスロットを使用します
AVNM 接続グループごとの仮想ネットワーク	250 (既定値)	最大 1,000 (要求による)	Azure サポートを通じて増加を要求する
AVNM スコープあたりのサブスクリプション数	N/A	1,000	スコープは、管理グループ内の複数のサブスクリプションにまたがることができます

サブスクリプションの組織

スポークが 10 を超える環境では、スポークをワークロード固有のサブスクリプションに分割します。これにより、ワークロードチームごとの課金、RBAC、クォータの制限が分離されます。
ハブ VNet、ゲートウェイ、ファイアウォールに専用の接続サブスクリプションを使用します。これは、Azure landing zones (プラットフォームサブスクリプション) で推奨されているパターンです。
管理グループの下でサブスクリプションをグループ化し、AVNM がAzure Policy条件を使用してサブスクリプション間でスポーク VNet を動的に検出して管理できるようにします。

Azure Policyを使用したトポロジの適用

Azure Policyを使用して、構成のずれを防ぎます。

非ハブ VNet へのピアリングを拒否します。 ターゲットが指定されたハブ VNet でない限り、VNet ピアリングの作成をブロックするポリシーを管理グループレベルで割り当てます。
UDR の関連付けが必要です。 0.0.0.0/0 → Firewall ルートを含むルートテーブルを含まないスポークサブネットを監査 (または拒否) するポリシーを割り当てます。
AVNM グループメンバーシップを適用します。 タグ ( NetworkRole:Spoke など) に基づいて AVNM の動的メンバーシップ規則を使用して、新しい VNet が自動的に登録されるようにします。

フラットからハブスポークへの移行パス

フラットネットワークトポロジの使用を開始し、共有サービスまたはワークロード間のセグメント化を必要とする環境が拡大している場合は、次の移行パスに従います。

手順 1: ハブ VNet を計画する

既存のフラット VNet と重複しないハブ ( 10.0.0.0/16など) に新しいアドレス空間を割り当てます。
デプロイする共有サービス (ファイアウォール、ゲートウェイ、Bastion、DNS リゾルバー) を決定します。
ハブサブネットレイアウトテーブルごとにハブサブネットのサイズを設定します。

手順 2: ハブに共有サービスをデプロイする

ハブ VNet を作成し、Azure Firewall (または選択した NVA) をデプロイします。
ハイブリッド接続が必要な場合は、VPN/ExpressRoute ゲートウェイをデプロイします。
セキュリティで保護された VM アクセスのためにAzure Bastionをデプロイします。
カスタム DNS を使用する場合プライベート DNSリゾルバーを構成します。

手順 3: ワークロードをスポークに移行する

ワークロードごとに新しいアドレス空間を持つスポーク VNet を作成します。 re-IPできない場合は、ハブと重複しない限り、既存の範囲を保持できます。
各スポークをハブにピア接続します。 ハブ側でゲートウェイ転送を有効にし、スポーク側でリモートゲートウェイを使用します。
ハブファイアウォールを指す既定のルートを使用して、スポークサブネットに UDR を適用します。
フラット VNet から適切なスポークに VM とサービスを移動または再デプロイします。ワークロードの複雑さに応じて、Azure Resource Moverまたは再デプロイを使用します。
ファイアウォール規則を作成して、フラット VNet 内で先に許可していたスポーク間およびスポークからインターネットへのトラフィックパターンを許可します。

手順 4: フラット VNet の使用停止

新しいハブスポークトポロジを介して、すべてのワークロードに到達可能であることを確認します。
プライベート IP アドレスが変更された場合は、DNS レコードを更新します。
すべてのトラフィックを移行して検証したら、古いフラット VNet を削除します。

Tip

ワークロードを段階的に移行します。重要でないワークロードから始めて、ルーティングとファイアウォール規則を検証してから、運用ワークロードに進みます。

代わりにVirtual WANを検討する場合

ハブスポークトポロジの複雑さが増している場合は、Azure Virtual WANの方が適しているかどうかを評価します。

要因	ハブアンドスポーク (従来)	Azure Virtual WAN
Management	カスタマーマネージドハブインフラストラクチャ	Microsoftマネージドハブのルーティングと接続
最適な用途	30 個未満の VPN ブランチ接続、フルコントロールが必要	30 以上の VPN ブランチ、多くのAzure リージョン
Routing	顧客が UDR を手動で構成する	ハブでの自動ルーティング
SD-WAN 統合	手動によるNVAのデプロイ	ネイティブ SD-WAN パートナー統合
グローバルトランジット	カスタマーマネージドのハブ間ルーティングが必要	組み込み: すべてのハブが自動的に相互接続される

詳細な比較については、Azure Virtual WANトポロジに関する記事を参照してください。

設計上の考慮事項

リフトアンドシフト移行の場合は、移行するすべてのワークロードで使用される共有サービスを含む 1 つのハブをデプロイします。

VPN Gatewayを持つ単一ハブ。 VPN Gateway (または ExpressRoute ゲートウェイ) をハブの GatewaySubnet にデプロイします。すべてのスポークワークロードは、移行中および移行後にオンプレミス接続のためにゲートウェイ転送を通じてこのゲートウェイを共有します。
ハブ内の Azure Bastion ハブ内の 1 つの Bastion デプロイにより、移行されたサーバー上のパブリック IP を公開することなく、すべてのピアリングされたスポークにわたって VM への安全な RDP/SSH アクセスが提供されます。
送信トラフィックの一元化されたファイアウォール。 ハブにAzure Firewallをデプロイします。ファイアウォールを指す既定のルートを使用して、すべてのスポークサブネットに UDR を構成します。すべての外向きトラフィックとスポーク間トラフィックは、この単一の検査ポイントを経由します。
1 つのハブから開始し、スポークを段階的に追加します。 各ワークロードを移行する際に、そのスポーク VNet をハブとピアリングします。 1 つのハブでは、最大 500 のピアリング接続 (AVNM では 1,000) がサポートされます。

移行と最新化のシナリオでは、プラットフォームインフラストラクチャとアプリケーションワークロードを分離するデュアルハブトポロジを計画します。

デュアルハブのデプロイ。 プライマリリージョンにハブをデプロイし、バックアップリージョンに 2 つ目のハブをデプロイします。各ハブには、独自のファイアウォール、ゲートウェイ、および Bastion が含まれています。これにより、PaaS ワークロードのアクティブ/アクティブアーキテクチャがサポートされます。
IT 所有のハブ、アプリチーム所有のスポーク。 プラットフォームチームは、ハブサブスクリプション (接続サブスクリプションパターン、共有ハブネットワークリソース用の専用Azure サブスクリプション、ワークロードサブスクリプションとは別) を管理します。アプリケーションチームは、Private Link サブネットとワークロードリソースの管理権限を委任された状態で、自身のスポークサブスクリプションを管理します。
スポークごとのPrivate Linkサブネット。 各スポーク VNet には、プライベートエンドポイント用の専用サブネットが含まれています。アプリケーションチームは、自分のスポーク内で PaaS サービス (Azure SQL、ストレージ、Key Vault) へのPrivate Link接続を作成します。
SNAT/DNAT としてのハブファイアウォール。 各ハブの中央ファイアウォールは、送信トラフィックの送信元 NAT と受信トラフィックパターンの宛先 NAT を提供します。アプリケーションチームは、一元的な検査をバイパスできません。

クラウド間接続の場合は、従来のハブスポークとVirtual WANのどちらが適切なトランジットモデルを提供するかを評価します。

ハブスポークとVirtual WANの決定。 ブランチ接続数が 30 未満で、クラウド間 VPN トンネルの数が少なく、1 つまたは 2 つのAzure リージョンで動作する場合は、VPN Gatewayを使用した従来のハブスポークの方が簡単です。多数の VPN、ブランチ、リージョン、またはクラウドエッジがある場合、Virtual WANはスケーリングが向上する自動ルーティングを提供します。
クラウド間トンネルのVPN Gateway。 ハブスポークモデルで、ハブにVPN Gatewayをデプロイし、AWS Virtual Private Gateway と Google Cloud VPN エンドポイントへのサイト間接続を作成します。各接続では、IPSec/IKE 暗号化が使用されます。
複雑さの増加を評価します。 クロスクラウド資産が拡大する (AWS アカウント、Google クラウドプロジェクト、またはAzureリージョンが増えた) 場合は、ハブスポークとVirtual WANの決定を再検討します。 Virtual WANは、大規模な多数のトンネルを管理する際にコスト効率が高くなります。

詳しい比較については、Azure Virtual WAN トポロジをご覧ください。

前提条件

ハブアンドスポークネットワークを設計する前に、次の手順を実行します。

仮想ネットワークとサブネットの計画を完了します。必要なスポークの数と、各スポークに必要なサブネットを把握します。
IP アドレススキームを定義します。ハブとスポークのアドレス空間は重複してはなりません。
VNet ピアリングは非推移的であることを理解しておいてください。スポークは、ハブ経由で他のスポークへの接続性を引き継ぎません。

セキュリティに関する考慮事項

ハブアンドスポークトポロジは、ハブのセキュリティ適用を一元化します。次の原則を適用します。

すべてのスポークトラフィックをハブファイアウォール経由でルーティングします。 ファイアウォールを指す既定のルートで UDR を使用します。この構成により、ファイアウォールは、すべてのスポーク間フローとスポーク対インターネットフローを検査およびログに記録します。
スポークサブネットの NSG を多層防御の一環として使用します。 中央のファイアウォールを使用する場合でも、スポークサブネット上のネットワークセキュリティグループは、セグメント化の追加レイヤーを提供します。サブネットレベルで予期しない横トラフィックを拒否します。 NSG の設計ガイダンスについては、ネットワークセキュリティグループとアプリケーションセキュリティグループに関するページを参照してください。
ゲートウェイトランジットは注意して有効にしてください。 ゲートウェイトランジットは、オンプレミスのルートをすべてのスポークに公開します。拡張された接続に対してファイアウォール規則が考慮されていることを確認します。
スポーク VM 上のパブリック IP を削除します。 ハブ内のAzure Bastionは、VM をインターネットに公開することなく、セキュリティで保護された管理アクセスを提供します。
各スポークをセキュリティ境界として扱います。 異なるスポークのワークロードは、既定で分離されたままになります。スポーク間の接続には、明示的なルーティングとファイアウォール規則が必要です。

フラットネットワークトポロジ: 共有サービスを必要としない単一のワークロードの場合
Azure Virtual WAN トポロジ: 大規模なマネージドルーティングと接続用
マルチリージョンネットワーク: 複数のAzure リージョンにまたがるワークロード用
VNet とサブネット: ハブコンポーネントのサブネットのサイズ設定
IP アドレスの計画: ハブとスポークの CIDR 計画
ネットワークセキュリティグループとアプリケーションセキュリティグループ: スポークサブネットの多層防御

詳細情報

次のステップ

Tip

あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。

リフトアンドシフト体験の次の手順:

オンプレミスネットワークに接続する: ハブ VNet で VPN Gateway または ExpressRoute を設定して、重要な移行依存関係を確立します。

次に、最新化の取り組みを行います。

複数リージョンのデプロイを計画する: 顧客向けアプリケーションのプライマリリージョンとバックアップリージョン間でアクティブ/アクティブをデプロイします。

マルチクラウドへの移行における次のステップ:

Azure Virtual WANをトランジットモデルとして評価する: Virtual WANまたはハブスポークが複数の VPN、ブランチ、リージョンを持つクロスクラウド資産に最適かどうかを評価します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-01