🎯 結論ファースト
ELB（Elastic Load Balancing）は、大量のアクセスを複数のサーバーに均等に振り分ける交通整理役です。主に2種類あり、それぞれ得意分野が異なります。
🔵 ALB（Application Load Balancer）
「リクエストの中身を見て判断する賢い案内係」。URLやヘッダーを読み取り、最適なサーバーへ振り分ける。Web アプリやマイクロサービス向き。
🟢 NLB（Network Load Balancer）
「中身は見ずに超高速で通すスピード配達員」。IPアドレスとポート番号だけで瞬時に転送。ゲームサーバーやリアルタイム通信向き。
📖 そもそもロードバランサーとは？
ロードバランサーは、大勢のお客さんが一度にやってきても、1台のサーバーに負荷が集中しないように「交通整理」する仕組みです。
🍽️ たとえ話：大人気レストランの「案内係」
想像してください。あなたは大人気レストランのオーナーです。毎晩100組のお客さんが来店します。
もしシェフが1人しかいなければ、料理が追いつかずお客さんは何時間も待つことに…。
そこでシェフを5人に増やし、入口に「案内係（ホスト）」を置きます。
案内係は、各シェフの忙しさを見ながら「あなたはA番テーブルへ」「あなたはB番テーブルへ」とお客さんを均等に振り分けます。
これがまさにロードバランサーの仕事です！
🍽️ レストランの案内係 ＝ ロードバランサーの図
(大量のリクエスト)
(ELB)
🔧 AWS での実際の構成イメージ
ユーザー
(ロードバランサー)
🔀 ALB と NLB — 2つの案内係の違い
AWSには主に2種類のロードバランサーがあります。同じ「案内係」でも、案内の仕方がまったく違います。
「パスタ」→ イタリアンシェフへ
「寿司」→ 和食シェフへ
「デザート」→ パティシエへ
リクエストの中身を読んで、最適な場所へ振り分けます。
中身は一切確認せず、とにかく超高速で振り分けます。
1秒間に何百万人ものお客さんが来ても捌けるほどのスピード。
IPアドレスとポート番号だけで瞬時に転送します。
🏗️ 動作するレイヤーの違い（OSI参照モデル）
ALBとNLBは、ネットワーク通信の「どの階層」で動作するかが異なります。これが性能と機能の違いに直結します。
📶 OSI参照モデルでの動作レイヤー
💡 レイヤーの違いをたとえると…
ALB（L7）は、手紙を開封して中身を読んでから配達先を決める郵便局員。「この手紙は請求書だからA課へ」「これはお礼状だからB課へ」と内容で仕分けます。
NLB（L4）は、封筒の宛名（IP）と部署番号（ポート）だけ見て、中身を開けずに超高速で届ける配達員。内容を確認しない分、圧倒的に速いのです。
📋 ALB・NLB 機能の詳細
それぞれのロードバランサーが持つ具体的な機能を見てみましょう。
Application Load Balancer
レイヤー7 ／ HTTP・HTTPS 特化Network Load Balancer
レイヤー4 ／ TCP・UDP 特化🛣️ ALB のコンテンツベースルーティング例
📊 ALB vs NLB 一覧比較
主要な違いをまとめて確認しましょう。
| 比較項目 | 🔵 ALB | 🟢 NLB |
|---|---|---|
| 動作レイヤー | レイヤー7（アプリケーション層） | レイヤー4（トランスポート層） |
| 対応プロトコル | HTTP, HTTPS, WebSocket | TCP, UDP, TLS |
| ルーティング方式 | URL パス・ホスト名・ヘッダーなど | IP アドレス＋ポート番号のみ |
| レイテンシー | ミリ秒〜（中身解析のため） | マイクロ秒〜（超低遅延） |
| スループット | 高い | 極めて高い（毎秒数百万件） |
| 静的IP | ❌ 非対応（DNS名で接続） | ✅ 対応（Elastic IP 割当可） |
| SSL/TLS | 終端（解読してから転送） | パススルー可能（そのまま転送） |
| たとえ | 🧑💼 注文を聞いて案内するコンシェルジュ | ⚡ 番号札だけで通す超速受付 |
🎯 どんな時にどちらを使う？
具体的なユースケースで使い分けを確認しましょう。
🌐 Webアプリケーション
ECサイト、SNS、管理画面など HTTP/HTTPS ベースのWebアプリ。URLパスやドメインで振り分けたい場合に最適。
ALB を選択🎮 ゲームサーバー
オンラインゲームのリアルタイム通信。超低遅延が求められ、UDP通信が必要な場面。
NLB を選択🏗️ マイクロサービス
複数サービスを1つのALBで管理。/users → ユーザーサービス、/orders → 注文サービスなどパスで振り分け。
ALB を選択📡 IoT / リアルタイム通信
大量のIoTデバイスからのTCP/UDP接続。毎秒数百万リクエストを処理する必要がある場面。
NLB を選択🐳 コンテナ / Lambda
ECS、EKS、Lambda などのサーバーレスやコンテナ環境。ALBの柔軟なターゲットタイプが活きる。
ALB を選択🔒 固定IPが必要な場面
ファイアウォールでIP許可リストを設定する場合。DNS名ではなく固定IPでアクセスさせたい場面。
NLB を選択🔀 ALB / NLB 選択フローチャート
振り分けたい？
または TCP/UDP 通信？
🏛️ 典型的な構成パターン
実際の AWS 環境でよく使われる構成パターンを見てみましょう。
🔵 ALB の典型構成 — Webアプリ + マイクロサービス
(HTTPS)
(SSL終端)
ALBがHTTPSを解読 → URLパスを確認 → 適切なターゲットグループへ転送
🟢 NLB の典型構成 — ゲーム / リアルタイム通信
(TCP/UDP)
(静的IP)
NLBが固定IPでリクエスト受付 → IP+ポートだけ見て → 超高速でサーバーへ転送
⚠️ 知っておきたい注意ポイント
💰 コスト感覚
ALBの方がNLBより少し安いことが多いです。ただし、トラフィック量やルール数で変動するため、AWS料金計算ツールで事前に見積もりましょう。
🔗 ALB + NLB の組み合わせ
NLBの背後にALBを配置するパターンもあります。NLBの静的IPとALBの高度なルーティングを両立させる構成です。
🏥 ヘルスチェック
両方ともターゲットの健全性を監視します。異常なサーバーを自動的に除外し、復旧したら再登録。ALBはHTTPレベル、NLBはTCPレベルで確認します。
🌍 クロスゾーン負荷分散
複数のAZ（アベイラビリティゾーン）にまたがって負荷分散できます。ALBはデフォルトで有効、NLBはデフォルトで無効なので設定を確認しましょう。
✅ まとめ
ALB を選ぶとき
HTTP/HTTPSのWebアプリを扱う。URLやヘッダーで賢くルーティングしたい。マイクロサービスやコンテナ環境で使う。
NLB を選ぶとき
超低遅延が必要。TCP/UDPの生の通信を捌きたい。静的IPが必須。毎秒数百万件の超高トラフィックを処理する。