Route ServerのルートマップがGA：初回作成後のCLI失敗と経路伝播を検証する

結論：初回作成を経路と管理手順の両方に影響する変更として扱う

【確認済み事実】Azure Route ServerのルートマップはAzureパブリッククラウドで一般提供されています。NVAとのBGPピアリング、同一仮想ネットワーク内のExpressRoute・VPNゲートウェイ等との経路交換を制御できます。根拠は公式資料1・2です。

【編集上の判断】導入の採否は、広告する経路を変えられることだけでなく、既存の管理・増設・復旧手順が継続して使えるかで決めます。ルートマップの削除を管理ツールの非互換まで解消する切戻しとみなさず、検証環境で導入後の管理操作を先に確認する方針を提案します。

背景と技術的要因：ルート制御とデータ通信、リソース型を分ける

【確認済み事実】公式資料1は、経路の要約・フィルタリング、AS-PATHの変更、BGP Communityによるタグ付けを一般提供機能として案内しています。公式資料4は、ルートマップがコントロールプレーンのルーティング情報を処理し、パケットを直接フィルタリングするACLではないと説明しています。

【確認済み事実】Route ServerはARM上ではRoute Server SKUのMicrosoft.Network/virtualHubsリソースですが、Azure Virtual WANの仮想ハブとは異なります。根拠は公式資料4です。

【編集上の設計案】IaCのリソース型が似ていることを理由に、Virtual WANの接続や操作例をそのまま流用しないようにします。接続点、処理方向、期待する経路広告を設計書へ記録し、通信の許可・拒否はNSGやファイアウォール等の制御と別に照合します。

公表・更新・適用日、数値と対象コマンド・API

【日付の区別】公式資料1のロードマップ登録日は2026-11-04、適用欄は2026年11月です。厳密なGA適用日、同告知の更新日、強制移行期限、非推奨化期日は確認できずnullです。公式資料2の表示更新日は2026-11-05、資料3・4は2026-11-04です。Learn資料の初回公表日は確認できずnullとします。公開日・確認日は2026-11-11です。sourceDateは資料1で登録日、資料2〜4で表示更新日を保持しています。

【確認済み事実】初回のルートマップ作成では、Route Serverのアップグレードに最大約30分かかる場合があります。公式資料3はAz.Network 8.2.0以降を前提とし、BGPピアリングへの適用にUpdate-AzRouteServerPeerの-RoutingConfigurationを使用する手順を示しています。

【確認済み事実】公式資料3では、ルートマップ作成後のaz network routeserver peering createがApiVersionDoesNotSupportConnectionsForRouteServerで失敗する場合、ポータルまたはAdd-AzRouteServerPeerを案内しています。az network routeserver deleteとRemove-AzRouteServerの削除エラーには、Microsoft.Network/virtualHubsへのREST DELETEとapi-version=2026-05-01を示しています。これは当該回避手順のAPI版であり、全操作の最小対応版を意味しません。

【編集上の確認事項】最大約30分を無停止や完了時刻の保証と解釈せず、変更枠と監視を用意します。破壊的な削除の検証は破棄可能な環境に限定し、実運用の対象ID、影響範囲、承認条件を別途確認します。

設計・実装上の確認事項：関連付けとRoutingConfigurationの置換を審査する

【確認済み事実】公式資料3は、初回作成後はルートマップを削除しても一部コマンドの失敗が残ると説明しています。またUpdate-AzRouteServerPeerはピアリングのルーティング構成全体を置き換え、-RoutingConfigurationを省略するとルートマップがピアリングから除去されると注意しています。

【編集上のIaC設計案】Terraform・Bicep・PowerShell・CLIの利用箇所と版を採取し、作成、ピア追加、設定更新、削除・再構築を個別に試験します。既存ピアの現在値を読み出し、InboundRouteMapとOutboundRouteMapの両方を保全してから片方向を変更します。更新後の読み戻しで、意図しない関連付け解除がないことを確認します。

【確認済み事実】公式資料2は接続の方向ごとに1つのルートマップを適用できること、未一致の経路は既定で許可されることを説明しています。送信側マップの処理はRoute Serverの最適経路選択後であり、その内部の最適経路選択は変更しません。

【編集上の設計案】ルールの順序、Equals／Contains、Continue／Terminate、条件なしの扱いをレビュー項目にします。許可リスト方式を期待する場合は未一致時の結果も明示し、通常経路、代替経路、管理経路で必要な広告が残るか試験します。

【編集上の設計案】ゲートウェイ・スポークへの適用では、公式資料3が案内するポータル操作とIaCの管理範囲を記録します。手作業がある場合は差分・担当・設定結果を残し、次回の再適用で設定が消えないことを受け入れます。要約前後のBGP属性や既存の要約設定との関係も確認します。

運用・監視・フェイルオーバーと責任分界：広告と実通信を別々に試す

【確認済み事実】公式資料3はConnections Dashboard、Effective Routes、受信側BGPピアの経路を照合するよう案内しています。スポークのプレフィックスがEffective RoutesにOn-linkとして残っていることだけでは、相手へ伝播したかは判断できません。リソースの関連付け成功だけでもポリシー効果は確認できません。

【編集上の監視案】構成の保存結果、接続への関連付け、処理後のプレフィックス数・属性、相手側受信経路、実通信を時刻付きで採取します。意図したDrop対象と、影響させない対照プレフィックスを比較し、データベースや管理端末等からの往復通信も確認します。

【編集上のDR設計案】NVA停止、ExpressRouteからVPNへの切替、通常系への復帰を検証し、経路の撤回・再広告とアプリ再接続を測定します。AS-PATH変更の前後で実際の送受信経路を確認し、非対称経路が状態保持型ファイアウォールやNATへ与える影響も試験します。

【編集上の責任分界案】基盤担当はRoute Serverと関連付け、NVA・回線担当はBGP広告と相手側経路、IaC担当は版・構成保全・再適用、アプリ担当は疎通と復旧判定を担う案を定めます。切戻しが関連付け解除なのか設定復元なのかを明示し、管理コマンドの非互換が残る場合の手順も保守範囲へ含めます。

【適用上の前提】本稿は個別環境の設計保証や法的助言を行いません。実装適用にあたっては検証環境での事前テストおよび業務範囲の確認が必要です。以下のチェックリストは編集上の提案であり、環境ごとの受入条件を具体化してください。