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

最初に: 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 の終端をアプリ本体ではなく入口側で受けたい

要するに 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 も含まれます。

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

ユーザーは ALB にアクセスする
ALB が受け取ったリクエストをルールに従って振り分ける
正常な EC2 にだけ流す

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

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

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

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

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

1. ALB が入口になる

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

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

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

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

実務では次の形がよく出ます。

80 番で HTTP を受ける
443 番で 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 へアクセスする
ALB のリスナーが接続を受ける
ルールを評価して、対象のターゲットグループを決める
ターゲットグループ内の正常な 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 は入口の安定化、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 の別サービスと一緒に出てきます。最初は次のつながりを押さえると整理しやすいです。

EC2: 実際にアプリを動かすサーバー
Auto Scaling: EC2 の台数を増減する
CloudWatch: メトリクスや監視を見る
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つで十分です。

ALB は Web の入口
リスナーとルールで振り分ける
ターゲットグループの正常な EC2 に流す
ヘルスチェックと Auto Scaling までつなげて考える

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

まとめ

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

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

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

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

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

参考リンク

AWS Docs: What is an Application Load Balancer?
AWS Docs: Listeners for your Application Load Balancers
AWS Docs: Target groups for your Application Load Balancers
AWS Docs: Health checks for Application Load Balancer target groups