ハブ アンド スポーク ネットワーク トポロジHub and spoke network topology

"ハブ アンド スポーク" は、一般的な通信またはセキュリティ要件を効率的に管理するためのネットワーク モデルです。Hub and spoke is a networking model for efficiently managing common communication or security requirements. Azure サブスクリプションの制限の回避にも役立ちます。It also helps avoid Azure subscription limitations. このモデルでは、次の懸念事項に対処します。This model addresses the following concerns:

  • コストの削減と管理の効率。Cost savings and management efficiency. 複数のワークロードで共有できるサービス (ネットワーク仮想アプライアンス (NVA) や DNS サーバーなど) を 1 か所に集めることで、IT は過剰なリソースと管理作業を最小限にすることができます。Centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location allows IT to minimize redundant resources and management effort.
  • サブスクリプションの制限の克服。Overcoming subscription limits. 大規模なクラウドベースのワークロードでは、単一の Azure サブスクリプション内で許可されるリソースよりも多くのリソースの使用が求められる場合があります。Large cloud-based workloads might require using more resources than are allowed in a single Azure subscription. さまざまなサブスクリプションから中央のハブへのワークロード仮想ネットワークのピアリングで、こうした制限を克服できます。Peering workload virtual networks from different subscriptions to a central hub can overcome these limits. 詳細については、Azure サブスクリプションの制限に関するページを参照してください。For more information, see Azure subscription limits.
  • 懸念事項の分離。Separation of concerns. 中央の IT チームとワークロード チームの間で個々のワークロードをデプロイすることができます。You can deploy individual workloads between Central IT teams and workload teams.

小さなクラウド資産は、このモデルによって追加で提供される構造と機能の恩恵を受けない場合があります。Smaller cloud estates might not benefit from the added structure and capabilities that this model offers. しかし、大規模なクラウド導入作業で、上記のいずれかの懸念事項が 1 つでもあれば、ハブおよびスポーク ネットワーク アーキテクチャの実装を検討してください。But larger cloud adoption efforts should consider implementing a hub and spoke networking architecture if they have any of the concerns listed previously.

注意

Azure 参照アーキテクチャ サイトには、独自のハブおよびスポーク ネットワークを実装するための基礎として使用できるサンプル テンプレートが含まれています。The Azure reference architectures site contains example templates that you can use as the basis for implementing your own hub and spoke networks:

概要Overview

ハブ アンド スポーク ネットワーク トポロジの例Example of a hub and spoke network topology
"図 1:ハブ アンド スポーク ネットワーク トポロジの例。Figure 1: Example of a hub and spoke network topology.

図に示したように、Azure では 2 種類のハブおよびスポーク設計がサポートされます。As shown in the diagram, Azure supports two types of hub and spoke design. 通信、共有リソース、一元的セキュリティ ポリシーをサポートするか (図では VNet hub というラベルが付いています)、ブランチとブランチの間またはブランチと Azure の間の大規模な通信用に Azure Virtual WAN に基づく設計をサポートします (図では Virtual WAN というラベルが付いています)。It supports communication, shared resources, and centralized security policy (labeled as VNet hub in the diagram), or a design based on Azure Virtual WAN (labeled as Virtual WAN in the diagram) for large-scale branch-to-branch and branch-to-Azure communications.

ハブは、ゾーン (インターネット、オンプレミス、スポーク) 間のイングレスまたはエグレス トラフィックを制御および検査する中央ネットワーク ゾーンです。A hub is a central network zone that controls and inspects ingress or egress traffic between zones: internet, on-premises, and spokes. ハブ アンド スポークのトポロジでは、IT 部門は一元化された場所でセキュリティ ポリシーを効率的に適用できます。The hub and spoke topology gives your IT department an effective way to enforce security policies in a central location. また、構成の誤りや露出の可能性も低減されます。It also reduces the potential for misconfiguration and exposure.

多くの場合、ハブには、スポークによって消費される共通のサービス コンポーネントが含まれます。The hub often contains the common service components that the spokes consume. 共通の中央サービスの例を次に示します。The following examples are common central services:

  • 信頼されていないネットワークからアクセスするサード パーティがスポーク内のワークロードにアクセスする前のユーザー認証に必要な Windows Server Active Directory インフラストラクチャ。The Windows server Active Directory infrastructure, required for user authentication of third parties that gain access from untrusted networks before they get access to the workloads in the spoke. これには、関連する Active Directory フェデレーション サービス (AD FS) が含まれます。It includes the related Active Directory Federation Services (AD FS).
  • オンプレミスおよびインターネット上のリソースにアクセスするための、スポーク内のワークロードの名前付けを解決する DNS サービス (Azure DNS が使用されていない場合)。A DNS service to resolve naming for the workload in the spokes, to access resources on-premises and on the internet if Azure DNS isn't used.
  • ワークロードにシングル サインオンを実装するための公開キー基盤 (PKI)。A public key infrastructure (PKI), to implement single sign-on on workloads.
  • スポーク ネットワーク ゾーンとインターネット間の TCP/UDP トラフィックのフロー制御。Flow control of TCP and UDP traffic between the spoke network zones and the internet.
  • スポークとオンプレミス間のフロー制御。Flow control between the spokes and on-premises.
  • (必要に応じて) スポーク間のフロー制御。If needed, flow control between one spoke and another.

共有ハブ インフラストラクチャを使用して複数のスポークをサポートすることで、冗長性を最小限に抑え、管理を合理化し、全体的なコストを削減できます。You can minimize redundancy, simplify management, and reduce overall cost by using the shared hub infrastructure to support multiple spokes.

各スポークのロールは、異なる種類のワークロードをホストできます。The role of each spoke can be to host different types of workloads. スポークは、同じワークロードの反復可能なデプロイのためのモジュール方式のアプローチも提供します。The spokes also provide a modular approach for repeatable deployments of the same workloads. 例として、開発またはテスト、ユーザー受け入れテスト、ステージング、運用があります。Examples include dev/test, user acceptance testing, staging, and production.

スポークでは、組織内のさまざまなグループを分離して有効にすることもできます。The spokes can also segregate and enable different groups within your organization. 例として Azure DevOps グループがあります。An example is Azure DevOps groups. スポーク内には、基本的なワークロードや、階層間のトラフィック制御を伴う複雑な多層ワークロードをデプロイできます。Inside a spoke, it's possible to deploy a basic workload or complex multitier workloads with traffic control between the tiers.

サブスクリプションの制限と複数のハブSubscription limits and multiple hubs

Azure では、種類に関係なく、すべてのコンポーネントが Azure サブスクリプションにデプロイされます。In Azure, every component, whatever the type, is deployed in an Azure subscription. 異なる Azure サブスクリプションに Azure コンポーネントを分離することで、差別化されたレベルのアクセスと承認の設定など、さまざまな業種の要件を満たすことができます。The isolation of Azure components in different Azure subscriptions can satisfy the requirements of different lines of business, such as setting up differentiated levels of access and authorization.

単一のハブおよびスポーク実装で、多数のスポークにスケールアップできます。A single hub and spoke implementation can scale up to a large number of spokes. ただし、他の IT システムと同様に、プラットフォームの制限があります。But as with every IT system, there are platform limits. ハブのデプロイは特定の Azure サブスクリプションにバインドされており、サブスクリプションには制約と制限があります。The hub deployment is bound to a specific Azure subscription, which has restrictions and limits. その一例が、仮想ネットワーク ピアリングの最大数です。One example is a maximum number of virtual network peerings. 詳細については、Azure サブスクリプションとサービスの制限 に関する記事を参照してください。For more information, see Azure subscription and service limits.

制限が問題になる可能性がある場合は、単一のハブアンドスポークからハブアンドスポークのクラスターにモデルを拡張することによって、アーキテクチャをさらにスケールアップできます。In cases where limits might be an issue, you can scale up the architecture further by extending the model from a single hub and spoke to a cluster of hubs and spokes. 仮想ネットワーク ピアリング、Azure ExpressRoute、Azure Virtual WAN、またはサイト間 VPN を使用して、1 つ以上の Azure リージョン内の複数のハブを相互接続できます。You can interconnect multiple hubs in one or more Azure regions by using virtual network peering, Azure ExpressRoute, Azure Virtual WAN, or a site-to-site VPN.

ハブとスポークのクラスターCluster of hubs and spokes
"図 2:ハブとスポークのクラスター。Figure 2: A cluster of hubs and spokes.

複数のハブを導入すると、システムのコストと管理のオーバーヘッドが増加します。The introduction of multiple hubs increases the cost and management overhead of the system. これが妥当なのは、ユーザーのパフォーマンスやディザスター リカバリーのために、スケーラビリティ、システムの制限、または冗長性やリージョン レプリケーションが必要な場合だけです。This is only justified by scalability, system limits, or redundancy and regional replication for user performance or disaster recovery. 複数のハブが必要なシナリオでは、運用を容易にするため、すべてのハブで同じサービスのセットを提供する必要があります。In scenarios that require multiple hubs, all the hubs should strive to offer the same set of services for operational ease.

スポーク間の相互接続Interconnection between spokes

1 つのスポーク内に、複雑な多層ワークロードを実装できます。It's possible to implement complex multitier workloads in a single spoke. 多階層の構成は、同じ仮想ネットワーク内のサブネット (すべての階層に対して 1 つ) を使い、ネットワーク セキュリティ グループを使ってフローをフィルター処理することによって実装できます。You can implement multitier configurations by using subnets (one for every tier) in the same virtual network and by using network security groups to filter the flows.

アーキテクトは、複数の仮想ネットワークに多層ワークロードをデプロイできます。An architect might want to deploy a multitier workload across multiple virtual networks. 仮想ネットワーク ピアリングにより、スポークは同じハブまたは異なるハブの他のスポークに接続できます。With virtual network peering, spokes can connect to other spokes in the same hub or in different hubs.

このシナリオの一般的な例は、アプリケーション処理サーバーが 1 つのスポーク (仮想ネットワーク) にあるケースです。A typical example of this scenario is the case where application processing servers are in one spoke or virtual network. データベースは別のスポーク (仮想ネットワーク) にデプロイされています。The database deploys in a different spoke or virtual network. この場合、仮想ネットワーク ピアリングでスポークを相互接続することによって、ハブの通過を簡単に回避できます。In this case, it's easy to interconnect the spokes with virtual network peering and avoid transiting through the hub. ハブをバイパスすることで、ハブにしか存在しない重要なセキュリティ ポイントや監査ポイントがバイパスされることがないように、アーキテクチャとセキュリティを慎重に見直すことが解決策となります。The solution is to perform a careful architecture and security review to ensure that bypassing the hub doesn't bypass important security or auditing points that might exist only in the hub.

スポークの相互接続とハブへの接続Spokes connecting to each other and a hub
"図 3:スポークの相互接続とハブへの接続。Figure 3: Spokes connecting to each other and a hub.

スポークは、ハブとして機能するスポークに相互接続することもできます。Spokes can also be interconnected to a spoke that acts as a hub. この方法では 2 レベルの階層が作成され、上位レベル (レベル 0) のスポークが、階層の下位レベル (レベル 1) のスポークのハブになります。This approach creates a two-level hierarchy: the spoke in the higher level (level 0) becomes the hub of lower spokes (level 1) of the hierarchy. ハブ アンド スポーク実装のスポークは、トラフィックがオンプレミス ネットワークまたはパブリック インターネットのいずれかで送信先に到達できるように、中央のハブにトラフィックを転送する必要があります。The spokes of a hub and spoke implementation are required to forward the traffic to the central hub so that the traffic can transit to its destination in either the on-premises network or the public internet. 2 レベルのハブのアーキテクチャでは複雑なルーティングが導入され、シンプルなハブおよびスポーク関係のメリットが失われます。An architecture with two levels of hubs introduces complex routing that removes the benefits of a simple hub and spoke relationship.