Network Design Review Template

Architecture contract

diagramの美しさではなく、traffic matrix・ownership・failure mode・runtime acceptanceが説明できることを設計承認の条件にする。Microsoftのnetworking / landing-zone guidanceを基礎にした本サイト独自の実務review templateとして、未決事項・assumption・local-only factを明示し、test PASSだけで完成扱いしない。

この記事の目次

要点境界構成設計判断展開責任分界確認失敗例変更安全 Sources

Network Design Review Templateを理解するための前提

このページはMicrosoft公式checklistの転載ではなく、Azure networking design guidanceを基礎にAZ VNet Spaceが実務向けに統合したreview template。最初にbusiness/application requirementではなく、required flow / denied flow / dependency / failure behaviorまでtraffic matrixへ落とす。『VNet間通信が必要』だけでは粒度が粗い。

addressingはCIDR重複チェックに加え、growth、hybrid summarization、Private Endpoint/AKS等のIP consumption、renumber costを確認する。 routingはnormal pathだけでなくreturn path、BGP/UDR/system routeの優先、NVA statefulness、gateway propagation、failover時のpathを確認する。

DNSはprivate/public namespace、Private DNS zone link、resolver/forwarder、on-prem conditional forwarding、cache/TTL、failoverをarchitecture componentとして扱う。 securityはNSG/ASG、Firewall/NVA、WAF、Private Link、Security Admin Rules、identity/accessを層として整理し、central teamとworkload teamの責任分界を明示する。

最終承認にはcontrol-plane stateだけでなく、browser/CLI/device/application等で観測可能なpositive・negative・failure/recovery testを含める。

通信や判断の流れを追う

Platform policyShared servicesSpoke / Workload運用・変更

Ownership / Control / Data plane boundary

Requirement boundary

誰と誰が、何のprotocol/port/FQDNで、なぜ通信するかをowner付きで定義する。

Platform boundary

connectivity subscription / hub / firewall / DNS / gateway等のshared service責任を定義する。

Workload boundary

spoke VNet / subnet / NSG / endpoint / application listener等の責任を定義する。

Acceptance boundary

configuration存在ではなくreal journeyとfailure recoveryを完了条件にする。

Architecture model

Requirements

Traffic / dependency / SLO

何を実現するか

Architecture

Address / topology / route / DNS

どう構成するか

Governance

Security / ownership / Policy

誰が守るか

Delivery

IaC / staged rollout / rollback

どう安全に変えるか

Runtime

Positive / negative / failure test

本当に動くか

読み方レビュー順は『構成図を見る → 気になる点を指摘』ではなく、requirementとtraffic matrixから設計を検証し、最後にruntime acceptanceまで一本につなげる。未確認のlocal-only stateは推測で埋めない。

設計判断

判断軸	推奨する問い	設計時に固定するもの
Business / application	どのuser/system journeyがnetworkに依存し、許容停止時間はどれくらいか。	owner、SLO、critical flow、maintenance constraint。
Addressing	現在/将来のCIDRは重複せず拡張可能か。	IP plan、IPAM owner、reserve、hybrid summary。
Topology	hub-spoke / vWAN / mesh / direct peeringの選択理由は何か。	diagram、region boundary、shared service、scale limit。
Routing	normal/failure時の往復pathを説明できるか。	route matrix、BGP/UDR、NVA symmetry、failover。
DNS	private/public/hybrid resolutionのquery pathは何か。	zone authority、resolver、forwarding、TTL/failure。
Security	central guardrailとworkload policyをどこで分けるか。	NSG/Firewall/WAF/SAR/PE、exception、logs。
Operations	誰が何をmonitorしincident時に何を最初に見るか。	metrics/logs/alerts/runbook/on-call boundary。
Change safety	どの単位でcanary/rollbackするか。	deployment wave、stop condition、known-good artifact。

実装・展開の順序

Scope / ownersを固定する。 project、subscription、region、platform/workload/partnerの責任者と変更権限を記録する。
traffic matrixを作る。 source/destination/protocol/port/FQDN、required/denied、normal/failure、ownerを列挙する。
address / topology / route / DNSをreviewする。 各decisionにassumption、alternative、rejected reasonを残す。
security / governanceを重ねる。 central guardrail、workload least privilege、Policy/AVNM、exception processを責任分界へ落とす。
failure scenarioを設計する。 hub/NVA/gateway/DNS/region/link lossを想定し、expected pathとrecovery targetを明示する。
acceptance testを作る。 positive、negative、failure/recovery、reload/restart後のobservable resultを列挙して実装前に承認する。

Platform team / Workload team の責任分界

領域	Platform / central team	Workload / application team
Connectivity platform	hub/vWAN、ER/VPN、Firewall/NVA、shared DNS、IPAM、central observabilityを所有。	利用要件とworkload dependencyを明示。
Workload network	guardrail/module/interfaceを提供。	VNet/subnet/NSG/PE/application endpointとlocal IaCを所有。
Security	central baseline、exception governance、logging standardを所有。	application-specific access matrixとdata sensitivityを提示。
Operations	shared service monitoring/runbook/escalationを所有。	application symptom / synthetic test / business impactを観測。
Change manager	cross-team rollout/rollback gateを統合。	owning scopeのvalidationとsign-offを実施。

Design review gates

1. Context & scope

subscription / region / tenantを明示
ownersとdecision authorityを記録
既存/新規/移行を区別

2. Traffic matrix

required flowにbusiness owner
denied flowをnegative test化
failure時のalternate pathを記述

3. Addressing

Azure/on-prem/partner overlapなし
growthとlarge contiguous blockを確保
IPAM/delegationを明示

4. Topology & routing

normal/return pathを説明可能
BGP/UDR/system routeを区別
NVA stateful symmetryを検証

5. DNS

authority/zone/link/resolverを明示
hybrid forwarding loopなし
TTL/cache/failoverをtest

6. Security

central/workload責任分界
NSG/Firewall/WAF/PE/SARの層を整理
exceptionにowner/expiry

7. Resilience

component/zone/region failureを列挙
RTO/RPO/connection recoveryを定義
single point of failureを承認

8. Observability

metrics/logs/flow evidenceを選定
alertにowner/runbook
change前baselineを保存

9. Delivery

IaC/source authorityを明示
canary/wave/stop condition
known-good rollback artifact

10. Acceptance

positive test
negative test
failure/recovery test
reload/restart/persistenceを必要に応じ確認

Copy/paste — review record skeleton

# Network Design Review
## Scope / Owners
- Tenant / subscriptions / regions:
- Platform owner:
- Workload owner:
- Security owner:

## Required / Denied Traffic
| Source | Destination | Proto/Port | Required? | Path | Owner |

## Addressing / IPAM
- VNet CIDRs:
- Growth reserve:
- Hybrid summaries:
- Overlap check evidence:

## Routing / DNS / Security
- Normal path:
- Return path:
- Failure path:
- DNS query path:
- Central guardrails:
- Workload controls:

## Rollout / Rollback
- Canary:
- Wave:
- Stop condition:
- Known-good rollback:

## Final Verification
- Positive:
- Negative:
- Failure/recovery:
- Observable runtime evidence:

Verification / review evidence

設計レビューで残す証拠

approved traffic matrixとdenied-flow matrix
address/IPAM planとoverlap/growth evidence
normal/failure route matrix、DNS query path
central/workload responsibility matrix
security exceptionとexpiry
canary/wave/rollback/final verification record

runtimeで確認すること

required flowがreal application protocolで成功すること
denied flowが意図したcontrolで失敗し、別pathへ逃げないこと
effective route/security/DNS stateがdesign artifactと一致すること
shared-service/NVA/gateway等のfailure testでexpected recoveryが成立すること
reload/restart/connection re-establishment後も期待stateを維持すること
monitoring/loggingで上記testを後から追跡できるevidenceが残ること

Azure CLI — basic design inventory (read-only)

az network vnet list -o table
az network route-table list -o table
az network nsg list -o table

PowerShell — basic design inventory (read-only)

Get-AzVirtualNetwork | Select-Object Name,ResourceGroupName,Location,AddressSpace

Common failure modes

症状 / anti-pattern	原因になりやすい設計	確認・是正
構成図はあるが障害時pathが不明	normal topologyだけをreviewしfailure matrixがない。	component/link/region failureごとのexpected pathとRTOを追加。
通信要件が『Azureから社内へ』だけ	traffic matrixのsource/destination/protocol/owner粒度が不足。	5-tuple/FQDN/application journeyまで分解。
testはpingだけ	L3到達性とapplication/DNS/security behaviorを同一視。	real protocol、DNS、TLS/L7、negative flowを追加。
誰もcentral route変更を承認できない	platform/workload責任分界とdecision authorityが未定義。	resource/controlごとのRACI相当を明記。
rollback手順は設定を戻すだけ	route convergence、DNS cache、stateful session、persistent stateを確認していない。	observable post-rollback acceptanceを定義。

Change safety / rollback

一括変更を避ける: 設計レビュー自体では『戻せる構成』を作ることが目的。implementation artifactのknown-good version、configuration deployment target、route/DNS/securityのbaseline evidenceをchange前に保存し、rollback後のpositive/negative/failure testを事前に定義する。