ALBとNLB、何が違う？「レイヤー」からわかるL1〜L7

AWSでFargateなど大部分を管理してくれるサービスを使っていると、裏側の仕組みを以前ほど意識しなくなった気がします。 そんな中で、ふと気になったのがロードバランサーの「ALB」と「NLB」でした。 「たしか、レイヤーが違うんだよな……」そこまでは何となく覚えています。 でも、そもそもレイヤーって何でしょう？L1、L2、L7と数字を並べられても、何を分けているのか説明できませんでした。 今回はこの『わかったつもり』をほどくために、通信の役割から調べてみました。ALBとNLBの違いまでつなげて整理していきます。

ALBはL7、NLBはL4。違うのは「何を見て振り分けるか」

ロードバランサーは、受け取った通信を、背後のサーバーやコンテナなどへ振り分ける仕組みです。AWSのALB（Application Load Balancer）はL7、NLB（Network Load Balancer）はL4で動くロードバランサーとして説明されています。 ALBはHTTPのHostやURLのパスなどを見て振り分けられます。一方、NLBはIPアドレスやポート番号など、接続・フローを識別する情報を使います。この『どの情報に基づいて判断するか』を理解するための道具が、レイヤーという考え方です。 なお、NLBの名前にあるNetworkと、OSI参照モデルの『ネットワーク層＝L3』は、そのまま対応するわけではありません。名前からL3と思い込まないようにしたいところです。

そもそもレイヤーとは、通信の仕事を分けた「層」

Webページをひとつ開くだけでも、いくつもの仕事が必要です。どのページを要求するかを伝え、送り先を決め、途中のネットワークを渡り、最後は電気・光・電波として情報を運びます。 これらをひとまとめに考えると複雑なので、役割ごとに分けて整理します。その区切りがレイヤー（layer＝層）です。代表的な整理の仕方が、通信の機能を7つに分ける『OSI参照モデル』。LはLayerの略で、L1は第1層を意味します。 7台の機械を順番に通る、という意味ではありません。同じ機器やソフトウェアが複数の層の仕事を担うこともありますし、数字が大きいほど高性能ということでもありません。

L1〜L7を、下から順に見てみる

下の層ほど信号や配送の仕組みに近く、上の層ほどアプリケーションがやり取りする内容に近づきます。まずは名称の丸暗記より、『それぞれ何の担当なのか』をつかむと読みやすくなります。

たとえばL3のIPアドレスがネットワーク上の宛先を示すのに対し、L4のポート番号は、その宛先のどの通信の入口に届けるかを区別します。L7になると、『どのページを取得したいか』のような要求の内容を扱います。 L4だから必ず確実に届く、というわけでもありません。TCPには順序をそろえたり、失われたデータを再送したりする仕組みがありますが、UDP自体には同じ仕組みがありません。層が同じでも、プロトコルによって役割の果たし方は違います。

実際のインターネットが、7つにきれいに分かれているわけではない

OSIはあくまで役割を整理する参照モデルです。インターネットで使われるTCP/IPのモデルでは、OSIのL5〜L7に相当する機能を、まとめてアプリケーション層として扱います。 そのため、実際の技術をすべて1つの層へ押し込もうとすると、かえって混乱します。暗号化はL6の説明によく登場しますが、『TLSは常にL6だけの機能』と固定して理解する必要はありません。また、L5のセッションという言葉と、Webアプリのログイン状態を表すセッションも、同じ意味として扱わないほうが整理できます。

URLをひとつ開くとき、各層にはどんな情報がある？

例として、https://example.com/api/orders へのアクセスを考えます。ここではHTTP/1.1をTLSとTCPの上で使う場合に絞ります。HTTP/3のように別の仕組みを使う通信もあるため、すべてのWeb通信がこの形というわけではありません。

『443番に届いた』という情報だけでは、/shop を開きたいのか、/api/orders を呼びたいのかはわかりません。HTTPとして内容を読むと、Hostやパスがわかります。 この違いを踏まえると、L7のロードバランサーという言葉が少し具体的になります。L7の仕事をするからといって下の層が不要になるのではなく、下の層に支えられた通信の、さらに上の情報を判断に使うわけです。

ALBとNLBで、振り分け方はどう変わる？

ALB：HTTPの内容をルールにできる

同じサイトでも、/shop はショップ用、/api はAPI用のターゲットグループへ送る。こうしたパスに応じた振り分けを、ALBではルールとして設定できます。Hostに応じて送り先を分けることも可能です。 ターゲットグループは、転送先として登録したサーバーやタスクなどのまとまりです。入口となる『リスナー』で通信を受け、ルールに従って転送先のグループを決める、と考えると設定の意味が見えてきます。

NLB：TCP接続なら、同じ接続は同じターゲットへ

NLBはTCP・UDPなどの通信を扱い、接続・フローの情報から転送先を選びます。たとえばTCPでは、送信元と宛先のIPアドレス・ポート番号などを使って振り分け先を決め、1本のTCP接続が続いている間は同じターゲットへ転送します。 その接続で /shop の次に /api を要求しても、NLB自身がパスを読んで別のターゲットグループに切り替えるわけではありません。受け取ったアプリ側でパスごとの処理をすることとは、区別して考えます。

「HTTPSならALB」「L4なら暗号化を解けない」とは限らない

調べていて、ここは覚え方を単純にしすぎないほうがよいと感じました。NLBにもTLSリスナーがあり、TLSの暗号化・復号をロードバランサー側で担う構成にできます。一方、TCPの443番で受け、暗号化された通信をそのまま転送して、背後のアプリ側で復号する構成もあります。 つまり、『HTTPSを使う』だけではALBかNLBかは決まりません。どこでTLSを終端するかと、HTTPの内容に応じて振り分けたいかは、分けて考える必要があります。レイヤーの分類は入口になっても、製品の全機能を表す一覧ではないのです。

Fargateを使うと、ロードバランサーは不要になる？

私が最初に曖昧にしていたのは、ここもでした。Fargateは、コンテナを動かすサーバー自体の管理をAWSに任せられる実行基盤です。通信をどこへ振り分けるかとは、担当が違います。 Amazon ECSのサービスをFargateで動かす構成でも、ALBやNLBを組み合わせられます。利用者からの通信を受ける入口と、実際にアプリが動く場所は、別々に考えるわけです。

もちろん、外からリクエストを受けないバッチ処理など、ロードバランサーを置かない使い方もあります。『Fargateだから不要』でも『Fargateなら必須』でもなく、アプリの入口が必要か、どんな通信を受けるかによって構成を決めます。

選ぶときは、層の数字より「したいこと」から

• HTTPのHostやパスで、WebアプリやAPIの送り先を分けたい：ALBを候補にする。
• TCP・UDPなどの通信を受けたい、または入口の固定IPが要件になる：NLBを候補にする。NLBの固定IPは有効なアベイラビリティーゾーンごとに割り当てられるため、単一IPと決めつけない。
• HTTPSを使いたい：それだけでは決めず、TLSを終端する場所と振り分け条件を確認する。

実際に採用するときは、対応プロトコル、可用性、セキュリティ、料金なども要件と照らし合わせます。L7だから上位互換、L4だから必ず速い・安い、といった選び方にはしません。

次に「ALBとNLBって何が違うの？」と聞かれたら

今なら、こう説明したいと思います。 『ALBはHTTPのHostやパスなど、リクエストの内容を見て振り分けられるL7のロードバランサー。NLBはIPアドレスやポートなどの接続情報に基づいて振り分けるL4のロードバランサーです。Fargateはアプリを動かす基盤なので、ロードバランサーとは役割が違います』 『レイヤーが違うらしい』で止まっていたときより、設定画面で何を決めているのかが見えやすくなりました。次にL2やL3という言葉が出てきたときも、数字だけで身構えず、『今は通信のどの仕事の話だろう？』から考えられそうです。

出典・参考資料

AWSの仕様は2026年11月1日に公式ドキュメントで確認しました。図は説明のために作成したもので、AWSの公式構成図や実環境の画面キャプチャではありません。 OSI参照モデルとTCP/IPの対応は、Oracle『System Administration Guide: IP Services』の「TCP/IP Protocol Architecture」も参照しています。