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

Load Balancer Outbound Rules

Standard public Load Balancer outbound rulesを、SNAT port allocation、explicit egress、NAT Gateway優先順位、idle timeoutまで整理する。

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

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

Outbound ruleはpublic Standard Load Balancer frontend IPを使ってbackend poolのoutbound SNATを明示定義する機能。 現在のMicrosoft guidanceではproduction-grade outboundの第一選択はNAT Gateway。LB outbound ruleは利用可能だが大規模SNATには第一候補ではない。

NAT Gatewayをsubnetへ関連付けるとLB outbound rule等よりoutbound precedenceが高く、新規flowはNAT Gatewayを使う。 outbound ruleはTCP/UDPを扱い、1 frontend IPあたり利用可能ephemeral port上限は64,000。SNAT port exhaustionをcapacityとして設計する。

inbound load-balancing ruleのautomatic outbound SNATをoutbound ruleで制御する場合、disableOutboundSnatを明示する。 internal Standard Load Balancer単体はInternet egressを自動提供しない。NAT Gatewayや別public LB outbound等のexplicit egressが必要。

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

Control plane / Data plane / Observability

Inbound

VIP→backendのload-balancing rule。

Outbound

backend→InternetのSNAT。inbound successとは独立。

Preferred egress

大規模/新規productionはNAT Gatewayを先に比較する。

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

Client-to-backend path

  1. backend VMがInternet destinationへnew outbound flowを開始する。
  2. Azureがsubnet/NICのexplicit outbound method precedenceを評価する。
  3. NAT Gatewayがあれば通常それが優先される。なければLB outbound rule等を評価する。
  4. LB outbound ruleではfrontend public IPとallocated SNAT portへsourceを変換する。
  5. Internet responseをstateful mappingでbackend private IP/portへ戻す。
  6. idle timeout/port reuse/flow volumeによりSNAT capacityが消費・解放される。

仕組みを分解する

LBがinboundで正常だからegressも正常、という推論は成立しません。outboundではSNAT port allocationとexplicit outbound methodが中心です。connection timeoutが増えた場合はDNSやNSGだけでなく、SNAT port usage、destinationごとのconnection churn、idle timeout、NAT Gateway有無を確認します。

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

設計判断

判断軸設計方針
新規productionNAT Gatewayを基準点にする。LB outbound ruleを選ぶなら理由とSNAT capacityを記録する。
Public IP allowlist固定egress IPが必要ならNAT Gateway public IP/prefixまたはLB frontendを明示し、変更手順を管理する。
SNAT portsbackend最大台数と同時connection数からports per instanceを設計し、scale-out時の取り分を確認する。
Idle timeout長時間connectionはkeepalive/retry behaviorと合わせる。

確認手順

Read-only verification

  • backend subnetにNAT Gatewayが付いていないか最初に確認する。
  • LB outbound ruleのfrontend/backend pool/protocol/idle timeout/port allocationを確認する。
  • backendから外部echo service等へ接続し、実際のsource public IPを記録する。
  • SNAT関連metrics/logとapplication timeout率を同時間帯で相関する。

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 outbound-rule list -g <rg> --lb-name <lb> -o jsonc
az network nat gateway list -g <rg> -o table
az network vnet subnet show -g <rg> --vnet-name <vnet> -n <subnet> --query "{nat:natGateway.id,defaultOutbound:defaultOutboundAccess}" -o jsonc
PowerShell — read-only first
(Get-AzLoadBalancer -ResourceGroupName <rg> -Name <lb>).OutboundRules | Format-List *
Get-AzNatGateway -ResourceGroupName <rg>

障害切り分け

症状第一候補証拠次の確認
Internetへ出られないexplicit egressなしsubnet/NIC outbound configNAT Gateway等を確認
断続timeoutSNAT port exhaustionSNAT metrics/connection countNAT Gateway/port allocation見直し
想定外public IPmethod precedenceNAT Gateway/ILPIP/LB ruleactual egress IP照合
outbound rule作成失敗automatic SNAT競合disableOutboundSnatinbound rule設定確認
一部protocolのみ失敗protocol設定outbound rule protocolAll/TCP/UDPを要件確認

変更時の確認と rollback

  • egress public IP/prefixとallowlist影響を記録してから変更する。
  • NAT Gateway追加時は既存flowが旧pathを継続し、新規flowが新pathになる点を踏まえて検証する。
  • port allocation変更前後のconnection数/timeout率を保存する。
  • rollbackはsource public IPとnew outbound flowの両方で確認する。
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

2026年のMicrosoft guidanceはNAT Gatewayをoutbound connectivityの推奨方式として最上位に置いている。2026-03-31以降、新規VNetはprivate subnet既定でdefault outbound accessを前提にしない。

Nat Gateway
関連するpacket path・health・TLS・delivery設計を続けて確認。Private Subnet Outbound
関連するpacket path・health・TLS・delivery設計を続けて確認。Azure Load Balancer
関連するpacket path・health・TLS・delivery設計を続けて確認。Azure Load Balancer Health Probes
関連する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を再確認してください。