ELB はなぜ 4 種類に分かれているのか - ALB・NLB・GWLB・CLB の設計判断の裏側
ALB、NLB、GWLB、CLB (Classic) の 4 種類のロードバランサーがなぜ統合されずに併存しているのかを、OSI 参照モデルのレイヤー、パフォーマンス特性、歴史的経緯から解説します。
Classic Load Balancer - ELB の原点
2009 年に登場した Elastic Load Balancing (現在の Classic Load Balancer) は、AWS 初のロードバランサーサービスでした。CLB は L4 (TCP) と L7 (HTTP/HTTPS) の両方のトラフィックを処理できる汎用的なロードバランサーとして設計されました。しかし、この「何でもできる」設計が、後に問題を生みます。L4 と L7 のロードバランシングは、技術的に根本的に異なる処理です。L4 はパケットの送信元・送信先 IP アドレスとポート番号だけを見てルーティングします。パケットの中身 (HTTP ヘッダーやボディ) は一切解析しません。L7 は HTTP リクエストの内容 (URL パス、ホストヘッダー、Cookie など) を解析してルーティングします。この 2 つの処理を 1 つのサービスで提供すると、L4 の処理に L7 のオーバーヘッドが影響し、L7 の機能拡張が L4 の安定性に影響するというトレードオフが生じます。CLB はこの制約により、L7 の高度なルーティング (パスベースルーティング、ホストベースルーティング) を実装できませんでした。現在の AWS は CLB を EC2-Classic ネットワーク上に構築されたアプリケーション向けと位置づけ、ALB または NLB への移行を推奨しています。CLB が旧世代であることは、操作 API の系統にも表れています。CLB は初代の Elastic Load Balancing API (バージョン 2012-06-01) で操作し、以降に追加された ALB・NLB・GWLB はターゲットグループを前提とする別系統の API (elasticloadbalancingv2・バージョン 2015-12-01) に属します。
ALB の誕生 - L7 に特化した設計
2016 年に登場した Application Load Balancer (ALB) は、L7 (HTTP/HTTPS) に完全に特化したロードバランサーです。CLB では不可能だったパスベースルーティング (/api/* は API サーバーへ、/static/* は静的ファイルサーバーへ)、ホストベースルーティング (api.example.com と www.example.com を異なるターゲットグループへ)、HTTP ヘッダーや Cookie に基づくルーティングが可能になりました。ALB が L7 に特化したことで実現した重要な機能が、WebSocket のネイティブサポートと HTTP/2 のサポートです。CLB は HTTP/HTTPS リスナーでは WebSocket を扱えず、中身を解析しない TCP リスナーで素通しさせる回避策が必要でした。HTTP/2 もサポートしていません。ALB はさらに、AWS WAF との統合、Cognito 認証の組み込み、Lambda 関数をターゲットとして直接呼び出す機能など、アプリケーション層に密接に関わる機能を次々と追加しています。これらの機能は L7 の HTTP リクエストを解析できるからこそ実現可能であり、L4 のロードバランサーでは原理的に不可能です。L7 を解析できる強みは、新しいプロトコルへの対応にも表れます。ALB のターゲットグループにはプロトコルバージョンという設定があり、既定の HTTP/1.1 のほかに HTTP/2 と gRPC を選べます (2026 年 8 月時点の公式ドキュメント記載)。gRPC を選ぶと、ALB が gRPC リクエストを解析してパッケージ・サービス・メソッド単位で適切なターゲットグループへ振り分け、単方向・クライアントストリーミング・サーバーストリーミング・双方向ストリーミングのすべてを扱えます。ヘルスチェックは /package.service/method の形式でメソッドを指定し、成功と見なす gRPC ステータスコードも自分で決めます。制約として、リスナープロトコルは HTTPS のみ、リスナールールのアクションは forward のみ、ターゲット種別は instance と ip のみで、Lambda 関数はターゲットにできません。ALB の料金は、LCU (Load Balancer Capacity Unit) という独自の単位で計算されます。LCU は新規接続数、アクティブ接続数、処理データ量、ルール評価数の 4 つの指標の最大値で決まります。
NLB の誕生 - L4 の極限性能を追求
2017 年に登場した Network Load Balancer (NLB) は、L4 (TCP/UDP/TLS) に特化し、極限のパフォーマンスを追求したロードバランサーです。NLB は毎秒数百万のリクエストを処理でき、レイテンシも ALB より低く抑えられます。ただし AWS は両者のレイテンシを具体的な数値では公表しておらず、公式の表現は NLB について「超低レイテンシ」という定性的なものにとどまります。カタログ値の比較で選ぶのではなく、自分のワークロードで実測して判断するのが正しい姿勢です。この性能差は、NLB がパケットの中身を一切解析しないことから生まれます。NLB はフロー (送信元 IP + ポート、送信先 IP + ポートの組み合わせ) 単位でルーティングを決定し、以降のパケットは同じターゲットに転送します。HTTP ヘッダーの解析、Cookie の読み取り、URL パスの評価といった処理が一切ないため、通過するまでの処理段数そのものが少なく、オーバーヘッドが小さく済みます。NLB のもう一つの重要な特徴は、静的 IP アドレスのサポートです。ALB は IP アドレスが動的に変わるため、DNS 名でしかアクセスできません。NLB は各 AZ に固定の IP アドレス (Elastic IP を割り当て可能) を持つため、ファイアウォールの IP ホワイトリストに登録できます。金融機関や通信事業者のように、接続先の IP アドレスを固定する必要がある環境では NLB が必須です。加えて NLB はクライアントの送信元 IP をターゲットまで保持できるため、アプリケーション側は転送ヘッダーに頼らずアクセス元を判定できます。
Gateway Load Balancer の追加 - 経路にアプライアンスを挟む 4 番目の選択肢
2020 年に追加された Gateway Load Balancer (GWLB) は、4 番目のロードバランサーです。ALB と NLB が「受け取ったトラフィックの宛先を選ぶ」装置であるのに対し、GWLB は「トラフィックの経路に検査装置を挟む」装置で、目的の方向がそもそも違います。用途は、ファイアウォール、侵入検知・防御システム (IDS/IPS)、ディープパケットインスペクション装置といったサードパーティの仮想アプライアンスを、透過的な単一の入口と出口としてまとめ、需要に応じてスケールさせることです。GWLB は OSI 参照モデルの第 3 層 (ネットワーク層) で動作し、全ポートのすべての IP パケットを待ち受けて、リスナールールで指定したターゲットグループへ転送します。同一フローが同じアプライアンスに届くよう、既定では 5 タプル (ほかに 3 タプル、2 タプル) でフロースティッキネスを維持します。GWLB と登録済みのアプライアンスの間は、GENEVE (RFC 8926) プロトコルのポート 6081 でトラフィックを受け渡します (2026 年 8 月時点の公式ドキュメント記載)。ここでカプセル化が要るのは、アプライアンス側の都合ではなく透過性の要件そのものです。元のパケットを一切書き換えずに運ぶことが透過動作の前提であり、そのままのパケットは送信元・送信先 IP が GWLB やアプライアンスの IP と一致しないため、IP に基づく通常の VPC ルーティングでは GWLB もアプライアンスも迂回されてしまいます。元のパケットを新しい L3 パケットに包む以外に、両者の間を成立させる方法がないのです。さらに GENEVE は TLV (Type-Length-Value) 形式で任意の付帯情報を運べるため、GWLB はエンドポイントの ID やフロー Cookie といった情報をパケットごとに添えられます。これにより、CIDR が重複しうるマルチテナントのアプライアンスでもトラフィックの出自を区別でき、フローの取り違えを避けられます。固定長フィールドしか持たない VXLAN や GRE ではこの要件を満たせなかったことが、GENEVE を選んだ理由として公式に説明されています。配置も専用の形をとります。GWLB は仮想アプライアンスと同じ VPC に置き、アプライアンスをターゲットグループに登録します。VPC 境界をまたぐトラフィックの受け渡しには、AWS PrivateLink による Gateway Load Balancer エンドポイントを使います。利用側の VPC ではルートテーブルでこのエンドポイントを次ホップに指定するため、エンドポイントとアプリケーションサーバーは別のサブネットに作る必要があります。アプリケーション側の設定を変えずに検査を挿入できるのは、この経路設計とカプセル化が揃っているからです。
なぜ 1 つに統合しないのか
「ALB と NLB を 1 つのサービスに統合すればいいのでは」という疑問は自然ですが、統合しない理由は技術的に明確です。L4 と L7 のロードバランシングは、処理のパイプラインが根本的に異なります。L7 はすべてのパケットを受信し、HTTP リクエストとして再構成し、ヘッダーを解析し、ルーティングルールを評価し、必要に応じてヘッダーを書き換えてからターゲットに転送します。この処理はメモリと CPU を消費します。L4 はパケットのヘッダー (IP + TCP/UDP) だけを見て転送先を決定し、パケットの中身には触れません。この 2 つの処理を 1 つのサービスに統合すると、L4 の性能が L7 の処理パイプラインに引きずられて劣化します。GWLB を加えると、統合できない理由はもう 1 段はっきりします。ALB と NLB は自分が接続やリクエストの終端になり、必要に応じてヘッダーやアドレスを書き換える装置です。GWLB は逆に、元のパケットを書き換えないことが仕様上の要件で、そのためにカプセル化とルートテーブル連携を前提としたデータ経路を持ちます。終端する装置と透過する装置を 1 つの製品にまとめれば、設定項目には互いに無意味なものが混ざり、利用者から見て「今どちらの動作をしているのか」が読み取れなくなります。CLB が「何でもできる」設計のまま L7 の高度なルーティングを実装できなかった事実は、この分岐が後付けの都合ではないことを示しています。AWS の設計哲学「目的特化型サービス」は、この種のトレードオフを避けるために、機能を分離して最適化する方針です。4 種類あるという事実は選択肢の乱立ではなく、L7 で終端する、L4 で終端する、L3 で透過的に挟む、そして旧世代の汎用型という 4 つの異なる仕事に、それぞれ最適な実装を割り当てた結果です。
選択の判断基準
4 種類の ELB の選択は、ワークロードの特性で決まります。HTTP/HTTPS のトラフィックを処理し、パスベースやホストベースのルーティングが必要なら ALB です。Web アプリケーション、REST API、マイクロサービスのほとんどは ALB が最適で、gRPC もターゲットグループのプロトコルバージョンでネイティブに扱える ALB が第一候補になります。TCP/UDP のトラフィックを処理し、極限のパフォーマンスや静的 IP が必要なら NLB です。ゲームサーバー、IoT デバイスからの接続、金融取引システムのように、L7 の解析が不要で接続数とレイテンシが支配的なワークロードが向きます。サードパーティのファイアウォールや IDS/IPS、ディープパケットインスペクション装置をトラフィックの経路に挟みたいなら GWLB です。これはロードバランサーを選ぶというより、検査基盤の入口と出口を 1 か所にまとめ、アプライアンス群をスケールさせる設計判断になります。ただし GENEVE 対応のアプライアンスと経路設計が前提になるため、公式ドキュメントで統合要件を確認してから採用を決めます。CLB は新規構築では選びません。AWS は CLB を EC2-Classic ネットワーク (2022 年に廃止) 上のアプリケーション向けと位置づけ、ALB または NLB への移行を推奨しています。移行には公式の移行ウィザードがあり、既存 CLB の設定から同等の ALB または NLB を作成できます。ただしウィザードは新しいロードバランサーを作るだけで既存の CLB を変換するわけではないため、トラフィックの切り替えは自分で行う必要があります。組み合わせるパターンもあります。NLB の背後に ALB を配置すれば、NLB の静的 IP と ALB の L7 ルーティングを両立できます。NLB は AWS PrivateLink のエンドポイントサービスに使えるため、PrivateLink でサービスを公開しつつ L7 ルーティングも必要な場合にこの構成が選ばれます。GWLB は他の 3 つと排他ではなく、ALB や NLB の手前のルーティング経路に挟んで併用するのが基本の使い方です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。