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

"ハブ アンド スポーク" は、一般的な通信またはセキュリティ要件を効率的に管理するためのネットワーク モデルです。 Azure サブスクリプションの制限の回避にも役立ちます。 このモデルでは、次の懸念事項に対処します。

• 経費節約と効果的な管理：ネットワークの仮想アプライアンス(NVAs) や DNS サーバーのような複数のワークロードで共有できるサービスを集中させます。 サービスの場所は1つであるため、IT 部門はリソースと管理作業量を最小限に抑えることができます。

• サブスクリプションの制限の克服: 大規模なクラウドベースのワークロードでは、単一の Azure サブスクリプション内に収蔵されるリソースよりも多くのリソースの使用が求められる場合があります。 さまざまなサブスクリプションから中央のハブへのワークロード仮想ネットワークのピアリングで、こうした制限を克服できます。 詳細については、Azure サブスクリプションの制限に関するページを参照してください。

• 懸念事項の分離の策定: 中央の IT チームとワークロード チームの間で個々のワークロードをデプロイできます。

小さなクラウド資産は、このモデルによって追加で提供される構造と機能の恩恵を受けない場合があります。 しかし、大規模なクラウド導入作業で、上記のいずれかの懸念事項が 1 つでもあれば、ハブアンドスポーク ネットワーク アーキテクチャの実装を検討してください。

注意

Azure 参照アーキテクチャ サイトには、独自のハブ アンド スポーク ネットワークを実装するための基礎として使用できるサンプル テンプレートが含まれています。

• Azure にハブアンドスポーク ネットワーク トポロジを実装する
• Azure に共有サービスを含むハブアンドスポーク ネットワーク トポロジを実装する

概要

図 1: ハブ アンド スポーク ネットワーク トポロジの例。

図に示したように、Azure では 2 種類のハブアンドスポーク設計がサポートされます。 1つ目の型は、通信、共有リソース、および一元化されたセキュリティポリシーをサポートします。 この型は、図では 仮想ネットワークハブ としてラベル付けされています。 2つ目の型は、図では Virtual WAN としてラベル付けされている Azure Virtual WAN に基づいています。 この型は、大規模なブランチ間通信とブランチ Azure 間通信用です。

ハブは、ゾーン (インターネット、オンプレミス、スポーク) 間のイングレスまたはエグレス トラフィックを制御および検査する中央ネットワーク ゾーンです。 ハブアンドスポークのトポロジでは、IT 部門は一元化された場所でセキュリティ ポリシーを効率的に適用できます。 また、構成の誤りや露出の可能性も低減されます。

多くの場合、ハブには、スポークによって消費される共通のサービス コンポーネントが含まれます。 一般的なセントラルサービスの例を次に示します：

• Azure DNS が使用されていない場合、オンプレミスおよびインターネット上のリソースにアクセスするための、スポーク内のワークロードの名前付けを DNS サービスが解決します。
• 公開キー基盤には、ワークロードのシングル サインオンが実装されています。
• スポーク ネットワーク ゾーンとインターネット間の TCP および UDP のトラフィック フローが制御されます。
• スポークとオンプレミス間のフローが制御されます。
• 必要に応じて、あるスポークと別のスポーク間のフローがコントロールされます。

共有ハブ インフラストラクチャを使用して複数のスポークをサポートすることで、冗長性を最小限に抑え、管理を合理化し、全体的なコストを削減できます。

各スポークのロールは、異なる種類のワークロードをホストできます。 スポークは、同じワークロードの反復可能なデプロイのためのモジュール方式のアプローチも提供します。 例として、開発またはテスト、ユーザー受け入れテスト、ステージング、運用があります。

スポークでは、組織内のさまざまなグループを分離して有効にすることもできます。 例として Azure DevOps グループがあります。 スポーク内には、基本的なワークロードや、階層間のトラフィック制御を伴う複雑な多層ワークロードをデプロイできます。

上の図に示されている Application Gateway は、管理とスケールを向上させるためにサービスを提供しているアプリケーションを使用してスポークでライブ配信できます。 ただし、企業のポリシーでは、管理と職務の分離のために、ハブに Application Gateway を設置するように指示することがあります。

サブスクリプションの制限と複数のハブ

Azure では、あらゆる種類のコンポーネントが Azure サブスクリプションにデプロイされます。 異なる Azure サブスクリプションに Azure コンポーネントを分離することで、差別化されたレベルのアクセスと承認の設定など、さまざまな業種の要件を満たすことができます。

1 つのハブ アンド スポーク実装で多数のスポークにスケールアップできますが、他の IT システムと同様に、プラットフォームの制限があります。 ハブのデプロイは特定の Azure サブスクリプションにバインドされており、サブスクリプションには制約と制限があります。 その一例が、仮想ネットワーク ピアリングの最大数です。 詳細については、Azure サブスクリプションとサービスの制限 に関する記事を参照してください。

制限がイシューになる可能性がある場合は、ハブとスポークのクラスターにモデルを拡張することによって、アーキテクチャをスケールアップできます。 次のものを使用して、1つまたは複数の Azure リージョンに複数のハブを接続できます：

• 仮想ネットワーク ピアリング
• Azure ExpressRoute
• Azure Virtual WAN
• サイト間 VPN

"図 2:ハブとスポークのクラスター。

複数のハブを導入すると、システムのコストと管理のオーバーヘッドが増加します。 この増加は、次のことによってのみ正当化されます：

• スケーラビリティ
• システム制限
• ユーザーパフォーマンスまたはディザスターリカバリーのための冗長性とリージョン内のレプリケーション

複数のハブが必要なシナリオでは、運用を容易にするため、すべてのハブで同じサービスのセットのオファーをする必要があります。

スポーク間の相互接続

1 つのスポーク内に、複雑な多層ワークロードを実装できます。 多階層の構成は、同じ仮想ネットワーク内のサブネット (すべての階層に対して 1 つ) を使い、ネットワーク セキュリティ グループを使ってフローをフィルター処理することによって実装できます。

アーキテクトは、複数の仮想ネットワークに多層ワークロードを展開したいのかもしれません。 仮想ネットワーク ピアリングにより、スポークは同じハブまたは異なるハブの他のスポークに接続できます。

このシナリオの一般的な例は、アプリケーション処理サーバーが 1 つのスポーク (仮想ネットワーク) にあるケースです。 データベースは別のスポーク (仮想ネットワーク) にデプロイされています。 この場合、仮想ネットワーク ピアリングでスポークを相互接続することによって、ハブの通過を簡単に回避できます。 ハブをバイパスすることで、ハブにしか存在しない重要なセキュリティ ポイントや監査ポイントがバイパスされることがないことを確実にするように、アーキテクチャとセキュリティを慎重にレビューする必要があります。

図 3: スポークの相互接続とハブへの接続の例。

スポークは、ハブとして機能するスポークに相互接続することもできます。 この方法では 2 レベルの階層が作成されます：上位レベル (レベル 0) のスポークが、階層の下位レベルまたはレベル1のスポークのハブになります。 スポークは、中央のハブにトラフィックを転送するために必要とされます。 この要件は、トラフィックがオンプレミスネットワークまたはパブリックインターネットで同期先プロバイダーに転送できるようにするためです。 2 レベルのハブのアーキテクチャでは複雑なルーティングが導入され、シンプルなハブアンドスポーク関係のメリットが失われます。

Note

Azure Virtual Network Manager (AVNM) を使用すると、接続とセキュリティ制御を一元管理するために、ハブ アンド スポーク仮想ネットワーク トポロジを新規に作成したり既存のものをオンボードしたりできます。

接続構成を使用すると、メッシュ、またはスポーク仮想ネットワーク間の直接接続を含むハブ アンド スポーク ネットワーク トポロジを作成できます。

セキュリティ構成を使用すると、グローバル レベルで 1 つまたは複数のネットワーク グループに適用できる規則のコレクションを定義できます。

次のステップ

ここでは、ネットワークのベストプラクティスについて説明しました。次は、ID とアクセス制御にアプローチする方法について説明します。

ID 管理とアクセス制御セキュリティのベスト プラクティス