ELB（Elastic Load Balancing）ALB, NLB, GWLB, CLB

Black Belt

■ELB の特徴

数年前から Classic Load Balancer は選択できますが、別枠になっています。（2026年3月現在も一応 CLB は選択できます）そのうち使えなくなるのかなと思いますがいまだに使用できます。実際 Classic Load Balancer はシンプルで使い勝手がいいのでいまだに利用するユーザーはいそうですね。

ちなみに「Gateway Load Balancer（GWLB）」というサービスが誕生しています。

CLB の特徴

昔からある従来型のロードバランサーです。現在は新規設計なら通常 ALB か NLB を選択します。

細かく設計をしようとすると物足りないところがあるかもしれません。例えば複数のバックエンドサービスにトラフィックをルーティングする際は、サブドメインを分割するなどの構成にする必要があります。

ALB の特徴

ALB は、レイヤー 7（OSI モデルの第 7 層であるアプリケーションレイヤー）で動作します。（レイヤー 4 には対応していません）トラフィックを複数のアベイラビリティーゾーンの複数のターゲット(EC2 インスタンスなど) に分散して可用性を向上させます。

パスベースのルーティング（パスルーティング）のサポートをしているのでリクエスト内の URL に基づいてリクエストを転送するリスナーのルールを設定できます。URL の内容に基づいて適切なサービスにリクエストをルーティングできます。更にホスト名、HTTP ヘッダー などを見て振り分けることもできます。URL、ホスト名、HTTPヘッダーで振り分けができます。

コンテナ化されたアプリケーションもサポートしています。

Amazon Elastic Container Service (Amazon ECS) は、タスクをスケジュールするときに未使用のポートを選択し、そのポートを使用するターゲットグループにタスクを登録できます。また、ヘルスチェックを設定することで、ロードバランサーは正常なターゲットにのみリクエストを送信できます。

ALB で SNI（Server Name Indication、サーバー名表示）が利用可能

ALB で SNI が利用できます。

SNI を利用すると、1つの ALB に複数の FQDN が利用でき、それぞれのドメインに対してSSL/TLS証明書が利用できます。

NLB の特徴

• 開放型システム間相互接続 (OSI) モデルの第 4 層（L4）で機能します。
• 毎秒数百万のリクエストを処理できます。
• コンテナ化されたアプリケーションのサポート。

GWLB の特徴

ファイアウォールや IDS/IPS などの仮想アプライアンスに通信を通すためのロードバランサーです。普通の Web 振り分け用ではなく、セキュリティ機器を透過的に挟みたいときに使います。サーバーへ振り分ける ELB ではなく、通信を検査装置群へ通す ELB です。

リスナー（Listener）について

ELB には ALB、NLB、GWLB、CLB があり、それぞれリスナーの概念を持っています（GWLB は例外）。リスナー = 入口の受け方と言えます。

ALB のリスナーについて

リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。リスナー = 入口の受け方、ターゲットグループ = 転送先のまとまりと考えると分かりやすいです。ALB は、受けたリクエストに対して リスナールールを上から評価し、条件に合うターゲットグループへ転送します。

例えば、ALB の場合は以下の設定をすることが多いです。

• HTTP : 80
• HTTPS : 443

HTTPS のリスナーを作成するには、証明書が必要です。ALB の HTTPS リスナーでは、ACM の証明書や IAM に取り込んだ証明書を使えます。DigiCert などの外部ベンダーで購入した SSL 証明書をインポートして利用することも可能ですが、その場合は定期的に SSL 証明書を更新する必要があり、期限に間に合わないとエラーとなりユーザーがサイトにアクセスできなくなるなどのリスクがあります。そのため ACM で SSL 証明書を発行して紐づける運用にした方が自動で更新されるのでお勧めです。

ALB のリスナールールについて

ALB のリスナーはルールを持てます。例えば以下のようなルールを設定できます。

• example.com は Web 用ターゲットグループへ
• api.example.com は API 用ターゲットグループへ
• /images/* は画像用ターゲットグループへ

ドメインもサブドメインもパスに対しても振り分けるルールを設定できます。

ELB の暖気申請（Pre-warming）について

• NLB は暖気申請（Pre-warming）が不要です。

ELB の HTTP 応答コード（エラーコード）

ELB はエラーコードのメトリクスを CloudWatch に送信します。

• HTTPCode_Backend_5XX　←　登録済みインスタンスからサーバーエラー応答が送信された場合
• HTTPCode_ELB_5XX　←　ロードバランサーまたは登録されたインスタンスがエラーが原因であるか、またはロードバランサーが応答を解析できなかった場合
• HTTPCode_Backend_3XX　←　登録済みインスタンスからリダイレクト応答が送信された場合
• HTTPCode_Backend_4XX　←　登録済みインスタンスからクライアントエラー応答が送信された場合