Elastic Load Balancing (ELB)

は、複数のターゲットに受信トラフィックを分散するマネージドなサービスです。インスタンス、、アドレス、関数などへリクエストを分散し、で正常なターゲットだけにトラフィックを送ります。

SAA では、ELB を単に「負荷分散するサービス」として覚えるだけでは不十分です。 Application Load Balancer、Network Load Balancer、Gateway Load Balancer、Classic Load Balancer の違いを理解し、ルーティング、低、固定 IP、終端、連携、可用性設計を判断できることが重要です。

Point

ELB = Elastic Load Balancing の略です。
Elastic は「伸縮する」、Load は「負荷」、Balancing は「均等化」という意味です。
つまり ELB は「アクセス負荷を複数の処理先へ分散するサービス」と覚えます。
和訳
- Elastic: 伸縮性のある
- Load: 負荷
- Balance: 釣り合い、均衡
- Weblio英和辞書「balance」

概要

は、利用者からのアクセスを受け取り、背後にある複数のサーバーやサービスへ振り分ける入口です。 1 台のインスタンスに直接アクセスさせる構成では、そのインスタンスが停止するとアプリケーション全体が使えなくなります。 ELB を使うと、複数に配置したターゲットへトラフィックを分散し、障害時には正常なターゲットへ迂回できます。

SAA では、まずの種類を選びます。 / のパスやホスト名で振り分けるなら、/ の高性能処理や固定が必要なら、ファイアウォールなどの仮想アプライアンスを透過的に挟むなら、旧世代の単純な負荷分散ならと判断します。

見るポイント	代表的な判断
HTTP のパスやホスト名で振り分けたいか	Application Load Balancer を選びます。
TCP/UDP、低、高、固定 IP が必要か	Network Load Balancer を選びます。
IDS/IPS やファイアウォールアプライアンスを挟みたいか	Gateway Load Balancer を選びます。
古い EC2-Classic 世代の構成か	Classic Load Balancer は移行対象として考えます。
障害に強くしたいか	複数 AZ、、連携を確認します。

主要技術

①ロードバランサーの種類

には複数の種類があります。 SAA では、問題文のプロトコル、ルーティング条件、性能要件、固定要件、セキュリティ機器要件から選びます。

種類	主なレイヤー	主な用途	判断ポイント
Application Load Balancer	Layer 7	/、Web アプリ、	パスベース、ホストベース、HTTP ヘッダー、ターゲット、連携で選びます。
Network Load Balancer	Layer 4	//、高性能、固定 IP	低、大量接続、静的 IP、送信元 IP 保持で選びます。
Gateway Load Balancer	Layer 3/4	ファイアウォール、IDS/IPS、ネットワークアプライアンス	トラフィックを透過的に検査機器へ流したい場合に選びます。
Classic Load Balancer	Layer 4/7 の旧世代	既存の古い構成	新規設計では基本的にまたはへ移行します。

Point

ALB = Application Load Balancer の略です。
NLB = Network Load Balancer の略です。
GWLB = Gateway Load Balancer の略です。
CLB = Classic Load Balancer の略です。
試験では、ALB は HTTP の中身を見る、NLB はネットワーク接続を高速にさばく、GWLB は検査機器を挟む、と整理します。

⚠️ 頻出: 「パス /api と /images で別ターゲットへ振り分ける」は ALB、「固定 IP が必要」は NLB、「仮想ファイアウォール群へ透過的に流す」はです。

②Application Load Balancer

はアプリケーション層、つまり / の内容を見てルーティングするです。 Web アプリケーション、、、連携でよく使います。

ALB の中心要素は、、ルール、です。リスナーはポートとプロトコルで接続を待ち受けます。ルールは条件に応じてどのターゲットグループへ転送するかを決めます。ターゲットグループは実際の転送先をまとめる単位です。

ALB の機能	用途	試験での判断ポイント
パスベースルーティング	`/api`、`/static` などで振り分け	マイクロサービス分割で頻出です。
ホストベースルーティング	`api.example.com`、`admin.example.com` で振り分け	複数ドメインを 1 つの ALB で扱えます。
HTTP ヘッダー・クエリ条件	リクエスト内容で詳細に制御	高度なアプリケーションルーティングで使います。
HTTPS 終端	証明書でを終端	バックエンドの暗号化負荷を減らせます。
Lambda ターゲット	Lambda 関数を直接呼び出し	Web で使えます。
連携	Web 攻撃対策	や悪意あるリクエストの防御で検討します。

ALB は、HTTP/2、gRPC などにも対応します。ただし、をそのまま通したい場合や、TLS をバックエンドで復号したい場合は、の TCP リスナーを検討します。

ターゲットグループのルーティングアルゴリズムは、既定のラウンドロビンのほか、最小未処理リクエスト（Least outstanding requests）と加重ランダムから選べます。リクエストごとに処理の重さが大きく異なる場合は、処理中のリクエストが最も少ないターゲットへ送る最小未処理リクエストにすると、特定のターゲットへの偏りを抑えられます。最小未処理リクエストと加重ランダムは、スロースタートと併用できません。

⚠️ 頻出: 「HTTP リクエストのパス、ホスト名、ヘッダーで振り分ける」は ALB です。NLB は HTTP の中身を見た柔軟なルーティングには向きません。

③Network Load Balancer

はトランスポート層のです。、、などの接続を高性能に処理し、大量の接続や低が必要なワークロードに向きます。また、ロードバランサーに固定が必要な場合にも候補になります。

NLB の特徴	用途	判断ポイント
Layer 4 負荷分散	TCP/UDP/TLS	以外のプロトコルや低レイテンシ通信で使います。
固定 IP /	許可リスト登録、固定宛先	クライアント側で IP 固定が必要な場合に選びます。
送信元 IP の保持	クライアント IP をターゲットで確認	アプリ側で送信元 IP が必要な場合に有効です。
高	大量接続、急増するトラフィック	高性能なロードバランサーとして使います。
TLS	TLS 終端	証明書管理と復号を NLB 側へ寄せられます。
ターゲット	NLB の背後に ALB を置く構成	固定 IP と HTTP ルーティングを組み合わせたい場合に検討します。

NLB はごとにロードバランサーノードを作ります。クロスゾーン負荷分散を有効にすると、各ノードがすべての有効 AZ のターゲットへ分散できます。 NLB ではクロスゾーン負荷分散が既定で無効で、無効な場合は基本的に同じ AZ 内のターゲットへ分散するため、AZ ごとのターゲット数の偏りに注意します。ALB では既定で有効です。

⚠️ 頻出: 「TCP/UDP の高性能ロードバランシング」「静的 IP」「Elastic IP を割り当てたい」「送信元 IP を保持したい」は NLB を選びます。

④Gateway Load Balancer と Classic Load Balancer

は、サードパーティや自作のネットワーク仮想アプライアンスをスケールさせるためのです。ファイアウォール、侵入検知、侵入防止、パケット検査などの機器を複数台並べ、トラフィックを透過的に流す用途で使います。

種類	試験での位置づけ	注意点
Gateway Load Balancer	セキュリティアプライアンスの透過的なスケール	通常の Web アプリ振り分けではなく、ネットワーク検査用途です。
Classic Load Balancer	旧世代のロードバランサー	新規設計ではまたはを優先します。

は以前からある旧世代のロードバランサーです。 / と / の基本的な負荷分散に対応しますが、パスベースやホストベースの柔軟なルーティング、中心の設計では ALB/NLB が優先されます。試験で CLB が出る場合は、既存システムや移行文脈として捉えます。

⚠️ 頻出: 「仮想アプライアンスを水平スケールさせてトラフィック検査」は GWLB です。「新規の Web アプリに CLB」は基本的に選びません。

⑤ヘルスチェック、ターゲットグループ、Auto Scaling

はでターゲットの状態を確認し、正常なターゲットへだけトラフィックを送ります。とでは単位でヘルスチェックを設定します。グループとターゲットグループを連携すると、起動したインスタンスを自動登録し、終了したインスタンスを自動登録解除できます。

要素	役割	試験での判断ポイント
	クライアントからの接続を受ける	プロトコルとポートを設定します。
ルール	条件に応じて転送先を決める	ALB ではパスやホスト名で振り分けます。
ターゲットグループ	転送先ターゲットのまとまり	ヘルスチェック、ポート、プロトコルを管理します。
ヘルスチェック	正常なターゲットを判定する	異常なターゲットには送らない設計にします。
Deregistration delay	登録解除時の待機	処理中リクエストを安全に完了させます。
Auto Scaling	ターゲット数を自動調整	ELB と組み合わせて可用性と性能を確保します。

ターゲットタイプには、インスタンス、アドレス、などがあります。 IP ターゲットを使うと、内の IP、ピアリング先、や経由のリソースなどを登録できる場合があります。では、同じ上の複数タスクを異なるポートで登録できるため、ALB との組み合わせがよく使われます。

⚠️ 頻出: 「Auto Scaling で増えた EC2 に自動でトラフィックを流したい」は、Auto Scaling グループを ELB のターゲットグループに連携します。

⑥セキュリティ、TLS、監視、DNS

インターネット向けはパブリックに公開され、内部ロードバランサーは内からのみ利用します。、、ルート、NACL、ターゲット側の許可設定を合わせて確認します。にはセキュリティグループを関連付け、ターゲット側では ALB のセキュリティグループからの通信だけを許可する設計が基本です。

ALB 自身のセキュリティグループは、インバウンドとアウトバウンドを分けて考えます。インターネット向け ALB のインバウンドは、のポートに対して 0.0.0.0/0 からの通信を許可します。利用者のを事前に絞れないため、ここを狭めると正規の利用者を止めてしまいます。ターゲットのセキュリティグループを送信元に指定したインバウンドルールは向きが逆で、ALB へ入る通信の許可にはなりません。

アウトバウンドは、ターゲットのセキュリティグループを宛先として、必要なポートだけを許可します。見落としやすいのがです。のヘルスチェックポートがリスナーの転送先ポートと違う場合、その両方へのアウトバウンドが必要です。転送先のポートだけを許可すると、ヘルスチェックだけが失敗し、ターゲットが unhealthy のままトラフィックが流れません。

ルールの向き	送信元または宛先	ポート	目的
インバウンド	`0.0.0.0/0`	リスナーのポート	インターネットからのリクエストを受けます。
アウトバウンド	ターゲットのセキュリティグループ	転送先のポート	ターゲットへリクエストを転送します。
アウトバウンド	ターゲットのセキュリティグループ	ヘルスチェックのポート	ターゲットの状態を確認します。

送信元や宛先には、の代わりにセキュリティグループの ID を指定できます。 ALB やターゲットの IP が変わっても書き換えが要らないため、を保ちやすくなります。セキュリティグループはなので、応答を通すための戻り方向のルールは不要です。

⚠️ 頻出: 「ALB のセキュリティグループに最小権限で付けるルール」は、インバウンドがリスナーのポートのみ、アウトバウンドが転送先のポートとヘルスチェックのポートの 2 つ、と数えます。

観点	関連機能	判断ポイント
終端	+ HTTPS リスナー	証明書管理と終端をロードバランサー側に寄せます。
エンドツーエンド暗号化	HTTPS ターゲット / パススルー	バックエンドまで暗号化したい場合に考えます。
Web 攻撃対策	+ ALB	のリクエスト制御に使います。
	Alias	の DNS 名へ独自ドメインを向けます。
監視		5xx、ターゲット応答時間、HealthyHostCount などを見ます。
ログ	アクセスログ、接続ログ	トラブルシューティングや監査に使います。

ALB で HTTPS リスナーを使うと、ACM の証明書で TLS を終端できます。ロードバランサーで復号し、ターゲットへで送る構成もありますが、バックエンドまで暗号化が必要な場合はターゲット側も HTTPS にします。暗号化された通信をロードバランサーで復号せずに通したい場合は、NLB の TCP リスナーを検討します。 ALB はターゲットの証明書を検証しないため、ターゲット側の HTTPS には自己署名証明書も使えます。 HTTPS リスナーがクライアントと交渉する TLS のバージョンと暗号スイートは、リスナーのセキュリティポリシーで決まります。CLI やで作ったリスナーの既定のポリシー (ELBSecurityPolicy-2016-08) は TLS 1.0 と 1.1 も受け付けるため、TLS 1.2 以上に限りたい場合は、既存のリスナーのセキュリティポリシーを TLS 1.2 以上だけを許可するものへ変更します。

⚠️ 頻出: 「独自ドメインで ELB に向ける」は Route 53 Alias レコードを使います。「ALB で Web 攻撃対策」は AWS WAF 連携を選びます。

試験対策

SAA の問題は、最初に種別を選ぶと整理しやすいです。 / の内容で振り分けるなら、/ や固定なら、セキュリティアプライアンスを透過的に挟むなら、旧世代の既存構成ならと判断します。

次に、可用性を確認します。複数にロードバランサーを配置し、各 AZ にターゲットを用意し、で異常ターゲットを外す設計が基本です。と連携すると、負荷に応じてターゲットを増減できます。

問題文のキーワード	優先して考える機能	理由
パスやホスト名で振り分け	ALB	HTTP/HTTPS の内容に基づくルーティングができます。
gRPC、、HTTP/2	ALB	アプリケーション層のプロトコル対応で検討します。
TCP/UDP、高性能、低	NLB	の高性能ロードバランシングに向きます。
固定 IP、	NLB	ロードバランサーの IP 固定要件に対応できます。
ファイアウォール群へ透過的に流す	GWLB	ネットワークアプライアンスのスケールに使います。
Web 攻撃対策	ALB +	L7 のリクエスト検査ができます。
HTTPS 証明書を簡単に管理	+ HTTPS	終端をロードバランサー側で扱えます。
Auto Scaling と連携		起動・終了するを自動登録できます。
独自ドメインで ELB に向ける	Alias	ELB の名へ安定してルーティングできます。

よくある誤答は、ALB と NLB の境界を混同することです。 ALB は HTTP の中身に基づく判断が得意です。 NLB は TCP/UDP の接続処理、固定 IP、低レイテンシ、高が得意です。「HTTPS だから必ず ALB」ではなく、TLS を終端するのか、暗号化された TCP をそのまま通すのかを確認します。

コスト面では、ロードバランサーの稼働時間、処理したトラフィック量、LCU/NLCU、クロスゾーン通信、ログ保存、WAF 連携などが影響します。 ALB は、稼働している時間ごとの料金と、使用した LCU（新しい接続数、アクティブな接続数、処理したバイト数、ルール評価のうち最も多い指標）に課金されます。時間料金はロードバランサーごとにかかるため、トラフィックの少ないサービスごとに ALB を分けると時間料金が台数分重なります。ホストベースルーティングで複数のドメインを 1 つの ALB にまとめ、サービスごとのターゲットグループへ振り分けると、時間料金を 1 台分にできます。ルールが 10 個を超えると、ルール評価が LCU の計算に入ります。ロードバランサーが使うパブリック IPv4 アドレスにも、通常のアドレス料金がかかります。 SAA では料金の数値暗記より、ALB/NLB/GWLB の選定、可用性、セキュリティ、運用負荷のトレードオフを重視します。