Cloud Service
ロードバランサ
Azure のロードバランサの使い分け早見。L4 は Load Balancer、L7 は Application Gateway、グローバル配信＋エッジ WAF は Front Door、DNS ベースの広域振り分けは Traffic Manager。
ひと目で使い分け
Azure はロードバランサが「L4 / L7 / グローバル / DNS」で別サービスに分かれています。まず**スコープ（リージョン内かグローバルか）とレイヤ（L4 か L7 か）**で当たりをつけます。
| やりたいこと | 選ぶもの |
|---|---|
| TCP/UDP を超低遅延で分散（リージョン内・L4） | Azure Load Balancer |
| HTTP/HTTPS を URL/ホストで振り分け（リージョン内・L7） | Application Gateway |
| L7 で Web 攻撃も防ぎたい（WAF 統合） | Application Gateway WAF_v2 |
| 世界中へキャッシュ配信＋グローバル L7＋エッジ WAF | Azure Front Door |
| DNS レベルでリージョン間を振り分け／フェイルオーバー | Traffic Manager |
詳細比較（L4 と L7）
リージョン内の主役は Load Balancer（L4） と Application Gateway（L7） です。Load Balancer は SDN 上のパススルー型、Application Gateway はフルリバースプロキシという根本的な違いがあります。
| 観点 | Azure Load Balancer | Application Gateway |
|---|---|---|
| レイヤ | L4 (TCP/UDP) | L7 (HTTP/HTTPS) |
| 方式 | パススルー（フローを直接転送） | リバースプロキシ（中身を解釈） |
| ルーティング | 5タプル等でハッシュ振り分け | URL パス/ホスト/ヘッダ/クエリ |
| レイテンシ | 極小（超低遅延・高スループット） | プロキシ分のオーバーヘッドあり |
| TLS 終端 | 不可（L4 パススルー） | 可（証明書は Key Vault 連携） |
| WAF | 不可 | 可（WAF_v2 で OWASP/Bot 対策） |
| セッション維持 | セッション永続化（ソース IP 等） | Cookie ベースのアフィニティ |
| スコープ／配置 | リージョン内・専用サブネット不要 | リージョン内・専用サブネットが必要 |
グローバル分散の比較（Front Door と Traffic Manager）
複数リージョンをまたぐ広域分散は、L7 プロキシ型の Front Door か、DNS 応答を切り替える Traffic Manager の二択です。
| 観点 | Azure Front Door | Traffic Manager |
|---|---|---|
| 動作レイヤ | L7（リバースプロキシ／エッジ） | DNS（応答する宛先を変える） |
| クライアント接続先 | 最寄り POP に終端→バックボーン経由 | 返ってきた IP へ直接接続 |
| キャッシュ/CDN | あり（エッジキャッシュ） | なし |
| TLS 終端 / WAF | 可（エッジで終端・WAF 統合） | 不可（DNS のみ） |
| 振り分け単位 | パス/ルート・優先度/重み | Priority/Performance/Weighted/Geographic ほか |
| フェイルオーバー速度 | 速い（プローブ→即経路切替） | TTL に依存（キャッシュ分の遅延） |
| 非 HTTP プロトコル | 原則 HTTP/HTTPS 向け | HTTP/HTTPS/TCP 何でも（IP/CNAME を返すだけ） |
選び方
- VM/VMSS の TCP・UDP を低遅延で分散、内部 LB、非 HTTP プロトコル → Azure Load Balancer（Standard）
- Web/API を URL・ホストで振り分け、TLS 終端、リージョン内 L7 → Application Gateway（v2）
- L7 ＋ SQLi/XSS など Web 攻撃の防御も一体で → Application Gateway WAF_v2
- 世界中のユーザーへ高速配信＋グローバル L7 ＋エッジ WAF → Azure Front Door
- DNS レベルでリージョン間フェイルオーバー／最寄り誘導（プロキシ不要） → Traffic Manager
- API の認証・流量制限・変換まで欲しい（LB ではなく API ゲートウェイ） → API Management
1 つに絞る必要はありません。インターネット → Front Door（グローバル L7/CDN/WAF）→ Application Gateway（リージョン内 L7）→ 内部 Load Balancer（L4）→ アプリ層のように重ねるのが大規模構成の王道。グローバル振り分けだけ DNS で済むなら、前段を Traffic Manager に置き換える手もあります。
TCP/UDP・超低遅延・非 HTTP ＝ Load Balancer（L4）、URL/ホストルーティング・TLS 終端・WAF ＝ Application Gateway（L7）。HTTP の中身でルーティングしたいのに L4 の Load Balancer を選ぶ、あるいは単なる TCP 分散に L7 プロキシを使ってオーバーヘッドを背負う、というミスマッチが頻出です。
- Standard Load Balancer は既定でクローズ。NSG で明示的に許可しないとトラフィックは通らない（Basic は既定オープンという挙動差）
- Load Balancer に WAF は付けられない。Web 攻撃防御は Application Gateway WAF_v2 か Front Door の WAF
- Traffic Manager は L7 プロキシではなく DNS ベース。フェイルオーバーの体感速度は TTL に左右される
- apex（
example.com）に Traffic Manager/Front Door を向けるなら、CNAME 不可のため Azure DNS のエイリアスレコードを使う - L4 は SNAT ポート枯渇が定番トラブル。送信規則の明示割り当てか NAT Gateway へ逃がして解消
Front Door や Application Gateway の WAF を入れても、オリジン（App Service / VM / Storage）が公衆インターネットに直接公開されたままでは、攻撃者は前段を迂回してオリジンを直撃できます。Private Link や X-Azure-FDID ヘッダ検証 / サービスタグ（AzureFrontDoor.Backend）/ NSG でオリジンへの直接アクセスを必ず塞いでください。
関連: Azure Load Balancer / Application Gateway / Azure Front Door / CDN / Azure DNS / Traffic Manager / API Management
Azure Service
ロードバランサを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: Azure / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Azure
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。