L4 vs L7 Load Balancing Decisionを理解するための前提
Azure Load Balancer/Gateway Load BalancerはL4 flowを扱い、Application Gateway/Front DoorはHTTP(S)等のproxyとしてL7 requestを扱う。 L4はTLSをbackendまでpass-throughでき、backendがoriginal client source IPを見られる一方、HTTP host/path/WAF等は理解しない。
L7 proxyはclient/backend connectionを分離し、TLS termination、Host/path routing、WAF、rewrite等を提供する。original client IPは通常X-Forwarded-For等で渡す。 Application Gatewayはregional/VNet-integrated L7、Front Doorはglobal edge L7、Traffic ManagerはDNS steeringでdata pathに入らない。
stateful NVA insertionはHA Ports/Gateway Load Balancerなどapplication load balancingとは別problem。 選定は「globalかregionalか」より先に、protocol、proxy許容性、TLS ownership、application-aware controlが必要かを固定する。
Control plane / Data plane / Observability
TCP/UDP flow。payloadを理解しない。
HTTP(S) request。TLS/Host/path/header/WAFを扱う。
Traffic Manager。endpoint選択だけでpacket pathには入らない。
Client-to-backend path
- protocolがHTTP(S)かraw TCP/UDPかを固定する。
- proxy terminationを許容できるかを確認する。
- TLS termination/end-to-end/mTLS ownershipを決める。
- Host/path/WAF/rewrite/cache等のL7機能要否を決める。
- regional/global/DNS-only placementを決める。
- client IP、origin security、health model、egressを最後にservice固有設計へ落とす。
仕組みを分解する
「443だからL7」「globalだからFront Door」と短絡しないことが重要です。443でもTLS pass-throughのraw TCPならL4要件です。逆にregionalでもHost/path routingやWAFが必要ならApplication Gatewayです。Traffic Managerはglobalですがproxyではないため、TLS/WAF/cacheを提供しません。
運用時は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は到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Raw TCP/UDP | Standard Load Balancer。NVA chainingならGateway LB/HA Portsを比較。 |
| Regional HTTP(S) | Application Gateway v2。WAFならWAF_v2。 |
| Global HTTP(S) | Front Door Standard/Premium。managed WAF/Private Link originならPremium。 |
| DNS-only steering | Traffic Manager。endpoint側serviceと組み合わせる。 |
確認手順
Read-only verification
- protocol/portだけでなくactual handshakeとHTTP semanticsをpacket captureで確認する。
- backendがsource IPをpacketで必要か、headerでよいかをapplication ownerと固定する。
- TLS termination pointとcertificate/private key ownerをdiagramに記載する。
- health probeがL4/L7のどのfailureを検知するかtestする。
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 list -o table
az network application-gateway list -o table
az afd profile list -o table
az network traffic-manager profile list -o tableGet-AzLoadBalancer
Get-AzApplicationGateway
Get-AzFrontDoorCdnProfile
Get-AzTrafficManagerProfile障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| HTTP route不可 | L4 service選択 | service type | AppGW/Front Door比較 |
| client IP必要 | proxy/L4要件未整理 | backend source/header | L4 or XFF trust |
| global failover遅い | DNS steering TTL | TTL/connection path | Front Door proxy比較 |
| mTLS壊れる | TLS termination point | handshake/cert | pass-through/feature確認 |
| NVA asymmetry | app LBとservice chain混同 | packet path | GWLB/HA Ports |
変更時の確認と rollback
- service migrationはDNS/VIP切替をseparate phaseにする。
- TLS termination変更はcertificate/hostname/client behaviorをbefore/after保存する。
- proxy導入時はHost/XFF/redirect/cookie回帰を行う。
- rollback pathはold endpointをTTL期間維持する。
Current notes — 2026-09-11
2026時点でもservice boundaryは明確: Load Balancer=L4、Application Gateway=regional L7、Front Door=global edge L7、Traffic Manager=DNS steering。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。