MS_AzureLoadBalancer

Azure Load Balancer

• 戻る（AzureのGW / LB的なモノ。）

概要

サービス名で、以下の 3 層の構成から成る。

詳細

SKU

Basic と Standard の SKU がある。

Basic

Basic IP アドレスに対応

Standard

• Standard IP アドレスに対応
• 可用性セットで利用可能。

移行メモ（正誤・最新化）: 「可用性セットで利用可能」は Basic でも可能であり、
Standard の本来の差分は次のとおり。

	Basic	Standard
バックエンド	単一の可用性セット / VMSS	VNET 内の任意の VM
可用性ゾーン	非対応	対応（ゾーン冗長 / ゾーン指定）
既定のセキュリティ	既定で開放	既定でクローズ（NSG での明示的許可が必要）
SLA	なし	あり
課金	無料	有料

なお Basic SKU は 2025 年 9 月末で提供終了（廃止）とされているため、
新規は Standard を選択すること。
また Basic / Standard の IP アドレス SKU は LB の SKU と一致させる必要がある
（混在できない）点が、移行時の落とし穴になりやすい。

Internal or External

以下の両方に対応

ILB (Internal Load Balancer)

• 内部用
• Web Server → AP Server

ELB (External Load Balancer)

• 外部用（パブリック IP アドレスとセット）
• Internet → Web Server

構成

以下の 3 階層を経てロードバランシングを行う。

ルーター

• L3 でのトラフィック分散
• パケットレベルで分散

ロードバランサ

• L4 でのトラフィック分散
• 本サービスの本体

ホストエージェント（Ananta Manager）

• 適切な VM にトラフィックが届くようにする。
• VM や上のアプリのヘルスチェックもここで行う。

補足: 「Ananta」は Azure のソフトウェア ロードバランサの研究名称
（Microsoft Research の論文 "Ananta: Cloud Scale Load Balancing"）に由来する。
本ページの 3 層モデルはその内部アーキテクチャの説明であり、
利用者が直接触る概念ではない。ただし
**「LB は物理装置ではなく分散ソフトウェアである」**という理解は、
後述の「LB の IP を NSG の宛先に書けない」といった
Azure 固有の挙動を納得するうえで重要である。

LB や NSG は物理的には存在していない。

VFP の中にロジックとして実装されている。

• VM から物理層にパケットが送られる際に
• VFP によってパケット・フィルタ処理が行われ、
• これにより適切なホスト・マシンに転送される（NLB 的）。

補足（実務上の帰結）: この実装のため、
ロードバランサのフロントエンド IP 宛の通信は、
NSG の評価時点では既に「宛先＝バックエンド VM の IP」に書き換わっている。
したがって NSG のルールに
LB のフロントエンド IP を宛先として書いても機能しない。
詳細は Network Security Group (NSG) を参照。

また、同じ理由でバックエンド VM 同士が LB 経由で自分自身を呼ぶ
（ヘアピン / ループバック）構成は既定では動作しない。

参考

Microsoft Learn

• Load Balancer
  https://learn.microsoft.com/ja-jp/azure/load-balancer/

---

Tags: 移行, インフラストラクチャ, クラウド, Azure, 通信技術