最初のクラウドネットワークは簡単です。10 個目になる頃には、ピアリング接続が網の目のように張り巡らされ、オフィスへの VPN トンネルが 3 本、それぞれ少しずつ違う設定で動き、どのネットワークにもファイアウォールがコピーされ、何が何に到達できるのか誰も自信を持って言えなくなります。ハブアンドスポークは、そこから抜け出す標準的な方法です。共有の接続と検査のための中央ネットワークを 1 つ置き、ワークロードはそのネットワークを通じてのみ接続する、分離されたスポークに置きます。
この記事ではトポロジを説明したあと、図を使って 2 通りに構築します。Azure ではハブ仮想ネットワークとピアリングで、AWS では Transit Gateway で構築します。ルーティングとセグメンテーション、トラフィックの検査、送信トラフィックの集約、チームを驚かせるコスト、そしてマネージドなハブのほうが適している場合についても扱います。
フルメッシュが立ち行かなくなる理由
すべてのネットワークを互いに直接つなぐには、n(n−1)/2 本の接続が必要です。10 個なら 45 本、50 個なら 1,225 本になり、それぞれに独自のルートとセキュリティルールがあります。さらに、ピアリングはどちらのクラウドでも推移的ではありません。A が B と、B が C とピアリングしていても、A は B を経由して C に到達できません。ハブアンドスポークではスポークごとに接続は 1 本で済み、ルーティングとセキュリティポリシーはハブという 1 か所に集約されます。
ハブに置くもの
| ハブに置くもの | 理由 |
|---|---|
| VPN と専用線のゲートウェイ | オンプレミスへの接続を 1 本にし、全スポークで共有する |
| 中央のファイアウォールや検査 | スポーク間、オンプレミス向け、インターネット向けのトラフィックに対するポリシーの適用点を 1 つにする |
| DNS リゾルバーとフォワーダー | クラウドとデータセンターをまたいで一貫した名前解決を行う |
| 踏み台やリモートアクセス | スポークにパブリック IP を置かずに管理アクセスする |
| 送信トラフィック | NAT と送信フィルタリングを共有する |
ワークロードはハブに置きません。アプリケーションはスポークに置き、通常はアプリケーション、チーム、環境ごとに 1 つずつ用意します。こうすれば、1 つのスポークでのミスがほかに広がりません。
Azure のハブアンドスポーク
Microsoft のハブスポーク参照アーキテクチャでは、Azure Firewall、VPN または ExpressRoute のゲートウェイ、Azure Bastion を、それぞれ専用のサブネットに分けてハブ仮想ネットワークに置きます。Azure Firewall には /26 以上のサブネットが必要です。スポークは仮想ネットワークピアリングでハブに接続します。Microsoft はこれを非推移的だと説明しています。ピアリングしたネットワーク同士は互いに通信できますが、互いを経由して通信することはできません。
ここから 2 つのことが言えます。
- ゲートウェイの共有は明示的に設定します。 ハブ側のピアリングでゲートウェイ転送を許可し、各スポークがリモートゲートウェイを使うことで、スポークはハブのゲートウェイ経由でオンプレミスに到達します。
- スポーク間のトラフィックにはルートが必要です。 各スポークのユーザー定義ルートで、ほかのスポーク宛てのトラフィックと、通常は既定ルートも、ファイアウォールのプライベート IP に送ります。ファイアウォールはポリシーが許可したものだけを転送します。代わりに Azure Virtual Network Manager でピアリングと接続グループを大規模に管理することもでき、特殊なケースでは 2 つのスポーク間を直接ピアリングする選択肢も残ります。
Microsoft が管理するハブが必要なら、Azure Virtual WAN が、ルーティング、ゲートウェイ、任意のファイアウォールを組み込んだハブを提供します。その代わり、細部の制御は少なくなります。
AWS のハブアンドスポーク
AWS では、ハブは通常 Transit Gateway です。VPC、VPN 接続、Direct Connect ゲートウェイがアタッチされるリージョン単位のルーターです。
- スポークは VPC アタッチメントです。Transit Gateway のクォータによると、Transit Gateway は既定で 5,000 個のアタッチメントをサポートするので、ピアリングのメッシュをはるかに超えて拡張できます。
- セグメンテーションは Transit Gateway のルートテーブルで実現します。本番のアタッチメントをあるルートテーブルに、開発のアタッチメントを別のルートテーブルに関連付ければ、両者は互いのルートを学習しません。それでも、どちらも共有サービスの VPC には到達できます。
- 検査は、AWS Network Firewall や、Gateway Load Balancer の背後に置いたサードパーティーのアプライアンスを動かす専用の検査用 VPC で行います。スポークのルートテーブルは Transit Gateway を指し、Transit Gateway のルートがトラフィックを検査用 VPC に通します。
- 検査用 VPC のアタッチメントでアプライアンスモードを有効にすると、フローの往復が同じアベイラビリティーゾーンに保たれます。ステートフルなファイアウォールにはこれが必要です。
- 送信トラフィックの集約:VPC ごとに NAT ゲートウェイを置く代わりに、NAT ゲートウェイを持つ送信用 VPC がすべてのスポークに対応します。
多数のリージョンにまたがるグローバルネットワークでは、Azure における Virtual WAN の役割を AWS Cloud WAN が担います。ポリシーベースのセグメントを持つマネージドなコアネットワークです。
2 つのクラウドの比較
| 概念 | Azure | AWS |
|---|---|---|
| ハブ | ハブ仮想ネットワーク | Transit Gateway と共有 VPC |
| スポークの接続 | 仮想ネットワークピアリング | Transit Gateway の VPC アタッチメント |
| ルーティングの制御 | ユーザー定義ルート | Transit Gateway のルートテーブルと VPC のルートテーブル |
| 検査 | Azure Firewall またはパートナーのアプライアンス | AWS Network Firewall または Gateway Load Balancer 配下のアプライアンス |
| オンプレミス | ハブ内の VPN または ExpressRoute ゲートウェイ | Transit Gateway にアタッチした VPN または Direct Connect ゲートウェイ |
| マネージドな代替 | Azure Virtual WAN | AWS Cloud WAN |
ルーティング、セグメンテーション、対称性
ハブアンドスポークのネットワークを予測可能に保つルールは 3 つです。
- 既定ルートはハブを指します。 スポークはローカル以外のトラフィックをすべてハブに送るので、うっかり検査を迂回するものはありません。
- セグメントは明示的に定義します。 どのスポークがどのスポークと通信してよいかを決めます。本番と開発は通常は通信できず、共有サービスには通常どこからでも到達でき、オンプレミスへのアクセスはファイアウォールを通ります。
- 戻りのトラフィックは同じ経路を通らなければなりません。 ステートフルなファイアウォールは、往路を見ていない応答を破棄します。非対称なルートは「ファイアウォールのルールはあるのに何も動かない」という状況の最も一般的な原因です。
アドレス計画は、最初のスポークを作る前に書き出しておきましょう。スポーク同士やオンプレミスと重複する CIDR 範囲はハブ経由でルーティングできず、あとから直すのは大変です。
コスト
ハブを通るすべてのバイトには、どこかで料金がかかります。AWS では、執筆時点(2026 年 11 月)の米国東部(バージニア北部)の Transit Gateway の料金は、アタッチメント 1 つあたり 1 時間 $0.05、処理データ 1 GB あたり $0.02 です。スポークのアタッチメントが 10 個あれば、トラフィックがなくても約 10 × $0.05 × 730 時間、つまり月におよそ $365 かかります。スポーク間のトラフィックが 10 TB あれば、約 10,240 GB × $0.02 で処理料金がおよそ $205 加わり、さらにファイアウォール自体の処理料金がかかります。Azure では、ピアリングしたトラフィックにピアリングの両端で GB 単位の料金がかかり、Azure Firewall も独自の処理料金を加えます。
一般的な最適化は対象を絞ったものです。ハブはポリシーのために残し、非常に大量のデータをやり取りし、検査を必要としない特定のスポークのペアにだけ直接ピアリングを追加します。
ハブアンドスポークを使うべきでない場合
- ネットワークが 2〜3 個ならハブは不要です。直接ピアリングのほうがシンプルです。
- レイテンシーが重要な東西トラフィックは、パケットごとに余分なホップとファイアウォールを通ることになります。やり取りの多いサービスのペアを検査に通す前に、計測してください。
- 内部トラフィックが非常に多いと、GB 単位の処理料金がネットワークコストの最大の項目になることがあります。そうしたフローには直接ピアリングが正当化されることがよくあります。
- 非常に大規模なマルチリージョン環境では、手作りのルートテーブルより、Virtual WAN や Cloud WAN といったマネージドなハブのほうが適している場合があります。
ハブアンドスポークの図
ダイアグラムの内容
- On-premises DC · 10.0.0.0/16
- Azure
- Hub VNet
- Azure Firewall
- VPN / ExpressRoute gateway
- Spoke VNet: prod
- Spoke VNet: dev
- AWS
- Transit Gateway
- Inspection VPC
- Network Firewall
- Spoke VPC: prod
- Spoke VPC: dev
- ExpressRoute or VPN
- Direct Connect or VPN
- peering · UDR to firewall
- inspect (appliance mode)
- attachment, prod route table
- attachment, dev route table
図の読み方は次のとおりです。
- 上部のオンプレミスは各クラウドに 1 回ずつ接続します。Azure のハブのゲートウェイと、AWS の Transit Gateway です。
- Azure のフレームは、ファイアウォールと VPN ゲートウェイを持つハブ仮想ネットワークと、それとピアリングした 2 つのスポークを示します。スポーク間のトラフィックはファイアウォールを通ります。
- AWS のフレームは、中央の Transit Gateway、ファイアウォールを持つ検査用 VPC、アタッチされた 2 つのスポーク VPC を示します。
- エッジのラベルは接続の種類を示します。ピアリング、アタッチメント、VPN、専用線です。
- Markdown ブロックには、ルーティングのルールと前述のコストの数字をまとめています。
レビューに耐えるネットワーク図を描くには
- すべてのネットワークに CIDR 範囲を書きます。 レビュアーが最初に確認するのは重複です。
- ファイアウォールは、実際にトラフィックが通る場所に描き、既定ルートがそれを指していることを示します。
- 接続にはすべて種類のラベルを付けます。 ピアリング、アタッチメント、VPN は動作もコストも異なります。
- 図はリージョンごとに 1 枚にします。 マルチリージョンのネットワークを 1 枚のキャンバスに描くと、重要なリージョン間リンクが埋もれがちです。
1 つのネットワークの内部については AWS VPC 図を参照してください。物理トポロジと論理トポロジ全般はネットワークトポロジ図で、ネットワーク上の位置だけでアクセスを許可すべきでない理由はゼロトラストアーキテクチャ図で説明しています。マルチリージョンの設計は AWS マルチリージョンアーキテクチャ図で扱っています。
Archboard で作る
- Google または GitHub でサインインし、図を作成します。
- 上部に、オンプレミスネットワーク用として基本パックの ボックス を追加します。
- Azure 用に基本パックの フレーム を追加します。その中に、ハブ仮想ネットワーク用としてネットワークパックの VPC ノードを置き、さらにその中に ファイアウォール と、VPN ゲートウェイ用の デバイス ノードを置きます。スポーク用には、それぞれ CIDR を書いた VPC ノードをさらに 2 つ追加します。
- AWS 用に基本パックの フレーム を追加します。その中に、Transit Gateway 用としてネットワークパックの ルーター、ファイアウォール を内側に置いた検査用 VPC の VPC ノード、スポーク用の VPC ノードを 2 つ追加します。
- オンプレミスを Azure のゲートウェイと Transit Gateway に、スポークをそれぞれのハブに接続し、すべてのエッジに接続の種類のラベルを付けます。
- ルーティングのルールとコストを書いた基本パックの Markdown ブロックを追加します。
この例で使うダイアグラムノードは 14 個で、Free プランの範囲に収まります。
よくある質問
ハブアンドスポーク型ネットワークトポロジとは何ですか? 中央の 1 つのネットワーク(ハブ)が共有の接続、セキュリティ、サービスを持ち、各ワークロードのネットワーク(スポーク)はハブにだけ接続する設計です。スポーク間やオンプレミスへのトラフィックはハブを通ります。
仮想ネットワークピアリングは推移的ですか? いいえ。Azure でも AWS でも推移的ではありません。同じハブとピアリングした 2 つのスポークは、ルートでトラフィックをハブ内のファイアウォールやルーターに送らない限り、ハブを経由して互いに到達できません。
Transit Gateway と VPC ピアリングの違いは何ですか? VPC ピアリングは 2 つの VPC を直接つなぎ、推移的ではありません。Transit Gateway は多数の VPC やオンプレミス接続がアタッチされるリージョン単位のルーターで、セグメンテーション用のルートテーブルを持ちます。
ハブ仮想ネットワークの代わりに Azure Virtual WAN を使うべきですか? Virtual WAN は、ハブのルーティングとゲートウェイを Microsoft に管理してほしい大規模な環境やマルチリージョンの環境に向いています。自前で管理するハブは制御の自由度が高く、1〜2 リージョンに少数のスポークがある構成でよく使われます。
ハブアンドスポークのコストはどれくらいですか? ハブへの接続と処理したトラフィックに、時間単位と GB 単位で料金がかかり、さらにファイアウォールの処理料金が加わります。執筆時点の AWS の米国東部では、Transit Gateway のアタッチメントが 1 時間 $0.05、データ処理が 1 GB あたり $0.02 です。