AWS

ALBとELBの違いとは?AWSロードバランサーの種類・使い分け・リスナールール設定を解説

AWSで「ALBとELBは何が違うのか」と迷うのは、ELBが特定のロードバランサーの名前だと誤解しやすいためです。実際にはELBはロードバランシングサービスの総称で、ALBはその中の一種類にすぎません。この記事では、ELBとALBの関係、4種類のロードバランサー(ALB・NLB・GWLB・CLB)の違いと使い分け、そしてALBを実際に動かすリスナールールの条件・優先度・上限までを、AWS公式ドキュメントの現行仕様に沿って解説します。

まとめ:ELBは総称、ALBはその一種類

先に結論を整理します。

  • ELB(Elastic Load Balancing)はAWSのロードバランシングサービスの総称で、ALB・NLB・GWLB・CLBの4種類を含みます。「ELBという単体のロードバランサー」は存在しません。
  • 会話で単に「ELB」と言うとき、文脈によっては最初期のCLB(Classic Load Balancer)を指すことがあります。CLBは2009年当時、種類が1つしかなく単に「ELB」と呼ばれていた名残です。
  • HTTP/HTTPSのアプリケーションを扱うならALBが標準の選択肢です。URLパスやホスト名で振り分けられるのはL7を解釈するALBだけです。
  • ALBの中身はリスナー → ルール → ターゲットグループという構造で、ルールは既定100個まで(緩和可)。2025年10月からは正規表現による条件指定とURL・ホストヘッダーの書き換えにも対応しました。

以降で、それぞれの違いと具体的な設定を順に見ていきます。

ELB(Elastic Load Balancing)とは?ALBとの関係

ELBは4種類のロードバランサーの総称

ELBはAWSのマネージドなロードバランシングサービスの名称で、受信したトラフィックを複数のターゲット(EC2インスタンス、コンテナ、IPアドレスなど)へ分散します。ELBという一つの製品があるのではなく、用途の異なる4種類のロードバランサーがELBという括りの中に用意されています。ALB(Application Load Balancer)は、そのうちHTTP/HTTPSアプリケーション向けの種類です。したがって「ALBとELBの違い」という問いは、正確には「ALBと、ELBに含まれる他の種類(特にCLB)との違い」を指しています。

「ELB」がCLBを指す理由とALBとの違い

2009年にAWSが最初に提供したロードバランサーは、種類が1つしかなかったため単に「ELB(Elastic Load Balancing)」と呼ばれていました。これが後にClassic Load Balancer(CLB)と改称された、現在のCLBです。その後ALBやNLBが追加され、ELBは複数種類を束ねるサービス名として定着しました。この経緯から、古い資料や現場では「ELB=旧来のCLB」という意味で使われることが今も残っています。ALBとCLBの主な違いは、ALBがURLパスやHTTPヘッダーといったL7(アプリケーション層)の情報でリクエストを振り分けられるのに対し、CLBはそうした高度なコンテンツルーティングを持たない旧世代である点です。新規構築でCLBを選ぶ理由はほとんどなく、AWSもALBまたはNLBへの移行を推奨しています。

ELBの4種類(ALB・NLB・GWLB・CLB)の違いと使い分け

4種類は動作するOSI階層と扱えるプロトコルが異なり、そこから用途が決まります。新規で構築するなら、HTTPアプリケーションはALB、TCP/UDPの低遅延通信はNLBが基本です。CLBは既存環境の維持以外で選ぶ場面はありません。

種類 階層 主なプロトコル ルーティングの特徴 静的IP 主な用途
ALB L7 HTTP / HTTPS / gRPC パス・ホスト・ヘッダーで振り分け 非対応 Web・API・マイクロサービス
NLB L4 TCP / UDP / TLS 超低遅延・送信元IP保持 対応(Elastic IP) 低遅延通信・ゲーム・IoT
GWLB L3 IP(GENEVE) 仮想アプライアンスへ透過的に転送 非対応 ファイアウォール・IDS/IPS
CLB L4 / L7 TCP / SSL / HTTP / HTTPS 旧世代の基本的な分散 非対応 既存環境の維持(新規非推奨)

ALB:HTTP/HTTPSのコンテンツルーティング向け

ALBはHTTP/HTTPSを解釈するL7ロードバランサーで、2016年に登場しました。URLパス(/api/*)やホスト名、HTTPヘッダー、クエリ文字列といったリクエストの中身を見て振り分けられるのはALBだけです。WebSocketやHTTP/2、gRPCにも対応し、AWS WAFの適用やCognito・OIDCによる認証もリスナー側で構成できます。1つのドメインの下でパスごとに別サービスへルーティングする、といったマイクロサービス構成の入口として使うのが典型です。ここまでのL7機能が要るならALBを選びます。

NLB:TCP/UDPの超低遅延・静的IP向け

NLBはL4で動作し、TCP・UDP・TLSをそのまま高速に転送します。毎秒数百万規模のリクエストを、極めて低いレイテンシで処理できるのが特徴です。ALBにはない静的IP(Elastic IPの割り当て)を持てるため、ファイアウォールでIP許可リストを組む必要がある場合や、HTTP以外のプロトコルをそのまま通したい場合はNLBを選びます。送信元IPをターゲットまで保持できる点も、L4ならではの利点です。

GWLB:セキュリティ機器の透過挿入向け

GWLB(Gateway Load Balancer)はL3のIPパケットを扱い、サードパーティのファイアウォールやIDS/IPSといった仮想アプライアンスを通信経路へ透過的に挿入するための専用ロードバランサーです。GENEVEプロトコルでトラフィックを検査機器へ渡すため、経路上に自前でルーティングを組み直す必要がありません。一般的なWeb/APIの負荷分散が目的なら不要で、ネットワークセキュリティの検査基盤を構築するときに使います。

CLB:レガシー、新規では選ばない

CLBはL4とL7の基本的な分散を行う最初期のロードバランサーで、VPC内では現在も利用できます。ただしALB/NLBが持つパスベースルーティングやコンテナ連携などの機能を欠くため、AWSは移行を推奨しています。既存環境をそのまま維持する場合を除き、新規設計での採用は避けるのが妥当です。

ALBの構成要素(リスナー・ルール・ターゲットグループ)

ALBを設定するうえでは、リクエストが「リスナー → ルール → ターゲットグループ」の順に流れる構造を押さえると理解が早くなります。

リスナー:受信プロトコルとポート

リスナーは、指定したプロトコルとポートで接続要求を待ち受けるプロセスです。ALBのリスナーはHTTPまたはHTTPSに対応し、ポートは1〜65535の範囲で指定します。ALBを使い始めるには少なくとも1つのリスナーが必要で、リスナーが1つも無いとクライアントからのトラフィックを受け取れません。HTTPSリスナーではSSL証明書をロードバランサー側に配置し、暗号化・復号の処理をALBにオフロードできます。各リスナーには必ずデフォルトアクション(デフォルトルール)があり、どのルールの条件にも一致しなかったリクエストはこのアクションで処理されます。

ルールとターゲットグループの関係

リスナーが受け取ったリクエストは、リスナールールによって行き先が決まります。各ルールは「条件(コンディション)」と「アクション」の組で構成され、条件に一致したリクエストをforward(ターゲットグループへ転送)・redirect(リダイレクト)・fixed-response(固定レスポンス返却)のいずれかで処理します。転送先となるターゲットグループは、実際のターゲット(EC2、コンテナ、Lambda、IPアドレス)をまとめた単位で、ヘルスチェックもここで設定します。ALBはコンテナサービスと組み合わせる構成が多く、たとえばAWS ECSとは?コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】で解説するECSサービスの前段にALBを置き、パスごとに異なるコンテナへ振り分けます。

ALBリスナールールの設定(条件・優先度・上限)

条件(コンディション)の6種類

リスナールールの条件は次の6種類です。ホスト名・パス・HTTPヘッダーはワイルドカード(*は0文字以上、?は任意の1文字)または正規表現でマッチでき、HTTPメソッドは完全一致、送信元IPはCIDRで指定します。1つのルールでは、host-header・http-request-method・path-pattern・source-ipを各1つまで、http-headerとquery-stringを複数まで組み合わせられます。

条件タイプ 振り分けの基準 マッチ方式
host-header ホスト名(ドメイン) ワイルドカード / 正規表現
path-pattern URLのパス ワイルドカード / 正規表現
http-header 任意のHTTPヘッダー値 ワイルドカード / 正規表現
http-request-method HTTPメソッド(GET等) 完全一致
query-string クエリ文字列のキー/値 ワイルドカード
source-ip 送信元IPアドレス CIDR指定

host-headerとpath-patternの値はいずれも最大128文字です。path-patternはURIの正規化後に、パス部分(クエリ文字列は除く)に対して大文字小文字を区別して評価されます。source-ipはプロキシ経由の場合プロキシのIPになり、X-Forwarded-Forの値では判定されない点に注意してください(クライアントIPで振り分けたいときはhttp-header条件でX-Forwarded-Forを見ます)。

優先度と評価順序

ルールには1〜50000の整数で優先度を付けます。ALBは優先度の小さいルールから順にリクエストを評価し、最初に条件へ一致したルールのアクションを実行します。デフォルトルールは優先度を変更できず、常に最後に評価されます。したがって、より限定的な条件(例:/api/admin/*)を、包括的な条件(例:/api/*)より小さい優先度に置かないと、意図した限定ルールに到達しません。運用中は優先度に間隔を空けて採番しておくと、後からルールを差し込みやすくなります。

ルールの上限とクォータ

ALBのリスナールール関連には次のクォータがあります。ルール数は既定100個で、Service Quotasから緩和申請できますが、比較文字列やワイルドカードの数は緩和できません。ルールが増えるほど評価コスト(後述のLCU)も上がるため、無制限に増やす前にホスト名やパスの設計で条件をまとめることを検討します。

項目 既定値 緩和
ルール数 / ALB(デフォルト除く) 100
比較文字列 / ルール 5 不可
ワイルドカード / ルール 6 不可
評価数 / ルール 5 不可
リスナー / ALB 50
ターゲットグループ / ALB 100 不可
ターゲット / ALB 1,000

ここで「比較文字列 / ルール」はAWS公式の Condition Values per Rule(1ルール内で指定できる値の合計)、「評価数 / ルール」は Match evaluations per rule(1リクエストで照合される文字列の数)を指します。いずれも1条件あたりは最大3、1ルールあたりは最大5です。

正規表現とURL・ホストヘッダー書き換え(2025年10月対応)

従来、ALBのリスナールール条件はワイルドカード(*?)でしか文字列を照合できず、正規表現は使えませんでした。この制約は2025年10月のアップデートで解消され、host-header・http-header・path-patternの各条件で正規表現によるマッチが使えるようになりました。あわせて、リクエストを転送する前に書き換えるtransforms(URL書き換え・ホストヘッダー書き換え)も一般提供されています。

transformsは条件とアクションの間に位置し、正規表現でパスやホストヘッダーを照合して置換文字列に書き換えます。たとえば/api/v1/users/usersへ書き換えてパスのプレフィックスを取り除く、といった処理を、これまで必要だったNGINXなどのプロキシ層なしにALB単体で実現できます。ただし正規表現には制限があり、先読み(lookahead)・後読み(lookbehind)・後方参照(backreference)・atomic group・所有量指定子・サブルーチン・再帰・Unicode文字クラス(\p{L}など)は使えません。複雑な変換を組む際は、この非対応機能に注意して設計します。

よくある質問

ELBとは何ですか?

ELB(Elastic Load Balancing)はAWSのロードバランシングサービスの総称です。ALB・NLB・GWLB・CLBという4種類のロードバランサーを含み、受信トラフィックを複数のターゲットへ分散します。「ELB」という単体の製品があるわけではありません。

ALBとはどういう意味ですか?

ALBはApplication Load Balancerの略で、ELBに含まれる種類のうちHTTP/HTTPS向けのL7ロードバランサーです。URLパスやホスト名、HTTPヘッダーといったリクエストの中身を見てターゲットを振り分けられるのが特徴で、Webアプリケーションやマイクロサービスの入口として使われます。

ALBとNLBはどう使い分けますか?

HTTP/HTTPSのアプリケーションで、パスやヘッダーによる振り分け・認証・WAF連携が必要ならALBを選びます。TCP/UDPをそのまま低遅延で通したい、静的IP(Elastic IP)が要る、HTTP以外のプロトコルを扱う、といった要件があればNLBを選びます。迷った場合、一般的なWebシステムではALBが基本です。

ALBの料金はなぜ高いのですか?

ALBの料金は「時間あたりの基本料金」と「LCU(ロードバランサーキャパシティユニット)」の合算で決まります。LCUは新規接続数・アクティブ接続数・処理バイト数・ルール評価数の4指標のうち最も大きいものに応じて課金されるため、リクエストが多い、あるいはルールが複雑で評価数が多い構成ほどLCUが増え、結果的に高く感じられます。ルールを整理して評価数を抑えることがコスト最適化につながります。

ALBのリスナールールはいくつまで作れますか?

デフォルトルールを除いて1つのALBあたり100個までが既定の上限で、Service Quotasから緩和申請できます。ただし1ルールあたりの比較文字列(5個)やワイルドカード(6個)は緩和できないため、上限に近づいたら条件のまとめ方や、正規表現条件・transformsによる集約を検討します。

関連記事

資料請求

RELATED POSTS 関連記事