Azure Virtual Network Peeringは、Azure上の複数の仮想ネットワークをプライベートに接続するための基本機能です。2026年5月20日に更新された公式ドキュメントでは、従来のVNet全体を接続するピアリングに加え、サブネット単位の接続、ピアリング済みVNetのアドレス空間変更、ゲートウェイ経由の経路集約、課金上の注意点が実務上の確認ポイントとして重要になっています。既存環境で今すぐ確認すべき結論は、「接続範囲」「アドレス空間」「ゲートウェイ転送」「NSG・UDR・DNS」「料金」をセットで棚卸しすることです。公式ページ自体は2026年5月20日に更新されています。(Microsoft Learn)
Azure Virtual Network Peeringでまず押さえるべき基本
Azure Virtual Network Peeringは、2つ以上のAzure Virtual Networkを接続し、接続性の面では1つのネットワークのように扱えるようにする機能です。通信はパブリックインターネットではなくMicrosoftのバックボーンネットワーク上を通り、同一リージョン内のVNet Peeringと、異なるリージョン間を接続するGlobal Virtual Network Peeringの2種類があります。(Microsoft Learn)
同一リージョン内のピアリングでは、仮想マシン間の遅延は同一VNet内と同等と説明されており、スループットはピアリング自体ではなくVMサイズ側の帯域に依存します。つまり、ExpressRoute GatewayやVPN Gatewayを経由させずにVNet間通信を低遅延で実現したい場合に向いています。(Microsoft Learn)
一方で、Azure Virtual Network Peeringは「接続すれば終わり」の機能ではありません。NSG、UDR、DNS、ゲートウェイ転送、アドレス重複、Basic Load Balancer、料金まで影響するため、ネットワーク管理者だけでなく、アプリ開発者、IaC担当者、セキュリティ担当者も設定内容を理解しておく必要があります。(Microsoft Learn)
2026年5月20日更新で特に確認したい変更点
サブネット単位で接続できるSubnet Peeringが重要になった
従来のVirtual Network Peeringは、基本的にVNet全体のアドレス空間・サブネットを対象に接続します。公式ドキュメントでは、これに対して特定のサブネットだけをピアリング対象にできる「Subnet Peering」が追加の柔軟性として説明されています。(Microsoft Learn)
実務上のメリットは、VNet全体を公開せず、必要なサブネットだけを接続できることです。たとえば、開発VNetのうちアプリケーションサブネットだけを共有基盤VNetの監視サブネットと接続し、DBサブネットや管理用サブネットは接続対象から外す、といった設計がしやすくなります。
ただし、Subnet Peeringは通常のピアリングより注意点が多い機能です。公式の詳細ページでは、利用にはサブスクリプションの登録が必要で、構成方法はTerraform、PowerShell、API、CLI、ARMテンプレートに限られるとされています。また、既存のVNet PeeringをSubnet Peeringへ直接変更することはできず、リンク種別を変える場合は既存のピアリングを削除して作り直す必要があります。(Microsoft Learn)
| 確認項目 | 実務での意味 | 対応の目安 |
|---|---|---|
| 接続対象 | VNet全体ではなく、必要なサブネットだけを接続できる | 接続要件をサブネット単位で洗い出す |
| 利用条件 | サブスクリプション登録や利用できる構成手段に制約がある | 本番導入前にサブスクリプションとIaC方式を確認する |
| 既存ピアリングからの変更 | 通常のVNet PeeringからSubnet Peeringへ直接変更できない | 削除・再作成による通信断を前提に移行計画を立てる |
| 上限 | 1つのリンクで片側200サブネット、VNet全体では合計1,000サブネットまでの制限がある | 大規模環境ではネットワーク設計書にサブネット数を明記する |
| セキュリティ | 現行リリースでは非対象サブネットにも経路が見えるケースがあり、NSGで制御することが推奨されている | 参加サブネット側に許可元・許可先を絞ったNSGを設定する |
特に本番環境では、Subnet Peeringの詳細ページにあるVM SKUに関する制約も見落とせません。古い世代のSKUに起因する障害リスクを避けるため、該当するV5世代や指定されたSKU条件を確認するよう案内されています。既存VMを含む環境では、ネットワーク設定だけでなく、接続先ワークロードのSKU棚卸しも必要です。(Microsoft Learn)
ピアリング済みVNetのアドレス空間を停止なしで変更できる
公式ドキュメントでは、ピアリング済みのAzure Virtual Networkについて、既存のピアリング済みアドレス空間に対するダウンタイムなしでアドレス空間を変更できると説明されています。対応する変更は、既存アドレス範囲のプレフィックス変更、アドレス範囲の追加、アドレス範囲の削除です。IPv4とIPv6の両方に対応し、クロステナント環境でもサポートされます。(Microsoft Learn)
ただし、アドレス空間を変更した後は、ピアリング相手との同期が必要です。公式手順では、複数の変更をまとめて最後に同期するのではなく、アドレス空間を変更するたびに同期することが推奨されています。classic VNetとピアリングしているシナリオでは、この機能はサポートされない点にも注意が必要です。(Microsoft Learn)
実務では、次の順序で進めると失敗を減らせます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前確認 | 既存VNet、ピアリング相手、サブネット、UDR、NSGを棚卸しする | 追加・削除するCIDRが他VNetやオンプレミスと重複しないか |
| 変更 | Azure portal、PowerShell、CLI、IaCでアドレス空間を変更する | 削除するアドレス範囲にリソースが残っていないか |
| 同期 | PeeringのSyncを実行する | 変更ごとに同期する |
| 検証 | 有効ルートと疎通を確認する | Next hopがVirtual network peeringになっているか |
アドレス範囲を削除する場合は、その範囲内にリソースやサービスが残っていると削除できません。単にCIDRを消すのではなく、サブネット内のVM、NIC、Private Endpoint、PaaS連携などを先に確認する必要があります。(Microsoft Learn)
Gateway TransitとAdvertised Gateway Prefixesの確認が必要
ハブアンドスポーク構成では、ハブVNetにVPN GatewayやExpressRoute Gatewayを配置し、スポークVNetがそのゲートウェイを利用する構成がよく使われます。Virtual Network PeeringとGlobal Virtual Network PeeringはいずれもGateway Transitをサポートしますが、リモートゲートウェイを利用するVNetは、自身のゲートウェイを持てません。1つのVNetで使えるゲートウェイは、ローカルまたはリモートのどちらか一方です。(Microsoft Learn)
2026年5月20日更新の公式情報では、Advertised Gateway Prefixesも重要な確認項目です。ハブアンドスポークでGateway Transitを使う場合、既定ではハブとピアリングされたVNetのアドレス空間がオンプレミスへ広く広告されます。summarizedGatewayPrefixesを設定すると、個別のスポークCIDRではなく集約したCIDRを広告でき、オンプレミス側に広告される経路数を減らせます。(Microsoft Learn)
たとえば、スポークが増え続ける環境で /24 の経路を大量に広告している場合、オンプレミス側ルーターやExpressRouteの経路上限に近づく可能性があります。この場合、設計上許容できるなら /16 などの集約プレフィックスで広告し、経路数を抑える判断が有効です。ExpressRoute Gatewayでは、Azure側から広告されるIPv4仮想ネットワーク経路の上限が1,000、IPv6は100と示されているため、大規模なハブアンドスポーク構成では早めに確認すべきです。(Microsoft Learn)
課金は「両端の受信・送信」が基本になる
Virtual Network自体は無料で作成できますが、VNet Peeringではピアリングされたネットワーク間の受信・送信データ転送に対して両端で課金されます。Global VNET Peeringはゾーン構造に基づく料金になり、リージョンの組み合わせによって料金が変わります。(マイクロソフトAzure)
また、Gateway Transitを使う場合、ゲートウェイを持たないスポーク側、つまりリモートゲートウェイを利用する側にもVirtual Network Peeringの料金が発生する点が公式ドキュメントで明記されています。以前の記載から修正された注意点として示されているため、既存のコスト見積もりが古い前提になっていないか確認が必要です。(Microsoft Learn)
影響を受けやすい管理者・開発者
Azure Virtual Network Peeringの更新内容は、ネットワークチームだけの問題ではありません。特に、接続範囲の最小化、アドレス空間変更、ハイブリッド接続、IaC運用、課金管理を行っているチームに影響します。
| 対象者 | 確認すべきこと | 優先度 |
|---|---|---|
| ネットワーク管理者 | Peering状態、アドレス空間、ゲートウェイ転送、UDR、NSG | 高 |
| セキュリティ担当者 | VNet全体を接続してよいか、Subnet Peeringで範囲を絞れるか | 高 |
| Azure管理者 | Network Contributor権限、クロステナント・クロスサブスクリプションの権限 | 高 |
| IaC担当者 | 通常PeeringとSubnet Peeringの差分、既存リンクの削除・再作成要否 | 高 |
| アプリ開発者 | 名前解決、接続先IP、Basic Load Balancer、P2S VPN経路更新 | 中 |
| FinOps担当者 | 同一リージョン・グローバルPeering、Gateway Transit、AVNM経由通信の転送料 | 中 |
クロスサブスクリプションやクロステナントでピアリングする場合は、権限とリソースIDの扱いも重要です。公式手順では、Network Contributorロールまたは必要なカスタムロールが求められ、異なるMicrosoft Entraテナント間では相互にゲストユーザーを追加するケースが説明されています。(Microsoft Learn)
設計時に確認すべき設定ポイント
接続範囲は「VNet全体」か「サブネット単位」かを先に決める
新規構築では、最初に「VNet全体を接続する必要があるか」を判断します。共有基盤、監視、ログ収集、踏み台、特定アプリ間通信だけが目的なら、Subnet Peeringの検討余地があります。逆に、複数サブネット間で自由に通信する前提のワークロードでは、通常のVNet Peeringのほうが運用しやすい場合があります。
判断基準は次のとおりです。
| 選択肢 | 向いているケース | 避けたいケース |
|---|---|---|
| 通常のVNet Peering | ハブとスポーク、共有基盤、複数サブネット間で広く通信する環境 | 接続範囲を厳密に絞りたい環境 |
| Subnet Peering | 監視、管理、特定アプリ連携など、接続対象が限定される環境 | 頻繁に接続サブネットを変更する環境、既存Peeringを止めにくい環境 |
| Gateway Transit | スポークからオンプレミスへ集約接続したい環境 | 各VNetが個別にゲートウェイを持つ必要がある環境 |
| Service Chaining | Azure FirewallやNVAを経由させたい環境 | UDRやNVAの運用責任を持てない環境 |
| Azure Virtual Network Manager | 多数のVNetを一元管理したい環境 | 個別PeeringとSubnet Peeringが混在し、競合を整理できていない環境 |
Azure Virtual Network Managerを使う場合、接続構成によってハブアンドスポークやメッシュ接続を管理できます。ドキュメントでは、通常のピアリングより大規模な接続管理を実現できるConnected Groupの説明もありますが、Subnet Peeringとの競合シナリオでは注意が必要です。Subnet Peeringが存在する状態でAVNMがVNet Peeringを作成しようとした場合、既存のピアリングがあると判断して新しい要求を無視するケースが説明されています。(Microsoft Learn)
アドレス空間の重複は作成前に必ず確認する
Virtual Network Peeringでは、ピアリングするVNet同士のアドレス空間が重複してはいけません。既存環境に新しいスポークを追加する場合、Azure上のVNetだけでなく、オンプレミス、VPN接続先、将来追加予定のCIDRも含めて確認する必要があります。(Microsoft Learn)
よくある失敗は、開発環境で 10.0.0.0/16 を使い回しており、後から本番ハブに接続できなくなるケースです。小規模な検証環境でも、将来ハブアンドスポークに参加させる可能性があるなら、最初からIPアドレス設計表に登録しておくべきです。
NSGとUDRはPeering作成後に再確認する
Peeringを作成しても、NSGで拒否されていれば通信できません。逆に、Peering作成時に広く接続を許可すると、想定以上のサブネット間通信が成立することがあります。公式ドキュメントでは、Peering構成時にNSGルールを開くか閉じるかを設定し、必要に応じて特定アクセスをブロックできると説明されています。(Microsoft Learn)
UDRを使う場合は、NVAやVPN Gatewayを経由するService Chainingの設計が重要です。Virtual Network Peeringでは、UDRの次ホップとしてピアリング先VNet内のVMやVPN Gatewayを指定できますが、ExpressRoute Gatewayを次ホップ種別にしてVNet間をルーティングすることはできません。(Microsoft Learn)
DNSは自動で別VNetの名前解決まで面倒を見ない
ピアリングでIP到達性が確保されても、既定のAzure名前解決だけで別VNet内の名前を解決できるわけではありません。公式ドキュメントでは、ピアリングされたVNet間の名前解決にはAzure Private DNSまたはカスタムDNSサーバーが必要とされています。(Microsoft Learn)
アプリ開発側では、「IPでは疎通するがFQDNでは失敗する」という障害が起きがちです。Private Endpoint、App Service、SQL Managed Instance、AKSなどを使っている環境では、Peering設定と同時にPrivate DNS Zoneのリンク状況も確認しましょう。
移行・展開で失敗しやすいポイント
Peeringは自動的に推移しない
Virtual Network Peeringは推移的な接続ではありません。VNet AとVNet B、VNet BとVNet Cをピアリングしても、VNet AとVNet Cが自動的に通信できるわけではありません。AとCを直接通信させたい場合は明示的にPeeringを作成するか、ハブ側のNVAなどを経由する設計が必要です。(Microsoft Learn)
この仕様を誤解すると、ハブアンドスポーク構成で「スポーク同士が通信できない」という問い合わせが発生します。スポーク間通信が必要なら、直接Peering、AVNMのConnected Group、NVA経由のいずれで実現するかを設計段階で決めておきましょう。
Global PeeringではBasic Load Balancerに注意する
Global Virtual Network Peeringでは、別リージョンのVNet内にあるBasic Load BalancerのフロントエンドIPへ通信できない制約があります。Standard Load BalancerはVirtual Network PeeringとGlobal Virtual Network Peeringの両方でサポートされますが、Basic Load Balancerを使う古い構成では移行前の確認が必須です。(Microsoft Learn)
古いIaaS構成をそのまま別リージョン連携する場合は、ロードバランサーSKUを確認してください。アプリが正常でも、ネットワーク経路上のSKU制約で疎通しないことがあります。
VNetを移動する前にPeeringを削除する必要がある
ピアリング中のVNetは、別のリソースグループやサブスクリプションへ移動できません。移動するには、Peeringを削除し、VNetを移動し、再度Peeringを作成する必要があります。(Microsoft Learn)
この制約は、サブスクリプション統合やリソース整理のときに見落とされがちです。移動作業の前に、接続停止の影響、再作成後のPeering状態、NSG・UDR・DNS・VPNクライアントの確認まで含めて手順化しましょう。
P2S VPNクライアントは再ダウンロードが必要になることがある
Point-to-Site VPNを利用している場合、Virtual Network Peering構成後に新しい経路をクライアントへ反映するため、VPNクライアントを再ダウンロードする必要があると説明されています。(Microsoft Learn)
「Azure上のVM同士は通信できるが、在宅端末からスポーク側へ接続できない」という場合は、VPNクライアント側のルートが古いままになっていないか確認してください。
管理者が今日確認すべきチェックリスト
Azure Virtual Network Peeringの更新内容を受けて、既存環境では次の項目を確認してください。
| チェック項目 | 確認方法 | 問題がある場合の対応 |
|---|---|---|
| Peering状態 | Azure portal、CLI、PowerShellで両方向がConnectedか確認 | 片方向だけなら対向側のPeeringを作成・修正 |
| 接続範囲 | VNet全体かSubnet Peeringか確認 | 最小権限化が必要ならSubnet Peeringを検討 |
| アドレス空間 | VNet、オンプレミス、将来予定CIDRを確認 | 重複する場合はPeering前に再設計 |
| アドレス変更後の同期 | PeeringのSync状況を確認 | 変更ごとに同期し、有効ルートを確認 |
| NSG | 送信元・宛先・ポート・サービス タグを確認 | 全許可ではなく必要な通信だけ許可 |
| UDR | 次ホップがNVA、VPN Gateway、意図した経路か確認 | ExpressRoute GatewayをVNet間UDRの次ホップにしない |
| DNS | Private DNS Zoneリンク、カスタムDNS、条件付き転送を確認 | IP疎通だけでなくFQDN疎通をテスト |
| Gateway Transit | remote gateway利用側が自身のGatewayを持っていないか確認 | ローカルGatewayとリモートGatewayのどちらを使うか決める |
| 経路広告 | オンプレミスへ広告されるCIDR数を確認 | summarizedGatewayPrefixesで集約を検討 |
| 料金 | 同一リージョン、Global Peering、Gateway Transitの通信量を確認 | Azure Pricing Calculatorや実績メトリックで見積もる |
開発者が知っておくべき実装上の注意
アプリ開発者にとって、Virtual Network Peeringは「ネットワークチームが設定するもの」に見えがちですが、実際にはアプリの接続文字列、FQDN、Private Endpoint、負荷分散、監視、認証基盤に影響します。
特に確認すべきなのは、接続先をIPで固定していないか、DNS名が別VNetから解決できるか、グローバルピアリング先にBasic Load Balancerが残っていないか、オンプレミスからの戻り経路があるか、という点です。Peering作成後の疎通テストでは、単に ping やポート疎通を見るだけでなく、実際のアプリプロトコルでログイン、API呼び出し、DB接続、名前解決まで確認してください。
また、Subnet Peeringを使う場合は「同じVNet内の別サブネットだから到達できるはず」という前提が崩れる可能性があります。接続対象サブネットが限定されるため、アプリ構成図にはVNet単位ではなく、サブネット単位の接続関係を書き込むべきです。
導入・変更時のおすすめ手順
新規導入や既存環境の見直しでは、次の順序で進めると安全です。
| フェーズ | 作業 | 成果物 |
|---|---|---|
| 現状把握 | VNet、サブネット、Peering、Gateway、NSG、UDR、DNSを棚卸し | ネットワーク構成表 |
| 設計 | 通常Peering、Subnet Peering、Gateway Transit、AVNMの使い分けを決める | 接続方針書 |
| 影響確認 | アドレス重複、Basic Load Balancer、P2S VPN、課金を確認 | 影響範囲リスト |
| 実装 | Peering作成、NSG・UDR・DNS設定、必要ならSync | 変更手順書 |
| 検証 | 有効ルート、Network Watcher、アプリ疎通、ログを確認 | 疎通確認結果 |
| 運用 | 通信量、経路広告数、Peering上限、変更履歴を監視 | 運用チェックリスト |
公式ドキュメントでは、Peeringの存在確認に有効ルートを使い、Next hop typeがVirtual network peeringになっているかを確認する方法が示されています。さらに、Azure Network Watcherの接続チェックを使うと、送信元VMのNICから宛先VMのNICまでの経路を確認できます。(Microsoft Learn)
まとめ：まずは既存Peeringの棚卸しから始める
Azure Virtual Network Peeringの2026年5月20日更新で特に重要なのは、Subnet Peeringによる接続範囲の細分化、ピアリング済みVNetのアドレス空間変更、Gateway Transit時の経路集約、そして課金条件の再確認です。既存環境では、Peering状態だけを見るのではなく、NSG、UDR、DNS、ゲートウェイ、アドレス空間、料金をまとめて点検する必要があります。
次に取るべき行動は明確です。まず、Azure portalまたはCLIで既存Peeringを一覧化し、接続範囲、アドレス空間、ゲートウェイ転送、通信量を確認してください。そのうえで、VNet全体を接続し続ける必要があるのか、Subnet PeeringやAdvertised Gateway Prefixesで設計を見直すべきかを判断しましょう。大規模なハブアンドスポーク環境ほど、早めの棚卸しが障害予防とコスト最適化につながります。
コメント