# AWSのロードバランサー「ALB」と「NLB」の違いと使い分け

URL: https://webrandum.net/alb-nlb-comparison/
公開日: 2026-10-29
更新日: 2026-10-29
カテゴリー: インフラ
タグ: AWS, ELB
出典: Webrandum（著者: サイトウ マサカズ）

AWSでウェブアプリのロードバランサーを作るとき、最初にALBとNLBのどちらを使うかを選びます。

それぞれの違いについて調べると「ALBはL7、NLBはL4」と出てきますが、ネットワークに関する知識が無い人からすると、これだけではイマイチ理解できません。

今回はELBで選べるロードバランサーの種類をまとめつつ、ALBとNLBの違いと使い分けを整理します。

## Elastic Load Balancingの基本

![](https://webrandum.net/mskz/wp-content/uploads/2026/10/image_1-3-1024x604.png)

[ロードバランサー – Amazon Elastic Load Balancer (ELB) – AWS](https://aws.amazon.com/jp/elasticloadbalancing/)

ロードバランサーとは、サイトへのアクセスを複数のサーバーに振り分けて、1台に負荷が集中しないようにする仕組みです。

コンビニなどでレジを待つときにフォーク型で並ぶようなものだと考えると分かりやすいです。1つの列に並び、空いたレジへ順番に進んでいく並び方です。

ロードバランサーも同じように、受け付けた通信を複数のサーバーへ振り分けます。
ちなみに、この振り分け先になるEC2インスタンスやコンテナなどを「ターゲット」と呼びます。

そしてAWSのロードバランサーのサービスが「ELB（Elastic Load Balancing）」です。
ややこしいですが、ELBというサービスの中に、ALBやNLBといったロードバランサーが何種類か用意されています。

また、ELBはターゲットが正常に動いているかを定期的に確かめる「ヘルスチェック」も行っています。
このヘルスチェックがあるおかげで、応答しなくなったターゲットには通信を送らないので、止まっているサーバーにアクセスが送られてエラーになるのを防げます。

## ロードバランサーの種類

2026年10月時点で、ELBで選べるロードバランサーは下記の4種類です。

| 種類 | 動作する層 | 主な用途 |
| --- | --- | --- |
| Application Load Balancer（ALB） | 第7層（アプリケーション層） | ウェブサイト・ウェブアプリ・API |
| Network Load Balancer（NLB） | 第4層（トランスポート層） | HTTP以外の通信、IPアドレスの固定 |
| Gateway Load Balancer（GWLB） | 第3層（ネットワーク層） | ファイアウォールなどを通信経路に挟む |
| Classic Load Balancer（CLB） | （旧世代） | 既存環境のみ |

### Application Load Balancer（ALB）

ALBはHTTPとHTTPSの通信を扱う、ウェブサイト・ウェブアプリ向けのロードバランサーです。
名前もApplication Load Balancerなのでアプリケーション向けだと覚えられます。

WebSocketにも対応しているので、チャットのようにつなぎっぱなしで通信するアプリケーションも扱えます。

HTTPのリクエストを読めるALBでは、下記のような機能が使えます。

- URLやドメインで振り分け先を変える 例：`/api/`はAPIのサーバー、`blog.example.com`はブログのサーバーのように振り分けられる

- HTTPでアクセスされたら、HTTPSへリダイレクトする サーバー側の`.htaccess`などに書かなくて済む

- Amazon Cognitoなどと連携してログイン画面を挟む（HTTPSリスナーのみ）

- AWS WAF（不正なリクエストを遮断するファイアウォール）を使う

ヘルスチェックもHTTPまたはHTTPSで行い、指定したパスが返すステータスコードで正常かどうかを判断できます。

### Network Load Balancer（NLB）

NLBはHTTPに限らず、TCPやUDPの通信を扱うロードバランサーです。

独自プロトコルのサービスなど、HTTP以外の通信を振り分けたい場合はNLBを選びます（対応しているプロトコルの一覧は[NLBのドキュメント](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-listeners.html)を参照）。

IPアドレスを、AZ（リージョンの中にあるデータセンターのまとまり）ごとに1つ固定できるのも特徴です。

また、クライアントのIPアドレスを接続元のままターゲットに渡せます（ただし、ターゲットをIPアドレスで登録した場合、TCPやTLSでは既定で無効なので、ターゲットグループの設定で有効にします）。

NLBの[ヘルスチェック](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/target-group-health-checks.html)は、既定ではTCPで接続できるかどうかだけを確認します。
ポートさえ開いていれば、アプリケーションがエラーを返していても正常と判定されるので、ウェブアプリを載せるならHTTPやHTTPSに変えておきます。

なお、NLBのセキュリティグループ（受け付ける通信を決めるファイアウォール）は、作成時に付けなかった場合は後から追加できません。
後から付けたくなったら作り直しになるので、作成時に付けておく必要があるので注意しましょう。

### Gateway Load Balancer（GWLB）

ファイアウォールなどのセキュリティ製品を通信経路に挟むためのロードバランサーです。
ウェブサイトを公開するだけなら、出番はほとんどありません。

### Classic Load Balancer（CLB）

旧世代のロードバランサーで、現在AWSは[ALBやNLBへの移行を推奨](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)しています。
古い環境でCLBが残っている場合は、HTTP/HTTPSならALB、TCPならNLBへの移行を検討します。

これから新しく作る場合はALBかNLBを選びましょう。

## ALBとNLBの違い

ALBとNLBは、どちらも通信をターゲットへ振り分けるロードバランサーです。

この2つの大きな違いは、NLBがIPアドレスとポート番号だけを見て振り分けるのに対して、ALBはURLやCookieを含むHTTPリクエストの中身まで見て振り分ける点です。

この違いは、よく郵便物の仕分けに例えられます。
NLBは封筒の宛名だけを見て仕分ける係で、ALBは封筒を開けて手紙を読み、内容に合わせて担当の部署へ回す係です。

ALBとNLBの特徴を表にまとめると下記のようになります（2026年10月時点）。

| 項目 | ALB | NLB |
| --- | --- | --- |
| 扱う通信 | HTTP・HTTPS | TCP・UDP・TLSなど |
| 振り分けの単位 | リクエストごと | 接続ごと |
| 振り分けの条件 | パス・ホスト名・ヘッダーなど | プロトコルとポート |
| IPアドレスの固定 | 固定されない（IPAMプールから割り当てることは可） | AZごとに固定。インターネット向けはElastic IPも使える |
| クライアントのIPアドレス | X-Forwarded-Forヘッダーで受け取る | 接続元のまま渡せる |
| 暗号化の解除（TLS終端） | HTTPSリスナー | TLSリスナー。暗号化したまま渡すことも可 |
| ログイン・AWS WAF | 対応 | 非対応 |
| ヘルスチェック | HTTP・HTTPS | 既定はTCP。HTTP・HTTPSも可 |
| ターゲット | インスタンス・IP・Lambda | インスタンス・IP・ALB |

例えば、同じ接続で`/api/users`と`/images/logo.png`が続けて送られたとします。

NLBは、TCPの場合は接続を始めるときに振り分け先を決め、切断されるまで同じターゲットに送ります。
ブラウザは一度つないだ接続を使い回してリクエストを続けて送るので、この2つはどちらも同じターゲットに届きます。

それに対してALBは、[リクエストごとに](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)振り分け先を決めます。
パスごとに振り分け先を設定しておけば、この2つを別々のターゲットへ送れます。

このように、HTTPの中身を見て振り分けたいのか、接続単位で振り分けられれば十分なのかで、どちらを使うのかが変わってきます。

## 実際にはどう使い分けるのか

HTTP/HTTPSのウェブサイトやウェブアプリなら、まずはALBを使うことから考えます。
URLでの振り分け、HTTPSへのリダイレクト、AWS WAFは、どれもNLBにはない機能だからです。

複数のアプリケーションを動かす場合も、ロードバランサーを増やす必要はありません。
1つのALBで、パスやホスト名ごとにターゲットグループ（振り分け先のターゲットをまとめたもの）を分ければ済みます。

そのうえで、下記のようなALBでは満たせない要件があるときにNLBを選びます。

- HTTP以外のプロトコル（TCPやUDP）を扱う

- 接続先のIPアドレスを固定する必要がある

- クライアントのIPアドレスを、ヘッダーではなく接続元のまま受け取りたい

ウェブ制作の案件でウェブサイトやウェブアプリを公開するだけなら、固定IPの要件くらいで、それ以外はあまり無いんじゃないかと思います。

## まとめ

ALBとNLBは、IPアドレスとポート番号だけで判断しているか、URLやCookieを含むHTTPリクエストを見て判断しているかの違いです。URLでの振り分けやWAFがALBにしかないのは、HTTPの中身を見ているからです。

ウェブサイトであればALBで構成を組み、そのうえで「IPアドレスを固定してほしい」「HTTP以外の通信もある」と言われた時点でNLBを検討します。

初めてELBを知ったときは、とりあえず「アプリケーションならALB」と丸暗記しているような状態でした。
しかし、どうなっているか詳しく調べて整理してみると、それぞれの機能差がどこからきているのか分かって面白いです。

また、NLBを使う場合は、後から追加できないセキュリティグループを作成時に付けることだけは忘れないようにしましょう。