WebDesigner's Memorandumウェブデザイナーの備忘録

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

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

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

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

Elastic Load Balancingの基本

ロードバランサーとは、サイトへのアクセスを複数のサーバーに振り分けて、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のドキュメントを参照)。

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

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

NLBのヘルスチェックは、既定ではTCPで接続できるかどうかだけを確認します。
ポートさえ開いていれば、アプリケーションがエラーを返していても正常と判定されるので、ウェブアプリを載せるならHTTPやHTTPSに変えておきます。

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

Gateway Load Balancer(GWLB)

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

Classic Load Balancer(CLB)

旧世代のロードバランサーで、現在AWSはALBやNLBへの移行を推奨しています。
古い環境で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月時点)。

項目ALBNLB
扱う通信HTTP・HTTPSTCP・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は、リクエストごとに振り分け先を決めます。
パスごとに振り分け先を設定しておけば、この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を使う場合は、後から追加できないセキュリティグループを作成時に付けることだけは忘れないようにしましょう。

著者について

プロフィール画像

@31mskz10

1997年生まれ。2016年から専門学校でデザインを学び、卒業後は神戸の制作会社でWeb制作に従事しています。Webrandumは2016年から運営し、ウェブデザイン、フロントエンド開発、WordPress、CSS、JavaScript、制作環境の効率化を中心に、実際に試した内容を執筆しています。

Twitterをフォロー Facebookでいいね