NLBとALBの違い｜ELBとは・4種類の選び方をL4/L7の実演で比較

ロードバランサーは、届いたリクエストを後ろの複数のサーバー（ターゲット）に配る「受付」です。AWS では、受付が各アベイラビリティーゾーン（AZ）にノードとして置かれ、DNS 名でまとめて公開されます。図の TG はターゲットグループ（送り先の集まり）です。

flowchart TD
    C[クライアント] --> D[DNS 名で解決]
    D --> L[ELB のノード<br>AZ ごと]
    L --> R{リスナーと<br>ルール}
    R -->|/api/*| T1[TG api]
    R -->|それ以外| T2[TG web]
    T1 --> H[正常な<br>ターゲットへ]
    T2 --> H

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（Python 3.13.18）の上で、作業場所の venv に moto 5.2.5（moto_server）・boto3 1.43.122・AWS CLI 1.46.2・pytest 9.2.0 を入れ、認証情報はダミーの値（testing）だけを使って、127.0.0.1 の moto_server に向けて ALB・NLB・ターゲットグループ・リスナー・ルールを作りました。AWS には一切接続していません。L7 と L4 の違いは、apt-get download で取った nginx 1.24.0（Ubuntu）の .deb を作業場所に展開して 127.0.0.1 で起動したものと、Python の asyncio で書いた最小の TCP 転送（L4）を並べ、curl 8.5.0・OpenBSD netcat・OpenSSL 3.0.13 で確かめています。AWS 上の挙動（既定値・料金・エラーの原因・制限）は、AWS の公式ドキュメント・AWS CLI リファレンス・料金ページで確かめた範囲だけを書きました。料金は米国東部（バージニア北部）の値です。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

ELBとは（ロードバランサーの役割とAWSでの位置づけ）

この節では、ロードバランサーとは何をするものか、AWS の ELB がどういう仕組みで動いているかが分かります。

ロードバランサー（負荷分散装置）は、外から来た通信を複数のサーバーに配り、壊れたサーバーには配らないようにする仕組みです。サーバー1台だと、アクセスが集中したときに遅くなり、そのサーバーが止まるとサービス全体が止まります。ロードバランサーを前に置くと、サーバーを増やして処理を分け合え、1台が止まっても残りで受け続けられます。

ELB（Elastic Load Balancing）は、AWS が運用するロードバランサーのサービス名です。機器を買って置く必要はなく、通信量に合わせて AWS 側で能力が増減します。公式ドキュメントは、ELB の動き方を次のように説明しています。

• AZ を有効にすると、その AZ にロードバランサーのノードが作られる。有効にしていない AZ に登録したターゲットには通信が来ない。
• クライアントは、ロードバランサーの DNS 名を引き、返ってきたノードの IP アドレスのどれかに送る。DNS の TTL は60秒。
• 受け取ったノードが、正常なターゲットを1つ選んで、プライベート IP アドレスで送る。
• ALB は少なくとも2つの AZ を有効にする必要がある。

サーバーを増やす「スケールアウト」と、ロードバランサーの振り分け方式（ラウンドロビン・最小接続など）の一般的な話は、関連記事「スケールアップとスケールアウトの違い｜負荷分散方式の一覧と選び方」で扱っています。この記事は AWS の ELB に絞ります。

「ELB」という言葉の2つの使われ方

ELB は2009年に1種類だけで始まり、のちに ALB・NLB が加わったため、最初の1種類は「Classic Load Balancer（CLB）」と呼ばれるようになりました。そのため、以前の資料で「ELB」と書かれているものは CLB を指していることがあります。今の AWS の用語では、ELB は4種類をまとめた名前です。AWS CLI でも、ALB・NLB・GWLB は aws elbv2、CLB は aws elb と、コマンドが分かれています。

ELBの4種類（ALB・NLB・GWLB・CLB）の違い一覧

この節では、ELB の4種類がそれぞれ何を担当するのかが、一覧表で分かります。

4種類の違いは、「通信のどの層を見て振り分けるか」です。ALB は HTTP の中身まで読む L7、NLB は TCP・UDP の接続（フロー）単位で振り分ける L4、GWLB はファイアウォールなどの仮想アプライアンスを経路に挟む L3、CLB は L4 と L7 の両方を扱う前の世代です。次の表は、AWS 公式の機能比較表から主な行を抜き出したものです。

CLB のターゲットの欄は公式の比較表では「-」で、CLB は EC2 インスタンスを登録して使います。NLB のセキュリティグループについて、公式ドキュメントは「セキュリティグループを付けずに作った NLB には、あとから付けられない」と書いています（後の節で、moto ではこの制限が再現されなかったことも示します）。

ALBとNLBの違い（L7とL4）を手元で実演して比べる

この節では、ALB と NLB の違いの芯である「L7 と L4 の違い」が、実際の出力で分かります。

L7 のロードバランサーは HTTP のリクエストを1件ずつ読んでから送り先を決め、L4 のロードバランサーは TCP の接続を1本ずつ送り先に結ぶだけで、中身は読みません。AWS には接続しないため、ALB の代わりに nginx（L7 の振り分け）、NLB の代わりに Python で書いた最小の TCP 転送（L4）を 127.0.0.1 で動かし、同じ2台の Web サーバー（web-a・web-b）と API サーバーを後ろに置きました。AWS の ALB・NLB そのものの性能や挙動を測ったものではありませんが、層の違いで何が変わるかははっきり見えます。

L4 の転送は、接続を受けたら順番にターゲットを選び、バイト列をそのまま中継するだけのものです（中身を読む処理はありません）。

async def handle(cr, cw):
    t = pick()                      # 正常なターゲットを順番に選ぶ
    tr, tw = await asyncio.open_connection(*t)
    await asyncio.gather(pipe(cr, tw), pipe(tr, cw))   # 中身は読まずに中継

nginx 側は、/api/ で始まるパスを API サーバーへ、それ以外を web-a・web-b へ送る設定です。

upstream web { server 127.0.0.1:19091 max_fails=2 fail_timeout=10s;
               server 127.0.0.1:19092 max_fails=2 fail_timeout=10s; keepalive 8; }
upstream api { server 127.0.0.1:19093; }
server {
    listen 127.0.0.1:19080;
    location /api/ { proxy_pass http://api;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host; }
    location / { proxy_pass http://web; proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host; }
}

実演1：パスで振り分けられるのは L7 だけ

同じ4つの URL を、L7（ポート19080）と L4（ポート19081）に送りました。後ろのサーバーは、自分の名前と受け取ったヘッダーを返します。

### L7: path routing
{"server": "web-a", "path": "/", "peer": "127.0.0.1:59132", "xff": "127.0.0.1", "proto": "http", "host": "127.0.0.1"}
{"server": "web-b", "path": "/", "peer": "127.0.0.1:36170", "xff": "127.0.0.1", "proto": "http", "host": "127.0.0.1"}
{"server": "api", "path": "/api/users", "peer": "127.0.0.1:35244", "xff": "127.0.0.1", "proto": "http", "host": "127.0.0.1"}
{"server": "api", "path": "/api/users", "peer": "127.0.0.1:35252", "xff": "127.0.0.1", "proto": "http", "host": "127.0.0.1"}
### L4: same paths
{"server": "web-a", "path": "/", "peer": "127.0.0.1:59140", "xff": null, "proto": null, "host": "127.0.0.1:19081"}
{"server": "web-b", "path": "/", "peer": "127.0.0.1:36186", "xff": null, "proto": null, "host": "127.0.0.1:19081"}
{"server": "web-a", "path": "/api/users", "peer": "127.0.0.1:59150", "xff": null, "proto": null, "host": "127.0.0.1:19081"}
{"server": "web-b", "path": "/api/users", "peer": "127.0.0.1:36198", "xff": null, "proto": null, "host": "127.0.0.1:19081"}

L7 では /api/users が API サーバーに届き、X-Forwarded-For（元のクライアントの IP）と X-Forwarded-Proto が付きました。L4 では /api/users も Web サーバーに届き、ヘッダーは何も足されていません。AWS でも、パスやホスト名での振り分けは ALB のリスナールールの機能で、NLB にはありません。ALB は X-Forwarded-For・X-Forwarded-Proto・X-Forwarded-Port を自動で付けると公式ドキュメントに書かれています。

実演2：1本の接続で6回送ると、L4 は全部同じサーバーに行く

curl に URL を6つ渡すと、1本の TCP 接続（keep-alive）で6回のリクエストを送ります。送り先の集計は次のとおりです。

L7:
Counter({'web-a': 3, 'web-b': 3})
L4:
Counter({'web-a': 6})

公式ドキュメントも、NLB は「個々の TCP 接続を、その接続が続くあいだ1つのターゲットに送る」と説明しています。HTTP/2 や gRPC のように1本の接続を長く使うクライアントが少数だと、NLB では負荷が偏ることがあります。逆に、接続の行き先が変わらないことを前提にしたプロトコルには NLB が向きます。

実演3：HTTP 以外のプロトコルを通せるのは L4

1行ずつ返すだけの自作の TCP サーバー（HTTP ではない）を後ろに置き、L4 と L7 に同じ文字列を送りました。

$ printf 'hello\r\nPING\r\n' | nc -q1 127.0.0.1 19082      # L4 経由
+READY line-echo
ECHO hello
ECHO PING
$ printf 'hello\r\n' | nc -q1 127.0.0.1 19080             # L7（HTTP）経由
HTTP/1.1 400 Bad Request

L7 は HTTP として読めないものを 400 で断り、L4 は中身を気にせず通しました。データベース、MQTT、独自の TCP プロトコル、UDP の DNS やゲームの通信を負荷分散したいときに NLB を選ぶのはこのためです。

実演4：X-Forwarded-For の扱い

クライアントが自分で X-Forwarded-For: 203.0.113.7 を付けて送ると、次のようになりました。

L7: {"server": "api", ..., "xff": "203.0.113.7, 127.0.0.1", ...}
L4: {"server": "web-b", ..., "xff": "203.0.113.7", ...}

L7 は受け取った値の後ろに、実際に接続してきた IP を足しました。L4 はクライアントが書いた値をそのまま渡しています。X-Forwarded-For の左端はクライアントが自由に書けるので、アプリで使うときは「右から何番目が自分のロードバランサーが足した値か」を決めて読みます。NLB で元の IP を渡す方法は、送信元 IP の保持（クライアント IP の保持）か Proxy Protocol v2 で、次の NLB の節で扱います。

ALBとは（できること：パス・ホストでの振り分け、リダイレクト、認証）

この節では、ALB で何ができるか、どんな構成で使うかが分かります。

ALB は、HTTP・HTTPS のリクエストを読んで、リスナールールの条件に合うターゲットグループへ送る L7 のロードバランサーです。公式ドキュメントでは、受け取ったノードがリスナールールを優先度の順に評価し、合ったルールのターゲットグループから、そのグループに設定した方式（既定はラウンドロビン）でターゲットを選ぶ、と説明されています。

振り分けの方式は、ターゲットグループごとにラウンドロビン（既定）・最小未処理リクエスト（least outstanding requests）・重み付きランダム（weighted random）から選べます。公式ドキュメントによると、最小未処理リクエストと重み付きランダムはスロースタートと併用できず、重み付きランダムはスティッキーセッションとも併用できません。

ALB の接続のアイドルタイムアウトは既定で60秒、クライアントとの keep-alive は既定で3,600秒です。ターゲット側（アプリや Web サーバー）の keep-alive をこれより短くすると、502 の原因になります（エラーの節で扱います）。

NLBとは（固定IP・TCP/UDP・送信元IP・低レイテンシー）

この節では、NLB の特徴と、ALB ではなく NLB を選ぶ理由が分かります。

NLB は、TCP・UDP・TLS などの接続を、中身を見ずにターゲットへ送る L4 のロードバランサーです。公式ドキュメントでは、プロトコル・送信元 IP とポート・宛先 IP とポート・TCP のシーケンス番号をもとにしたフローハッシュでターゲットを選ぶ、と説明されています。

NLB を選ぶ主な理由

• 固定 IP が要る：取引先のファイアウォールに IP で許可してもらう、IP でしか指定できない機器から接続する。AZ ごとに Elastic IP を割り当てられます（後の節で moto で作った出力を示します）。ALB には固定 IP がありません。
• HTTP 以外のプロトコル：TCP（データベース・MQTT・SMTP など）、UDP（DNS・ゲーム・音声）、QUIC。
• クライアントの IP をそのまま渡したい：インスタンス型のターゲットグループでは、クライアント IP の保持が既定で有効です。IP 型の TCP・TLS では既定で無効で、属性 preserve_client_ip.enabled で切り替えます。
• 長時間の接続・大量の接続：公式の比較表で「Long-lived TCP connection」は NLB と GWLB だけに付いています。
• PrivateLink で他の VPC にサービスを公開：エンドポイントサービスの裏に置けるのは NLB（と GWLB）です。

NLB のターゲットの種類には「ALB」があり、固定 IP（NLB）とパスでの振り分け（ALB）を両方使いたいときは NLB の後ろに ALB を登録します。クライアント IP を保持できない構成では、Proxy Protocol v2 で送信元の情報をターゲットに渡せますが、公式ドキュメントは、アプリがそのヘッダーを読めることを先に確かめるよう注意しています。

GWLBとCLBとは（使う場面と、新規にCLBを選ばない理由）

この節では、残りの2種類である GWLB と CLB が、どんな場面のものかが分かります。

GWLB（Gateway Load Balancer）は、ファイアウォールや侵入検知などの仮想アプライアンスを、通信の経路の途中に透過的に挟むためのものです。クライアントが GWLB に直接つなぐのではなく、ルートテーブルで GWLB エンドポイントへ通信を向け、GWLB が GENEVE（UDP 6081番）でカプセル化してアプライアンスへ送ります。公式ドキュメントでは、5タプルのフローハッシュでアプライアンスを選び、同じフローのパケットは同じアプライアンスへ送り続けます。アプライアンスを売っている各社の製品と組み合わせて使うもので、Web アプリの負荷分散には使いません。

CLB（Classic Load Balancer）は前の世代のロードバランサーです。公式の CLB のユーザーガイドには「Classic Load Balancer は前の世代のロードバランサーで、現行の世代のロードバランサーへの移行を勧める」と書かれています。パスでの振り分け、HTTP/2・gRPC、Lambda のターゲット、WebSocket、SNI（1つのリスナーで複数の証明書）などは CLB の欄に印がありません。既存の CLB を見つけたら、HTTP なら ALB、TCP なら NLB への移行を検討します。

1. 1HTTP・HTTPS の Web・API → ALBパス・ホストで振り分け、WAF・認証・リダイレクト
2. 2TCP・UDP・固定 IP・PrivateLink → NLB中身を見ずに速く通す。送信元 IP を保てる
3. 3固定 IP と L7 の両方 → NLB の後ろに ALBターゲットの種類「alb」
4. 4通信を検査する機器を挟む → GWLBGENEVE・ルートテーブルで経路に入れる
5. 5CLB → 新規には選ばない既存のものは現行の世代へ移行を検討

ALBとNLBの選び方（判断表）

この節では、要件から ALB と NLB のどちらを選ぶかが、判断表で分かります。

迷ったら「HTTP の中身を見て何かしたいか」を問います。したいなら ALB、見なくてよいか見られないなら NLB です。

手元の計測：L7 と L4 で応答時間はどれだけ違うか

127.0.0.1 で、直接・nginx（L7）・自作の L4 転送のそれぞれに 2,000 回ずつ GET を送り、1回の応答時間を測りました（先に100回の空打ち）。AWS の ALB・NLB の性能を表す値ではなく、「層を1つ挟むとどのくらい増えるか」の目安です。

direct      keepalive=False mean=1.683ms p50=0.459ms p99=4.858ms
direct      keepalive=True  mean=0.144ms p50=0.114ms p99=0.281ms
L7 nginx    keepalive=False mean=0.512ms p50=0.321ms p99=4.353ms
L7 nginx    keepalive=True  mean=0.304ms p50=0.240ms p99=3.318ms
L4 forward  keepalive=False mean=1.231ms p50=0.932ms p99=4.841ms
L4 forward  keepalive=True  mean=0.248ms p50=0.212ms p99=0.667ms

keep-alive ありでは、L7 も L4 も直接より 0.1ms 前後増えただけでした。keep-alive なし（毎回新しい接続）では、L7 の方が速くなっています。nginx が後ろのサーバーとの接続を使い回している（keepalive 8;）ため、後ろのサーバーが毎回接続を作り直す手間が消えたからです。L4 はクライアントの接続ごとに後ろへも新しい接続を作るので、その手間がそのまま残ります。差が出るのは層の違いよりも、接続の使い回し方です。

なお、最初の計測では、後ろのサーバーが応答のヘッダーと本文を別々に書き出していたため、keep-alive ありの方が 44ms 前後と大幅に遅くなりました。Nagle アルゴリズムと遅延 ACK の組み合わせによる典型的な遅れで、サーバー側で TCP_NODELAY を有効にすると消えました。ロードバランサーを疑う前に、後ろのサーバー単体の応答も測ると原因を取り違えません。

ELBの構成要素：リスナー・ルール・ターゲットグループ

この節では、ELB を作るときに出てくる部品の名前と、つながり方が分かります。

ELB は「ロードバランサー → リスナー → ルール → ターゲットグループ → ターゲット」の順につながります。どれか1つが欠けると通信は流れません。

AWS CLI で ALB を一式作る手順（実際の AWS 向けのコマンド）は、関連記事「ALBをAWS CLIで作成｜ターゲットグループ・リスナー・ルール設定」で扱っています。この記事では、同じ部品を moto で作ったときの出力と、モックでは分からない点を後の節で示します。

ヘルスチェックの仕組みと既定値（ALB・NLB）

この節では、ヘルスチェックがどう動き、既定値がどうなっているか、異常から戻るまでにどれだけかかるかが分かります。

ヘルスチェックは、ロードバランサーが各ターゲットに定期的に問い合わせ、決まった回数続けて失敗したら外し、決まった回数続けて成功したら戻す仕組みです。公式ドキュメントの既定値は次のとおりです。

既定値のままだと、異常になってから外されるまでに約60秒（30秒×2回）、戻ってから再び送られるまでに約150秒（30秒×5回）かかります。moto で作ったターゲットグループも、ALB 向けは間隔30秒・タイムアウト5秒・5回・2回、NLB の TCP 向けはタイムアウト10秒と、同じ既定値を返しました。

手元の L4 転送で、外れて戻るまでを見る

自作の L4 転送に、2秒間隔・2回失敗で異常・3回成功で正常という小さなヘルスチェック（TCP で接続できるか）を入れ、web-b を止めてから起動し直しました（時刻は UTC）。

20:49:48 conn 127.0.0.1:51630 -> 19091
20:49:48 conn 127.0.0.1:51640 -> 19092
20:49:48 connect 19092 failed: [Errno 111] Connect call failed ('127.0.0.1', 19092)
20:49:52 target 19092 -> unhealthy
20:49:53 conn 127.0.0.1:51654 -> 19091
20:49:53 conn 127.0.0.1:51660 -> 19091
20:49:58 target 19092 -> healthy
20:50:01 conn 127.0.0.1:55056 -> 19092
20:50:01 conn 127.0.0.1:55066 -> 19091

20:49:48 に止めた直後の1件は、まだ「正常」と思っている web-b に送られ、クライアントには curl: (52) Empty reply from server が返りました。4秒後に unhealthy になってからは web-a だけに送られ、20:49:53 に起動し直すと5秒後に healthy に戻り、また交互に配られました。ヘルスチェックで外れるまでの数十秒は、壊れたターゲットにも送られることがあるので、アプリ側のリトライや、デプロイ前にターゲットを外す（登録解除の遅延）設計と組み合わせます。

L7 は1回目の失敗をその場で別のサーバーに送り直す

同じ時刻に nginx（L7）にも送ると、クライアントには 200 だけが返り、error.log に次の行が残りました。

2026/10/29 20:49:48 [error] 24597#24597: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:19092/", host: "127.0.0.1:19080"
2026/10/29 20:49:48 [warn] 24597#24597: *6 upstream server temporarily disabled while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:19092/", host: "127.0.0.1:19080"

nginx は接続に失敗したリクエストを次のサーバーへ送り直し、2回失敗した web-b を10秒間外しました（max_fails=2 fail_timeout=10s）。2台とも止めると、L7 は HTTP/1.1 502 Bad Gateway の応答を返し、L4 は接続を閉じるだけで、クライアントには curl: (52) Empty reply from server が出ました。L7 はエラーを HTTP の応答として返せますが、L4 は接続を切ることしかできません。なお、ALB・NLB では、すべてのターゲットが異常になると、全ターゲットに送る「fail open」の動きになると公式の比較表に書かれています。

ターゲットの状態と理由コード（ALB）

describe-target-health で見える状態と、よく出る理由コードです（公式ドキュメント）。Elb で始まるものはロードバランサー側、Target で始まるものはターゲット側が原因です。

スティッキーセッション・クロスゾーン・TLS終端・固定IPの比較表

この節では、設計でよく比べられる機能を、ALB と NLB で並べて確かめられます。

クロスゾーンの有無で配分がどう変わるか

公式ドキュメントの例では、AZ-A にターゲット2台、AZ-B に8台あり、各 AZ のノードに通信が半分ずつ届くとき、クロスゾーンが有効なら10台が10%ずつ、無効なら AZ-A の2台が25%ずつ、AZ-B の8台が6.25%ずつになります。NLB は既定で無効なので、AZ ごとの台数をそろえないと偏ります。ただし、クロスゾーンを有効にすると AZ をまたぐ通信が増えます。

スティッキーセッションを手元で確かめる

nginx で Cookie の値（sid）のハッシュで送り先を決める設定にすると、同じ sid は毎回同じサーバーへ行きました。ALB の期間ベースのスティッキーも、同じ考え方で Cookie を見て送り先を固定します。

u1 web-b
u1 web-b
u1 web-b
u2 web-a
u2 web-a
u2 web-a
u3 web-a
u3 web-a

u2 と u3 が同じ web-a に寄ったように、スティッキーセッションは配分が偏る原因になります。公式ドキュメントも NLB のスティッキーについて、接続とフローの偏りが可用性に影響しうると注意しています。セッションの情報は ElastiCache や DynamoDB などに置き、どのサーバーに来てもよい作りにすると、スティッキーに頼らずに済みます。

TLS の終端を手元で確かめる

nginx に自己署名の証明書を置いて 127.0.0.1:19443 で HTTPS を受け、後ろへは HTTP で送りました。

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
*  subject: CN=t90.local
< HTTP/1.1 200 OK
{"server": "web-a", "path": "/", "peer": "127.0.0.1:38882", "xff": "127.0.0.1", "proto": "https", "host": "web"}

後ろのサーバーは HTTP で受けていますが、X-Forwarded-Proto: https で元が HTTPS だったと分かります。アプリが「HTTP で来たから HTTPS へリダイレクト」と判断してしまうリダイレクトループは、このヘッダーを見ないことで起きます。また、このサーバーでは Host ヘッダーを設定し忘れたため、"host": "web"（upstream の名前）が届きました。ALB は元の Host ヘッダーをそのまま渡すので、自前のプロキシを ALB の代わりに置くときは、この違いにも気をつけます。

motoでALB・NLBを作ってみる（AWSに接続しないCLI実行）

この節では、AWS のアカウントが無くても、ELB の部品を作って出力の形を確かめる方法と、その限界が分かります。

moto は、AWS の API を手元で真似する Python のライブラリです。moto_server を 127.0.0.1 で起動し、AWS CLI の --endpoint-url をそこへ向けると、料金も外部への通信も発生させずに aws elbv2 のコマンドを試せます。認証情報はダミーの値を入れます。

python3 -m venv venv
PIP_CACHE_DIR=./pipcache venv/bin/pip install "moto[server]" boto3 awscli
venv/bin/moto_server -H 127.0.0.1 -p 45090 &
export AWS_ACCESS_KEY_ID=testing AWS_SECRET_ACCESS_KEY=testing AWS_DEFAULT_REGION=ap-northeast-1
E="--endpoint-url http://127.0.0.1:45090"

ALB とターゲットグループを作る

VPC・2つの AZ のサブネット・セキュリティグループ・EC2 インスタンス2台を作ったあと、ALB とターゲットグループを作りました。

aws elbv2 create-load-balancer --name t90-alb --type application \
  --subnets $SA $SC --security-groups $SG $E
aws elbv2 create-target-group --name t90-web --protocol HTTP --port 80 \
  --vpc-id $VPC --health-check-path /health $E

{
    "TargetGroupName": "t90-web",
    "Protocol": "HTTP",
    "Port": 80,
    "HealthCheckProtocol": "HTTP",
    "HealthCheckPort": "traffic-port",
    "HealthCheckIntervalSeconds": 30,
    "HealthCheckTimeoutSeconds": 5,
    "HealthyThresholdCount": 5,
    "UnhealthyThresholdCount": 2,
    "HealthCheckPath": "/health",
    "Matcher": { "HttpCode": "200" },
    "TargetType": "instance",
    "ProtocolVersion": "HTTP1"
}

リスナー（HTTP:80、既定は web へ）と、/api/* を api へ送る優先度10のルールを足して、describe-rules で並びを見ました。

+--------+----------+------------------------------------------------------------------+
|  Cond  |    P     |                               TG                                 |
+--------+----------+------------------------------------------------------------------+
|  /api/*|  10      |  arn:aws:elasticloadbalancing:...:targetgroup/t90-api/6878...    |
|  None  |  default |  arn:aws:elasticloadbalancing:...:targetgroup/t90-web/ee25...    |
+--------+----------+------------------------------------------------------------------+

スティッキーセッションは、ターゲットグループの属性で有効にします。

aws elbv2 modify-target-group-attributes --target-group-arn $TGW \
  --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=lb_cookie \
  Key=stickiness.lb_cookie.duration_seconds,Value=300 $E

NLB を Elastic IP つきで作る

Elastic IP を2つ確保し、--subnet-mappings で AZ ごとに割り当てました。

aws elbv2 create-load-balancer --name t90-nlb --type network --scheme internet-facing \
  --subnet-mappings SubnetId=$SA,AllocationId=$EA SubnetId=$SC,AllocationId=$EC $E

"LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/t90-nlb/18a0b423cabce0ab",
"Type": "network",
"SecurityGroups": [],

TCP:80・UDP:53・TLS:443 のリスナーを作り、HTTP のリスナーを作ろうとすると次のエラーになりました。

An error occurred (ValidationError) when calling the CreateListener operation: Listener protocol 'HTTP' must be one of 'UDP, TCP, TLS, TCP_UDP'

pytest でインフラのコードを試す

boto3 で ALB を組み立てる関数を、@mock_aws を付けたテストで確かめました。AWS の認証情報を持たない CI でも動きます。

@mock_aws
def test_duplicate_priority_is_rejected():
    ec2 = boto3.client("ec2", region_name="ap-northeast-1")
    elb = boto3.client("elbv2", region_name="ap-northeast-1")
    lb, tg = build_alb(ec2, elb)
    l = elb.describe_listeners(LoadBalancerArn=lb["LoadBalancerArn"])["Listeners"][0]
    kw = dict(ListenerArn=l["ListenerArn"], Priority=10,
              Actions=[{"Type": "forward", "TargetGroupArn": tg["TargetGroupArn"]}])
    elb.create_rule(Conditions=[{"Field": "path-pattern", "Values": ["/api/*"]}], **kw)
    with pytest.raises(elb.exceptions.PriorityInUseException):
        elb.create_rule(Conditions=[{"Field": "path-pattern", "Values": ["/v2/*"]}], **kw)

..                                                                       [100%]
2 passed in 2.38s

moto で分かること・分からないこと

moto は API の形を確かめるのには便利ですが、AWS の検査を全部は真似しません。今回、本物の AWS なら通らない操作がいくつも通りました。

一方、優先度の重複（PriorityInUse）、使用中のターゲットグループの削除（ResourceInUse）、ALB への TCP リスナー、32文字を超える名前は、moto でもエラーになりました。moto は「呼び出し方と戻り値の形」を確かめる道具として使い、構成の正しさは AWS 上の検証環境か、CloudFormation・Terraform の検証で確かめるのが安全です。

ELBの料金（LCU・NLCU）と月額の目安

この節では、ELB の料金の仕組みと、通信量ごとの月額の目安が分かります。

ALB・NLB の料金は「動かしている時間」と「使った量（LCU・NLCU）」の合計です。使った量は複数の指標のうち最も大きいもので数えます。2026年10月29日時点の公式の料金ページでは、表示されていた単価は米国東部（バージニア北部）の値でした。東京リージョンの単価は AWS 料金見積りツールで確かめます。

この単価で、3つの通信の形の月額（730時間）を Python で計算しました。

def alb(new_cps, active_pm, gb_ph, rule_eval_ps=0):
    lcu = max(new_cps/25, active_pm/3000, gb_ph/1, rule_eval_ps/1000)
    return lcu, (0.0225 + lcu*0.008) * 730
def nlb_tcp(new_cps, active_pm, gb_ph):
    nlcu = max(new_cps/800, active_pm/100000, gb_ph/1)
    return nlcu, (0.0225 + nlcu*0.006) * 730

小さなサイト: 新規5/秒 アクティブ300/分 0.2GB/時 -> ALB 0.20LCU $17.59/月  NLB 0.20NLCU $17.30/月
中規模API: 新規100/秒 アクティブ6000/分 3GB/時 -> ALB 4.00LCU $39.78/月  NLB 3.00NLCU $29.57/月
接続が多いIoT: 新規400/秒 アクティブ200000/分 0.5GB/時 -> ALB 66.67LCU $405.76/月  NLB 2.00NLCU $25.19/月
何も流さなくても: ALB/NLB $16.43/月

通信量が少ないうちは種類による差は小さく、新しい接続やアクティブな接続が多い使い方では、ALB の LCU が跳ね上がります。公式の料金ページには、新規の利用者向けに CLB と ALB で月750時間などの無料利用枠があることも書かれています。開発環境の ALB を作ったまま放置すると、何も流れていなくても時間料金がかかり続けます。

よくあるエラー／つまずき（502・503・504・作成時のエラー）

この節では、ELB でよく見るエラーの原文と、どこを直すかが分かります。

ALB の 5xx は「ロードバランサーが作った応答」か「ターゲットが返した応答」かで、見る場所が変わります。公式ドキュメントでは、ロードバランサーが作ったエラーは CloudWatch の HTTPCode_ELB_5XX_Count、ターゲットが返したエラーは HTTPCode_Target_5XX_Count に数えられます。

• 1ヘルスチェックのパスが 200 を返すかログイン画面へのリダイレクト（302）や 401 を返すと Target.ResponseCodeMismatch になる
• 2ターゲットの SG がロードバランサーからの通信を許しているかALB・NLB の SG を送信元に指定すると、ロードバランサー経由だけに絞れる
• 3ターゲットの AZ をロードバランサーで有効にしているか有効でない AZ のターゲットは unused になり、通信が来ない
• 4アプリの keep-alive がアイドルタイムアウトより長いか短いと、ターゲットが先に接続を閉じて 502 になる
• 5NLB を作るときにセキュリティグループを付けたか付けずに作ると、あとから付けられない

504 の詳しい切り分けは関連記事「504 Gateway Time-outとは？原因と直し方｜見ている人・運営者別」で、nginx をリバースプロキシにしたときの 502・504 は関連記事「Nginxリバースプロキシ設定｜proxy_passの書き方と502/504対処」で扱っています。ALB に独自ドメインを向ける Route 53 のエイリアスレコードは、関連記事「Route 53レコードをAWS CLIで作成｜A・CNAME・エイリアス例」にあります。

よくある質問

Q. ELBとは何ですか？ A. AWS のロードバランサーのサービス（Elastic Load Balancing）の名前で、ALB・NLB・GWLB・CLB の4種類の総称です。届いた通信を複数のターゲットに配り、ヘルスチェックで異常なターゲットを外します。

Q. ALBとNLBの違いは何ですか？ A. ALB は HTTP・HTTPS の中身（パス・ホスト名・ヘッダー）を読んで振り分ける L7、NLB は TCP・UDP の接続を中身を見ずに送る L4 です。手元の実演では、1本の接続で送った6件のリクエストが、L7 では3件ずつに分かれ、L4 では全部が同じサーバーへ行きました。

Q. NLBとは何ですか？ A. Network Load Balancer の略で、TCP・UDP・TLS（QUIC も）を扱う L4 のロードバランサーです。Elastic IP で IP を固定でき、クライアントの IP を保ったままターゲットへ渡せます。

Q. ALBに固定IPを付けられますか？ A. 付けられません。IP を固定したいときは、NLB に Elastic IP を割り当て、その後ろに ALB をターゲットとして登録します。

Q. ロードバランサーとリバースプロキシは何が違いますか？ A. リバースプロキシはクライアントの代わりに後ろのサーバーへ取り次ぐもので、複数のサーバーに配る機能を持つとロードバランサーとしても働きます。nginx はその両方を兼ねられ、この記事でも ALB の代わりに使いました。ALB は運用まで AWS が引き受けるリバースプロキシ型のロードバランサーです。

Q. CLB（Classic Load Balancer）は今も使えますか？ A. 使えますが、公式のユーザーガイドで前の世代と書かれ、現行の世代への移行が勧められています。新しく作るなら ALB か NLB を選びます。

Q. ELBの料金はいくらですか？ A. 米国東部では ALB・NLB とも 0.0225 USD/時間に、ALB は 0.008 USD/LCU 時間、NLB は 0.006 USD/NLCU 時間が加わります（2026年10月29日時点）。何も流さなくても1台あたり月 16.43 USD ほどかかります。東京の単価は料金見積りツールで確かめます。

Q. ヘルスチェックで unhealthy になる原因は？ A. ヘルスチェックのパスが 200 以外を返している（Target.ResponseCodeMismatch）、セキュリティグループやポートの設定で届かない（Target.Timeout）が多い原因です。describe-target-health の理由コードで切り分けます。

Q. AWS に接続せずに ELB の操作を練習できますか？ A. moto を使うと、127.0.0.1 の moto_server に AWS CLI や boto3 を向けて、作成・一覧・属性の変更を試せます。ただし、ヘルスチェックは常に healthy で、サブネットの数や NLB のセキュリティグループの制限など、本物なら止められる操作が通ることがあります。

Q. ELBという言葉を電気の分野でも見かけます。 A. 電気設備では、ELB は漏電遮断器（Earth Leakage Breaker）を指すことがあります。この記事の ELB は AWS の Elastic Load Balancing です。

まとめ

• ELB は AWS のロードバランサー4種類の総称。Web・API は ALB、TCP・UDP・固定 IP・PrivateLink は NLB、通信を検査する機器を挟むなら GWLB、CLB は前の世代。
• L7 はリクエスト1件ごと、L4 は接続1本ごとに振り分ける。手元では keep-alive の6件が L7 で3件ずつ、L4 で全部同じサーバーに行き、HTTP 以外の通信は L4 だけが通した。
• ヘルスチェックの既定は30秒間隔・2回失敗で外す・5回成功で戻す。外れるまでのあいだは壊れたターゲットにも送られるので、リトライと登録解除の遅延を組み合わせる。
• 料金は時間料金＋LCU・NLCU。何も流さなくても1台で月 16 USD ほどかかり、接続が多い使い方では NLB が大幅に安くなる。
• moto は AWS に接続せずに API の形を確かめられるが、ALB の2AZ必須や NLB のセキュリティグループの制限などは再現されない。構成の正しさは別の方法で確かめる。

参考・出典

確認日はいずれも 2026年10月29日です。

• AWS「Elastic Load Balancing の機能（製品比較）」：https://aws.amazon.com/elasticloadbalancing/features/
• AWS「Elastic Load Balancing の料金」：https://aws.amazon.com/elasticloadbalancing/pricing/
• AWS「How Elastic Load Balancing works」：https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
• AWS「Health checks for Application Load Balancer target groups」：https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html
• AWS「Health checks for Network Load Balancer target groups」：https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html
• AWS「Edit target group attributes for your Application Load Balancer」：https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-target-group-attributes.html
• AWS「Edit target group attributes for your Network Load Balancer」：https://docs.aws.amazon.com/elasticloadbalancing/latest/network/edit-target-group-attributes.html
• AWS「Network Load Balancers」：https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html
• AWS「Listeners for your Network Load Balancers」：https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html
• AWS「Security groups for your Network Load Balancer」：https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-security-groups.html
• AWS「Application Load Balancers」：https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html
• AWS「Troubleshoot your Application Load Balancers」：https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html
• AWS「Security policies for your Application Load Balancer」：https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html
• AWS「What is a Classic Load Balancer?」：https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html
• AWS CLI Command Reference「create-load-balancer」：https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-load-balancer.html
• AWS CLI Command Reference「create-listener」：https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-listener.html
• moto「Non-Python SDK’s / Server Mode」：https://docs.getmoto.org/en/latest/docs/server_mode.html
• nginx「Module ngx_http_upstream_module」：https://nginx.org/en/docs/http/ngx_http_upstream_module.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。