Gateway Load Balancerを理解するための前提
Gateway Load BalancerはAzure Load Balancer portfolioのGateway SKUで、third-party NVAをtransparentにservice chainするためのmanaged dataplane。 Standard Public Load Balancer frontendやStandard NIC IP configuration等のsupported consumer resourceからchainする。GWLB frontendをUDR next hopにはできない。
consumer→GWLB→NVA→consumerのtrafficはVXLAN encapsulationを使い、NVA backendへ渡される。 Gateway Load Balancerはflow stickinessとsymmetryを提供し、stateful NVAが同じpathを往復する設計を簡素化する。
consumer applicationへ戻る際もoriginal source IPを保持でき、public publishingとsecurity appliance ownershipを別subscription/tenantへ分離できる。 health probe + HA ports ruleがNVA backend availabilityを管理する。
Control plane / Data plane / Observability
Standard Public LB/NIC frontendがGWLBを参照する。
Gateway LB + NVA poolをsecurity/service provider側で運用できる。
VXLANでtrafficをNVAへ運び、flow symmetryを保持する。
Client-to-backend path
- client trafficがconsumer public endpointへ到達する。
- consumer resourceのchain設定によりGWLBへtrafficを送る。
- GWLBがVXLAN encapsulationしてhealthy NVA instanceへ配布する。
- NVAがinspect/transform/forwardし、GWLB tunnelへ返す。
- GWLBがconsumer resourceへtrafficを戻す。
- consumer Load Balancer/NICからapplication backendへ進み、replyも逆方向に同NVA chainを通る。
仕組みを分解する
Gateway Load Balancerを従来UDR-based NVA挿入と混同しないことが重要です。GWLB frontend IPをroute tableのnext hopには設定できません。consumer resourceのchainingとして構成し、provider networkのaddress overlapやsubscription/tenant境界を吸収しながらNVA serviceを挿入します。
運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Public publishing chain | public LB/NIC front endの前後へNVAをtransparentに挿入したい場合に適する。 |
| UDR based inspection | spoke east-west/egress全体のroute steeringが中心ならAzure Firewall/NVA + UDR等を別途比較する。 |
| VXLAN support | 選定NVA image/applianceがGateway LB integrationとVXLAN tunnel interfaceを正式サポートするか確認する。 |
| Ownership | consumer app teamとsecurity appliance provider teamのsubscription/tenant境界を明記する。 |
確認手順
Read-only verification
- consumer frontendのGateway Load Balancer referenceを確認する。
- GWLB frontend/tunnel interface/backend pool/health probeを確認する。
- NVAでVXLAN interfaceとinner packetのoriginal client IPをcaptureする。
- NVA failure時にnew flowがhealthy instanceへ移るか、return pathが同一instanceか確認する。
Evidence to keep
- resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
- DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
- 変更前後で同じclient journeyをnew connectionとして再実行する。
- Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
az network lb show -g <rg> -n <gateway-lb> -o jsonc
az network lb frontend-ip list -g <rg> --lb-name <gateway-lb> -o jsonc
az network lb address-pool list -g <rg> --lb-name <gateway-lb> -o jsoncGet-AzLoadBalancer -ResourceGroupName <rg> -Name <gateway-lb> | Format-List *障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| NVAを通らない | consumer chain未設定 | frontend reference | consumer resource association確認 |
| 片方向だけ失敗 | NVA tunnel/flow handling | VXLAN capture | appliance integration確認 |
| GWLBをUDR指定できない | 設計誤り | route table | consumer chainingへ変更 |
| probe unhealthy | NVA health endpoint | probe + NVA log | tunnel/health listener確認 |
| client IP欠落 | NVA自身のSNAT | inner packet capture | appliance policy確認 |
変更時の確認と rollback
- consumer chain reference解除を明確なrollback pointにする。
- provider NVA pool変更前にflow/session impactを記録する。
- VXLAN/tunnel configはvendor-supported templateと差分管理する。
- rollback後はconsumer→appのdirect pathとsource IPを再確認する。
Current notes — 2026-09-11
Gateway Load Balancerは現在もGateway SKUとして提供され、UDR next hopではなくsupported consumer resourceへのchainingを前提とする。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。