AZ VNet SpaceAzure Networking Wiki
Home / Load Balancing & Delivery
Load Balancing & Delivery参照資料確認: 2026-09-11

Azure Load Balancer

Azure Load Balancerを、5-tupleのLayer 4 flow、frontend/backend、health probe、source IP preservation、inbound/outbound境界までpacket単位で整理する。

この記事の目次
要点境界通信経路仕組み設計確認障害切り分け変更/rollbackCurrentSources

Azure Load Balancerを理解するための前提

Azure Load BalancerはLayer 4でTCP/UDP flowを分散し、HTTP headerやpayloadを解釈せずTLSも終端しない。 inbound flowはfrontend IP/portとload-balancing ruleに一致し、health probeでhealthyなbackendへflow単位で割り当てられる。

既定のdistributionは5-tuple hash。必要な場合だけClient IPまたはClient IP + protocol affinityを使う。 Load BalancerはproxyとしてTCP接続を終端しないため、通常のinboundではbackend VMまでoriginal client source IPが保持される。

Standard Load Balancerはsecure-by-defaultで、NSG許可とprobe許可を別々に確認する。Basic Load Balancerは2025-09-30にretire済み。 outbound connectivityはinbound ruleとは別設計。現在はNAT Gatewayを第一候補とし、LB outbound ruleは必要性がある場合に明示設計する。

通信や判断の流れを追う
ClientEdge / Load balancerRouting / HealthBackend

Control plane / Data plane / Observability

Control plane

frontend IP、backend pool、probe、rule、NAT rule/outbound ruleをresourceとして構成する。

Data plane

frontendで受けたL4 flowをhealthy backendへmappingし、payloadをproxy終端しない。

Evidence

frontend rule、probe status、effective NSG、backend listener、flow tupleを同一時刻で照合する。

判定原則L4 flow、L7 proxy、DNS steering、NVA chainingを同じ「load balancing」として扱わず、clientが最終的にどのIPへ接続し、どこでconnectionが終端/再生成されるかを最初に固定します。

Client-to-backend path

  1. clientがpublic/internal frontend IPとportへTCP/UDP flowを開始する。
  2. Azure dataplaneがload-balancing ruleとprobe状態を評価する。
  3. distribution modeのtupleからhealthy backendを選ぶ。
  4. packet headerをbackend IPへmappingして転送する。HTTP/TLS内容は解釈しない。
  5. backendは元client source IPを見て応答し、Azure dataplaneがfrontend flowへ戻す。
  6. 新規flowはその時点のhealthy setで再評価される。既存flowと新規flowを同一視しない。

仕組みを分解する

Load Balancer障害調査では「VIPにSYNが届く」「ruleが一致する」「probeがhealthy」「backend OS/appがlisten」「return pathが成立」を順番に分けます。HTTP 500のようなapplication responseはL4 LB自体のhealthを直接示しません。反対にprobeだけ200でも、本番port/pathが別ならユーザー通信が成功する保証はありません。

運用時は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は到達しません。

設計判断

判断軸設計方針
L4で十分かHTTP host/path/WAF/TLS terminationが不要ならLoad Balancerが候補。必要ならApplication Gateway/Front Doorを比較する。
Public vs internalInternet-facing VIPかVNet/hybrid内VIPかを先に決める。frontendの到達性とbackend public exposureは別論点。
Distribution既定5-tupleを基本とし、source-IP affinityはproxy/NAT配下で偏りが出ることを理解して採用する。
Outboundegress要件をinbound設計に混ぜず、NAT Gateway/LB outbound rule/public IP等から明示選択する。

確認手順

Read-only verification

  • PortalでFrontend IP configuration、Backend pools、Health probes、Load balancing rulesの参照関係を確認する。
  • backend NICのNSG/effective security rule、guest OS listener、application logを同じportで確認する。
  • Network Watcher Connection troubleshootやpacket captureでclient→VIPとbackend側の到達を分離して確認する。
  • 新規接続と既存接続を分け、backend removal/probe down後のflow behaviorを記録する。

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を併用し、観測面の一時差を識別する。
Azure CLI — read-only first
az network lb show -g <rg> -n <lb> -o jsonc
az network lb rule list -g <rg> --lb-name <lb> -o table
az network lb probe list -g <rg> --lb-name <lb> -o table
az network lb address-pool list -g <rg> --lb-name <lb> -o table
PowerShell — read-only first
Get-AzLoadBalancer -ResourceGroupName <rg> -Name <lb>
Get-AzNetworkInterface -ResourceGroupName <rg> | Select-Object Name,IpConfigurations

障害切り分け

症状第一候補証拠次の確認
VIPへTCP接続不可NSG/rule/backend listenerrule frontend/backend port、NSG、ss/netstatprobeとguest listenerを同portで比較
一部backendだけ使われないprobe unhealthyprobe status/application logprobe path/status code/dependency
client IPが見えない途中proxy/NVA/SNATbackend packet capture/source IPinline hopのNAT動作を確認
新規接続だけ失敗healthy set/port exhaustionprobe、SNAT metrics、new-flow testoutbound/inboundを分離
偏りが大きいaffinity/NAT concentratordistribution mode/source IP分布5-tupleへ戻すかfrontend分割

変更時の確認と rollback

  • rule変更前にfrontend/backend/probe/distribution/idle timeoutをexportする。
  • probe変更はhealthy setを変えるため、旧probe条件とapplication readiness条件を保存する。
  • backend pool変更時は既存flowを考慮し、connection drainingを期待しない。
  • rollback後は新規TCP/UDP flowを複数sourceから再生成して確認する。
Change safety: health probe、DNS、TLS certificate、WAF/routing rule、backend poolを同時に変えるとfailure domainを判別できません。1 hypothesisずつ変更し、各段階で同じobservable journeyを再実行します。

Current notes — 2026-09-11

Current behavior / guidance

Basic Load Balancerは2025-09-30に廃止済みです。既存Basic Load Balancerは稼働を続ける場合がありますが、Microsoft supportおよびSLA保証の対象外です。現行設計はStandard Load Balancerを基本とし、NVA挿入用途ではGateway Load Balancerを要件に応じて選定します。

Azure Load Balancer Health Probes
関連するpacket path・health・TLS・delivery設計を続けて確認。Load Balancer Outbound Rules
関連するpacket path・health・TLS・delivery設計を続けて確認。Load Balancer HA Ports
関連するpacket path・health・TLS・delivery設計を続けて確認。L4 vs L7 Load Balancing Decision
関連するpacket path・health・TLS・delivery設計を続けて確認。

Official sources

動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。