Azure Firewallを理解するための前提
Azure Firewallはcloud-nativeのfully stateful Firewall as a Serviceで、east-westとnorth-south trafficをinspectionできる。 Basic / Standard / Premiumの3 SKUがあり、StandardはL3-L7/threat intelligence、PremiumはIDPS/TLS inspection/URL filtering等を追加する。
workload trafficはFirewallへrouteされて初めてpolicy対象になる。Firewallをdeployしただけではspoke trafficは自動的に通らない（secured virtual hubを除く）。 Firewall PolicyではDNAT → Network → Applicationのrule type順序が重要で、parent policy ruleはchildより先に処理される。
network-rule trafficのSNATはdestination/private range設定に依存し、application-rule trafficはtransparent proxyを通じてSNATされる。 運用ではstructured logs、metrics、Firewall Workbookを有効化し、rule hit・threat/IDPS・DNS proxy・flowをKQLで追える状態にする。
Control plane と data plane
仕組み
workload subnetのrouteがFirewall private IP（またはsecured hub routing）へtrafficを送る。
Firewallが既存state/session、threat intelligence、NAT/Network/Application policyを評価する。
DNAT matchならdestination translationとallow処理、outboundはNetwork→Applicationの順でterminating matchを探す。
必要に応じSNATを行いdestinationへforwardする。PremiumではTLS inspection/IDPSが追加される。
return trafficをstatefulに処理し、logs/metricsへ観測可能なevidenceを出す。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- inspection対象flowと非対象flowを明確にし、UDR/BGPで経路をcontract化する。
- AzureFirewallSubnetはdedicatedかつ十分なsize（Microsoft Learnでは/26）を確保する。
- SKUはthroughputだけでなくDNS proxy、Threat Intel、IDPS/TLS inspectionなど必要controlで選ぶ。
- Policy rule hierarchyとownerを分離し、network ruleがapplication ruleをshadowしないかreviewする。
- diagnostic settingsを初日から有効化し、変更受入にrule hit/log evidenceを含める。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Topology | productionではhub-spoke / secured virtual hubを基本候補にする。 | central inspectionとshared connectivityの責務を分けやすい。 |
| Routing | 往復とも同じstateful Firewallへ戻るよう設計する。 | asymmetryはsilent dropの典型原因。 |
| Rules | Firewall Policyをsource of truthとしRCG/RC/rule hierarchyを明示する。 | classic rulesより中央管理・継承・分析を使いやすい。 |
| Logging | resource-specific structured logs + Log Analyticsを採用する。 | rule processing、threat、DNS、IDPSをKQLで横断しやすい。 |
確認手順
Azure Portal / Network Watcher
- Firewall → OverviewでProvisioning state、SKU、private/public IP、Policy associationを確認。
- Firewall Policy → Rule collection groupsでpriority/type/actionを確認。
- Diagnostic settings / Logs / Workbookで実rule hitとdeny/threat eventを確認。
- 代表spoke NICのEffective routes / Next hopでFirewall経由を証明。
Verification discipline
- subscription / resource group / resource ID / NIC / direction / 5-tupleを記録する。
- 同じ条件でbefore/afterを比較し、既存sessionとnew connectionを区別する。
- configuration、effective state、logs、application resultを別々の証拠として残す。
- 変更成功はcontrol-plane Succeededではなくobservable data-plane behaviorで判定する。
az network firewall show -g <rg> -n <firewall> -o jsonc
az network firewall policy show -g <rg> -n <policy> -o jsonc
az monitor diagnostic-settings list --resource <firewall-resource-id> -o jsoncGet-AzFirewall -ResourceGroupName <rg> -Name <firewall>
Get-AzFirewallPolicy -ResourceGroupName <rg> -Name <policy>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| policyはAllowなのにbypass | UDR/BGP/peering routeがFirewallを通していない | source NIC effective route / Next hop | routingを先に修正 |
| Webだけdeny | Network ruleが先にmatch、Application rule/FQDN/SNI/DNS問題 | rule type順序とFirewall logs | Network rule shadowを除去しDNS/SNI確認 |
| returnだけ失敗 | asymmetric route/SNAT設計 | 両方向routeとFirewall flow logs | symmetryを回復 |
| 負荷時にconnection失敗 | SNAT port/scale/throughput | SNAT metrics/log、Firewall performance | public IP/NAT Gateway integration/SKUを評価 |
変更時の確認と rollback
- 変更前Policy/RCG JSON、route、diagnostic evidenceを保存する。
- rollback時はpolicyだけでなくUDR/BGP/SNAT/DNSの関連変更を同じchange unitで戻す。
- stateful sessionは新規connectionで再検証し、route convergence後にacceptする。
What changed recently
2026年はFirewall性能資料やDNS/FQDN関連資料が更新されています。容量設計ではSKUの理論上限だけでなく、TLS inspection/IDPS modeを有効にしたときのcurrent performance tableを確認します。