EC2 で Web サーバーを1台立てられるようになると、「1台が落ちたらサイトが止まる」「アクセスが増えたら1台では足りない」という壁に当たります。教材ではここで ELB と Auto Scaling が出てきますが、ALB・NLB・GWLB の違いや、ヘルスチェックの意味があいまいなままだと、試験の選択肢の前で手が止まります。
この記事は、Elastic Load Balancing を「入口で受けて、正常なサーバーにだけ振り分ける仕組み」として捉え直し、3つの種類の違い、ヘルスチェック、Auto Scaling との組み合わせ、複数の AZ に置く理由までを順に整理します。
この記事の結論
- Elastic Load Balancing は、届いた通信を1つの入口で受けて、複数のターゲット（EC2・コンテナ・IP アドレスなど）に振り分けるサービスです。
- ALB は HTTP・HTTPS の中身（パスやホスト名）で振り分けるレイヤー7、NLB は TCP・UDP の接続を振り分けるレイヤー4、GWLB はファイアウォールなどの仮想アプライアンスを経由させるレイヤー3のロードバランサーです。
- ロードバランサーはヘルスチェックで各ターゲットを定期的に確かめ、正常と判定したターゲットにだけ通信を送ります。
- Auto Scaling グループで ELB のヘルスチェックを有効にすると、アプリが応答しなくなったインスタンスも入れ替えの対象になります。
- ALB は少なくとも2つの AZ のサブネットに置く決まりで、1つの AZ が止まっても別の AZ で受け続けられます。
Elastic Load Balancing とは（入口で受けて振り分ける）
Elastic Load Balancing（ELB）は、アプリへ届く通信を1つの入口で受けて、裏にいる複数のターゲットに分けて送るサービスです。ターゲットには EC2 インスタンス、コンテナ、IP アドレスなどを置けます。この入口をロードバランサーと呼びます。
たとえると、ロードバランサーは店の入口に立つ案内係です。お客さんは入口しか知らず、中に窓口が何個あるかを気にしません。案内係は、空いている窓口へ順に案内し、調子の悪い窓口には案内しません。窓口が増えても減っても、お客さんが覚える入口は1つのままです。
正確な言葉に戻すと、ロードバランサーは次の3つの部品でできています。
| 部品 | 役割 | たとえ |
|---|---|---|
| リスナー | どのプロトコルとポートで待ち受けるか（例: HTTPS の 443） | 入口の扉 |
| ルール | 届いた通信を、条件に応じてどのターゲットグループへ送るか | 案内の決まり |
| ターゲットグループ | 送り先の集まりと、そのヘルスチェックの設定 | 窓口の列 |
利用者から見える入口は、ロードバランサーの DNS 名です。独自のドメインで公開するときは、そのドメインの DNS の記録をこの名前に向けます。
ONE FRONT DOORリクエストの通り道
入口は1つ。正常なターゲットにだけ届く
-
DNS 名
利用者が知る入口
-
リスナー
HTTPS の 443 で待つ
-
ルール
/api ならこちら
-
グループ
ターゲットグループ
-
正常なターゲット
確認に通った台
ALB・NLB・GWLB は何が違うのか？
ELB には4つの種類があり、そのうち新しく作る構成で選ぶのは ALB・NLB・GWLB の3つです（Classic Load Balancer は前の世代）。違いは「通信のどこまでを読んで振り分けるか」、つまり OSI 参照モデルのどの層で動くかです。
| 見る点 | Application Load Balancer（ALB） | Network Load Balancer（NLB） | Gateway Load Balancer（GWLB） |
|---|---|---|---|
| 動く層 | レイヤー7（アプリケーション層） | レイヤー4（トランスポート層） | レイヤー3（ネットワーク層） |
| 扱う通信 | HTTP・HTTPS | TCP・UDP・TLS など | すべての IP パケット |
| 振り分けの条件 | パス・ホスト名・ヘッダーなど、HTTP の中身 | 接続（IP アドレスとポート） | 仮想アプライアンスの群れへ、行きと帰りを同じ経路で |
| 向く場面 | Web アプリ、マイクロサービスをパスで分ける | 独自の TCP・UDP、大量の接続、固定の IP アドレスが要るとき | ファイアウォールや侵入検知の製品を、通信の途中に挟むとき |
| 覚えておく性質 | HTTPS の証明書を ACM で付けられる。AWS WAF を関連付けられる | AZ ごとに固定の IP アドレスを持ち、インターネット向けなら Elastic IP も割り当てられる | アプライアンスとの間は GENEVE（UDP の 6081 番）で包んで送る |
THREE BALANCERSどこまで読むか
違いは、通信のどこまでを読んで振り分けるか
-
L7
ALB — HTTP・HTTPS の中身で振り分ける
パス・ホスト名で複数のサービスへ。ACM の証明書、AWS WAF
-
L4
NLB — TCP・UDP の接続を振り分ける
独自のプロトコル、大量の接続、AZ ごとの固定の IP アドレス
-
L3
GWLB — 検査の製品を通信の途中に挟む
ファイアウォールなどの仮想アプライアンス。GENEVE で包む
ALB は「中身を読める案内係」
ALB は HTTP のリクエストを読めるので、「/api で始まるものは API のサーバー群へ、それ以外は画面を返すサーバー群へ」のように、1つの入口の裏で複数のサービスに振り分けられます。HTTPS で公開するときは、AWS Certificate Manager（ACM）で発行した証明書をリスナーに付けると、証明書の更新の手間を減らせます。
NLB は「中身を読まずに速く渡す案内係」
NLB は HTTP の中身を見ず、接続の単位で振り分けます。独自の TCP のプロトコルや UDP を使うサービス、取引先に「この IP アドレスを許可してください」と伝える必要があるサービスでは、AZ ごとに固定の IP アドレスを持てる NLB が候補になります。
GWLB は「検査の関所へ通す係」
GWLB は、Web サーバーの前に置くものではありません。他社製のファイアウォールなどの仮想アプライアンスを複数台並べ、VPC に出入りする通信をそこへ透過的に通すためのものです。ルートテーブルで通信を GWLB のエンドポイントへ向けて使います。学習中の段階では「GWLB＝検査の製品を挟むためのもの」と覚えておけば、選択肢で迷いません。
CHECK 1ここまでの確認
URL が /api で始まるリクエストだけを別のサーバー群に送りたい。どのロードバランサーを選ぶ?
答えと解説
答え: 1. Application Load Balancer
URL のパスやホスト名は HTTP の中身なので、HTTP を読めるレイヤー7の ALB でないと条件にできません。NLB はレイヤー4で TCP や UDP の接続を振り分け、GWLB は仮想アプライアンスを経由させるためのものです。「ALB・NLB・GWLB の違い」の表を読み直してください。
ヘルスチェックとは（壊れた1台に送らない）
ロードバランサーが単なる「順番に配る係」で終わらないのは、ヘルスチェックがあるからです。ロードバランサーは、ターゲットグループに登録された各ターゲットへ、決まった間隔で確認のリクエストを送ります。決めた応答が返ってきたターゲットを正常（healthy）、返ってこないターゲットを異常（unhealthy）と判定し、正常なターゲットにだけ通信を送ります。
HEALTH CHECK送る台を選ぶ門
確認に応答した台だけに、通信を送る
ヘルスチェック（決めた間隔で /health を確かめる）
- 1号正常な応答を返す 送るAZ-a
- 2号アプリが応答しない 送らないAZ-a
- 3号正常な応答を返す 送るAZ-c
- 4号登録した直後 まだ送らないAZ-c・未確認
ヘルスチェックで決めるのは、主に次のことです。
- どのパス・ポートに確認のリクエストを送るか（例: /health）
- 何秒ごとに確かめるか
- 何回続けて失敗したら異常とするか、何回続けて成功したら正常に戻すか
登録したばかりのターゲットは、ヘルスチェックに1回通るまで正常と見なされません。起動に時間がかかるアプリでは、この間は通信が届かないことを知っておくと、デプロイの直後に慌てずに済みます。
もう1つ知っておきたいのは、ALB のターゲットグループですべてのターゲットが異常になったときは、健康状態に関係なく全部に送る（フェイルオープン）という振る舞いです。ヘルスチェックの設定を誤って全台が異常と判定されても、サイトが完全に止まるのを避けるための動きです。「異常のはずの台にも通信が来ている」と見えたら、まず全台が異常になっていないかを疑います。
Auto Scaling と組み合わせると何が起きるのか？
ELB は「いまいる台数に振り分ける」係で、台数そのものは増やしません。台数を増減するのは Amazon EC2 Auto Scaling の役目です。2つを組み合わせると、次のことが起きます。
- Auto Scaling グループがインスタンスを起動すると、ロードバランサーのターゲットグループに自動で登録される
- ヘルスチェックに通ると、そのインスタンスに通信が届き始める
- 負荷が下がって台数を減らすときは、ターゲットグループから外してから終了する
- 異常なインスタンスは、Auto Scaling が新しいものに入れ替える
注意が要るのは4つ目です。Auto Scaling グループの既定のヘルスチェックは、EC2 のステータスチェックだけです。EC2 のステータスチェックは「インスタンスが動いているか」を見るもので、アプリが固まっていてもインスタンス自体は動いているので、入れ替えの対象になりません。ELB のヘルスチェックを Auto Scaling グループでも有効にすると、ロードバランサーが異常と判定したインスタンスも入れ替えの対象になります。
もう1つの設定が、ヘルスチェックの猶予期間です。起動した直後のインスタンスはまだアプリの準備ができていないので、Auto Scaling はこの期間が過ぎるまでヘルスチェックの結果で入れ替えをしません。短すぎると、準備中のインスタンスを異常として入れ替え続けることになります。
| 見る点 | EC2 のステータスチェック（既定） | ELB のヘルスチェックを加えた場合 |
|---|---|---|
| 何を見るか | インスタンスと、その土台が動いているか | 決めたパスにアプリが正しく応答するか |
| アプリだけが固まったとき | 入れ替えない | 入れ替える |
| 設定するところ | 何もしなくても有効 | Auto Scaling グループで有効にする |
CHECK 2ここまでの確認
ALB からは異常と判定されているのに、Auto Scaling グループがそのインスタンスを入れ替えないのはなぜ?
答えと解説
答え: 1. Auto Scaling グループの既定のヘルスチェックは EC2 の状態だけを見ていて、ELB のヘルスチェックが有効になっていないから
Auto Scaling は既定では EC2 のステータスチェックで入れ替えを決めます。アプリだけが固まっていてもインスタンスは動いているので、ELB のヘルスチェックを加えないと入れ替わりません。「Auto Scaling と組み合わせると」の章を読み直してください。
なぜ複数の AZ に置くのか？
ロードバランサーを作るときは、どの AZ のサブネットに置くかを選びます。ALB は、少なくとも2つの AZ のサブネットを選ぶ決まりになっています。1つの AZ が使えなくなったり、その AZ に正常なターゲットがいなくなったりしても、別の AZ の正常なターゲットへ流し続けるためです。
ここで大事なのは、ロードバランサーだけを複数の AZ に置いても意味が薄いことです。ターゲット（EC2 インスタンス）も複数の AZ に分けて置き、Auto Scaling グループも複数の AZ にまたがるようにして、はじめて「1つの AZ が止まってもサービスが続く」構成になります。AZ の考え方は、リージョンと AZ の記事で整理しています。
READ ALSO — 未経験向け・段1 入口
リージョンと AZ の仕組み｜「どこに置くか」で、速さ・止まりにくさ・料金の何が変わるか
AZ をまたいだ振り分け方には、クロスゾーン負荷分散という設定があります。有効にすると、各 AZ にあるロードバランサーの窓口（ノード）が、AZ をまたいで全部のターゲットに均等に配ります。ALB ではロードバランサーの単位では常に有効で、NLB と GWLB では既定で無効です。AZ ごとのインスタンスの数に偏りがあるときに効いてくる設定なので、NLB を使うときは既定の値を意識しておきます。
CHECK 3ここまでの確認
ALB を作るときに、サブネットについて求められることは?
答えと解説
答え: 2. 少なくとも2つの AZ から、それぞれサブネットを選ぶ
ALB は少なくとも2つの AZ のサブネットを選ぶ決まりです。1つの AZ が使えなくなっても、別の AZ の正常なターゲットへ流し続けるためです。「なぜ複数の AZ に置くのか」の章を読み直してください。
まとめ
- Elastic Load Balancing は、1つの入口で受けた通信を、正常なターゲットにだけ振り分けるサービスです。
- HTTP の中身で振り分けるなら ALB、TCP・UDP の接続を速く渡したり固定の IP アドレスが要ったりするなら NLB、検査の製品を通信の途中に挟むなら GWLB を選びます。
- ヘルスチェックに通ったターゲットにだけ通信が届き、全台が異常になったときはフェイルオープンの振る舞いをします。
- Auto Scaling と組み合わせるときは、ELB のヘルスチェックを Auto Scaling グループでも有効にして、アプリが固まったインスタンスも入れ替わるようにします。
- ロードバランサーもターゲットも複数の AZ に置いて、はじめて1つの AZ の障害に耐える構成になります。
参照ソース
- What is Elastic Load Balancing? — ELB の定義、ターゲットの種類、4つのロードバランサーの種類（2026年9月時点の AWS 公式ドキュメント）
- How Elastic Load Balancing works — AZ ごとのノード、クロスゾーン負荷分散の既定の値（2026年9月時点の AWS 公式ドキュメント）
- What is an Application Load Balancer? — レイヤー7、リスナー・ルール・ターゲットグループ、パスによる振り分け（2026年9月時点の AWS 公式ドキュメント）
- Health checks for Application Load Balancer target groups — ヘルスチェックの仕組み、正常なターゲットにだけ送ること、全台が異常のときのフェイルオープン（2026年9月時点の AWS 公式ドキュメント）
- Update the Availability Zones for your Application Load Balancer — 少なくとも2つの AZ のサブネットを選ぶ決まり（2026年9月時点の AWS 公式ドキュメント）
- What is a Network Load Balancer? — レイヤー4、TCP・UDP・TLS、AZ ごとの固定の IP アドレス（2026年9月時点の AWS 公式ドキュメント）
- What is a Gateway Load Balancer? — レイヤー3、仮想アプライアンス、GENEVE（2026年9月時点の AWS 公式ドキュメント）
- Health checks for instances in an Auto Scaling group — 既定は EC2 のステータスチェックであること、ELB のヘルスチェックの有効化、猶予期間（2026年9月時点の AWS 公式ドキュメント）
