導入
複数のEC2に負荷を分散させたい。しかし「どのロードバランサーを使うか」は、扱う通信の階層によって変わります。SAAではALB/NLB/GWLBの使い分けが頻出です。
説明
Elastic Load Balancing(ELB) は、複数のターゲット（EC2、コンテナ、Lambdaなど）にトラフィックを自動分散するマネージドサービスです。目的に応じて3種類のロードバランサーがあります。
| 種類 | 階層 | 特徴 | 向いている用途 |
|---|---|---|---|
| ALB（Application Load Balancer） | L7（HTTP/HTTPS） | パスベース・ホストベースのルーティング、WebSocket対応 | Webアプリ、マイクロサービス、コンテナ |
| NLB（Network Load Balancer） | L4（TCP/UDP） | 超低レイテンシー、静的IP/Elastic IPを固定可能 | 高スループットが必要な通信、固定IPが必要な連携 |
| GWLB（Gateway Load Balancer） | L3（IPパケット） | サードパーティのセキュリティアプライアンスへの透過的な振り分け | ファイアウォールやIDS/IPSの一括適用 |
flowchart LR
C["クライアント"] --> ELB["ロードバランサー"]
ELB --> AZ1["EC2 (AZ-a)"]
ELB --> AZ2["EC2 (AZ-b)"]
ELB --> AZ3["EC2 (AZ-c)"]
ELBは複数AZにまたがるターゲットへ振り分けることで、第1章で学んだ「本番＝Multi-AZ」を実現する中心的な部品です。ヘルスチェックに失敗したターゲットは自動的に振り分け対象から外され、正常なターゲットのみにトラフィックが送られます。これがシステムの自己修復力の土台になります。
具体例
3つのシステムが、それぞれ違うロードバランサーを選ぶ理由を見てみましょう。
- マイクロサービスのWebアプリ → ALB …
/api/usersはユーザーサービスへ、/api/ordersは注文サービスへ、とURLのパスで振り分けたい。これはHTTP（L7）の中身を見る必要があるのでALB。 - オンライン対戦ゲームのサーバー → NLB … 求められるのは超低遅延と、ゲームクライアントが接続先に指定する固定IP。HTTPの中身は見ず、TCPを高速にさばければよい。→ 静的IPを持てるNLB。
- 全社の通信をまとめてファイアウォール検査 → GWLB … サードパーティのセキュリティ製品に、全トラフィックを透過的に通したい。→ GWLB。
いずれの場合も、ELBは複数AZのターゲットへ振り分け、ヘルスチェックに失敗したインスタンスを自動で外します。これが「本番＝Multi-AZ」と自己修復の土台。「パスで振り分け＝ALB、低遅延・固定IP＝NLB、セキュリティ製品経由＝GWLB」は、ほぼこの形で出題されます。
読んでみよう
「HTTPでパスごとに振り分けたい」→ALB、「TCPで超低遅延・固定IPが必要」→NLB、「既存のセキュリティアプライアンスを経由させたい」→GWLB、という対応を丸暗記して構いません。この3択はほぼそのままの形で出題されます。