Scope: 設計・運用で誤りやすい点を優先して整理。SKU/region/limitsは変更されるため、実装時はリンク先のcurrent Microsoft Learnを再確認してください。
Overview
custom/default probe結果からbackend availabilityを判定する。
Key technical points
- HTTP status、Host header、TLS trust、probe path、backend portの不一致が代表的なfailure要因。
- backend health画面とaccess/performance logsを突き合わせる。
- DNS backendを使う場合はApplication Gateway側のname resolution pathも確認する。
Design guidance
- L4/L7、regional/global、proxy/DNS、TLS termination、WAF要件を先に決める。
- health probeがapplication readinessを正しく表すかを設計する。
- backend healthが正常でもDNS/routing/NSG/WAF/client-side failureは別にあり得る。
Operations checklist
- frontend/listener/rule/backend/probeの紐付きを確認する。
- backend healthとNSG/route/DNSを確認する。
- TLS certificate/SNI/Host headerを確認する。
Common pitfalls
- health probe source/Host/pathを誤りbackendをunhealthyにする。
- L4/L7 serviceの役割を混同し二重NAT/proxyを作る。
Azure CLI quick check
read-only確認を優先し、実環境のsubscription/resource名へ置換してください。
az network application-gateway show-backend-health -g <rg> -n <appgw> -o jsoncVerification pattern
Control plane
resource state、association、policy、route/BGP configが期待通りかを確認。
resource state、association、policy、route/BGP configが期待通りかを確認。
Data plane
同一5-tupleまたは実application journeyで到達性・latency・security判定を実証。
同一5-tupleまたは実application journeyで到達性・latency・security判定を実証。
Observability
diagnostic logs / flow logs / Network Watcherで実際の判定とpathを残す。
diagnostic logs / flow logs / Network Watcherで実際の判定とpathを残す。
Rollback
設定を戻した後のroute convergence、DNS cache、existing sessionまで確認。
設定を戻した後のroute convergence、DNS cache、existing sessionまで確認。