AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

ELB と Auto Scaling

ELB（Elastic Load Balancing）はリクエストを複数のサーバーに振り分け、Auto Scaling はサーバーの台数を需要に合わせて自動で増減します。SAA では、この 2 つを複数 AZ にまたがって組み合わせる「止まらない・無駄のない」設計が頻出です。

ひとことで言うと: ELB は「受付係」、Auto Scaling は「人手を増減させる店長」です。

たとえるなら、受付係（ELB）が来店客を空いている窓口へ案内し、店長（Auto Scaling）は行列の長さを見て窓口の担当者を増やしたり減らしたりします。ある支店（AZ）が停電したら、別の支店で担当者を補充します。

このページで押さえる論点

ELB の仕組みと高可用性

ELB は、利用者からのリクエストを受け取って、ターゲットグループ（振り分け先をまとめたグループ）に登録されたターゲットへ分散します。ALB の場合、ターゲットには EC2 インスタンス、IP アドレス、Lambda 関数を指定できます。

ELB はヘルスチェック（定期的な生存確認）をターゲットグループ単位で行い、異常と判定したターゲットへの新しいリクエストを止めます。検知までの間や、すでに処理中のリクエストではエラーになることがあります。正常なターゲットが残っていれば、その後の新しいリクエストをそちらへ振り分けます。

利用者から見える入口は ELB の DNS 名（アドレス）1 つです。その裏で ELB は、指定した AZ ごとにロードバランサーノード（ELB の実体）を作ります。ALB を作るときは、少なくとも 2 つの AZ のサブネットを選ぶ必要があります。ALB の既定の振り分け方式はラウンドロビン（順番に割り当てる方式）です。

再生型アニメ図解

ALB が複数 AZ の EC2 に振り分ける

利用者 AZ-a AZ-c ALB EC2 ① EC2 ③ EC2 ② EC2 ④ ✕ 異常（Unhealthy）

※簡略化しています: リクエストを 1 件ずつ順番に動かしていますが、実際は多数のリクエストが同時に処理されます。異常の検知までや処理中の通信が必ず成功するとは限りません。ALB の既定の振り分け方式はラウンドロビン（順番に割り当てる方式）で、ほかの方式も選べます。ALB 自体も各 AZ に配置されますが、図では 1 つにまとめています。

図では ALB を 1 つの箱にまとめていますが、実際は AZ ごとにノードがあります。そのため AZ-a が止まっても、AZ-c のノードとターゲットで処理を続けられます。ELB 自体が単一障害点（そこが壊れると全体が止まる箇所）にならないのはこのためです。

ロードバランサーの種類と選び方

SAA で問われるのは ALB・NLB・GWLB の 3 種類です。「どの層（レイヤー）の情報を見て振り分けるか」で役割が分かれます。

種類動く層・扱う通信得意なこと選ぶ目安
ALB（Application）レイヤー 7（アプリケーションの中身を見る層）。HTTP / HTTPSURL のパス（/api など）やホスト名で振り分け先を変える。HTTPS の暗号化を ALB で終わらせる。Lambda 関数もターゲットにできるWeb アプリ、マイクロサービス
NLB（Network）レイヤー 4（ポート番号までを見る層）。TCP / UDP / TLS など非常に多くの接続を低遅延でさばく。AZ ごとに静的 IP アドレスを持ち、Elastic IP も割り当てられる。PrivateLink のエンドポイントサービスに使える固定 IP が必要、TCP/UDP のゲームや IoT、他 VPC へのサービス公開
GWLB（Gateway）レイヤー 3（IP パケットの層）。すべてのポートの IP パケットファイアウォールなどの仮想アプライアンス（ソフトウェアで動く専用装置）を通信経路に挟み、台数を増減させる他社製のファイアウォール・侵入検知／防止（IDS/IPS）製品で通信を検査したい

NLB の固定 IP と PrivateLink

NLB は、有効にした AZ ごとにネットワークインターフェイスを作り、そこから静的 IP アドレスを得ます。インターネット向けの NLB なら、サブネットごとに 1 つの Elastic IP アドレス（固定のパブリック IP）を関連付けられます。「取引先のファイアウォールで接続先の IP アドレスを許可リストに登録する必要がある」という要件は NLB を選ぶ合図です。

AWS PrivateLink は、自分の VPC で動かしているサービスを、インターネットを通さずに他の VPC や他の AWS アカウントへ公開する仕組みです。公開する側はエンドポイントサービスを作り、その裏にロードバランサーを置きます。NLB または GWLB を使えます。ALB のパス・ホスト名ルーティングも必要なら、NLB のターゲットに ALB を登録して、NLB + PrivateLink + ALB の構成にできます。

GWLB（Gateway Load Balancer）

GWLB はレイヤー 3 で動き、すべてのポートの IP パケットを受け取って、登録した仮想アプライアンスへ配ります。GWLB とアプライアンスの間は GENEVE というプロトコル（ポート 6081）でやり取りします。アプリケーション側の VPC には GWLB エンドポイント（VPC エンドポイントの一種）を置き、VPC の境界を越えて通信を検査用の VPC へ受け渡します。利用者やアプリから見ると経路の途中に透過的に挟まる「関所」で、アプライアンスの台数は需要に合わせて増減できます。

振り分けの細かい設定

クロスゾーン負荷分散

クロスゾーン負荷分散は、各 AZ のロードバランサーノードが他の AZ のターゲットにも振り分けるかどうかの設定です。有効なら、各ノードはすべての AZ のターゲットに分散します。無効なら、各ノードは自分の AZ のターゲットにだけ送ります。

たとえば AZ-a に 2 台、AZ-b に 8 台のターゲットがあるとします。有効なら 10 台がそれぞれ 10% ずつ受け取ります。無効だと、ノードごとに利用者の通信の 50% を自分の AZ の中だけで分けるため、AZ-a の 2 台は 25% ずつ、AZ-b の 8 台は 6.25% ずつとなり、負荷が偏ります。

種類クロスゾーン負荷分散の既定
ALBロードバランサー単位では常に有効（ターゲットグループ単位で無効にできる）
NLB既定で無効（作成後いつでも有効にできる）
GWLB既定で無効（作成後いつでも有効にできる）

登録解除の遅延（Connection Draining）

スケールインやメンテナンスでターゲットをロードバランサーから外すとき、いきなり切り離すと処理中のリクエストが途中で失敗します。登録解除の遅延を使うと、外すターゲットには新しいリクエストを送らず、処理中のリクエストが終わるまで待ってから登録解除を完了します。既定では 300 秒待ちます。Classic Load Balancer では同じ働きの機能を Connection Draining と呼びます。

スティッキーセッション

スティッキーセッション（セッション維持）は、同じ利用者のリクエストを同じ正常なターゲットへ送り続ける機能です。ALB は Cookie（ブラウザに保存される小さなデータ）を使って送り先を覚えます。ターゲットが異常と判定されれば、ALB はそのターゲットへのルーティングを止めます。一方、セッション情報をサーバー内だけに持たせていると、そのサーバーが停止した場合に情報を失うことがあります。SAA では、セッション情報を ElastiCache や DynamoDB に外出しし、どのサーバーが処理してもよい状態（ステートレス）にする設計が望ましいとされます。

HTTPS 通信の暗号化（SSL/TLS 終端・ACM・SNI）

ALB で HTTPS を受けるには、HTTPS リスナー（待ち受けの設定）に SSL/TLS のサーバー証明書を少なくとも 1 つ置きます。ALB は利用者との暗号化通信をそこで終わらせ（SSL/TLS 終端）、復号してからターゲットへ送ります。ターゲットグループのプロトコルを HTTPS にすれば、ALB からターゲットまでの通信も暗号化できます。暗号化・復号の処理を EC2 から肩代わりできるので、SSL オフロードとも呼ばれます。

証明書は AWS Certificate Manager（ACM）で作るのが推奨です。ACM が発行して ELB に置いた証明書は、期限切れの前に ACM が自動で更新を試みるため、更新忘れによる障害を防げます。

SNI（Server Name Indication）は、利用者が接続時に「どのホスト名に接続したいか」を伝える仕組みです。ALB は 1 つの HTTPS リスナーに複数の証明書を登録でき、利用者が伝えたホスト名に合う証明書を選びます。これにより、複数のドメイン（例: shop.example.com と blog.example.net）を 1 つの ALB でまとめて HTTPS 化できます。

Auto Scaling グループの基本

Auto Scaling グループ（ASG）は、EC2 を最小・希望・最大の 3 つの台数で管理します。希望容量（今あるべき台数）はスケーリングポリシーによって変わりますが、必ず最小〜最大の範囲に収まります。

Auto Scaling が行うのは、台数を増減する水平スケーリング（スケールアウト／スケールイン）です。インスタンスタイプを大きくする垂直スケーリング（スケールアップ）は行いません。台数で調整するので、負荷が下がった時間帯は台数を減らしてコストを抑えられます。

ASG に複数 AZ のサブネットを指定すると、Auto Scaling は各 AZ の台数が等しくなるように、台数が最も少ない AZ で新しいインスタンスを起動します。1 つの AZ が使えなくなると別の AZ で起動して補い、AZ が復旧すると AZ 間の台数を自動で均等に戻します。「ELB + 複数 AZ にまたがる ASG」が高可用性の基本形です。

起動テンプレート

起動テンプレートは、ASG が起動する EC2 の設計図です（AMI、インスタンスタイプ、セキュリティグループなど）。古い起動設定に代わるもので、AWS は起動テンプレートの利用を推奨しています。

Auto Scaling のヘルスチェック

ASG の既定のヘルスチェックは EC2 のステータスチェックで、インスタンス自体の故障しか検知できません。ELB のヘルスチェックを追加すると、EC2 は動いているのにアプリが応答しない場合も異常と判定され、Auto Scaling がそのインスタンスを新しいものに置き換えます。起動直後のインスタンスには、準備が整うまで追加のヘルスチェックを待つヘルスチェック猶予期間があります。

スケーリングの方法

「いつ・何を基準に台数を変えるか」によって、次の方法から選びます。動的スケーリング（ターゲット追跡・ステップ・シンプル）は CloudWatch のメトリクス（CPU 使用率などの数値）をもとに動きます。

方法動き方向いている場面
ターゲット追跡指標を目標値に保つように台数を自動計算する（例: 平均 CPU 使用率 50%、ALB のターゲットあたりのリクエスト数）多くの場面での第一候補。AWS が強く推奨
ステップCloudWatch アラームのしきい値を超えた幅に応じて、段階的に増減する台数を変える大きく超えたら一気に増やしたいなど、細かく制御したい
シンプルアラームで決まった台数だけ増減し、クールダウンが終わるまで次の増減をしないAWS はベストプラクティスとして使わないことを推奨
スケジュール指定した日時に希望容量や最小・最大を変える毎朝 9 時の始業時など、時刻の決まった変動
予測負荷の履歴から日ごと・週ごとのパターンを見つけ、予想される負荷の前に台数を増やす営業時間と夜間・週末で規則的に変わる負荷、起動に時間がかかるアプリ
手動希望容量を手で変える一時的な調整

下のシミュレーターはターゲット追跡スケーリングの例です。「平均 CPU 使用率を 50% に保つ」と目標を決めておくと、Auto Scaling が必要な台数を計算して希望容量を変えます。ただし最大を超えて増えたり、最小を下回って減ったりはしません。

操作できるシミュレーター

アクセス量と AZ 障害で台数がどう変わるか

設定: 最小 2 台 ／ 最大 8 台 ／ 目標 CPU 使用率 50%（EC2 1 台は 100 リクエスト/秒で CPU 100% になると仮定）

ALB AZ-a AZ-c

※簡略化しています: CPU 使用率はアクセス量に比例すると仮定し、ターゲット追跡スケーリングで計算した台数をすぐに反映しています。実際はメトリクスの収集間隔・インスタンスの起動時間・ウォームアップがあり、台数を減らす（スケールイン）ときはゆっくり慎重に行われます。AZ の復旧後は、Auto Scaling が AZ 間の台数を自動で均等に戻します。

クールダウンとウォームアップ

シミュレーターは計算した台数をすぐ反映していますが、実際には新しいインスタンスが起動して処理できるようになるまで時間がかかります。その間に「まだ CPU が高い」と判断して増やし過ぎないための仕組みが 2 つあります。

仕組み使うポリシー内容
クールダウンシンプルスケーリングスケーリングの後、次のスケーリングを始めるまで待つ時間。既定は 300 秒
ウォームアップターゲット追跡・ステップスケーリング起動したばかりのインスタンスを、ウォームアップが終わるまでグループの集計メトリクスに数えない。クールダウンを待たずにすぐ次のスケールアウトを始められる

ターゲット追跡スケーリングは、負荷が減ったときは徐々にスケールインして、可用性を優先します。スケールアウトの途中（ウォームアップ中）は、ポリシーによるスケールインが止められます。

ライフサイクルフック

ライフサイクルフックは、インスタンスの起動時や終了時に一時停止させ、その間に独自の処理を差し込む機能です。処理が終わったら「続行」を通知すると次の状態へ進みます。

タイミング待機状態使い方の例
スケールアウト（起動）Pending:Wait必要なソフトウェアをインストールし、準備が整ってからリクエストを受け始める（ELB に登録されるタイミングを制御する）
スケールイン（終了）Terminating:Wait終了する前にログやデータを取り出す。EventBridge の通知から Lambda 関数を呼び出して処理する

待機する時間（ハートビートタイムアウト）の既定は 1 時間です。

問題文のキーワード → 選ぶべき答え

問題文によく出る言い回し選ぶべき答えと理由
「URL のパス」「ホスト名」で振り分け先を変えたいALB。レイヤー 7 で HTTP の中身を見て振り分けられる
「固定 IP アドレス」「取引先が IP を許可リストに登録」NLB（+ Elastic IP）。AZ ごとに静的 IP を持つ
「TCP / UDP」「非常に多くの接続」「超低遅延」NLB。レイヤー 4 で大量の接続をさばく
「サードパーティ製のファイアウォール／IDS/IPS で通信を検査」GWLB。仮想アプライアンスを経路に透過的に挟み、台数も増減できる
「自社サービスを他の VPC・他アカウントへ、インターネットを通さず公開」NLB + PrivateLink（エンドポイントサービス）
「PrivateLink で公開し、URL パスでも振り分けたい」NLB + PrivateLink + ALB。NLB のターゲットに ALB を登録する
「EC2 の暗号化処理の負荷を減らす」「証明書の更新の手間を減らす」ALB で SSL/TLS 終端 + ACM。ACM の証明書は自動更新される
「1 つのロードバランサーで複数ドメインを HTTPS 化」ALB の SNI。1 つのリスナーに複数の証明書を登録できる
「AZ ごとのインスタンス数が異なっても、各インスタンスに均等に分散」クロスゾーン負荷分散を有効にする（NLB・GWLB は既定で無効）
「スケールイン時に処理中のリクエストを失わない」登録解除の遅延（Connection Draining）
「アプリが応答しないインスタンスを自動で入れ替え」ASG のヘルスチェックに ELB のヘルスチェックを追加する
「平均 CPU 使用率を 50% 前後に保つ」「最小の運用負荷で」ターゲット追跡スケーリング
「毎週月曜の朝に急増する」「決まった時刻」スケジュールに基づくスケーリング（周期的なパターンなら予測スケーリングも可）
「終了前にログを退避」「起動後にソフトを入れてから受け付け」ライフサイクルフック
「オンデマンドとスポットを組み合わせてコストを最小に」起動テンプレートで複数の購入オプションを指定した ASG

引っかけポイント

まとめ: SAA 試験で押さえるポイント

確認問題

参考リンク

AWS 公式ドキュメント（外部サイトが開きます）。