ORIVECTOR › AWS Cloud Practitioner › ALB・NLB・GWLB

CLF-C02 + 実務イメージ

ALB・NLB・GWLBの違い
「FWクラスタでよくない？」から理解する

公開日：2026-09-01 ｜更新日：2026-09-03

ALBやGWLBを暗記しようとすると分かりにくいですが、オンプレでよく見る「顧客 → FW → LB → Web → AP」と比較すると役割が見えてきます。

まず結論：ELBは大きなカテゴリ

Elastic Load Balancing（ELB）はAWSの負荷分散サービスの総称です。その中にALB、NLB、GWLBなどがあります。

種類	主なレイヤー	得意な仕事
ALB	L7	HTTP/HTTPSのWebアクセスをアプリへ振り分ける
NLB	L4	TCP/UDP/TLSなどの大量・低遅延な通信を振り分ける
GWLB	L3	Firewall、IDS/IPSなどの仮想ネットワークアプライアンスへ通信を振り分ける

大事なのは「どれが一番強いか」ではなく、何に通信を振り分けたいのかです。

ALBはWebシステムの受付係

ユーザー ↓ HTTP/HTTPS ALB ↙ ↓ ↘ Web1 Web2 Web3 ↓ AP ↓ DB

ALBはL7でHTTP/HTTPSを理解し、ホスト名やURLパスなどの条件でターゲットグループへルーティングできます。Webアプリの入口で「このリクエストをどのサーバーに処理させるか」を決める役です。

NLBは高速なL4交通整理

NLBはL4でTCP、UDP、TLSなどを扱います。HTTPのURLを見て細かく振り分けるALBとは違い、ネットワーク接続を高速にさばく用途が中心です。

試験の基本： ALB＝L7・HTTP/HTTPS、NLB＝L4・TCP/UDP/TLS。

ではGWLBは何を振り分ける？

GWLBのターゲットは、普通のWebサーバーではなくFirewall、IDS/IPS、DPIなどの仮想ネットワークアプライアンスです。

┌→ 仮想FW-A 通信 → GWLB ────┼→ 仮想FW-B ├→ 仮想FW-C └→ 仮想FW-D ↓ 本来のシステム

つまりGWLB自身がFirewallなのではありません。Firewall群などへ通信を振り分ける側です。GWLBはIPパケットを受け、登録された仮想アプライアンスへフローを振り分けます。

「FWを稼働待機クラスタにすればよくない？」

ここが一番重要です。従来のオンプレ構成に慣れていると、この疑問が自然に出てきます。

従来のActive / Standby

通信 → FW-A【Active】 → LB → Web FW-B【Standby】

FW-Aが通常の通信を処理し、障害時にFW-Bへ切り替える方式です。可用性を確保するという目的なら、これで要件を満たすケースは当然あります。

GWLB + 複数の仮想FW

┌→ FW-A ├→ FW-B 通信 → GWLB ─┼→ FW-C └→ FW-D

GWLBでは複数の仮想アプライアンスをターゲットとして登録し、正常なターゲットへトラフィックを振り分けられます。ターゲットの追加・削除もしやすく、仮想FW群を水平に扱いやすくなります。

FWクラスタとGWLBを比較

	Active/Standby FW	GWLB + 仮想FW群
考え方	障害時に交代	複数アプライアンスへフローを分散
待機機	待機する構成が一般的	複数ターゲットを処理に利用可能
拡張	製品のHA方式に依存	ターゲットを追加・削除しやすい
ヘルスチェック	FW製品側のHA等	GWLBターゲットグループで実施
向く場面	従来型HAで要件を満たせる	AWS上で仮想アプライアンス群を分散・拡張したい

腹落ちポイント： Active/Standbyでも構成できる。ただGWLBを使えば、複数の仮想FWを「ただの予備機」にせず、処理ターゲットとして活用しながら可用性とスケールを設計しやすい。

なぜALBでFWへ振り分けないの？

ALBはHTTP/HTTPSリクエストをアプリケーションのターゲットへ届けるL7ロードバランサーです。一方、FWは通信の最終目的地ではなく「本来の宛先へ向かう途中で検査する装置」です。仮想FWなどを透過的にサービスチェーンへ組み込み、そこへIPフローを振り分ける用途にGWLBが用意されています。

ALB：ユーザー → ALB → Web / AP ↑ アプリを振り分ける GWLB：通信 → GWLB → 仮想FW群 → 本来の宛先 ↑ 検査装置を振り分ける

GWLBの少し深い話

GWLBはOSI参照モデルのL3で動作し、仮想アプライアンスとの通信にはGENEVE（UDP 6081）を使用します。また、同じ通信フローを特定のアプライアンスへ維持する仕組みがあります。Stateful Firewallでは同じセッションの通信を適切に扱う必要があるため、この「フロー単位」の考え方が重要です。

ただしCLF-C02学習ではGENEVEの細部まで暗記するより、GWLB＝Firewallなどの仮想ネットワークアプライアンス向けという役割を押さえる方が優先です。

オンプレ経験者向けの覚え方

【見慣れた構成】顧客 → FWクラスタ → LB → Web → AP → DB 【AWSで役割を分けて考える】 ALB ：Web/APへのHTTP(S)振り分け NLB ：L4通信の振り分け GWLB ：仮想FW/IDS/IPSなどへの振り分け

「ロードバランサーはFWの後ろでWebを振り分けるもの」という経験があるほどGWLBは違和感が出やすいですが、GWLBはWeb用LBの上位版ではなく、ネットワークアプライアンスを扱う別用途のLBと考えると整理できます。

試験前の最終整理

ALB： L7。HTTP/HTTPS。Webアプリの振り分け。
NLB： L4。TCP/UDP/TLS。高速なネットワーク通信。
GWLB： L3。Firewall・IDS/IPSなどの仮想アプライアンス群へ通信を振り分ける。

そしてGWLBについては「FWそのものではない」「Active/Standbyを否定するものでもない」の2点を押さえておけば、かなり理解しやすくなります。