AWS Elastic Load Balancing(ELB)

Overview

Elastic Load Balancing（以降、ELBと表記）は、フルマネージド型の負荷分散サービス。
ELBはAWSにおける負荷分散サービスの総称で、用途に応じて4つのロードバランサーが用意されている。

Application Load Balancer（以降、ALBと表記）
Network Load Balancer（以降、NLBと表記）
Gateway Load Balancer（以降、GWLBと表記）
Classic Load Balancer（以降、CLBと表記）

ELBは複数台のEC2インスタンスやLambda関数に処理を振り分けたい場合に有用なサービスで、最大のメリットは高い拡張性を備えていること。

オンプレミスでは、ロードバランサーを用意する場合、負荷分散専用の機材を用意するか、サーバーに負荷分散機能を持たせるソフトウェアを組み込むことでロードバランサーとして構築する必要がある。
どちらの場合でも、処理能力にはハードウェアの限界があり、自動的な拡張には対応できない。
そのため、予想される負荷に対して充分な性能や台数をあらかじめ確保しておく必要がある。
ELBではハードウェアの制約を受けず負荷状況に応じて自動的にスケーリングするため、とくに意識することなくシステムの信頼性を担保できる。

ELBの基本用語

リスナー

外部からアクセスするプロトコルとポートを指定して接続リクエストをチェックする
1つのロードバランサーに対して最小1個、最大10個のリスナーを設定できる。

リスナールールとアクション

リスナールールとは、受信したトラフィックの中身を判定する条件のこと。
HTTPヘッダーや送信元IPアドレスなどに基づき、異なるアクションを設定できる。
複数のリスナールールを設定し、どのルールを優先するか優先度を設定できる。
リスナールールに応じて実行できるアクションは大きく分けて5種類ある。

メンテナンス用などに利用する「固定レスポンス」
HTTPのリクエストをHTTPSに転送する「リダイレクト」

デフォルトでは、ターゲットグループへ転送するアクションが設定されます。

ターゲットとターゲットグループ

ターゲットとは、ELBがトラフィックを転送するリソースやエンドポイント（AWSサービスに接続するためのURL）などのこと。
EC2インスタンスやLambda、IPアドレスなどを指定可能。
ひとつのELB配下で管理されるターゲットの集合のことをターゲットグループと呼ぶ。
また、ターゲットグループは、ターゲットの死活監視をおこなうヘルスチェックという機能も備えています。ターゲットのEC2インスタンスに異常が発生した場合、そのEC2インスタンスはヘルスチェックに失敗します。ヘルスチェックに失敗したEC2インスタンスはELBから切り離されるため、正常なインスタンスのみに通信を転送でき、システムの可用性が向上します。

SSLターミネーション

リスナーにSSL証明書を設定しELBでSSL認証を終端する機能
クライアントからのSSL（HTTPS通信:ポート443番）リクエストをELBにてSSL認証をし、ターゲットグループに属するEC2インスタンスに対してはSSLではなくHTTP通信（ポート80番）を行います。
ロードバランサーとEC2インスタンス間はSSL通信をしないため、EC2インスタンスの負荷を軽減するメリットがあります。

tip

SSL証明書はAWS ACMを利用して無料で発行できる。

スティッキーセッション

同一セッション中のユーザーリクエストを同じターゲットに振り分ける機能。
サーバーがセッションを管理するために発行したCookie(Webサーバーがクライアントに一時的にデータを保存させる仕組み)の情報をロードバランサーが読み取り、直前にアクセスしたターゲットへ導く。

tip

スティッキーセッションで利用するCookieの生成元は、ELBまたはアプリケーションのいずれかを選択できます。

Pre-warming（暖機運転）

ELBを事前にスケール（Pre-warming）させておく操作のこと。
ELBはリクエストの増加に伴って自動的にスケールアウトするが、急激にアクセス要求されるとELBのスケールアウトが間に合わず、サービスが一時的に利用できなくなる可能性がある。
そこで、あらかじめ申請しサービスの利用不可を回避できる。

ELBのメリット

導入することでのメリットは次の通り。

サービスの負荷を分散できる

ELBは、トラフィックを複数のターゲットに分散して転送することで、システムの可用性・耐障害性・信頼性などを高めます。

サービスを常時モニタリング

ELBは、ヘルスチェック機能によりターゲットをリアルタイムにモニタリングしています。ターゲットに異常が発生したことを素早く検知し、正常稼働しているターゲットにだけトラフィックを転送します。

自動的なスケーリング

ELBは、トラフィックの増加に応じて自動的にスケーリングするため、事前にインスタンスを複数台準備しシステムの冗長化をするHAクラスタリングを行う必要はありません。

初期コストを抑えやすい

従量課金制のため、初期費用や基本料金が発生しません。そのため、ハードウェア、ソフトウェアのロードバランサーよりも低コストで導入できます。

ALB(アプリケーションロードバランサー)

レイヤー7（アプリケーション層）で動作するロードバランサー
レイヤー7はOSI参照モデルの7層目を指す。
ALBが対応するプロトコルは HTTP、HTTPS で、クライアントとロードバランサー間のSSLターミネーションをサポートしている。
ELBの中ではもっとも多機能であり、パブリックサブネットにALBを配置し、プライベートサブネットにEC2やRDSなどのリソースを配置する、いわゆるWeb3層アーキテクチャなどさまざまケースで利用されている。

ALBとELBの違い

参考URL

ELBとは「Elastic Load Balancing」の略称で、元々はこのELBがAWSにおけるロードバランシングサービスだった。
しかしのちにALBが追加オプションとして開発された際に、ELBはその名称を「Classic Load Balancer（CLB）」に変えることになる。そしてALBとCLBのサービスをまとめた総称として、ELBが使われるようになったのです。さらに今ではNetwork Load Balancer（NLB）も追加され、その内容がさらに充実しています。つまりELBとは、ALB、CLB、NLBという3種類の魅力的なロードバランサーを持つAWSのロードバランシングサービスの総称のこと

ALBの特徴

**レイヤー7（アプリケーションレイヤー）**での動作
新たにWebSocketとHTTP/2をサポート
最新のアプリケーションアーキテクチャを対象
ターゲットグループにルーティングが行える
複数のアベイラビリティーゾーンの利用

レイヤー7での動作について

旧来のELBはロードバランサーとして、レイヤー4のトランスポート層と、レイヤー7のアプリケーション層の両方で活動していた。レイヤー4ではネットワークパケットの内容を細かく精査することなく負荷を分散し、レイヤー7ではパケット内のHTTPとHTTPSといった情報にアクセスしてより効率的な負荷分散を実行します。

一方でALBはレイヤー7だけで機能するロードバランサーであり、ELBとは違ってアプリケーション層に特化するスタイルを取っています。そのためより便利で使いやすい機能の実装や追加が可能となり、全体のサポート力が高まることになったのでしょう。

登録解除

ELBに接続されたターゲット（通常はEC2インスタンスやコンテナなどのバックエンドリソース）を、ロードバランサーから外す（切断する）プロセスのことを指す。
具体的には、ターゲットがALBからのトラフィックの分散対象としての役割を停止することを意味します。

登録解除の具体的な意味

ターゲットグループからの削除ターゲットは、ALBによってトラフィックを分散するためのターゲットグループに属しています。登録解除とは、そのターゲットグループから特定のターゲットを外すプロセスです。
プロセスの流れ

登録解除のリクエスト: 登録解除は手動でリクエストするか、自動スケーリングポリシーやデプロイプロセスの一部として発生することがあります。
接続中のリクエストの完了: ALBは、ターゲットの登録解除が開始されても、既にターゲットに送信されているリクエストを完了させるようにします。これが、登録解除の遅延時間の設定がある理由です。
新しいリクエストの停止: 登録解除が開始されると、ALBはそのターゲットに新しいリクエストを送信しなくなります。これにより、ターゲットが新しいトラフィックを処理するのを防ぎます。

登録解除が完了するまでの遅延時間

登録解除の遅延時間（デフォルトでは300秒）は、ALBがターゲットに送信されているすべての既存リクエストを完了させるための猶予期間。
この遅延時間が経過するか、ターゲットがすべてのリクエストを処理し終えると、登録解除が完了し、ターゲットはターゲットグループから外されます。

登録解除のユースケース

スケーリングダウン: 例えば、トラフィックの量が減少し、バックエンドのキャパシティを減らしたい場合、ターゲットを登録解除してリソースを削減することがある。
メンテナンス: ターゲットに対してメンテナンスやアップデートを行う際に、ユーザーリクエストを受け付けないようにするため、ターゲットを一時的に登録解除することがある。
ローリングデプロイ: アプリケーションの新バージョンをデプロイする際に、古いターゲットを段階的に登録解除し、新しいターゲットを追加することがある。

まとめ

登録解除とは、ALBからターゲット（バックエンドリソース）を外すプロセスです。この操作により、ターゲットはトラフィックを処理しなくなりますが、登録解除の遅延時間中は既存のリクエストを完了できます。これにより、サービスの中断を最小限に抑えることが可能になります。

API GatewayとALBの比較

HTTPSの終端：API GatewayとALBの比較とセキュリティ上の考察

API Gateway を ALB の「前段」に置く構成

**API Gateway を ALB の「前段」に置く構成（API Gateway → ALB → ECS）は“あり”**だが、狙いがハッキリしているときに選ぶ構成。

何が起きる？（メリット/デメリット）

観点	API Gateway を ALBの前に置く（HTTP API + VPC Link or 直接HTTP）
認証/認可	強い：Cognito/OIDC JWT の認可、Lambda Authorizer、mTLS（カスタムドメイン）、APIキー/Usage Plan
レート制御/課金	強い：ステージ/キー単位のスロットリング・クォータ・メータリング
変換/集約	強い：ヘッダ/クエリ/ボディのマッピング、複数バックエンド集約、ステージ別ルーティング
セキュリティ	WAF 連携、mTLS、IP 制限など。ALB 側 WAF と二重化も可（ただし複雑化）
可観測性	API GW のメトリクス＋ALB のメトリクス。分散トレース設計は一工夫必要
レイテンシ	1ホップ増（API GW → ALB）。CloudFront よりは軽いが、ALB 直より遅くなる
コスト	1リクエスト課金が載る（トラフィック多いと効いてくる）＋ ALB/NLB の基本料
タイムアウト	API GW 統合の最大タイムアウト ~30s（長時間処理やストリーミングは要設計）
プロトコル	API GW は gRPC 非対応（HTTP/2 でも gRPC 透過不可）。gRPC は ALB 直が向く

まとめ：API 管理（Auth/レート制御/マルチテナント/課金/ステージ分離）を活かしたいなら。単純な REST バックエンドなら ALB 直の方が速くて安くて簡単。

どんな構成がベスト？

パターン	経路	向くケース	注意点
A：推奨・シンプル	API Gateway → NLB → ECS	VPC Link の相性が良く、低レイテンシ・低コストで API 管理を前段に載せたい	ルーティングは API Gateway ルートで実施。NLB ヘルスチェック設計を明確に
B：あなたの案	API Gateway → ALB → ECS	既存の ALB ルール/監視/可用性設計を活かしたい、Path/Host ベースの複雑ルーティングを継続	NLB よりレイヤ高＋ホップ増でコスト/レイテンシ増。WebSocket/gRPC は結局 ALB 直運用になりがち
C：最小・高速	ALB 直 → ECS	国内中心・POST 主体・シンプル API／まず動かしたい	認証/スロットリング/課金はアプリ側 or WAF で実装。後から API GW/CloudFront を差し込み可能

tip

VPC Link はAPI Gateway から VPC 内のリソースへ私設回線でつなぐための橋

選定の指針（Flutter モバイル API 前提）

条件	推奨構成
Auth/レート制御/マルチテナント/外部公開 API を強くやりたい	A（API GW → NLB → ECS）または B（API GW → ALB → ECS）
高トラフィック・低レイテンシ・gRPC/ストリーム	C（ALB 直）または C + CloudFront（GET のみキャッシュ）
将来拡張を見据えつつ最短で出したい	まず C（ALB 直） → 必要になったら A に昇格

実装のコツ（API Gateway + ALB + ECS の場合）

統合方式：HTTP API + VPC Link（ALB を Private にすると攻撃面が狭くなり◎）
CORS：API Gateway で最小許可（Authorization を許可するなら明示）
認証：Cognito JWT（/refresh は短命アクセストークン運用）
スロットリング：クライアント別（アプリ/社内ツール）に Usage Plan を分ける
タイムアウト設計：API GW ~30s 制限 → バックエンドは 非同期化 & ジョブID 返し＋ポーリング/Push 通知
監視：API GW（5xx/4xx/RPS/Latency）と ALB（Target 5xx/ELB 5xx）を両方見る。相関用に Correlation-Id を共通ヘッダで

これで迷わない最短結論

ニーズ	まず選ぶべき構成
API 管理（Auth/レート制御/外部公開）を強くやりたい	A（API GW → NLB → ECS）
既存の ALB 運用を活かしたい/ルールが複雑	B（API GW → ALB → ECS）
まず動かしたい・安く速く	C（ALB 直 → ECS）

Overview​

ELBの基本用語​

リスナー​

リスナールールとアクション​

ターゲットとターゲットグループ​

SSLターミネーション​

スティッキーセッション​

Pre-warming（暖機運転）​

ELBのメリット​

サービスの負荷を分散できる​

サービスを常時モニタリング​

自動的なスケーリング​

初期コストを抑えやすい​

ALB(アプリケーションロードバランサー)​

ALBとELBの違い​

ALBの特徴​

レイヤー7での動作について​

登録解除​

登録解除の具体的な意味​

まとめ​

API GatewayとALBの比較​

API Gateway を ALB の「前段」に置く構成​

何が起きる？（メリット/デメリット）​

どんな構成がベスト？​

選定の指針（Flutter モバイル API 前提）​

実装のコツ（API Gateway + ALB + ECS の場合）​

これで迷わない最短結論​