ExpressRoute / VPN Gateway のルート広告を要約できるようになった！ Summarized Gateway Prefixes 🚀

こんにちは、経路表の都合でアドレス設計まで引っ張られるとちょっとつらいアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

なお、この記事は 2026/05/25 の執筆時点 の情報で、扱っている機能は Public Preview です。

TL;DR

• 2026/05/20 に Azure Updates へ、ExpressRoute Gateway と VPN Gateway の広告プレフィックスを要約できる Preview が追加されました
• Hub-and-Spoke で Azure からオンプレミスへ広告する経路数を減らしたいときの有力候補です
• ルート数上限の課題に効く可能性は高いですが、効くのは Azure -> オンプレミス の広告経路数です
• VPN Gateway ラボでは、設定直後に即切り替わるというより、BGP 再収束後に集約結果が反映されました
• Public Preview なので、本番適用前に受信ルート数の変化と切替時挙動は見ておいたほうが安心です

先に結論

結論からいうと、Azure -> オンプレミス の広告本数を減らしたい環境では有力候補です。

特に、Hub-and-Spoke で Azure からオンプレミスへ広告する prefix 数が増え、対向装置の受信上限が気になってきたときに検討しやすいです。

ただし、効くのは Azure -> オンプレミス の広告本数です。

こういう場面で候補になります

例えば次のような場面です。

• VNet Gateway (ER GW / VPN GW) の対向にあるオンプレミス側装置で、受信できるルート数に上限がある
• Hub-and-Spoke が大きくなってきて、Spoke を増やすたびに広告経路が増えていく
• その結果、Azure 側でぶら下げられる VNet 数やアドレス設計が先に苦しくなってくる
• できれば VNet を細かく割り直す前に、広告経路数を抑えられないか考えたい

こういう場面では、今回の Summarized Gateway Prefixes が候補に入ります。

Azure 側から広告するルート数を減らして、対向装置の受信上限問題を和らげられるか。この記事では、そこに絞って見ます。

何が追加されたの？

2026/05/20 に Azure Updates へ追加されたのがこちらです。

• Public Preview: Summarized advertised gateway prefixes for route advertisement

Microsoft Learn の説明では、Hub VNet に summarizedGatewayPrefixes というプロパティを設定することで、ExpressRoute Gateway や VPN Gateway がオンプレミスへ広告するプレフィックスを、個別 CIDR ではなく要約 CIDR に置き換えられます。

これまでは Spoke ごとに /24 を何本も広告していた構成でも、うまく設計できていれば /16 や /20 のような少数の要約プレフィックスに寄せられます。

どんな構成で向いているの？

まず考えやすいのは、Hub-and-Spoke + gateway transit の構成です。

今回はそのまま使いたい公式図が見当たらなかったので、まずはオリジナルでイメージ図を起こしてみました。
変更前後のイメージはこうです。

既定では、Hub VNet のアドレス空間に加えて、Peering された Spoke VNet のアドレス空間もオンプレミスへ広告されます。

たとえば次の形です。

項目	従来	要約後のイメージ
Hub	10.0.0.0/20	10.0.0.0/16
Spoke A	10.0.16.0/24	要約に含まれるので個別広告なし
Spoke B	10.0.17.0/24	要約に含まれるので個別広告なし
Spoke C	10.0.18.0/24	要約に含まれるので個別広告なし

このときオンプレミス側は、細かい /24 を何本も受ける代わりに、より大きい要約プレフィックスを受けることになります。

右側の図では、Hub VNet の 10.0.0.0/20 を別では書いていません。
Microsoft Learn では、summarizedGatewayPrefixes を設定すると、Gateway を持つ VNet の address space はそのまま広告されず、代わりに指定した要約プレフィックスが広告されると説明されています。

今回の例では、Hub の 10.0.0.0/20 と各 Spoke の /24 を個別に出すのではなく、それらを包含する 10.0.0.0/16 を広告するイメージです。
右図で 10.0.0.0/20 が出ていないのは、仕様に寄せた表現です。

要約する粒度は選べるの？

これは 自動ではなく、自分で選びます。

summarizedGatewayPrefixes は、Hub VNet 側に設定する 要約 CIDR のリストです。
Azure 側が勝手に丸めてくれるのではなく、利用者が「どこまでまとめるか」を設計して渡します。

たとえば、

• 10.0.0.0/16 で広くまとめる
• 10.0.0.0/16、10.1.0.0/16、10.2.0.0/16 のように複数に分ける
• IPv4 と IPv6 を別々に定義する

といった切り方ができます。

ただし前提もあります。

• Hub VNet の address space は、どれかの要約プレフィックスで必ずカバーする
• 要約リスト同士の重複は避ける
• 要約に 含まれない Spoke は、引き続き個別広告が残る

完全自動のサマライズ機能ではなく、設計した要約 CIDR を明示的に渡す機能です。

ルート数上限問題に効くのか？

ここが本題です。

まず、効く可能性が高いケース

次の 3 条件がそろっていれば、この機能は有力です。

• 減らしたいのが Azure -> オンプレミス の広告経路数 である
• Azure 側の Hub / Spoke アドレスをきれいに要約できる
• オンプレミス側が要約された経路を受けても運用上困らない

もう少し具体的に書くと、次のイメージです。

• オンプレミス側機器の制約が Azure から受信する BGP ルート数上限 にある
• Azure 側の Hub / Spoke アドレスが、少数の上位プレフィックスへ要約しやすい
• オンプレミス側で個別 Spoke プレフィックスではなく、要約プレフィックス受信でも問題ない

Microsoft Learn でも、この機能は「Azure からオンプレミスへ広告するプレフィックス数を減らすためのもの」として説明されています。

ExpressRoute FAQ では、単一 ExpressRoute 接続あたり Azure からオンプレミスへ広告できる上限として、たとえば次の目安が書かれています。

• IPv4: 1,000 prefixes
• IPv6: 100 prefixes

しかも、この上限を超えると ExpressRoute circuit と gateway の接続が切断され、上限を下回ると再確立すると明記されています。

この Preview は、Azure 発の広告件数を減らして、その上限に当たりにくくするための機能です。

何が減って、何が減らないの？

整理するとこうです。

観点	この機能で減らせる？	補足
Azure からオンプレミスへ広告する Hub/Spoke の経路数	○	本機能のど真ん中です
要約プレフィックスに含まれる Spoke の個別広告	○	要約に含まれるので個別には出なくなる
要約に含まれない Spoke の個別広告	×	そのまま残ります
オンプレミスから Azure へ広告する経路数	×	別問題です
Gateway が学習する総ルート上限	×	直接の解決策ではありません

設定はどこに入るの？

設定対象は Hub VNet 側です。

• Advertised gateway prefixes in Azure virtual networks - Microsoft Learn

• Summarized Gateway Prefixes for Route Advertisement in Azure Virtual Networks - Microsoft Tech Community

• Hub VNet にある GatewaySubnet を持つ VNet が対象
• プロパティ名は summarizedGatewayPrefixes
• Azure portal では Address space の中にある Advertised gateway prefixes から設定

実際のラボ環境で見ると、Hub VNet の「設定 > アドレス空間」ブレードにはこう出ていました。

「アドレス空間」タブでは、Hub VNet の 10.250.0.0/16 と peering 先の spoke が並んでいます。ここまでは通常の VNet と同じです。

隣の「アドバタイズされるゲートウェイ プレフィックス」タブを開くと、設定した要約プレフィックスが確認できます。

ここに 10.250.0.0/16 と 10.252.0.0/16 の 2 本が入っているのが、summarizedGatewayPrefixes が設定済みで、Portal 上でも反映されている証跡です。

Portal から設定する場合は、この「アドバタイズされるゲートウェイ プレフィックス」タブの「アドレス プレフィックスの追加」から要約したい CIDR を追加して「保存」します。

CLI / REST で設定する場合

Azure portal 以外で設定する場合は、ARM REST API で VNet の summarizedGatewayPrefixes プロパティを直接更新できます。

今回のラボでは、次のように az rest で設定しました。

Azure CLI (ARM REST)

# Hub VNet に summarizedGatewayPrefixes を設定する
az rest --method put --headers Content-Type=application/json \
  --uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>?api-version=2025-09-01" \
  --body @body.json

api-version=2025-09-01 は今回のラボで動作したバージョンです。この機能は Public Preview のため、必要な最小 API バージョンが今後変わる可能性があります。実行時は Virtual Networks - REST API Reference で最新の対応バージョンを確認してください。

body.json の中身はこうです。既存の VNet プロパティに summarizedGatewayPrefixes を足す形で渡します。

body.json（要約プレフィックスの指定部分）

{
  "properties": {
    "summarizedGatewayPrefixes": {
      "addressPrefixes": ["10.250.0.0/16", "10.252.0.0/16"]
    }
  }
}

az rest --method put で VNet 全体を更新するため、既存の address space や peering を壊さないよう、必要に応じて既存プロパティも body に含めてください。

この機能は Gateway リソースの SKU を変える話でも、Gateway を作り直す話でもなく、VNet 側のプロパティ更新として説明されています。

前提条件と制約

前提は次のとおりです。

• Hub VNet 側に設定する
• Spoke VNet に設定しても無視される
• GatewaySubnet と Gateway がない状態でも値の設定自体はできるが、効果が出るのは Gateway があるとき
• 要約プレフィックスは Hub 側のアドレス空間をちゃんと含める前提で考えたほうがよい
• 要約プレフィックス同士の重複は避ける
• 要約に含まれない Spoke は個別広告のまま残る
• Hub 自身の prefix も、要約プレフィックスに置き換わる
• IPv4 / IPv6 両対応だが、dual-stack なら両方を明示する
• Azure Route Server は不要

切り替わり方はどう見えた？

設定を入れた瞬間に learned routes がすぐ切り替わる感じではありませんでした。BGP 再収束後に集約結果が反映されます。

Branch 側で route 数が 6 本から 2 本へ減るところまで確認できました。
後追いで Activity Log と成果物時刻も突き合わせると、この回は設定成功直後ではなく、3 分程度 かかっていました。

今回確認できたのは、VNet の control plane 更新時刻と、Branch 側 learned routes が減ったことまでです。

• Activity Log で追えるのは VNet の control plane 更新時刻まで
• learned routes が実際に減った瞬間までは持たない
• 再収束時間や flap を見たいなら、事前に diagnostic settings を有効化して RouteDiagnosticLog / TunnelDiagnosticLog と learned routes の時系列採取を併用したほうがよい
• 今回の採取だけでは、瞬断や BGP セッション flap の有無までは断定していない

詳しくは参考欄の VPN Gateway monitoring / BGP troubleshooting の Docs を見ると追いやすいです。

実際に VPN Gateway でラボ検証してみた

ここまでは公式情報ベースの整理でしたが、机上だけでは少し気持ち悪かったので、Azure-only の VPN Gateway ラボでも試しました。

ラボ構成のイメージ

図解イメージとしては、Hub に VPN Gateway を置き、Branch（オンプレ相当）側から learned routes を観測する最小構成です。

※ このラボは Azure-only 構成 です。左側は実際のオンプレ機器ではなく、Azure 上の Branch VNet を オンプレ相当 として置いています。

見るポイントは Branch 側で何本の route を受けるか です。

ラボの前提

• Hub VNet: 10.250.0.0/16
• Branch VNet: 10.251.0.0/24 （オンプレ環境に見立てた VNet）
• Spoke: 10.252.1.0/24 から 10.252.5.0/24
• Hub / Branch に VPN Gateway を 1 台ずつ
• BGP 有効
• Hub 側の summarizedGatewayPrefixes:
  • 10.250.0.0/16
  • 10.252.0.0/16

並びをざっくり書くとこうです。

• Branch VNet
• VPN Gateway
• Hub VNet
• 5 つの spoke

この構成で、Branch 側 learned routes の before / after を見ました。

今回のラボでは、Gateway 作成まわりの前提として次を置いています。

• 新規 VPN Gateway は non-AZ SKU では作れず、VpnGw1AZ を使いました
• VpnGw1AZ では、zone 付き Standard Public IP が必要でした

before / after で何が変わったか

文字だけだと流れやすいので、まずは Branch 側で見えた learned routes の差分を表にするとこんな感じです。

観測点	設定前	設定後
Branch 側 learned routes 本数	6 本	2 本
Hub 側 prefix	10.250.0.0/16	10.250.0.0/16
Spoke 個別 prefix	10.252.1.0/24 〜 10.252.5.0/24	なし
要約 prefix	なし	10.252.0.0/16

実際の Azure portal の BGP peers 画面で見ると、設定前と設定後でこう変わります。
（Portal のスクショでは追加検証で足した 10.253.1.0/24 等も含まれるため、表の本数と Portal 上の本数は一致しません。Spoke 5 本分の集約が主題です。）

設定前（summarizedGatewayPrefixes 未設定）

見るポイントは 2 つです（赤枠の行）。

• BGP ピアテーブル: Hub 側 peer 10.250.255.30 / ASN 65010 の「受信したルート」列が 7 になっています
• 学習したルートテーブル（赤枠 下 2 行）: 10.252.1.0/24 や 10.252.2.0/24 など、Spoke 個別 prefix がそのまま並んでいます（画面内に見えているのは 2 行分ですが、スクロールすると /24 が 5 本並んでいます）

設定後（summarizedGatewayPrefixes 設定済み）

同じ 2 箇所を見てください（赤枠の行）。

• BGP ピアテーブル（赤枠 上）: Hub 側 peer の「受信したルート」が 7 → 3 に減っています
• 学習したルートテーブル（赤枠 下 2 行）: 10.252.1.0/24 〜 /24 が消えて、代わりに 10.252.0.0/16 の 1 本に集約されています。10.253.1.0/24 は要約に含まれない Spoke なので、個別のまま残っています

Branch 側で learned routes を見たところ、設定前は 6 本でした。

• 10.250.0.0/16
• 10.252.1.0/24
• 10.252.2.0/24
• 10.252.3.0/24
• 10.252.4.0/24
• 10.252.5.0/24

その後、Hub VNet に summarizedGatewayPrefixes を設定して BGP 再収束を待つと、Branch 側で見える learned routes は 2 本まで減りました。具体的には、10.252.1.0/24 〜 10.252.5.0/24 の 5 本が 10.252.0.0/16 の 1 本に集約され、Hub 自体の 10.250.0.0/16 はそのまま残っています。

• 10.250.0.0/16
• 10.252.0.0/16

Branch 側では、5 本の Spoke 個別 prefix が 1 本の要約 prefix にまとまりました。
Hub 側の 10.250.0.0/16 自体を summarizedGatewayPrefixes に入れていたので、Branch から見える Hub 側 prefix も 10.250.0.0/16 の 1 本です。GatewaySubnet の範囲が別 prefix として見えているわけではなく、Hub VNet の address space がそのまま 1 本の要約 prefix になっている 形です。

実際にやって分かったこと

• 設定直後に learned routes がすぐ減るとは限らず、BGP 再収束待ちが必要だった
• 要約に含まれない Spoke は、個別 prefix のまま残った
• Spoke 側に summarizedGatewayPrefixes を設定しても、route の変化は出なかった
• Hub 自身の prefix も、summary を入れると要約プレフィックスへ置き換わった

ここで見たのは、あくまで Azure 側で広告プレフィックスがどう減るか です。
ExpressRoute の circuit、private peering、provider 側 provisioning、実際の対向ルータの受信挙動までは、このラボでは見ていません。

実際にどこを検証すればいい？

今回のラボで route 集約の効果そのものは確認できましたが、本番適用前は最低でも次を見ておきたいです。

• 変更前後で、オンプレミス側が受信する Azure プレフィックス数が何本から何本に減るか
• 要約に含まれない Spoke が個別広告として残っていないか
• BGP セッション自体に flap が出るか
• ルート切替の再収束時間がどれくらいか
• オンプレミス側の prefix-list、route-map、FW ポリシーに影響がないか
• Azure portal の BGP peers 画面や PowerShell で広告ルートが期待どおりに変わっているか
• Activity Log の時刻だけで完了扱いにせず、learned routes / BGP peer status でも収束を確認する

このあたりを先に見ておくと、本番適用時の切り分けがやりやすくなります。

ExpressRoute と S2S VPN の共存構成で使うときの注意

この節は @carol0226 さんのコメントを踏まえて追記しました。Special Thanks 🙏

そもそも ER と VPN は同じ Hub VNet に共存できるの？

できます。ExpressRoute Gateway と VPN Gateway を同じ Hub VNet に置く構成（coexisting connections）は公式にサポートされています。

• Configure ExpressRoute and Site-to-Site coexisting connections - Microsoft Learn

典型的なユースケースは次の 2 つです。

• S2S VPN を ER のフェイルオーバーに使う
• ER に接続されていないサイトを VPN で追加接続する

制約として、VPN Gateway は RouteBased かつ Basic SKU 以外 が必要です。

公式 Docs の「Using S2S VPN as a backup for ExpressRoute private peering」に掲載されている構成図が分かりやすいです。ExpressRoute Private Peering + S2S VPN バックアップの典型構成はこうなります。

• Using S2S VPN as a backup for ExpressRoute private peering - Microsoft Learn

Longest Prefix Match で意図しない経路選択が起きる

この共存構成で summarizedGatewayPrefixes を使うときに注意が必要なのは、Longest Prefix Match (LPM) の動作です。

ER と VPN の共存構成では、Azure からオンプレ側に両方の Gateway からルートが広告されます。オンプレ側の CE ルータは、受信したルートに対して BGP best path selection を行います。その際、Longest Prefix Match（最長一致）が最優先 です。

Azure 側（effective routes）でもオンプレ側ルータでも、ルート選択の基本原則は共通です。

1. Longest Prefix Match（最長一致）: prefix 長が長い（具体的な）ルートが常に勝つ
2. ER 優先（既定）: prefix 長が同じなら ExpressRoute が優先される
3. AS Path 長: 上記が同じときの tiebreaker

公式 Docs にもこう書かれています。

While the ExpressRoute circuit is preferred over Site-to-Site VPN when both routes are the same, Azure will use the longest prefix match to choose the route towards the packet's destination.

今回のシナリオで問題になるのは、主に オンプレ側ルータの受信ルート選択 です。ER と VPN の両方からルートを受けたオンプレ側 CE ルータが、より具体的な prefix を持つ VPN 側のルートを LPM で優先してしまいます。

例えば次のケースです。

Gateway	広告される prefix	オンプレ側での扱い
ER GW（要約済み）	10.252.0.0/16	LPM で負ける
VPN GW（個別のまま）	10.252.1.0/24	LPM で勝つ → こっちが使われる

バックアップのはずの VPN がアクティブパスになってしまう可能性があります。

対策

対策	効果
VPN 側にも同じ要約を入れる	両者が同じ prefix 長になり、既定の ER 優先が効く
VPN 側の広告に AS Path prepending を入れる	同じ prefix 長でも AS Path で ER が勝つように寄せる
Azure Route Server で Routing preference を明示的に設定する	同一 prefix 長での優先順を制御する

ER と VPN を共存させている環境では、片方だけ要約するのではなく、両方揃えて設定するのが安全です。

ER 拠点と VPN 拠点の間のトランジットについて

なお、ER 接続拠点と VPN 接続拠点の間でトランジット（相互通信）を行いたい場合は、Azure Route Server の Branch-to-branch（ルート交換）を有効にする必要があります。Route Server なしでは ER 接続拠点と VPN 接続拠点の間のトラフィックは通りません。

• Azure Route Server support for ExpressRoute and Azure VPN - Microsoft Learn

• Routing preference with Azure Route Server - Microsoft Learn

まとめ

今回の Summarized Gateway Prefixes は、Azure からオンプレミスへ広告する route 数を抑えたいときに、既存構成を大きく崩さず試しやすい機能です。

特に次のような環境で候補に入ります。

• Hub-and-Spoke が大きくなってきた
• Spoke 数が増えてオンプレミス側の受信経路数がつらい
• でも VNet を細かく割り直したり、構成を大きく変えるのは避けたい

ただし、Preview です。
私なら、詰まっているのが Azure 側の広告本数上限なのか、対向装置側の受信上限なのかを先に切り分ける -> 受信経路数がどれだけ減るかを試す -> 切替時の見え方を見る の順で進めます。

参考

• Public Preview: Summarized advertised gateway prefixes for route advertisement

• Advertised gateway prefixes in Azure virtual networks - Microsoft Learn

• FAQ - Azure ExpressRoute - Microsoft Learn

• About ExpressRoute virtual network gateways - Microsoft Learn

• Azure virtual network peering - Microsoft Learn

• Azure virtual network traffic routing - Microsoft Learn

• Monitor Azure VPN Gateway - Microsoft Learn

• Azure VPN Gateway monitoring data reference - Microsoft Learn

• Troubleshoot BGP issues for Azure VPN Gateway - Microsoft Learn

• Summarized Gateway Prefixes for Route Advertisement in Azure Virtual Networks - Microsoft Tech Community