Azure仮想ネットワークのsummarizedGatewayPrefixes(アドバタイズされたゲートウェイ プレフィックス)をVPN Gatewayで実機検証してみた

はじめに

Hub & Spoke構成のAzure仮想ネットワークでは、Hubと各スポークVNetが持つアドレス空間の数だけルートがオンプレミスに広告されます(1つのVNetに複数のアドレス空間を定義している場合はその分だけ増えます)。スポークVNetが数百規模になると、ExpressRouteの広告可能プレフィックス数上限(IPv4で1,000、IPv6で100)に近づき、環境の拡張がネットワーク設計上のボトルネックになりかねません。

この課題に対応するのが summarizedGatewayPrefixes です。2026年8月に一般提供(GA)されたことで、この機能が正式に利用できるようになりました。Hub VNetにこのプロパティを設定すると、VPN Gateway/ExpressRoute GatewayはHubおよびスポークVNetの個別CIDRを広告する既定の動作に代えて、任意に指定した集約CIDR(サマリールート)をオンプレミスへ広告するようになります。

• Microsoft Learn: Azure仮想ネットワークでアドバタイズされたゲートウェイ プレフィックスの検証
• Azure Updates: Summarized advertised gateway prefixes for route advertisement(2026年8月 一般提供(GA)発表)

この機能がもたらすメリット

• 広告ルート数の大幅な削減: 数百のスポークVNetのCIDRを少数の集約プレフィックスに置き換えられるため、ExpressRouteの広告可能プレフィックス数上限に抵触しにくくなり、より大規模なHub & Spoke環境を構築できる
• オンプレミス機器の負荷軽減: オンプレミスルーター側で保持・処理するBGPルート数が減るため、ルーティングテーブルのサイズやBGP収束にかかる負荷を抑えられる。特にリソースが限られたオンプレミス機器では効果が大きい
• スポークVNet追加時の運用負担軽減: 新しいスポークVNetのアドレス空間が既に集約範囲に含まれていれば、オンプレミス側の(フィルターなど行っていなければ)設定変更なしにそのまま接続できる(本記事の手順4で実機確認)。スポークVNetを頻繁に追加・削除する環境で運用コストを下げられる
• 既存構成への影響が少ない: Hub VNet側のプロパティ変更のみで有効化でき、オンプレミス側のBGP設定(ピアIP・ASNなど)を変更する必要がない

本記事では、Azure VPN Gateway(Active/Active)とオンプレミスルーター(VyOS)を実際にBGPで接続し、summarizedGatewayPrefixes の設定パターンによってオンプレミス側が受信するルートがどう変化するかを実機で検証します。

検証環境

備考: 本記事の検証は2026年9月時点で実施しています。SKU、制限事項、CLI構文および機能仕様は変更される可能性があるため、最新情報は Microsoft Learn および Azure Updates を参照してください。

構成は以下のとおりです(Hub-Spoke間はVNetピアリングで接続しています)。

Hub & Spoke構成で、後から段階的に集約できるようCIDRを割り当てています。

VNet	CIDR	備考
Hub	10.0.0.0/24	VPN Gatewayを配置
Spoke1	10.1.1.0/24
Spoke2	10.1.2.0/24
Spoke3	10.1.3.0/24	検証の後半で追加

• VPN Gateway: SKU VpnGw1AZ(Active/Active、BGP対応、ゾーン冗長)
  • 非AZ SKU(VpnGw1〜VpnGw5)は2025年11月1日以降、新規作成が不可(2026年9月30日に廃止予定)となっているため、AZ SKUを選択しています。AZ SKUに紐づけるPublic IPにはゾーンの明示指定が必要です。
• オンプレミス対応機器: VyOS 1台(BGP AS 65516)。Azure VPN GatewayとActive/Active(2本のIPsecトンネル)で接続
• BGPピアリングIP: Azure VPN Gateway側のBGPピアリングIPは、カスタムAPIPAアドレスを設定していない場合、169.254.x.xではなくGatewaySubnet内のプライベートIPが使われます。今回は10.0.0.4(インスタンス1)と10.0.0.5(インスタンス2)で、以降の出力に出てくるネクストホップがこれにあたります
• IaC: インフラの作成はTerraformで実施(本記事にコードは掲載しません)。手順ごとに変化する設定(summarizedGatewayPrefixes、Spoke3のピアリング)はAzure CLIで実施

使用ツールのバージョン

ツール	バージョン
Terraform	v1.15.9
azurerm provider	3.117.1
Azure CLI	2.90.0
VyOS	1.5-stream (circinus, rolling)

検証シナリオ

手順	内容	期待値
1	通常のHub & SpokeでVPNを構成	Hub・Spoke1・Spoke2が個別にオンプレルーターに伝達される
2	Hub VNetのsummarizedGatewayPrefixesを構成(Spoke1・Spoke2のみ集約: 10.1.0.0/16)	Hub(個別)とSpoke(集約後)が伝達される
3	Hub VNetのsummarizedGatewayPrefixesを構成(Hub&Spoke全体を集約: 10.0.0.0/8)	Hub&Spoke全体(集約後)が伝達される
4	集約範囲内にSpoke3を追加	広告ルートに変化なし(10.0.0.0/8でカバー済のため)

ルートの確認は、オンプレ(VyOS)側の show ip route bgp と、Azure側の az network vnet-gateway list-advertised-routes で行いました。

実施結果

手順1: 通常のHub & Spoke構成(集約なし)

Azure側がオンプレミスに広告しているルートは、以下のコマンドで確認します。--peerにはオンプレミス側(VyOS)のBGPピアリングアドレスを指定します。

az network vnet-gateway list-advertised-routes `
  --resource-group <リソースグループ名> `
  --name <vpn-gateway名> `
  --peer <オンプレミス側BGPピアリングIP> `
  --output table

結果は以下のとおりです。なお実際の出力はActive/Activeの2インスタンス分がそれぞれ別行で返る(このケースでは3プレフィックス × 2インスタンスで6行)ため、本記事ではネクストホップをまとめて記載しています。

Network      NextHop              AsPath
-----------  -------------------  --------
10.0.0.0/24  10.0.0.4 / 10.0.0.5  65001    (hub)
10.1.1.0/24  10.0.0.4 / 10.0.0.5  65001    (spoke1)
10.1.2.0/24  10.0.0.4 / 10.0.0.5  65001    (spoke2)

AsPath列の65001はAzure VPN Gateway側のBGP ASNです(オンプレのVyOS側は65516)。

VyOS側の受信ルート(show ip route bgp)です。

B>  10.0.0.0/24 [20/0] via 10.0.0.4 (recursive), weight 1, 00:10:28
  *                      via 10.0.0.4, vti1 onlink, weight 1, 00:10:28
                       via 10.0.0.5 (recursive), weight 1, 00:10:28
  *                      via 10.0.0.5, vti2 onlink, weight 1, 00:10:28
B>  10.1.1.0/24 [20/0] via 10.0.0.4 (recursive), weight 1, 00:10:28
  *                      via 10.0.0.4, vti1 onlink, weight 1, 00:10:28
                       via 10.0.0.5 (recursive), weight 1, 00:10:28
  *                      via 10.0.0.5, vti2 onlink, weight 1, 00:10:28
B>  10.1.2.0/24 [20/0] via 10.0.0.4 (recursive), weight 1, 00:10:28
  *                      via 10.0.0.4, vti1 onlink, weight 1, 00:10:28
                       via 10.0.0.5 (recursive), weight 1, 00:10:28
  *                      via 10.0.0.5, vti2 onlink, weight 1, 00:10:28

VyOS側でも同じ3プレフィックスをBGPで受信しており、集約を行っていない既定動作として、Hub・Spoke1・Spoke2それぞれのアドレス空間が個別に広告されることを確認しました。Active/Active構成のため、各ルートは2本のトンネル(vti1/vti2)経由のECMP(Equal-Cost Multi-Path)として受信されています。

手順2: Spoke1・Spoke2のみを集約(10.1.0.0/16)

Hub VNetにsummarizedGatewayPrefixesを設定します。

az network vnet update `
  --resource-group <リソースグループ名> `
  --name <vnet-hub> `
  --summarized-gateway-prefixes address-prefixes="[10.1.0.0/16]"

なお、設定変更が広告ルートに反映されるまでには1〜2分程度のタイムラグがありました。実行直後に確認すると変更前のルートが返ってくるため、少し待ってから確認します。

設定後の広告ルートは以下のとおりです。

Network      NextHop              AsPath
-----------  -------------------  --------
10.0.0.0/24  10.0.0.4 / 10.0.0.5  65001    (hub, 個別のまま)
10.1.0.0/16  10.0.0.4 / 10.0.0.5  65001    (spoke1・spoke2集約後)

VyOS側の受信ルート(show ip route bgp)です。

B>  10.0.0.0/24 [20/0] via 10.0.0.4 (recursive), weight 1, 00:18:28
  *                      via 10.0.0.4, vti1 onlink, weight 1, 00:18:28
                       via 10.0.0.5 (recursive), weight 1, 00:18:28
  *                      via 10.0.0.5, vti2 onlink, weight 1, 00:18:28
B>  10.1.0.0/16 [20/0] via 10.0.0.4 (recursive), weight 1, 00:03:37
  *                      via 10.0.0.4, vti1 onlink, weight 1, 00:03:37
                       via 10.0.0.5 (recursive), weight 1, 00:03:37
  *                      via 10.0.0.5, vti2 onlink, weight 1, 00:03:37

Hubのアドレス空間(10.0.0.0/24)は集約範囲(10.1.0.0/16)に含まれないため、Hubは引き続き個別に広告されます。一方Spoke1・Spoke2の個別プレフィックスは広告されなくなり、10.1.0.0/16 という1つの集約プレフィックスにまとまりました(広告数: 3→2)。

手順3: Hub&Spoke全体を集約(10.0.0.0/8)

集約範囲をHub自身のアドレス空間も含む10.0.0.0/8に変更します。

az network vnet update `
  --resource-group <リソースグループ名> `
  --name <vnet-hub> `
  --summarized-gateway-prefixes address-prefixes="[10.0.0.0/8]"

設定後の広告ルートは以下のとおりです。

Network     NextHop              AsPath
----------  -------------------  --------
10.0.0.0/8  10.0.0.4 / 10.0.0.5  65001

VyOS側の受信ルート(show ip route bgp)です。

B>  10.0.0.0/8 [20/0] via 10.0.0.4 (recursive), weight 1, 00:00:02
  *                     via 10.0.0.4, vti1 onlink, weight 1, 00:00:02
                      via 10.0.0.5 (recursive), weight 1, 00:00:02
  *                     via 10.0.0.5, vti2 onlink, weight 1, 00:00:02

今度はHub自身のアドレス空間も集約範囲(10.0.0.0/8)に含まれるため、Hubの個別広告が停止し、Hub・Spoke1・Spoke2すべてが単一の集約プレフィックスに収束しました(広告数: 2→1)。

手順2と手順3を比較すると、「集約プレフィックスにHub自身のアドレス空間を含めるかどうか」でHubルートの扱いが変わる、という仕様がはっきりと確認できます。

手順4: 集約範囲内にSpoke3を追加

Spoke3(10.1.3.0/24)を作成し、Hubとピアリングします。

az network vnet peering create `
  --name peer-<vnet-hub>-<vnet-spoke3> `
  --resource-group <リソースグループ名> `
  --vnet-name <vnet-hub> `
  --remote-vnet <spoke3のリソースID> `
  --allow-vnet-access --allow-forwarded-traffic --allow-gateway-transit

az network vnet peering create `
  --name peer-<vnet-spoke3>-<vnet-hub> `
  --resource-group <リソースグループ名> `
  --vnet-name <vnet-spoke3> `
  --remote-vnet <hubのリソースID> `
  --allow-vnet-access --allow-forwarded-traffic --use-remote-gateways

追加後の広告ルートは以下のとおりです。

Network     NextHop              AsPath
----------  -------------------  --------
10.0.0.0/8  10.0.0.4 / 10.0.0.5  65001

VyOS側の受信ルート(show ip route bgp)です。

B>  10.0.0.0/8 [20/0] via 10.0.0.4 (recursive), weight 1, 00:05:25
  *                     via 10.0.0.4, vti1 onlink, weight 1, 00:05:25
                      via 10.0.0.5 (recursive), weight 1, 00:05:25
  *                     via 10.0.0.5, vti2 onlink, weight 1, 00:05:25

広告ルートは10.0.0.0/8のまま変化しませんでした(広告数: 1のまま)。追加したSpokeのアドレス空間が既に集約範囲に包含されているため、再設定なしで追加分もそのまま集約プレフィックスでカバーされることを確認しました。

つまずいたポイント

実機で検証する中でハマったポイントを共有します。

az network vnet update --summarized-gateway-prefixesの構文

Preview機能で、単純に--summarized-gateway-prefixes 10.0.0.0/8と渡すとエラーになります。address-prefixes=[10.0.0.0/8]のようなカッコ付き書式指定が必要でした。

まとめ

今回の検証で、summarizedGatewayPrefixes の挙動は記事の説明どおりであることを実機で確認できました。設計上のポイントとしては次のように整理できます。

• Hubを集約範囲に含めるかどうかは意図的に選ぶ必要がある。含めなければHubのルートは個別に見え続ける(トラブルシュート時の可視性は保たれるが広告数削減効果は限定的)。含めれば広告数は最小化できるが、オンプレ側から見てHub/Spokeどのアドレス空間が実際に存在するかの情報は失われる。
• 集約範囲を広めに(将来のSpoke追加分も含めて)設計しておけば、Spoke追加時のオンプレ側ネットワーク機器の再設定が不要になる。ExpressRouteの広告数上限が懸念される大規模Hub & Spoke環境では、この運用上のメリットは大きい。
• 一方で、集約範囲を広く取りすぎると、オンプレミス側のルーティングテーブル上で「実際にどの範囲が使われているか」が分かりにくくなるため、社内のIPAM管理・ドキュメントとセットで運用する必要がある。

大規模環境でExpressRoute/VPN Gatewayの広告ルート数削減を検討している場合は、有効な選択肢だと思います。

We Are Hiring!