Architecture & Governance参照資料確認: 2026-09-11

Reachability Verification

Azure Virtual Network Manager Network VerifierとNetwork Watcherを使い、policy/configuration上の到達可否と実data plane evidenceを分けて検証する。

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を2026-09-11時点で確認し、旧来の短い記事を公開運用向けdeep diveへ更新。SKU、region、limits、Preview statusは変わるため、実装直前にOfficial sourcesを再確認してください。
What changed recently: Network Verifierは2026-09時点のMicrosoft LearnでGAだがregion availabilityが限定される。current availabilityを実装時に確認する。

Reachability Verificationを理解するための前提

Network VerifierはAVNM scope内のresource/policyを静的解析し、source→destination pathとblocking controlを示す。 2026-09時点のMicrosoft LearnではNetwork VerifierはGAだが提供regionが限定されるため、利用regionをcurrent docsで確認する。

NSG/ASG、security admin rule、VNet peering、route table、service endpoint/ACL、Private Endpoint、Virtual WAN、Azure Firewall static L4等を分析対象に含む。 analysis resultはsupported featureを対象としたcontrol-plane reasoningであり、実packetやapplication responseを直接観測するものではない。

Network Watcher Connection troubleshoot/Next hop/IP flow verifyはruntime troubleshootingの補完として使う。 complianceでは「denyされること」の証明もallowと同じくintentとして保存する。

通信や判断の流れを追う
Platform policyShared servicesSpoke / Workload運用・変更

Control plane と data plane

Control planeVerifier workspaceとreachability analysis intent/resultがcontrol plane上で設定/計算される。
Data planeactual data planeはVM/service health、DNS、unsupported appliance、application listener等の影響を受けるためruntime evidenceを追加する。

仕組みと設計上の意味

static verifierのPASSをapplication successと同義にしない。

unsupported NVA behaviorやdynamic L7 policyは別途logs/testが必要。

Verifier scopeはNetwork Manager parent scopeに依存するため、対象resourceがscope外なら結果に含まれない。

pre-change intentとpost-change resultを保存するとchange validation evidenceとして再利用できる。

Packet / decision path

source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。

  1. source/destination/protocol/port intentを固定。
  2. Network Verifierでpolicy pathを分析。
  3. blocking/allowing resourceを記録。
  4. Network Watcher/runtime testで同じ5-tupleを確認。
  5. 結果差異があればunsupported layer/DNS/app/NVAを調査。

設計判断

判断点推奨理由
Design reviewVerifier intentを事前作成configuration導入前にreachabilityを検討
Change gatebefore/after result保存unexpected policy drift検出
IncidentVerifier→runtime toolの順config vs data planeを分離
Complianceexpected denyも定義least privilegeを証明

確認手順

Azure Portal

  • Virtual Network Manager → Verifier workspaceでanalysis intent/resultを確認。
  • source/destination resourceとport/protocolが依頼要件と一致するか確認。
  • Connection troubleshoot/Next hop等でruntime evidenceを追加。

Evidence contract

Identitysubscription / resource group / resource ID / regionを固定。
Before / After同じsource・destination・protocol・portで比較。
Effective state設定値だけでなくeffective route/security/health/logを取得。
Runtimecontrol-plane Succeededとapplication successを分けて判定。
Azure CLI — read-only first
az network watcher test-connectivity -g <rg> --source-resource <vm-or-id> --dest-address <fqdn-or-ip> --dest-port <port>
az network watcher show-next-hop -g <rg> --vm <vm> --source-ip <src> --dest-ip <dst> -o jsonc
az network watcher test-ip-flow -g <rg> --vm <vm> --direction Outbound --protocol TCP --local <src:port> --remote <dst:port>

障害切り分け

症状疑う点証拠次の確認
Verifier PASSだが通信不可DNS/app/unsupported applianceruntime test/logdata plane layerへ進む
Verifier DENYNSG/route/security admin rule等result blockerblocking resourceを修正
resourceが選べないNetwork Manager scope/region制約scope + availabilityscope/region確認
結果が古い/想定外configuration driftresource current configanalysis rerun

変更・rollback

  • analysis intent/resultをchange evidenceとして保存。
  • policy変更はexpected allow/deny両方のtest matrixを用意。
  • rollback後にVerifierとruntime testを再実行。
  • tool unsupported機能は手動検証項目として明示。

Official sources