Azure Load Balancing Decision Matrixを理解するための前提
Load Balancerはregional L4、Gateway Load Balancerはtransparent NVA chaining、Application Gatewayはregional L7、Front Doorはglobal L7 edge、Traffic ManagerはDNS steering。 「load balancing」という名称でもdata pathに入るserviceとDNS answerだけ返すserviceがある。最初にproxy/non-proxyを分ける。
WAFが必要ならApplication Gateway WAF_v2またはFront Door Premium/Standard custom rules等のfeature差を確認する。 private application entry pointはinternal Load Balancerまたはprivate Application Gateway、global public edgeからprivate originへはFront Door Premium Private Link等を比較する。
egressは別問題。inbound Load Balancerを選んでもbackend outbound architectureはNAT Gateway等で明示する。 multi-tier構成ではFront Door→Application Gateway→backendのようにserviceを組み合わせられるが、health/Host/client IP/security責任をlayerごとに分ける。
Control plane / Data plane / Observability
data planeにproxyが必要か。
HTTP-aware control/TLS/WAFが必要か。
regional/global/DNS-only/NVA chainのどこに配置するか。
Client-to-backend path
- traffic protocolとclient typeを固定する。
- L4 pass-throughかL7 proxyかDNS steeringかを選ぶ。
- regional/global scopeとprivate/public entry pointを決める。
- health evaluation pointとfailover targetを決める。
- TLS/Host/client IP/origin security要件をservice featureへmappingする。
- outbound/observability/rollbackを別軸で完成させる。
仕組みを分解する
正しい選定は単一表の「○×」だけでは終わりません。たとえばFront Door + AppGWは両方L7ですが、Front Doorはglobal edge/origin security、AppGWはregional VNet integration/backend health/TLSを担当できます。重ねる場合はHost header、X-Forwarded-For、WAF二重評価、probe sourceを明示します。
運用時は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は到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Standard Load Balancer | TCP/UDP、source IP preservation、low-latency L4、internal/public VIP。 |
| Gateway Load Balancer | third-party NVA transparent service chainとflow symmetry。 |
| Application Gateway v2 | regional HTTP(S)/TLS、Host/path routing、private frontend、WAF_v2。 |
| Front Door + Traffic Manager | Front Door=global proxy/CDN/WAF、Traffic Manager=DNS endpoint steering。用途を混同しない。 |
確認手順
Read-only verification
- architecture diagramにclient→edge/VIP→proxy→backendを実際のconnection boundaryで描く。
- 各hopのhealth source、TLS termination、source IP/headersを表にする。
- regional failure/backend failure/origin bypassなどfailure injectionを最低1つずつ試験する。
- DNS TTL/route/NSG/WAF/loggingをservice選定表とは別acceptanceにする。
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障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| 選定後に機能不足 | layer要件漏れ | requirements matrix | protocol/TLS/WAF再評価 |
| client IP期待違い | proxy boundary漏れ | packet/header | XFF trust or L4 |
| DRが遅い | DNS TTL/failover model | TTL + health | Front Door/TM差 |
| backend非公開化不足 | origin security漏れ | direct-origin test | Private Link/ACL/FDID |
| egress障害 | inboundと混同 | SNAT config | NAT Gateway等別設計 |
変更時の確認と rollback
- service cutover前にold DNS/VIPを維持する。
- certificate/domain ownershipを新旧serviceで重複可能にする。
- WAF policyはlayerごとにrollback可能にする。
- rollback判定はHTTP 200だけでなくclient IP/Host/TLS/origin bypassまで含める。
Current notes — 2026-09-11
Azureのload-balancing portfolioは機能が増えているが、L4/L7/DNS/NVA chainingという役割分担で整理すると選定を安定させられる。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。