AWS ELB入門 ALBとNLBの違いと使い分け オンプレ経験者のためのロードバランサー移行ガイド

「オンプレの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の設定項目がより理解しやすくなります。