Azure Networkingの「Azure Virtual Network Manager integration with Virtual WAN」は、Azure Virtual Network Managerのハブアンドスポーク接続構成で、Azure Virtual WANハブを“ハブ”として選べるようにするPublic Previewです。結論から言うと、Virtual WANをすでに中核ネットワークとして使っている環境では、スポークVNetの接続・ルーティング設定をネットワークグループ単位でまとめて管理しやすくなります。
一方で、これは2026年5月27日に公開・更新されたプレビュー機能であり、本番環境へすぐ全面適用するものではありません。特に、接続ポリシー、既存のVirtual WAN接続、Direct connectivity、対応リージョン、Private Endpointの規模、クロステナント構成は事前確認が必要です。(Microsoft Azure)
Azure Virtual Network Manager integration with Virtual WANとは
Azure Virtual Network Manager integration with Virtual WANは、Azure Virtual Network Manager、以下AVNM、のハブアンドスポーク接続構成で、従来のハブ仮想ネットワークだけでなく、Azure Virtual WANハブを接続先のハブとして利用できる機能です。
Azure Virtual WANは、VPN、SD-WAN、ユーザーVPN、ExpressRoute、仮想ネットワークなどをハブアンドスポーク型で接続するためのサービスです。Virtual WANハブは、複数の拠点やVNet間の中継点として使われます。(Microsoft Learn)
今回の統合により、AVNM側でネットワークグループを作成し、そのグループに含まれるVNetをVirtual WANハブへまとめて接続できます。さらに、Virtual WANのconnection policyを使って、複数のVNet接続に共通のルーティング構成を適用できます。(Microsoft Learn)
つまり、この機能の本質は「Virtual WANハブへのスポーク接続を、個別作業ではなくグループ単位で管理できるようにすること」です。
何が変わるのか
従来のAVNMによるハブアンドスポーク構成では、ハブ仮想ネットワークを選ぶと、AVNMがハブとスポークVNet間のVNetピアリングを作成します。今回のプレビューでは、ハブとしてVirtual WANハブを選んだ場合、AVNMがVirtual WANの仮想ネットワーク接続を作成または更新します。(Microsoft Learn)
| 観点 | 従来の主な構成 | 今回のPublic Previewで可能になること |
|---|---|---|
| ハブの種類 | ハブ仮想ネットワークを中心に構成 | Virtual WANハブをAVNMのハブアンドスポーク構成のハブとして利用 |
| 接続方式 | ハブVNetとスポークVNetのVNetピアリング | Virtual WANハブとスポークVNetのVirtual WAN VNet接続 |
| 管理単位 | VNetごとの接続設定やIaCでの一括管理 | AVNMのネットワークグループ単位で接続を展開 |
| ルーティング設定 | 個別接続やVirtual WAN側の設定に依存 | connection policyで共通設定を適用 |
| 展開方法 | 手動、スクリプト、IaC中心 | AVNMの接続構成を対象リージョンへデプロイ |
| 向いている環境 | 小〜中規模のハブスポーク構成 | Virtual WANを中核にした大規模・複数サブスクリプション環境 |
特に効果が大きいのは、Azure Landing Zoneのように、ワークロード用VNetが複数サブスクリプションに増えていく環境です。新しいVNetをどのハブへ接続し、どのルートテーブルやポリシーを適用するかを、ネットワークグループのルールに寄せて管理できます。
対象者は誰か
この更新の主な対象者は、Azure Networkingを組織横断で管理しているチームです。
| 対象者 | 確認すべき理由 |
|---|---|
| ネットワーク管理者 | Virtual WANハブへの接続方式、ルーティング、既存接続への影響を判断する必要がある |
| クラウド基盤・Platform Engineeringチーム | 新規VNetのオンボーディングをネットワークグループで標準化できる可能性がある |
| セキュリティ管理者 | Direct connectivityを有効化すると、VNet間通信がVirtual WANハブ上のFirewall/NVAを経由しない場合がある |
| アプリ開発・インフラ担当者 | VNet作成時のタグ、CIDR、Private Endpoint数、通信経路の確認が必要になる |
| IaC運用担当者 | 既存のTerraform、Bicep、ARMテンプレート、Azure CLI運用との役割分担を見直す必要がある |
反対に、Virtual WANを使っていない小規模環境や、単一VNetに近い構成では、急いで導入する必要性は高くありません。まずは「Virtual WANハブを中心に、増え続けるVNet接続を標準化したいか」で判断するとよいでしょう。
管理者が最初に確認すべき影響範囲
対応リージョンは限定される
この機能はPublic Previewであり、SLAなしで提供され、本番ワークロードには推奨されていません。また、利用できるAzureリージョンも限定されています。(Microsoft Learn)
日本の利用者にとって特に重要なのは、公式ドキュメント上の対応リージョンに「Japan East」は含まれている一方で、「Japan West」は掲載されていない点です。DRやマルチリージョン構成で西日本リージョンを前提にしている場合は、展開前に最新の公式リージョン一覧を確認してください。
対応リージョンとして示されているものは、West Central US、Australia Central、Australia Southeast、Brazil South、Canada Central、North Europe、France South、Germany Northeast、Germany West Central、Central India、West India、Japan East、Korea Central、Malaysia South、Malaysia West、Mexico Central、Norway West、Qatar Central、South Africa North、Sweden Central、Switzerland West、Taiwan North、UAE Central、East US、West US、West US 2です。(Microsoft Learn)
既存のVirtual WAN接続は削除されない場合がある
既存の手動作成済みVirtual WAN VNet接続があるVNetを、AVNMで管理するネットワークグループに追加した場合、AVNMはそのユーザー作成済み接続を保持します。ネットワークグループからVNetを削除しても、もともとのユーザー作成済み接続は削除されません。不要になった場合は手動で削除する必要があります。(Microsoft Learn)
ここは移行時の落とし穴です。
「ネットワークグループから外したからVirtual WANハブとの接続も消えたはず」と思い込むと、意図しない経路が残る可能性があります。
移行前には、少なくとも次の棚卸しを行ってください。
| 確認項目 | 確認内容 |
|---|---|
| 既存のVNet接続 | どのVNetがどのVirtual WANハブに接続済みか |
| 作成方法 | 手動作成、IaC作成、AVNM作成のどれか |
| ルートテーブル | Associated route tableとPropagated route tableの設定 |
| セキュリティ経路 | Azure Firewall、NVA、Routing Intentを経由する設計か |
| 削除方針 | AVNM管理へ移す接続と、手動で残す接続を分ける |
ネットワークグループの削除や変更が接続断につながる
AVNMでVirtual WANハブに接続されたネットワークグループからVNetを削除すると、そのVNetはVirtual WANハブから切断されます。変更前には、そのVNetが本当にハブ接続を失ってよいか確認する必要があります。(Microsoft Learn)
特に、動的メンバーシップをAzure Policyやタグ条件で管理する場合は注意が必要です。タグ変更やリソースグループ移動によって、VNetが意図せずネットワークグループから外れる可能性があります。
本番に近い環境では、いきなり動的メンバーシップに頼るのではなく、最初は静的メンバーシップで挙動を確認し、その後にタグベースの自動参加へ移行する進め方が安全です。
connection policyで確認すべき設定
今回の統合では、Virtual WAN hubのconnection policyが重要になります。connection policyは、複数のVirtual WAN VNet接続に共通設定を適用するための仕組みです。(Microsoft Learn)
主に管理できる項目は次のとおりです。
| 設定 | 何に影響するか | 確認ポイント |
|---|---|---|
| Enable internet security | 0.0.0.0/0の既定ルートをスポークVNetへ広告するか | インターネット向け通信をFirewall/NVA経由にする設計か |
| Associated route table | VNet接続がどのVirtual WANルートテーブルを参照するか | 本番、検証、共通サービスで混在していないか |
| Propagated route table / labels | VNet側のルートをどこへ伝播するか | オンプレミスや他リージョンへ不要な経路を広げていないか |
| Route maps | 受信・送信ルートにどのRoute mapを適用するか | 経路の変更やフィルタが想定通りか |
connection policyの設定は、競合する個別接続設定より優先されます。ただし、Routing Intentで管理される設定がある場合は、Routing Intent、connection policy、connection-level settingsの順で優先されます。(Microsoft Learn)
つまり、connection policyを変更すると、同じポリシーに属する複数のVNet接続へ一括で影響します。便利な反面、誤設定時の影響範囲も広くなります。環境別、リージョン別、重要度別にconnection policyを分け、段階的に変更できる設計にしておくべきです。
Direct connectivityは便利だが、セキュリティ経路を変える
AVNMでは、Virtual WANハブに接続されたネットワークグループ内のVNet同士にDirect connectivityを有効化できます。有効にすると、VNet間通信はVirtual WANハブを経由せず、ネットワークグループ内で直接通信する形になります。(Microsoft Learn)
これは、夜間バッチ、データ同期、大量転送、低遅延が必要なアプリケーションでは有効です。Virtual WANハブ上のFirewallやNVAを経由しないため、遅延やスループット面で有利になる場合があります。
ただし、セキュリティ設計上は慎重に扱う必要があります。公式ドキュメントでも、Connected groupやmesh構成は、VNet間通信をVirtual WANハブ上のセキュリティソリューションへ送るRouting Intentやルーティング構成より優先されると説明されています。(Microsoft Learn)
次のように判断すると実務で迷いにくくなります。
| 通信要件 | 推奨判断 |
|---|---|
| すべてのVNet間通信をFirewall/NVAで検査したい | Direct connectivityは原則オフ |
| 同一アプリ群や同一環境内で低遅延通信が必要 | 対象ネットワークグループを限定してDirect connectivityを検討 |
| 本番と検証環境を厳密に分離したい | Production用、Test用でネットワークグループを分ける |
| 一部通信だけ検査をバイパスしたい | 例外用ネットワークグループを作り、範囲を明確化する |
「速くなるかもしれないからオン」ではなく、「どの通信を検査対象から外してよいか」を先に決めることが重要です。
展開前に確認すべき前提条件
Microsoft Learnの構成手順では、開始前の前提として、既存のAzure Virtual Network Managerインスタンス、既存のAzure Virtual WANとVirtual WANハブ、スポークとして追加する1つ以上のVNetが必要とされています。(Microsoft Learn)
実務では、前提リソースの有無だけでなく、次の確認も行ってください。
| 確認項目 | 理由 |
|---|---|
| AVNMのスコープ | 管理グループ、サブスクリプション、リソースグループのどこまで管理対象にするかを決める |
| VNetのIPアドレス範囲 | 重複CIDRがあると接続後の通信設計が破綻しやすい |
| VNetのタグ設計 | 動的ネットワークグループで誤参加・誤除外を防ぐ |
| Virtual WANハブのルートテーブル | connection policyでどのルートを学習・伝播するかに直結する |
| Firewall/NVAの配置 | Direct connectivityやルーティング変更で検査経路が変わる |
| 既存のIaC | Terraform、Bicep、ARMテンプレート、Azure CLIとの二重管理を避ける |
| 運用監視 | Azure Monitor、Network Watcher、Activity Logで変更と通信を追跡できるようにする |
AVNMは構成を作成しただけでは対象VNetへ反映されません。構成は、対象リージョンへデプロイして初めて有効になります。問題が起きた場合は、デプロイモデルを通じて対象リージョンの構成を削除または変更することでロールバックします。(Microsoft Learn)
推奨する展開手順
プレビュー段階では、いきなり全サブスクリプション・全リージョンへ適用するのではなく、小さく検証してから広げるのが現実的です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 事前棚卸し | 既存VNet、Virtual WANハブ、VNet接続、ルートテーブル、Firewall経路を一覧化 | どのVNetをAVNM管理へ移すか決まっている |
| 検証用ネットワークグループ作成 | 最初は静的メンバーシップで少数のVNetを追加 | 意図しないVNetが含まれていない |
| connection policy作成 | 検証用のルートテーブル、伝播、Internet security設定を定義 | 既存本番ポリシーと分離されている |
| 接続構成作成 | Hub typeでVirtual WAN Hubを選び、対象ハブとconnection policyを指定 | Direct connectivityのオン・オフ方針が明確 |
| 対象リージョンへデプロイ | まずは検証リージョンまたは少数リージョンに展開 | Virtual WAN側でVNet接続を確認できる |
| 通信確認 | VNet間、オンプレミス、インターネット向け、Private Endpoint宛を確認 | 想定経路とログが一致している |
| 段階展開 | 環境別・リージョン別に対象を拡大 | 障害時の切り戻し手順が文書化されている |
Azureポータルでの構成手順としては、ネットワークグループを作成し、接続構成で「Connect network group to a hub」を選択し、hub typeに「Virtual WAN Hub」を指定します。その後、Virtual WANハブとconnection policyを選び、対象リージョンへ構成をデプロイします。(Microsoft Learn)
移行時に失敗しやすいポイント
既存接続の“残り方”を誤解する
既存のユーザー作成済みVirtual WAN接続は、AVNM管理に追加しても保持される場合があります。また、既存接続があるVNetを別のVirtual WANハブへ移したい場合、AVNMが既存接続を優先して保持する既知の制約があります。必要に応じて手動で移動する必要があります。(Microsoft Learn)
移行設計では、「接続を作る」だけでなく「どの接続を消すか」まで決めてください。
connection policyを大きく作りすぎる
1つのconnection policyに多数の本番VNetをまとめると、ルーティング変更の影響範囲が大きくなります。公式ドキュメントでも、変更影響を抑えるために、Virtual WAN内でupdate domainを慎重に定義し、複数のconnection policyに分けて段階的に変更することがベストプラクティスとして示されています。(Microsoft Learn)
実務では、少なくとも次の単位で分けることを検討してください。
- production、staging、development
- east、westなどのリージョン
- インターネット出口を持つVNetと持たないVNet
- Firewall検査必須のVNetとDirect connectivity許可のVNet
Direct connectivityでFirewall検査を迂回してしまう
Direct connectivityを有効にすると、VNet間通信がVirtual WANハブを通過しない場合があります。FirewallやNVAで全通信を検査する前提の環境では、意図せず監査・検査の対象外になる可能性があります。(Microsoft Learn)
オンにする場合は、事前に「どの通信をバイパスしてよいか」「ログ取得はどこで行うか」「セキュリティ管理者ルールやNSGで補完するか」を決めてください。
Private Endpointの規模を見落とす
構成手順では、Virtual WANハブは現時点でAVNM connected groupのhigh-scale private endpointsをサポートしないと説明されています。また、単一Virtual WANハブへ接続されたVNet群に4,000を超えるPrivate Endpointがある場合、ハブを経由するPrivate Link接続に影響する可能性がある既知の問題も示されています。(Microsoft Learn)
Private Endpointを多用する環境では、接続対象VNetの数だけでなく、Private Endpointの総数も棚卸ししてください。特に、PaaS利用が多い大規模環境では見落としやすいポイントです。
クロステナント構成を通常通り扱えると思い込む
既知の問題として、Virtual WANハブと異なるテナントにあるVNetに対して、AVNMの接続構成が正しく適用されないケースが示されています。この場合は、Terraform、Azure CLI、Azure PowerShellなどで手動管理する回避策が案内されています。(Microsoft Learn)
M&A後の環境、グループ会社別テナント、外部委託先のサブスクリプションを含む構成では、検証なしに自動展開へ進めないでください。
開発者・アプリ担当者が確認すべきこと
この更新はネットワーク管理者向けに見えますが、アプリ開発者やインフラ担当者にも影響します。特に、新しいVNetを作るたびにネットワークチームへ依頼していた環境では、タグやサブスクリプション条件によって自動的にVirtual WANハブへ接続される運用に変わる可能性があります。
開発者側では、次の点を確認しておくとトラブルを減らせます。
| 確認項目 | 具体例 |
|---|---|
| VNetのタグ | env=dev、network-zone=sharedなど、ネットワークグループ条件に使われるタグを誤設定しない |
| CIDR設計 | 他VNetやオンプレミスと重複するアドレス範囲を使わない |
| 通信先 | DB、API、Private Endpoint、オンプレミス向け通信がどの経路を通るか確認する |
| 例外通信 | Firewall/NVAを通す必要がある通信と、Direct connectivityを許可できる通信を分ける |
| 障害時の確認先 | アプリログだけでなく、Network Watcher、フローログ、Virtual WAN接続状態も確認対象にする |
「VNetを作れば自動でつながる」状態は便利ですが、誤ったタグで本来接続すべきでないネットワークへ参加するリスクもあります。開発チームには、VNet作成時の命名規則、タグ、IPレンジのルールを明文化して共有しておくべきです。
既存のハブアンドスポーク構成はどう扱うべきか
すでにハブVNetを使ったハブアンドスポーク構成がある場合、今回のプレビューだけを理由に急いでVirtual WAN中心へ移行する必要はありません。
判断基準は次のとおりです。
| 現在の構成 | 判断 |
|---|---|
| ハブVNet中心で安定しており、VNet数も少ない | 既存構成を維持し、AVNMの通常ハブスポーク管理を検討 |
| Virtual WANをすでに拠点接続や複数リージョン接続の中心にしている | 今回の統合を検証する価値が高い |
| 新規VNetが頻繁に増える | ネットワークグループとconnection policyによる標準化を検討 |
| すべての通信をFirewall経由で検査する必要がある | Direct connectivityを慎重に扱う |
| クロステナントや複雑な既存接続が多い | 手動接続・IaCとの併用を前提に段階移行 |
Azureのハブスポーク構成では、ハブは共有サービスやオンプレミス接続の中心になり、スポークはワークロードごとに分離されます。Azure Landing Zoneでも、接続性サブスクリプションにハブを置き、アプリケーション用サブスクリプションにスポークVNetを配置する考え方が一般的です。(Microsoft Learn)
Virtual WANを採用している組織では、このハブの役割をVirtual WANハブへ寄せ、AVNMでスポーク接続を管理する構成が選択肢になります。
よくある疑問
Public Previewでも本番環境で使えるのか
公式ドキュメントでは、このプレビューはSLAなしで提供され、本番ワークロードには推奨されないと説明されています。検証環境、開発環境、限定的なPoCで使い、GA前提の本番標準として固定しないほうが安全です。(Microsoft Learn)
AVNMはAzure Firewall経由のルーティングを自動で設定するのか
自動では設定しません。公式FAQでは、ハブにFirewallがあるだけでスポークトラフィックがAzure Firewall経由になるわけではなく、目的のプレフィックスがFirewallを次ホップに使うようルーティングを構成する必要があると説明されています。(Microsoft Learn)
複数のVirtual WANハブを1つのネットワークグループで管理できるのか
1つのAVNMネットワークグループとconnection policyは、単一のVirtual WANハブにのみ適用できます。複数のVirtual WANハブを管理する場合は、ハブごとにネットワークグループとconnection policyを分ける必要があります。(Microsoft Learn)
ハブを別のVirtual WANハブに変更するとどうなるのか
ネットワークグループを別のVirtual WANハブへ移す操作は破壊的な操作です。対象VNetは古いVirtual WANハブから切断され、新しいVirtual WANハブへ再接続されます。メンテナンスウィンドウを確保して計画する必要があります。(Microsoft Learn)
TerraformやBicepと併用できるのか
Azure Virtual Network Managerは、AzureRM Terraformプロバイダー、ARMテンプレート、Bicepで管理できると公式FAQに記載されています。ただし、今回のVirtual WAN統合はPublic Previewであり、利用する機能やプロバイダー側の対応状況は展開時点で確認してください。(Microsoft Learn)
まず取るべき次の行動
Azure Virtual Network Manager integration with Virtual WANは、Virtual WANを中心にしたAzure Networking運用を標準化するうえで有力な機能です。特に、ネットワークグループとconnection policyを組み合わせることで、VNet追加時の接続作業やルーティング設定を一貫させやすくなります。
ただし、Public Previewである以上、最初にやるべきことは導入ではなく棚卸しです。既存のVirtual WAN接続、ルートテーブル、Firewall/NVA経路、Private Endpoint数、対応リージョン、クロステナント構成を確認してください。
そのうえで、検証用のネットワークグループを作り、少数のVNetをVirtual WANハブへ接続し、connection policyの変更がどの範囲へ影響するかを確認します。問題がなければ、環境別・リージョン別に展開範囲を広げるのが現実的です。
本番導入を急ぐよりも、まずは「どのVNetをどのVirtual WANハブへ、どのポリシーで接続するか」を設計図として整理することが、今回の更新を安全に活用する第一歩です。
コメント