こんにちは、アーキテクトのやまぱんです。
補足コメントや質問、いいね、拡散、是非お願いします🥺！
間違ってたら優しく教えてください！

モチベーション

Azure Virtual Network Manager (以下、AVNM) のルーティング規則って
『有事の際 (具体的には オンプレ - Azure 間 でExpressRoute と VPN なり複数のプライべート接続が構成されている場合にいずれかの経路が不通となった際) にバックアップ回線として生きている経路に通信を寄せるようなことできるのかな？？？(-ω-;)』
という疑問がわいたので検証してみます。

ちなみに AVNM のアイコンはこちら↑

そもそも Azure Virtual Network Manager とは

本題にはいる前に、Azure Virtual Network Manager について簡単にご紹介します。
Azure Virtual Network Manager（AVNM）は、Azure内の仮想ネットワーク（VNet）を一元的に管理し、複数のサブスクリプションやリージョンにまたがるネットワークのグループ化、構成、デプロイ、および管理を可能にするサービスです。

Azure Portal はこんな感じの画面↑

VNet をグループ化して、そのネットワークのグループにそれぞれの構成をデプロイするイメージになります。
具体的には以下のような機能があります。
まず以下の 3 つは、AVNM → [構成] から作成することができます。

接続構成(Connectivity configuration) : 仮想ネットワーク間の接続方法を定義し、ハブ＆スポーク型やメッシュ型のトポロジを自動的に適用する機能。複数の VNet 間で接続を管理する際に便利。
セキュリティ管理構成 (Security admin):
各ネットワークに共通で適用するセキュリティポリシーを定義し、ネットワークセキュリティグループ（NSG）やファイアウォールの設定を一元管理する機能。セキュリティポリシーの徹底と標準化に役立ちます。
ルーティング構成 (user-defined routes management):
特定のトラフィックが通る経路を制御するためのルーティングポリシーを設定する機能。強制トンネリングやインターネット接続の制御などに利用される。

また以下は執筆時 (2025/02/03) 現在ではプレビュー表記として存在しています。

IP アドレス管理 (IPAM):
Azure内でIPアドレス空間をポリシーとして一元管理し、アドレスの重複や競合を防止する機能。
仮想ネットワーク検証ツール (Virtual Network Verifier):
VM間の接続性をネットワークポリシーに基づいて検証し、到達可能性を分析するツール。

とりあえずルーティング構成を試す

本題に入ります。

AVNM のルーティング構成を作成する。
こんなかんじです。対象とするネットワークグループを指定し、通常の UDR のように記載することができます。

デプロイする

デプロイする
以下のように先ほど作ったルーティング構成を選択し、リージョンも選択します。

では、AVNM をデプロイした後のルートテーブルを確認してみましょう。

以下はデプロイした後の画面ショットです。

既存の UDR が紐づいていない場合

ルートテーブル：AVNM_Managed_BD0FAE688A294FE49084630103413536 が関連付けられ、有効なルートには先ほど設定した、ルーティング規則の接頭辞として AVNM_Managed_ がついたルートが追加されていることがわかります。

ちなみにこの ルートテーブル：AVNM_Managed_BD0FAE688A294FE49084630103413536 は AVNM 専用のマネージドなリソースグループ (AVNM_Managed_ResourceGroup_"SubscriptionID")に存在します。マネージドな通常のルートテーブルリソースが存在しています。

既存の UDR が紐づいている場合

結果としては以下のようになりました。
黄色のハイライト部分が Azure Virtual Network Manager によるルートで、青色ハイライト部分が既存の UDR で設定していたルートになります。
ただし、見ての通り、既存の UDR の関連付けは切れた状態になっています。

残ってるのはロンゲストマッチ的に強いルートだけが残っていて、AVNMがロンゲストマッチでかってるやつはAVNMになってる（なお、同じプレフィックス長だと既存のUDRが勝ってる）

でもそもそもルートテーブル 2 つ紐づいてないのになんで残ってんだ!!😅って思いました。
でもこれは以下のドキュメントに書かれています。
既存のUDRが関連付けられてる場合はそれとマージしてよしなに新しいルートテーブルを AVNM はつくるようです。

既存の UDR を含むルートテーブルが存在する場合、デプロイされたルーティング構成に基づいて、既存のルートと新しいルートの両方を含む新しいマネージドルートテーブルが Azure Virtual Network Manager によって作成されます。

ルートとルートテーブルへの UDR 管理の影響 - MS Learn
https://learn.microsoft.com/ja-jp/azure/virtual-network-manager/concept-user-defined-route#impact-of-udr-management-on-routes-and-route-tables

アンデプロイする

以下からアンデプロイ(デプロイの削除)が可能です。

見てわかる通り、アンデプロイもデプロイの画面と同じで既存のルーティング構成を削除しますを選択することでアンデプロイになります。

既存の UDR が紐づいていない場合

既存の UDR が紐づいていない場合は以下のようにデフォルトのルート構成になりました。
*下部省略

既存の UDR が紐づいている場合

以下のように AVNM のルートが消えた新しいルートテーブル AVNM_Managed_D72F1C994D1F48BE80F794E8C40FAB15 が AVNM によってつくられ、それが関連付けられています。

青色ハイライト部分は AVNM をデプロイする前に既存の UDR で設定していた内容の一部になります。
AVNMをデプロイした際に優先度が AVNM より高かった既存の UDR のルートのみが残っている。AVNM より優先度が低かったルートは AVNM デプロイ時に消えてしまうので、アンデプロイをしても元に戻るわけではない。

もとに戻すためには手動で AVNM によってつくられたルートテーブルをの関連付けを解除することも可能

そうすることで元々の UDR のルートテーブルを関連付けることが可能。

ただし、AVNM の管理下にあるので、できれば AVNM の管理下 (NWグループ) から外して、既存の UDR を再度関連付けた方が気持ちいい。
せっかくAVNMによってルートテーブルを自動構成して一元管理しているのに一部のサブネットだけ手動でルートテーブルを管理する(UDR)って運用上よくないきがします。自動化できるものは自動化しましょう！

まとめ

今回の検証で、Azure Virtual Network Manager（AVNM）のルーティング規則が便利か感じられました！
また具体的な適応の参考になる部分もあったかなーと思います。
ロンゲストマッチによる制御がしっかり効いているところも知見でしたね 👀✨

現状だと、既存の UDR とAVNMによるルートがあった際に、同じプレフィックス長だと既存の UDR が優先されるので、個人的には同じプレフィックス長だった際に AVNM のルールを優先するようなオプションがあるといいなと思いました。

これをうまく使いこなせば、VNet がたくさんある環境でも設定ミスによるトラブルも減りそうです！
何より、ルートテーブルがAzure Virtual Network Manager によりマネージドリソースとして管理されているおかげで、いちいち手動で修正しなくてもいいのが楽ちんですね 🎉

これからも AVNMを使いこなして、もっと快適で安心なネットワーク構成を作れるように、どんどん検証を進めていきますよ～！💪🚀