ALBとELBの違い・使い分け完全ガイド｜AWS ELB入門（ALB/NLB/CLB）オンプレ経験者向け

「オンプレのF5 BIG-IPやHAProxyで負荷分散を組んできたけれど、AWSに移行したらELBのどのタイプを選べばいいのかわからない」——クラウド移行プロジェクトで、インフラ担当者が必ず直面する問題です。

オンプレ環境では、ロードバランサーの導入といえばF5 BIG-IPのようなハードウェアアプライアンスを購入するか、HAProxyやnginxをLinuxサーバーに入れてソフトウェアで構成するかの二択でした。いずれも初期費用、冗長構成の設計、ファームウェア更新、SSL証明書の管理まで自分たちで面倒を見る必要がありました。

この記事では、AWS Elastic Load Balancing（ELB）の基本から、ALBとNLBの違い、料金体系、よくあるトラブルまで、オンプレのロードバランサー運用経験者が押さえるべきポイントを体系的に解説します。

なぜELBなのか？オンプレのロードバランサーとの違い

オンプレでロードバランサーを運用してきた方なら、その運用負荷の高さは身に染みているはずです。F5 BIG-IPなら本体の購入費だけで数百万円、冗長構成にすれば倍。HAProxyで構築しても、サーバー障害時のフェイルオーバーやSSLオフロードの設定は自分で組まなければなりません。

AWS ELBは、こうした負荷分散の仕組みをフルマネージドで提供するサービスです。主な違いを整理します。

特にSSL証明書の管理は大きな差です。オンプレではLet’s Encryptの自動更新スクリプトを組んだり、商用証明書の期限管理をしたりと手間がかかりますが、ACMとELBを組み合わせれば証明書の発行から更新まで完全に自動化されます。

ALBとNLBの違い — どちらを選ぶべきか

AWS ELBには現在3つのタイプがありますが、実務で使うのはほぼALB（Application Load Balancer）とNLB（Network Load Balancer）の2つです。Classic Load Balancerは旧世代のため、新規構築では選ぶ理由がありません。

ALB（Application Load Balancer）

ALBはOSI参照モデルのレイヤー7（アプリケーション層）で動作します。オンプレでいえば、F5 BIG-IPのHTTPプロファイルやnginxのリバースプロキシに相当します。

・HTTPヘッダーやパスでルーティング: /api/* はバックエンドAへ、/web/* はバックエンドBへ、といったパスベースルーティングが可能
・ホストベースルーティング: api.example.com と www.example.com を1つのALBで振り分けられる
・WebSocket対応: 長時間接続が必要なアプリケーションにも対応
・AWS WAFとの統合: ALBにWAFルールを直接アタッチしてWebアプリケーションを保護できる

NLB（Network Load Balancer）

NLBはレイヤー4（トランスポート層）で動作します。オンプレでいえば、LVS（Linux Virtual Server）やF5のL4モードに近い動きです。

・TCP/UDP/TLSプロトコルに対応: HTTP以外のプロトコル（データベース接続、IoTデバイスのMQTT等）を扱える
・超低遅延: レイヤー4で処理するため、ALBより遅延が小さい
・固定IPアドレス: Elastic IPを割り当てられるため、ファイアウォールのホワイトリスト登録が必要な相手先との通信に向く
・大量同時接続: 数百万の同時接続を処理でき、ゲームサーバーやリアルタイム通信に適している

選定の判断基準

迷ったら、Webアプリケーションの負荷分散ならALB、それ以外のプロトコルや固定IPが必要ならNLBと覚えておけば、たいていのケースで正しい選択ができます。

AWS CLIでALBを作成する手順

マネジメントコンソールでも作成できますが、ここではインフラエンジニアが再現性のある手順として使えるAWS CLIでの作成例を示します。

1. ALBの作成

# ALBを作成（2つのパブリックサブネットを指定）
aws elbv2 create-load-balancer \
  --name my-web-alb \
  --subnets subnet-xxxxxxxx subnet-yyyyyyyy \
  --security-groups sg-zzzzzzzz \
  --scheme internet-facing \
  --type application

2. ターゲットグループの作成

# ターゲットグループを作成（ヘルスチェック付き）
aws elbv2 create-target-group \
  --name my-web-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-xxxxxxxx \
  --health-check-path /health \
  --health-check-interval-seconds 30 \
  --healthy-threshold-count 3 \
  --unhealthy-threshold-count 3

3. リスナーの作成

# HTTPS リスナーを作成（ACM証明書を指定）
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-web-alb/xxxxxxxxxx \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-targets/xxxxxxxxxx

オンプレでnginxのupstreamブロックを書いていた感覚に近いですが、ヘルスチェックやSSL終端が最初から組み込まれている点が大きな違いです。

料金の仕組み — LCU課金を理解する

ELBの料金体系は、オンプレの「機器を買い切り」とはまったく異なります。ALBの場合、以下の2つの要素で課金されます（2026年3月時点）。

・時間料金: ALB 1台あたり約$0.0225/時間（東京リージョン: ap-northeast-1）
・LCU（Load Balancer Capacity Units）料金: 実際のトラフィック量に応じた従量課金（約$0.008/LCU-時間）

LCUは以下の4つの指標のうち、最も消費量が多いものが適用されます。

・新規接続数: 1秒あたりの新規接続数
・アクティブ接続数: 1分あたりのアクティブ接続数
・処理バイト数: 1時間あたりの転送データ量
・ルール評価数: 1秒あたりのルール評価回数

一般的なWebアプリケーション（月間100万PV程度）であれば、ALB 1台の月額はおよそ$20〜$40程度に収まることが多いです。F5 BIG-IPの保守費用と比べれば、桁違いに安く済みます。

NLBの場合も基本構造は同じですが、LCUの代わりにNLCU（Network Load Balancer Capacity Units）で計算され、単価も若干異なります。

よくあるトラブルと対処法

ELBを運用していると、オンプレとは違った種類のトラブルに遭遇します。よくあるパターンと対処法を整理します。

1. ヘルスチェック失敗でターゲットがunhealthy

最も多いトラブルです。ターゲットインスタンスがunhealthyになると、ELBはそのインスタンスにトラフィックを送りません。

・原因1: ヘルスチェックパスが間違っている（/healthではなく/health/のようにスラッシュの有無）
・原因2: セキュリティグループでELBからのヘルスチェックポートが許可されていない
・原因3: アプリケーションの起動に時間がかかり、ヘルスチェックのタイムアウト内に応答が返らない

対処としては、まずターゲットグループの詳細画面でヘルスチェックのステータスコードとレスポンスを確認します。

# ターゲットのヘルス状態を確認
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-web-targets/xxxxxxxxxx

2. 502 Bad Gatewayエラー

ALBがバックエンドのターゲットに接続できない、またはターゲットが不正なレスポンスを返した場合に発生します。

・原因1: ターゲットインスタンスのアプリケーションがダウンしている
・原因2: ターゲットの応答がALBのアイドルタイムアウト（デフォルト60秒）を超えている
・原因3: すべてのターゲットがunhealthyで振り分け先がない

ALBのアクセスログを有効にしておくと、どのターゲットでエラーが発生したかを特定できます。オンプレのロードバランサーでtcpdumpを取っていたのと同じ感覚で、原因の切り分けに使えます。

3. クロスゾーン負荷分散の偏り

ALBではクロスゾーン負荷分散がデフォルトで有効ですが、NLBではデフォルトで無効です。AZ間でターゲット数が異なる場合、NLBではトラフィックが偏ることがあります。NLBでクロスゾーン負荷分散を有効にするか、各AZのターゲット数を揃えることで対処できます。

本記事のまとめ

AWS ELBは、オンプレのロードバランサーが抱えていた「初期費用」「冗長構成の設計」「SSL証明書管理」といった運用負荷を大幅に削減するサービスです。

オンプレでロードバランサーの設計・運用に苦労してきた方ほど、ELBの「設定するだけで冗長化・スケーリング・SSL管理が完結する」手軽さを実感できるはずです。まずはALBでWebアプリケーションの負荷分散から始め、TCP/UDPの要件が出てきたらNLBを検討する、という順序で進めてみてください。

Linuxサーバー上でのHAProxyやnginxの構築経験がある方は、姉妹サイトLinuxMaster.JPでリバースプロキシの基礎を復習しておくと、ALBの設定項目がより理解しやすくなります。

関連記事

• AWS Lambdaとサーバーレス設計入門 オンプレ経験者のためのアーキテクチャ移行ガイド
• AWS Well-Architectedフレームワーク入門 設計レビューで使える6本柱の実践ガイド
• マルチAZ構成とオートスケーリング入門 可用性を高めるAWS設計パターン

ALBとELBの違いを5項目で整理（OSIレイヤ・対応プロトコル・料金・機能・推奨用途）

「ELB」はAWSのロードバランサーサービス群の総称で、ALB（Application Load Balancer）はその中のL7特化型を指します。両者を並列に比較するのは厳密には誤りで、正しくはELBファミリー内のALB・NLB・CLBの3種類を5項目で整理する必要があります。料金体系も「時間単価＋LCU（Load Balancer Capacity Unit）」で共通ですが、LCUの計算ディメンションが種類ごとに異なる点に注意してください。

新規構築では原則ALBまたはNLBを選択し、CLBは2018年以降「Previous Generation」扱いのため避けるのが鉄則です。HTTP系トラフィックの90%以上はALBで要件を満たせる一方、固定IPが必要な場合や数百μs単位のレイテンシ要件がある場合はNLB一択となります。

ALB/NLB/CLB の使い分けフローチャート — ワークロード別の選択判断

3種類のロードバランサーを選択する判断基準は、実務では以下の4ステップで分岐させると迷いません。「①プロトコル → ②静的IPの要否 → ③レイテンシ要件 → ④L7ルーティング機能の必要性」の順に確認してください。

典型的なワークロード別の答えは明確です。WordPress等のWebサイトとECサイトはALB、オンラインゲームのリアルタイム通信とMQTTブローカーはNLB、SaaSのマルチテナント基盤はALB（ホストベースルーティング活用）、企業向けAPI Gatewayの前段で固定IPが必要な場合はNLB+ALBの二段構成が定石です。

なおCLBが残る数少ないケースは、EC2-Classicネットワーク上で稼働する10年以上前のレガシーシステムだけです。新規構築・移行案件では選択肢から外して問題ありません。

オンプレ F5 BIG-IP / HAProxy から AWS ELB への移行5ステップ（設定マッピング含む）

オンプレロードバランサーからAWS ELBへの移行は、設定項目を1対1で機械的にマッピングするのではなく、AWSのマネージドサービス特性に合わせて再設計するのが成功の鍵です。F5 BIG-IPのiRuleやHAProxyのACL設定をそのまま移植しようとすると破綻するため、以下5ステップで進めてください。

移行時の注意点は3つです。第一に、F5の複雑なiRule（TCL言語）はALB Listener Rulesでは表現しきれない場合があり、その際はLambda@EdgeまたはCloudFront Functionsとの組み合わせで代替します。第二に、SSL証明書はACM（AWS Certificate Manager）で無料発行できるため、商用証明書のコスト削減効果が大きい点を見積もりに反映してください。第三に、HAProxyのstickセッション（cookie insert）はALBのスティッキーセッション（duration_seconds最大7日）で代替可能ですが、アプリ側でセッション情報をElastiCacheに外出しする方が後々スケールしやすくなります。

移行スケジュールの目安は、小規模システム（VIP10個以下）で2週間、中規模（50個程度）で1-2ヶ月、F5のGTM相当のグローバル分散まで含む場合はRoute 53との組み合わせで3ヶ月以上を見込んでください。