サーバー ネットワーク 公開日 2026.04.24 更新日 2026.05.15

ALBとは?複数EC2へ振り分ける入口の基本をAWSで整理

ALBとは何かを、複数EC2へ振り分ける入口として整理します。ロードバランサーとの関係、リスナーとルール、ターゲットグループ、ヘルスチェック、Auto Scalingと組み合わせる意味まで初心者向けにまとめます。

先に要点

  • ALBは、複数の EC2 へ HTTP / HTTPS のリクエストを振り分ける AWS の入口サービスです。
  • リスナーが待ち受け、ルールでターゲットグループを選び、その中の正常な EC2 に流します。
  • ヘルスチェックで、応答できない EC2 をルーティング対象から外せます。
  • ALB は入口の安定化、Auto Scaling は台数調整の自動化を担当し、セットで使われることが多いです。

最初に: ALB は「複数のEC2へ振り分けるWebの入口」

AWSでWebアプリを動かし始めると、EC2 を1台だけ置く構成から、2台以上へ広げたくなる場面が出てきます。
そのときに必要になるのが ALB です。

ALB は Application Load Balancer の略で、AWS の ロードバランサー の一種です。
外部から来た HTTP / HTTPS のリクエストを受け取り、どの EC2 に渡すかを判断して振り分けます。たとえば次のような状況で使います。

台数

台数を増やしたい

Webアプリの台数を1台から2台、3台へ増やしたい

障害

止まりにくくしたい

1台が落ちても、残りの台へ流して止まりにくくしたい

振り分け

パスで分けたい

example.com/app はアプリA、example.com/admin はアプリBへ分けたい

HTTPS

入口で終端したい

HTTPS の終端をアプリ本体ではなく入口側で受けたい

ALB は Web アプリの入口の交通整理役

要するに ALB は、単なる「分散装置」ではなく、Webアプリの入口に置く交通整理役です。

この記事は 2026年4月24日時点の AWS 公式ドキュメントをもとに整理しています。主に What is an Application Load Balancer? Listeners for your Application Load Balancers Target groups for your Application Load Balancers Health checks for Application Load Balancer target groups を参照しています。

ALBとは何か

AWS公式では、Application Load Balancer は複数のターゲットへトラフィックを分散し、正常なターゲットにだけルーティングすると説明されています。
ここでいうターゲットには EC2 だけでなく、コンテナや IP アドレス、場合によっては Lambda も含まれます。

ただ、最初に覚えるなら次の理解で十分です。

読み込み中...

この形にしておくと、アプリの台数を増やしても URL を変えずに運用しやすくなります。
ユーザーは ALB の DNS 名や独自ドメインへアクセスするだけで、裏側でどの EC2 が応答したかを意識しません。

まず押さえたい4つの部品

ALB を理解するときは、次の4つをセットで見ると分かりやすいです。

部品 役割
ALB 外からのリクエストを受ける入口
リスナー どのポート・プロトコルで待ち受けるか
ルール どの条件のリクエストをどこへ流すか
ターゲットグループ 実際に流し込む先のまとまり
ルールを見てターゲットグループを選ぶ

特に大事なのは、ALB が直接 EC2 を細かく判断するというより、「ルールを見てターゲットグループを選ぶ」という流れです。

1. ALB が入口になる

ALB はクライアントから見た単一の窓口です。
複数の EC2 を裏に置いていても、利用者はその台数を意識せず、まず ALB に接続します。

この構成にすると、EC2 を入れ替えたり増減したりしても、入口を変えずに済みます。
運用側にとっては、構成変更を表に出しにくいのが大きな利点です。

2. リスナーが待ち受ける

リスナーは、ALB がどのプロトコル・ポートで接続を受けるかを決める部分です。
AWS公式では ALB のリスナーは HTTP / HTTPS を扱います。実務では次の形がよく出ます。

HTTP

80 番

80 番で HTTP を受ける

HTTPS

443 番

443 番で HTTPS を受ける

リダイレクト

HTTP から HTTPS へ

80 へ来たアクセスを 443 へリダイレクトする

このとき HTTPS の証明書は ALB 側で扱えるので、各 EC2 に同じ証明書設定を配る運用を減らせます。

3. ルールが振り分け方を決める

ALB の強みは、ただ均等に振り分けるだけではなく、HTTP レベルの情報で行き先を分けられることです。たとえば次のような分け方ができます。

ホスト名

ホストで分ける

example.com と admin.example.com で行き先を分ける

パス

パスで分ける

/api/* と /app/* で行き先を分ける

条件

条件で分ける

特定の条件に合うものだけ別サービスへ送る

AWS公式でも、ホスト名やパス、HTTP ヘッダー、メソッド、クエリ文字列、送信元IPなどに基づくルーティングに対応すると説明されています。
この性質があるので、ALB は「Webアプリの入口」と相性が良いです。

4. ターゲットグループが実際の配送先

ターゲットグループは、リクエストを流し込む先のまとまりです。
ALB はルールでターゲットグループを選び、その中の正常なターゲットへ配送します。

最初は EC2が2台入ったグループ くらいの理解で大丈夫です。
ただし実際には、AWS公式のとおりターゲットタイプとして instance ip lambda などを選べます。

初心者が EC2 構成で覚えるべきこと

EC2 そのものではなく、ターゲットグループ単位で考える。ヘルスチェックもターゲットグループごとに設定する。Auto Scaling とつなぐと、増減した EC2 を自動登録しやすい。

どうやって複数EC2へ振り分けるのか

構成をシンプルに書くと、流れは次のとおりです。

ユーザー ALB リスナー ルール ターゲットグループA EC2(正常) EC2(正常) ターゲットグループB EC2(正常) EC2(異常)
ルールでターゲットグループを選び、その中の正常な EC2 にだけ流す
  1. ユーザーが ALB へアクセスする
  2. ALB のリスナーが接続を受ける
  3. ルールを評価して、対象のターゲットグループを決める
  4. ターゲットグループ内の正常な EC2 へ流す

このとき ALB は、常に全部の EC2 に無条件で投げるわけではありません。
正常と判断できるものを見ながら送るので、障害時の逃がし先としても機能します。

振り分けのアルゴリズムは選べる

AWS公式では、ALB はターゲットグループ単位でルーティングし、デフォルトのルーティングアルゴリズムは round robin、代わりに least outstanding requests も選べると説明されています。つまり、単純な均等配分だけでなく、混み具合を見た配分もできます。

ヘルスチェックがなぜ重要なのか

ALB を入れる意味は「複数台に流せる」だけではありません。
本当に大事なのは、どの EC2 が今まともに応答できるかを見ていることです。

ALB ではターゲットグループごとにヘルスチェックを設定できます。
たとえば /health のようなURLへ定期的にアクセスし、期待したステータスコードが返るかを確認します。ここで重要なのは次の点です。

不十分

起動しているだけ

EC2 が起動しているだけでは不十分

確認する

アプリが応答できるか

アプリが応答できるかまで確認して初めて意味がある

外す

失敗したターゲット

失敗したターゲットは配信先から外せる

AWS公式ドキュメントでも、ターゲットは初回のヘルスチェックを通過してからリクエストを受けられるとされています。
逆に失敗すると unhealthy と見なされ、ルーティング対象から外れます。

よくある勘違い

EC2 が起動中 = 使える とは限りません。

OS は起動していてもアプリは壊れている状態

アプリケーションプロセスが落ちている。DB接続エラーで 500 を返している。タイムアウトで応答が返らない。こういうときにヘルスチェックがあると、壊れた1台へ延々と流し続けるのを避けやすくなります。

ALB と Auto Scaling はなぜ一緒に語られるのか

ALB を理解したあとで自然につながるのが Auto Scaling です。

ALB だけでも複数台へ振り分けはできますが、台数の増減を人手でやっていると、負荷変動への追従が遅れます。
そこで Auto Scaling Group とターゲットグループをつなぐと、起動した EC2 を自動で登録し、終了した EC2 を外しやすくなります。

この組み合わせが強い理由は次のとおりです。

  • 入口は ALB のまま変えずに済む
  • 裏の EC2 だけを増減できる
  • 新しい EC2 もヘルスチェック通過後に受け入れやすい

ALB の担当

入口の安定化

入口は ALB のまま変えずに、正常な EC2 へ流します。

Auto Scaling の担当

台数調整の自動化

起動した EC2 を登録し、終了した EC2 を外します。

つまり、ALB は入口の安定化、Auto Scaling は台数調整の自動化を担当します。
役割が違うので、セットで使われることが多いです。

ALB が向いている場面

ALB は次のような場面で特に向いています。

場面 1

Webアプリを複数台で動かしたい

もっとも典型的な用途です。1台構成だと、障害もメンテナンスもそのまま停止に直結します。ALB を前段に置いて複数 EC2 を束ねると、止まりにくい構成へ近づけます。

場面 2

パスやホスト名で行き先を分けたい

たとえば example.com/ はフロント、example.com/api/ はAPI、admin.example.com/ は管理画面、という整理です。このように URL やホストで分けたいなら、ALB のルールベースルーティングが噛み合います。

場面 3

HTTPS終端をまとめたい

証明書や TLS 設定を各 EC2 に個別で持たせるより、ALB 側で終端したほうが運用が整理しやすい場面があります。AWS公式でも HTTPS リスナーで証明書を扱えることが案内されています。

場面 4

WebSocket や HTTP/2 を使いたい

AWS公式では、ALB は WebSocket をネイティブサポートし、HTTPS リスナーでは HTTP/2 も扱えます。リアルタイム通信や近代的なWeb構成でも選択肢に入ります。

ALB が向かない、または注意したい場面

ALB は便利ですが、何にでも最適というわけではありません。

1. L4中心の要件なら別のLBのほうが合うことがある

ALB はアプリケーション層、つまり HTTP / HTTPS の入口として強いサービスです。そのため、TCP レベルの透過転送を重視する要件では、別のロードバランサーのほうが向くことがあります。AWS公式でも、ターゲット側で暗号化された 443/TCP をそのまま通したい場合は、Network Load Balancer の TCP リスナーを案内しています。

2. 置けば自動で高可用になるわけではない

ALB だけ置いても、裏側が1台しかなければ、その1台が止まると結局サービスは止まります。高可用性を狙うなら、少なくとも複数の Availability Zone にまたがって EC2 を配置する考え方が重要です。

3. ヘルスチェックの設計が雑だと意味が薄い

/ にアクセスして 200 が返れば健康、としているだけだと、本当に見たい故障を拾えないことがあります。アプリの性質に応じて、どのURLを、何秒で、どのステータスコードなら成功とするかを設計する必要があります。

まず覚えると理解しやすい関連サービス

ALB のまわりは AWS の別サービスと一緒に出てきます。最初は次のつながりを押さえると整理しやすいです。

1. サーバー

EC2

実際にアプリを動かすサーバー

2. 台数

Auto Scaling

EC2 の台数を増減する

3. 監視

CloudWatch

メトリクスや監視を見る

4. 防御

WAF

ALB の前で Web リクエストを制御する

AWS公式でも、ALB は EC2、Auto Scaling、CloudWatch、WAF などと連携する前提で説明されています。
ALB 単体ではなく、入口まわりの基盤として見たほうが理解しやすいです。

よくある誤解

誤解 1

ALB は DNS みたいなもの

似ているようで違います。DNS は名前解決、ALB は受けたHTTP/HTTPSリクエストの振り分けです。役割が別です。

誤解 2

ALB があれば全部の障害を隠せる

そこまではできません。裏側すべてが落ちていれば、当然どこへ流しても失敗します。ALB は入口の整理役であって、アプリそのものを直すものではありません。

誤解 3

2台に増やせば自動で最適化される

単に台数を増やすだけでは足りません。セッション管理、アプリのステートレス化、ヘルスチェック、Auto Scaling 連携まで含めて考えたほうが運用は安定しやすくなります。

最初に押さえるべきか

最初の学習順としては、次の4つで十分です。

読み込み中...

この4つが見えてくると、ALB を「複数EC2へ均等に流す箱」としてではなく、Webアプリを止まりにくくしながら運用しやすくする入口 として理解しやすくなります。

ALBに関するよくある質問

Q. ALB と NLB の違いは?

A. ALB は L7(HTTP/HTTPS、パスベースルーティング、SSL 終端)、NLB は L4(TCP/UDP、超高速、固定IP)。Web アプリ = ALB、高性能 TCP = NLB、と使い分けます。

Q. ALB の料金は?

A. 時間料金($0.0243/h、月約 $17.5) + LCU(Load Balancer Capacity Unit)料金。月数千円〜数万円が一般的。NAT Gateway よりは安め ですが、無視できないコスト要素。

Q. リスナールールとは?

A. ALB に来たリクエストを どのターゲットグループに振り分けるか のルール。パス(/api → API、/* → Web)、ホストヘッダー(api.example.com → A、www.example.com → B)、HTTP メソッド などで振り分け可能。

Q. SSL 証明書はどう設定する?

A. AWS Certificate Manager(ACM)で無料証明書を発行し、ALB のリスナーに設定。HTTPS 通信は ALB で終端 → 内部は HTTP の構成が一般的。

Q. WAF と組み合わせられますか?

A. はい、ALB + AWS WAF で 攻撃の前段ブロック + アプリ前ルーティング が可能。SQLi、XSS、Bot 攻撃 などを ALB の前でブロックします。

Q. ヘルスチェックの設定は?

A. パス(例: /health)、間隔、タイムアウト、成功/失敗閾値、を設定。30秒間隔 + 5回連続成功で healthy、3回連続失敗で unhealthy のような設定が定番。アプリ側で軽い /health エンドポイントを実装します。

Q. ALB と CloudFront の違いは?

A. CloudFront は CDN(エッジ配信)、ALB はオリジンへの振り分け。CloudFront → ALB → EC2 のように組み合わせると、配信高速化 + ルーティング + キャッシュ がフルに使えます。

まとめ

ALB は、複数の EC2 へ HTTP / HTTPS のリクエストを振り分ける AWS の入口サービスです。
ただ均等に流すだけでなく、リスナー・ルール・ターゲットグループ・ヘルスチェックを使って、正常なサーバーへ送り分けられるのがポイントです。

最初は次の理解で十分です。

  • ALB = Webの入口
  • ルールで行き先を決める
  • ターゲットグループ内の正常な EC2 に流す
  • Auto Scaling と組み合わせると運用しやすい

この流れが分かると、EC2 を1台構成から複数台構成へ広げるときに、なぜ ALB がよく一緒に出てくるのかが見えてきます。

この記事と一緒に読みたい

  1. EC2とは?仮想サーバーの基本をAWS初心者向けに整理
  2. Auto Scalingとは?EC2の台数を自動で増減する基本をAWSで整理
  3. NAT Gatewayとは?private subnet がそのままでは外へ出られない理由
  4. CloudFormationとは?AWS構成をコードで管理する基本
  5. ロードバランサー

参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。