ALB vs NLB 選び方完全ガイド
※本記事はプロモーションを含みます。
AWSのロードバランサーを導入する際、ALB（Application Load Balancer）とNLB（Network Load Balancer）のどちらを選べばよいのか、判断に迷うことが少なくありません。本記事では、ネットワークエンジニア出身で複数の資格保有者である筆者が、両者の特徴・違い・選択基準を詳しく解説します。記事の結論としては、Webアプリケーション・API向けはALB、超低遅延・高スループット向けはNLBという使い分けが一般的です。読了時間の目安は8～10分です。
ALB（Applicati…
ALBはAWSが提供するロードバランサーの一種で、OSI参照モデルの第7層（アプリケーション層）で動作します。HTTPやHTTPSのリクエストを解析し、ホスト名やパス、クエリパラメータなどの条件に基づいて、複数のバックエンドサーバーに振り分けることが特徴とされています。
ALBの主な特徴
- アプリケーション層での柔軟なルーティング：URLパス（例：/api/users）やホスト名（example.com vs api.example.com）に基づいた詳細なルーティング設定が可能です
- 複数プロトコル対応：HTTP/HTTPS、WebSocket、HTTP/2など、Webアプリケーションで一般的なプロトコルに対応しています
- マイクロサービス向け：複数のコンテナやサービスを1つのALBで管理でき、ECS・Kubernetesなどのコンテナオーケストレーションとの親和性が高いとされています
- 低遅延ながらアプリケーション層で動作：第4層（トランスポート層）のNLBに比べると遅延がありますが、Webアプリケーション用途では実用的な性能を発揮しています
ALBの料金体系
ALBの料金は以下の要素で構成されるのが一般的です：
| 料金要素 | 概要 |
| 時間単位の基本料金 | ロードバランサーの稼働時間に対する課金 |
| ロードバランサー容量ユニット（LCU） | 処理リクエスト数、接続数、スループット量などで計算される従量課金 |
ALBはリクエスト数に応じた従量課金のため、トラフィック量が比較的少ないアプリケーションであればコストを抑えやすいとされています。
NLB（Network L…
NLBはOSI参照モデルの第4層（トランスポート層）で動作するロードバランサーで、TCP/UDPレベルで極めて高速に通信を振り分けます。金融取引システムやオンラインゲーム、IoTデバイスなど、超低遅延と高スループットが求められるユースケースに適しているとされています。
NLBの主な特徴
- 超低遅延処理：第4層で動作するため、ALBと比べて遅延が極めて小さく、マイクロ秒単位での性能差が出てくるとされています
- 極めて高いスループット：1秒間に処理できるリクエスト数（RPS）がALBよりも大幅に大きく、数百万RPS以上の処理も可能とされています
- 接続ベースの管理：TCP/UDP接続単位での管理となるため、プロトコル解析のオーバーヘッドがありません
- 固定IPの利用可能：Elastic IPを割り当てることで、ロードバランサーのIPアドレスを固定できます。これは金融機関のIP制限などで有用とされています
- 非HTTP通信にも対応：DNSやSyslog、MQTT、カスタムプロトコルなど、HTTP以外の通信も負荷分散できます
NLBの料金体系
NLBの料金構造もALBと同様ですが、処理内容によってLCU（ロードバランサー容量ユニット）の計算方法が異なります：
| 料金要素 | 概要 |
| 時間単位の基本料金 | ロードバランサーの稼働時間に対する課金 |
| NLB容量ユニット（LCU） | 処理新規接続数、アクティブ接続数、スループット量で計算。ALBより高スループットでの課金になりやすい傾向 |
NLBは高スループットを必要とするアプリケーション向けのため、トラフィック量が増えるほどコストが上昇する可能性があるとされています。
ALBとNLBの主な違い
両者の違いを整理した表を以下に示します：
| 項目 | ALB | NLB |
| 処理層 | 第7層（アプリケーション層） | 第4層（トランスポート層） |
| 遅延 | 数ミリ秒～数十ミリ秒 | マイクロ秒単位 |
| スループット | 数万～数十万RPS | 数百万RPS以上 |
| ルーティング精度 | パス・ホスト名・ヘッダ等での細かい設定可能 | TCP/UDPレベルの基本的なルーティングのみ |
| プロトコル対応 | HTTP/HTTPS、WebSocket、HTTP/2 | TCP、UDP、TLS、DNS等幅広い |
| 固定IP割り当て | 不可 | 可能（Elastic IP） |
| コンテナ対応 | ECS・Kubernetesと親和性が高い | 対応だが、デメリットになりうる |
処理層による違い
ALBが第7層で動作する理由として、ホスト名やパス情報はHTTPヘッダに含まれており、これを解析するにはアプリケーション層での処理が必要だからです。一方、NLBは第4層のTCP/UDPパケットだけを見て振り分けるため、処理が単純で高速化しやすいとされています。
遅延とスループットの差
Webアプリケーション（例：ECサイト、SNS）の場合、数十ミリ秒の遅延はユーザー体験にほぼ影響しないとされています。しかし、金融取引やオンラインゲームのマッチメイキング、リアルタイム株価配信などは、マイクロ秒単位の差が勝敗や利益を左右するとされており、その場合はNLBが選ばれることが多いです。
スループットについても、一般的なECサイト（月数百万PV）であればALBで十分な可能性がありますが、大規模な取引所や配信サービス（月数十億PV）ではNLBの高スループット特性が活かされるとされています。
コストの差
基本料金はどちらもほぼ同等ですが、LCUの計算方法が異なるため、総コストは利用パターンに大きく依存するとされています。例えば：
- 低トラフィックサイト：ALBが有利の可能性があります
- 高スループットが必要な場合：NLBの方が安くなる可能性があります（ただし導入自体が適切か要検討）
どちらを選ぶべきか
ALBが向いているケース
- Webアプリケーション・REST API：複数のマイクロサービスをホスト名やパスで振り分ける必要がある場合
- ECS・Kubernetes環境：コンテナオーケストレーションとの統合が密な場合。ALBは自動的にサービス検出と統合できるとされています
- コスト重視：中規模以下のトラフィック量で、低レイテンシがそこまで重要でない場合
- HTTP/HTTPS通信のみ：Webアプリケーション特有の機能（例：HTTPリダイレクト、HTTPヘッダの追加）が必要な場合
- セッション管理が必要：スティッキーセッション（Cookie based）での負荷分散が必要な場合、ALBはこれをネイティブにサポートしているとされています
NLBが向いているケース
- 金融取引・リアルタイムシステム：マイクロ秒単位の遅延が重要な場合
- オンラインゲーム・ライブ配信：数百万RPS以上の超高スループットが必要な場合
- 非HTTP通信：DNS、Syslog、MQTT、カスタムプロトコルなど、HTTP以外の通信を負荷分散する必要がある場合
- 固定IPが必須：クライアント側でロードバランサーのIPを固定したい場合（金融機関のIP制限など）
- 極度の高スループット：数十万RPS以上の处理が常態の場合、NLBの方がコスト効率がよくなる可能性があります
- UDPベース通信：VoIP、ゲームサーバー間通信などUDP通信を負荷分散する必要がある場合
多くの組織にとっては、最初はALBで始めて、性能ボトルネックが確認されたらNLBへの移行を検討するというアプローチが現実的とされています。理由としては、ALBで十分な性能が出ている場合、NLBへの移行コストに見合わないことが多いからです。
移行・併用のポイント
実運用ではALBとNLBを併用することも少なくありません。例えば：
- フロントエンド：ALB→ クライアントからのHTTP/HTTPSリクエストを受け、複数のバックエンドサービスに振り分け
- バックエンド通信：NLB→ サービス間の超低遅延通信が必要な場合、マイクロサービス間のデータベースやキャッシュ層の通信をNLBで担当
このような多層構成にすることで、アプリケーション層の柔軟性と通信層の高性能を両立させることが可能とされています。
まとめ
ALBとNLBの選択は、アプリケーションの特性と要件によって決まるとされています。本記事の内容をまとめると以下の通りです：
- ALBは第7層で動作し、HTTPアプリケーション・マイクロサービス・コンテナオーケストレーション向けで、柔軟なルーティングが可能です
- NLBは第4層で動作し、超低遅延・高スループット・非HTTP通信・固定IP要件がある場合に選ばれます
- 大半のWebアプリケーションはALBで要件を満たす可能性が高く、特殊な要件（金融取引、IoT、ゲーム等）でNLBが検討される流れが多いとされています
- 実装前に現在のトラフィック量、将来の成長予測、遅延要件、プロトコル要件などを整理することが重要です
- AWS公式ドキュメント（Elastic Load Balancing ユーザーガイド）で最新の料金・性能情報を確認し、本番環境での導入を判断することをお勧めします
皆さんのアプリケーション要件に合わせて、適切なロードバランサーを選択されることを願っています。
免責事項
本記事の情報は執筆時点のものです。AWSのサービス仕様・料金・性能は予告なく変更される可能性があります。本番環境への導入前に、必ずAWS公式ドキュメント（Elastic Load Balancing ユーザーガイド）で最新情報をご確認ください。本記事の内容に基づいた判断による障害・損失につきまして、執筆者および提供元は一切の責任を負いかねます。
