まず結論 要件から決めるのが最短
ロードバランサーは「どれが高性能か」ではなく、「どの層で何を判断したいか」と「どんな通信を通したいか」で決まります。
Elastic Load Balancing の主要な選択肢は、ざっくり次の役割です。
- ALB：HTTP/HTTPS を理解して、パスやホスト名などで賢く振り分ける（レイヤー7）
- NLB：TCP/UDP/TLS などを高速にさばき、固定IPなどネットワーク要件に強い（レイヤー4）
- Gateway Load Balancer：L3で“全IPパケット”を検査アプライアンスへ透過転送する（主にセキュリティ/検査用途）
ここから先は、SAA-C03で問われやすい「設計判断の筋道」を作ることを目的に、要件→決定表で迷いを減らします。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
用語の整理 どこで何を見て振り分けるのか
同じ「負荷分散」でも、見ている情報の層が違うと、できること・できないことが決まります。
ALBはHTTPの世界で賢く振り分ける
ALBはアプリケーション層（レイヤー7）で動作し、HTTP/HTTPSを前提にした機能を持ちます。HTTP/2（HTTPSリスナー）など、HTTPの仕様に沿った機能がポイントです。
「/api はAへ、/images はBへ」「app.example.com は青、admin.example.com は赤」のような、URLやホスト名に基づくルーティングをしたいなら、基本はALBです。
NLBはL4で“中身を見ずに”さばく
NLBはトランスポート層（レイヤー4）で、TCP/UDP/TLS などの接続やパケット転送を得意とします。リスナーとして TCP/TLS/UDP などを扱えます。
L7のようにヘッダーやパスを見て判断することはできないため、HTTPの細かい振り分けは不得意、という整理になります。
また、NLBは有効化したAZごとにネットワークインターフェイスを作り、固定IP（必要ならEIP）を持てる点がネットワーク要件で強みになります。
Gateway Load Balancerは“透過型の検査”のための道具
Gateway Load Balancer はネットワーク層（レイヤー3）で動作し、全IPパケットをターゲット（多くは仮想アプライアンス）へ転送します。通信はGENEVE（ポート6081）でやり取りされ、フローのスティッキーも持ちます。
「WAFの代わり」ではなく、IDS/IPS・FW・DLPのような“検査アプライアンス”をスケールさせ、透過的に挟み込むための選択肢、と覚えると混乱しにくいです。
要件から決める決定表 ここだけ押さえる
この見出しのあと、まず表で当たりをつけて、次に具体例で腹落ちさせます。
早見の決定表
| あなたの要件 | ALB | NLB | Gateway Load Balancer |
|---|---|---|---|
| HTTP/HTTPSで、パスやホスト名で振り分けたい | ◎ | △ | × |
| gRPCやHTTP/2など“HTTPの文脈”で最適化したい | ◎ | △ | × |
| TCP/UDPなど非HTTPを分散したい | △ | ◎ | △ |
| 固定IPが必要、EIPを持たせたい | △ | ◎ | × |
| TLS終端をLB側でやりたい | ◎ | ◎（TLSリスナー） | × |
| アプリ側で終端して“エンドツーエンド暗号化”に寄せたい | △ | ◎（中身を見ない） | △ |
| セキュリティ検査アプライアンスを透過的に挟み込みたい | × | △ | ◎ |
| すべてのIPパケットを対象に扱いたい | × | △ | ◎ |
※「△」は“できなくはないが目的に対して本命ではない”の意味です。試験でも実務でも、ここを無理にこじらせると判断が崩れます。
決め方の手順
- まず 通信がHTTPかどうか を決める（HTTP中心ならALBが基本線）
- 次に 固定IPやL4要件 があるかを見る（必要ならNLBが強い）
- 最後に “検査アプライアンスの透過挿入” という特殊要件があるかを見る（あればGWLB）
具体例で腹落ちさせる ALBがハマるケース
ALBが向くのは「HTTPとして扱うと設計が簡単になる」場面です。
例 マイクロサービスでURLごとに行き先を変えたい
/api/*はAPIサービスへ/admin/*は管理画面へ/はフロントへ
このとき、HTTPリクエストを理解したルーティングができるALBが自然です。ターゲットグループ単位でヘルスチェックを持ち、ルールでどのターゲットグループに流すかを制御する、という設計が基本形になります。
例 ブラウザ向けでHTTP/2を使い、接続効率を上げたい
ALBはHTTPSリスナーでHTTP/2をネイティブサポートします。HTTPの機能を活かしてフロント側の接続効率を高めたいときは、ALBの方向で考えるのが分かりやすいです。
初学者がつまずきやすいポイント
- 「HTTPS＝ALB」と短絡しない
- NLBもTLSリスナーで暗号化/復号のオフロードができます。
- ただし、HTTPのルーティング（パス/ホスト）はALBの領域です。
具体例で腹落ちさせる NLBがハマるケース
NLBは「HTTPの都合を捨ててでも、ネットワーク要件を満たしたい」ケースで選ぶと筋が通ります。
例 固定IPで許可リスト運用したい
外部の接続元（取引先のFWなど）が「接続先IPの固定」を要求することがあります。NLBは有効化したAZごとに固定IPを持ち、必要ならEIPを関連付けられます。
このタイプの要件が出た時点で、ALBよりNLBが検討の中心になります。
例 TCPやUDPのプロトコルをそのまま分散したい
NLBはTCP/UDPなどのL4で扱えるプロトコルをリスナーとして持てます。
ゲーム、IoT、独自プロトコルなど、HTTP前提に寄せない方が自然なワークロードではNLBが第一候補になります。
例 L7でのルーティングが要らない ただ高スループットにさばきたい
NLBはL4で中身を見ないため、HTTPヘッダーやパスでの判断はできません。
逆に言うと「判断しない」分、設計が単純になり、L4要件が明確なときは選定が早いです。
ヘルスチェックとAZの考え方
NLBはターゲットのヘルスチェックを行い、デフォルトでは「そのAZのノードは、そのAZの健全なターゲットへ」ルーティングします。クロスゾーン負荷分散を有効にすると全AZの健全ターゲットへも送れます。
ここは問題文で「クロスゾーンが有効/無効」「AZ障害時の挙動」が匂わせられることがあるので、設計判断として整理しておくと安心です。
具体例で腹落ちさせる Gateway Load Balancerがハマるケース
Gateway Load Balancerは、ALB/NLBと同列の“アプリ公開用LB”だと思うとズレます。用途はかなり限定的です。
例 複数VPCにまたがってトラフィックを検査アプライアンスへ通したい
たとえば、次のような要件です。
- すべての北向き通信を、IDS/IPSや次世代FWで検査したい
- VPCごとに検査装置を置くのではなく、検査用VPCに集約してスケールさせたい
- 透過的に挟み込み、ルーティングを書き換えずに運用したい
GWLBはL3で全IPパケットを扱い、ターゲット（仮想アプライアンス）との間をGENEVE（ポート6081）で中継します。
この「L3」「全IPパケット」「アプライアンス」「GENEVE 6081」がセットで見えたらGWLBの出番です。
GWLBで覚えておくと強い要点
- L3で動作し、全IPパケットを対象にできる
- フローのスティッキーがあり、同じフローを同じアプライアンスへ寄せられる
- 目的は“検査アプライアンスのデプロイとスケールを容易にする”こと
まとめの文章
ALB/NLB/Gateway Load Balancerの選び分けは、「機能の暗記」よりも「要件の層」を見抜くのが近道です。HTTPの世界でパスやホスト名を見て振り分けたいならALB、TCP/UDPや固定IPなどネットワーク要件が前面に出るならNLB、そして“全IPパケットを透過的に検査アプライアンスへ通す”という特殊要件があるならGateway Load Balancer、という整理で迷いが減ります。
SAA-C03では、サービス名を当てるだけでなく、なぜその選択になるのかを言語化できると設計問題でも崩れにくくなります。体系的に復習したい場合は、ELB全体像→ALBとNLBの設計→VPC設計との接続（Route、セキュリティ、可用性）までを一気通貫で学べる教材を一つ持っておくと、理解の穴が埋まりやすいです。
Udemyでも、SAA-C03向けにVPCとELBをまとめて扱う講座が複数あるので、「体系的に学べる教材の一例」として自分の学習スタイルに合うものを選んでみてください。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
