AWS Elastic Load Balancing（ELB）の基本と使い分け

Elastic Load Balancingの役割

**Elastic Load Balancing（ELB）**は、アプリケーションへの着信トラフィックを複数のバックエンドへ分散するマネージドサービスです。EC2インスタンス、IPアドレス、コンテナなどをターゲットとして登録し、複数のアベイラビリティーゾーン（AZ）に配置したターゲットグループへ通信を振り分けます。

ロードバランサーはクライアントに対する共通の接続先になります。利用者が接続先を切り替えなくても、運用者はターゲットを追加・削除したり、障害のあるターゲットを入れ替えたりできます。クライアントからはロードバランサーのDNS名へ接続し、その背後でどのターゲットが処理するかをELBが制御します。

ELBはターゲットにヘルスチェックを行い、正常と判定されたターゲットへリクエストを送ります。個々のサーバーに障害が起きても、他の正常なターゲットへ処理を継続できるため、単一インスタンスを直接公開する構成より可用性を高められます。ヘルスチェックの判定は、設定したプロトコル、ポート、パス、応答条件に基づきます。アプリケーション全体が正常かどうかを自動的に完全判定するものではないため、実際の処理に必要な依存先も含めて適切なチェック先を設計します。

ELB自身も、受信トラフィックの変化に応じてロードバランサーの容量を自動調整します。一方、アプリケーションを処理するターゲットの台数を増減するのは、通常はAmazon EC2 Auto Scalingなどの役割です。ELBとAuto Scalingを連携させると、スケールアウトで起動したインスタンスをターゲットグループに登録し、スケールインで終了するインスタンスを登録解除できます。ロードバランサーの容量調整とバックエンド台数の調整は、別の仕組みとして理解しましょう。

ロードバランサーの種類

現行世代では、用途に応じて Application Load Balancer（ALB）、Network Load Balancer（NLB）、**Gateway Load Balancer（GWLB）**を選びます。**Classic Load Balancer（CLB）**は旧世代のロードバランサーです。既存環境で使われる場合はありますが、新しい構成では現行世代への移行が推奨されています。CLBが利用不能になったという意味ではなく、機能や構成を検討するときは移行先としてALBまたはNLBなどを比較します。

種類	主なレイヤーと通信	得意な用途・特徴	主なターゲット
ALB	アプリケーション層（L7）。主にHTTP/HTTPS	パス、ホスト名、HTTPヘッダーなど、リクエスト内容によるルーティング。TLS終端、認証連携、AWS WAFとの統合にも対応	インスタンス、IPアドレス、Lambda関数
NLB	トランスポート層（L4）を中心とする通信	TCP、TLS、UDPなどの接続を扱う。高い処理性能や低レイテンシーが必要なワークロード、静的IPアドレスが必要な構成に適する	インスタンス、IPアドレス、ALB
Gateway Load Balancer	ネットワーク層（L3）のIPパケット	ファイアウォール、侵入検知・防止、ディープパケット検査などの仮想ネットワークアプライアンスを透過的に挿入し、複数台に分散	仮想アプライアンスのインスタンスまたはIPアドレス
CLB	L4およびL7の旧世代機能	既存システムとの互換性を考慮する場合。新規設計では現行世代を優先	主にEC2インスタンス

ALB：HTTPリクエストの内容を見て振り分ける

ALBはL7で動作し、HTTPやHTTPSのリクエストを見て転送先を決定します。たとえば、/reports/以下のリクエストをレポート用サービスへ、それ以外を通常のWebアプリケーションへ送るように設定できます。ホスト名、パス、HTTPメソッド、ヘッダー、クエリ文字列、送信元IPアドレスなどをルールの条件にできます。

ALBは、Webアプリケーションやマイクロサービスの入口をまとめたい場合に適しています。HTTPSリスナーでTLSを終端し、AWS Certificate Manager（ACM）の証明書を使う構成や、Amazon CognitoまたはOIDCによるユーザー認証、AWS WAFによるリクエスト検査も組み合わせられます。ALBのアクセスログをS3へ保存すれば、リクエスト単位のアクセス状況を調査できます。Lambda関数をターゲットにできるのもALBの特徴です。

NLB：接続やネットワークプロトコルを扱う

NLBはL4を中心に動作し、アプリケーションのHTTPパスを解釈せず、接続やフローに基づいてターゲットへ転送します。一般的な選択肢としてTCP、TLS、UDP、TCP_UDPを扱い、現行のターゲットグループではQUICやTCP_QUICもサポートされています。必要なプロトコルと、リスナーおよびターゲットグループで利用できる組み合わせを確認して設計します。

AZごとに静的なIPアドレスを提供でき、インターネット向けNLBではサブネットごとにElastic IPアドレスを割り当てられます。接続先IPをファイアウォールなどの許可リストへ登録する要件や、高い処理性能が必要なTCP/UDPワークロードではNLBが候補になります。ALBのようなURLパス別の振り分けが必要なら、L7機能を持つALBを選びます。

Gateway Load Balancer：ネットワーク検査機器へ透過的に転送する

Gateway Load Balancerは、通信の入口で仮想アプライアンスを経由させるためのロードバランサーです。ファイアウォール、侵入検知・防止システム、パケット検査製品などを複数台に分散し、アプライアンスの増減にも対応できます。

GWLBはL3のロードバランサーとしてIPパケットを扱います。アプライアンスとGWLBの間ではGENEVEカプセル化を使用し、ポートは 6081 です。したがって、GWLBは一般的なWebアプリケーションのURLルーティング先ではなく、ネットワーク検査用アプライアンスの前段に配置します。

ELBを構成する要素

ELBの基本構成は、ロードバランサー、リスナー、リスナールール、ターゲットグループ、ターゲットに分けて考えると整理できます。

リスナー：受付プロトコルとポートを定義する

リスナーはロードバランサー上でクライアントからの接続を受け付けます。リスナーごとにプロトコルとポートを設定し、ALBならHTTP/HTTPS、NLBなら対応するTCP/TLS/UDP系プロトコルなどを指定します。1つのロードバランサーに複数のリスナーを設定し、たとえば暗号化されたWeb通信と別のアプリケーション用ポートを分けて受け付けられます。

受付側のプロトコルと、ターゲットグループからバックエンドへ接続するプロトコルは別々に設定できます。たとえばALBでクライアントからHTTPSを受け取り、ロードバランサーでTLSを終端した後、ターゲットグループへHTTPで転送できます。バックエンドでも暗号化する場合は、ターゲットグループ側をHTTPSにします。

ALBのルール：条件を評価してアクションを実行する

ALBでは、リスナーにルールを設定します。ルールは優先度の順に評価され、条件に合致したときにアクションを実行します。条件にはホスト名、パス、HTTPメソッド、HTTPヘッダー、クエリ文字列、送信元IPアドレスなどを使えます。よく使うアクションは、ターゲットグループへの転送、別URLへのリダイレクト、固定HTTPレスポンスの返却です。どの追加ルールにも一致しない場合に使うデフォルトルールもリスナーごとに必要です。

この機能により、複数のサービスを単一のALBの背後で運用できます。たとえば、/billing/への要求だけを請求サービスのターゲットグループへ転送し、その他の要求を既定のWebサービスへ送る構成を作れます。CLBの基本的な振り分けと比べ、ALBはHTTP内容に応じた細かなルーティングに適しています。

NLBではALBのようなHTTP内容に基づく条件ルールを使わず、リスナーとターゲットグループに指定した接続プロトコル、ポート、転送先を中心に設定します。GWLBはL3のIPトラフィックを透過的にアプライアンスへ渡すため、ALB型のWebリクエストルールを使うものではありません。各ロードバランサーで設定できるリスナーとプロトコルは異なります。

ターゲットグループ：転送先とヘルスチェックをまとめる

ターゲットグループは、トラフィックを転送するターゲットと、ターゲットへの接続プロトコル・ポート、ヘルスチェック設定をまとめます。ALBではEC2インスタンス、IPアドレス、Lambda関数をターゲットにできます。NLBではインスタンス、IPアドレス、またはALBをターゲットにできます。GWLBでは検査用の仮想アプライアンスをインスタンスまたはIPアドレスとして登録します。コンテナを使う場合も、ネットワークモードなどに応じてインスタンスやIPアドレスとしてターゲットグループへ登録します。

ロードバランサーの種類によって登録できるターゲットタイプが異なるため、「EC2、IP、Lambda、コンテナをどのロードバランサーにも登録できる」とは考えないでください。ALBのLambdaターゲット、NLBのALBターゲットのように、特定タイプに限られる機能があります。また、ターゲットタイプはターゲットグループ作成後に変更できません。

ヘルスチェックはターゲットグループ単位で設定します。EC2インスタンス自体が起動中でも、アプリケーションプロセスが停止していたり、応答パスが失敗していたりすれば、ヘルスチェックで異常と判定される可能性があります。逆に、チェック対象が単純な静的ページだけなら、アプリケーションの主要機能に問題があっても正常と判定されることがあります。サービスの実際の準備状態を確認できるエンドポイントを選びます。

ターゲットの選び方はロードバランサーの種類に応じて異なります。ALBではターゲットグループごとにルーティングアルゴリズムを設定でき、既定のラウンドロビンのほか、処理中リクエスト数が少ないターゲットを選ぶ方式も利用できます。NLBは接続のフロー情報に基づいてターゲットを選び、同じTCP接続やUDPフローはその存続中に同じターゲットへ送られます。

異常と判定されたターゲットは通常の振り分け対象から外されます。ただし、ターゲットグループ内の全ターゲットが異常の場合など、ELBがフェイルオープンして異常ターゲットにも通信を送る条件があります。ヘルスチェックだけで全障害時の動作まで保証されるわけではないため、各サービスの動作と監視をあわせて設計します。

TLS終端とバックエンド通信の暗号化

ALBとNLBはTLSを扱えます。TLSリスナーを設定すると、クライアントとロードバランサー間の接続を暗号化し、リスナーにサーバー証明書を関連付けます。HTTPSのWebリクエストを解釈するALBではHTTPSリスナー、L4接続を処理するNLBではTLSリスナーを使うのが基本です。NLBではTCPリスナーを使って暗号化済みの通信を復号せずに転送する構成も選べます。どの方式にするかは、ロードバランサーでTLSを終端するか、バックエンドまで暗号化を維持するかで決まります。

証明書にはACMで発行したものを使う方法が一般的です。通常のACMパブリック証明書は、対応するAWSサービスに関連付けて使い、証明書の発行や条件を満たした証明書の更新をマネージドにできます。ロードバランサー用のACM証明書はロードバランサーと同じリージョンに用意します。外部認証局から取得した証明書をインポートすることもできますが、インポート証明書はACMによるマネージド更新の対象外です。EC2などへ秘密鍵を直接配置する方式が必要なら、通常の証明書と区別して、エクスポート可能な証明書や外部管理の証明書を検討します。証明書の種類によって費用、鍵の保護、更新後の再配備責任が異なります。

クライアントからロードバランサーまでを暗号化しても、ロードバランサーからターゲットまでが自動的に暗号化されるわけではありません。ターゲットグループのプロトコルをHTTPSなどにし、ターゲット側にも対応する証明書を用意すると、VPC内のバックエンド通信も暗号化できます。ただし、ALBはターゲット証明書を検証しません。自己署名証明書や期限切れ証明書でもTLS接続自体は確立できるため、バックエンドTLSだけで接続先の真正性まで保証されると考えないでください。VPCのネットワーク制御やアクセス権限も併用します。VPC内部の通信でも、内部不正への備えや規制要件によって全区間の暗号化が必要な場合があります。TLS終端と各区間の暗号化を別々に確認しましょう。

スティッキーセッション

通常のロードバランシングではリクエストや接続が複数ターゲットへ分散されます。スティッキーセッション（セッションアフィニティ）を有効にすると、同じクライアントからの後続通信を一定期間同じターゲットへ送りやすくできます。アプリケーションのセッション状態を特定サーバーだけが保持するステートフルな構成などで利用されます。ただし、ターゲットの異常、登録解除、設定した有効期間の終了などにより、別ターゲットへ切り替わることがあるため、状態を失わない仕組みの代わりにはなりません。

方式はロードバランサーごとに異なります。

ロードバランサー	主な維持方法	動作の考え方
ALB	Cookie	ロードバランサーが生成するCookieで期間を指定する方式と、アプリケーションのCookieを使う方式がある。HTTP Cookieを利用するため、Webセッションの維持に向く
NLB	送信元IPアドレス	HTTP Cookieは解釈せず、同じ送信元IPアドレスからのフローを同じターゲットへ対応付ける。NAT配下の複数利用者が同じ送信元IPに見えると偏りにつながることがある
Gateway Load Balancer	フロー情報	送信元・宛先IPアドレスとプロトコルなどの情報に基づいて、ネットワークフローを同じ仮想アプライアンスへ維持し、パケットごとに異なる検査装置へ分散されることを防ぐ

アプリケーションCookie方式では、アプリケーション側でセッションCookieを発行し、そのCookieを使ってターゲットへの関連付けを保ちます。Cookieの有効期間やターゲット障害時の再割り当てを考慮し、スティッキーセッションに依存しすぎないセッション管理を設計してください。

ALBのスティッキーセッションにはクライアントがCookieを扱えることが必要で、ターゲットグループ単位で有効化します。また、ALBターゲットグループのクロスゾーン負荷分散を無効にすると、ターゲットのスティッキーセッションは利用できません。NLBの送信元IP方式はQUICトラフィックには適用されません。プロトコルやAZ間の分散設定がスティッキーセッションと両立するか、ロードバランサーごとの条件を確認します。

セキュリティグループとロードバランサーのIPアドレス

ロードバランサーを配置したAZには、そのAZでトラフィックを受け持つロードバランサーノードが作られ、VPC内のプライベートIPアドレスを持つネットワークインターフェイスが関連付けられます。ロードバランサーのサブネットや各AZのノードは、ターゲットが配置されるAZで受信・転送できるネットワーク設計にします。

ALBにはセキュリティグループを設定し、クライアントから受け付けるプロトコルとポートを制限できます。ターゲット側のセキュリティグループでは、クライアントのネットワーク全体を許可するより、ロードバランサーに関連付けたセキュリティグループからの通信だけを許可する構成が基本です。これにより、ターゲットへロードバランサーを迂回して直接アクセスされる経路を抑えられます。NLBにもセキュリティグループを関連付けられますが、作成時に関連付ける必要があり、セキュリティグループなしで作成した既存NLBへ後から追加できない点に注意します。GWLBはセキュリティグループでアクセス制御するロードバランサーではなく、アプライアンス側やVPCのネットワーク制御を組み合わせます。

インターネット向けロードバランサーへアクセスする際は、IPアドレスを固定の接続先として扱わず、AWSが提供するDNS名を使います。ALBのパブリックIPアドレスはAWSにより管理され、時間とともに変わる可能性があります。NLBはAZごとに静的IPアドレスを提供でき、インターネット向けNLBでは各AZのアドレスにElastic IPアドレスを割り当てられます。ファイアウォールの許可リストなど、接続先IPの固定が要件ならNLBが候補です。

ALBに固定IPアドレスを直接割り当てることはできません。ALBのL7ルーティングを保ちつつ固定のグローバルIPアドレスを入口にしたい場合は、AWS Global Acceleratorを前段に置く方法があります。NLBをALBのターゲットにする構成も可能で、NLBが提供する固定IPアドレスを入口にできますが、NLB自身はHTTPパスなどのアプリケーション情報を使って振り分けるわけではありません。要件が固定IPのみか、ALBのL7ルーティングやGlobal Acceleratorのグローバル経路制御も必要かを分けて選択します。

ELBとRoute 53のヘルスチェック

ELBとAmazon Route 53のヘルスチェックは、確認する対象と障害時の役割が異なります。ELBはターゲットグループに登録したバックエンドの状態を判断し、正常なターゲットへロードバランサー内の通信を転送します。Route 53はヘルスチェックの結果をDNSルーティングに利用し、必要に応じてDNS応答先を切り替えます。

比較項目	ELBのヘルスチェック	Route 53のヘルスチェック
主な対象	ターゲットグループに登録されたインスタンス、IPアドレスなど	公開エンドポイント、他のヘルスチェック、CloudWatchアラームなど
確認方法	ターゲットグループで指定したプロトコル・ポート・パス・成功条件・タイムアウト・間隔に基づく	エンドポイントの到達性や応答条件を確認する方式、CloudWatchアラームを使う方式、複数結果を組み合わせる計算済みヘルスチェックなど
異常時の動作	ロードバランサー内の通常の転送先から異常ターゲットを除外する。例外的なフェイルオープン条件はロードバランサーごとに確認する	DNSルーティングポリシーと組み合わせ、健全な別エンドポイントを応答先に選ぶフェイルオーバーを行う
料金の考え方	ELBのターゲットヘルスチェック自体に個別のヘルスチェック料金はない。ELBの利用料金は別途発生する	ヘルスチェックの種類や対象に応じた料金体系がある。現在の料金ページには、同一アカウント内またはリンクされたAWSエンドポイント向けに最大50件の無料枠が記載されている。無料枠の対象条件や超過分は料金ページで確認する

ELBのチェックはTCP接続だけでなく、HTTP/HTTPSの応答コードや応答時間を条件にして、アプリケーションの応答性を確認できます。Route 53はより広い対象を確認できますが、DNSのキャッシュやTTLの影響があるため、異常検知と利用者の接続先変更が同時に完了するとは限りません。Route 53のエイリアスレコードではELBの状態を評価する設定も利用でき、ELBを単独で使う構成とRoute 53を組み合わせる構成を要件に応じて選べます。

したがって、単一リージョン内で複数サーバーへ転送する役割はELB、複数のロードバランサーやリージョンなどの間でDNSの応答先を選ぶ役割はRoute 53と整理できます。両方を組み合わせる場合、Route 53がどのエンドポイントを利用者へ案内し、ELBがその先のどのターゲットへ転送するかを区別します。

Auto Scaling・監視との連携

EC2 Auto Scalingグループにターゲットグループを関連付けると、スケールアウトで起動したインスタンスを自動登録し、スケールインで終了するインスタンスを登録解除できます。これにより、アプリケーションへの負荷が増えたときに処理先を増やし、需要が下がったときに余分な処理先を減らす構成を作れます。デプロイやスケールイン時に処理中の接続を保護したい場合は、登録解除時の遅延設定も確認します。

CloudWatchのロードバランサーおよびターゲットグループのメトリクスを監視すると、正常・異常ターゲット数やリクエスト状況を把握できます。たとえばEC2が running でもアプリケーションが応答していない状況は、EC2の状態確認だけでは検知できません。ELBのヘルスチェックやメトリクスを使い、アプリケーション層の状態も監視します。

試験での選択基準

• HTTP/HTTPSのパスやホスト名に応じてサービスを分けたい：ALB。L7のリスナールールを使います。
• TCP/UDP系の接続を処理し、静的IPアドレスや高い処理性能が必要：NLB。必要なプロトコルとターゲットタイプも確認します。
• ファイアウォールやパケット検査アプライアンスを透過的に挿入したい：Gateway Load Balancer。アプライアンスとのGENEVE通信はUDP 6081です。
• Webセッションを同じターゲットへ維持したい：ALBはCookie、NLBは送信元IPによるスティッキーセッションを使います。GWLBはネットワークフローと同じアプライアンスの対応を維持します。
• ロードバランサーからターゲットまでの通信も暗号化したい：ターゲットグループのプロトコルとターゲット側の証明書を設定し、クライアント側のTLSとは別の区間として設計します。
• 接続先のIPアドレスを固定したい：NLBのAZごとの静的IPまたはElastic IPを検討します。ALBには直接割り当てられないため、Global Acceleratorなどを組み合わせます。
• 個々のバックエンドの障害で転送先を切り替えたい：ELBのターゲットヘルスチェックを使います。DNSを通じて別エンドポイントへ切り替える要件にはRoute 53を組み合わせます。
• 異常なバックエンドを避け、複数AZで可用性を高めたい：ヘルスチェック付きのターゲットグループを使い、各AZに正常なターゲットが配置されるようにします。
• 需要に合わせてバックエンド台数も変更したい：ロードバランサーの自動容量調整に加えて、EC2 Auto Scalingをターゲットグループと連携させます。
• 既存システムでCLBを使っている：CLBは旧世代として扱い、要件に合うALBまたはNLBへの移行を検討します。

料金はロードバランサーの種類や稼働時間、処理量などに応じて変わります。構成を比較するときは固定額を前提にせず、Elastic Load Balancingの公式料金ページで対象リージョンと課金要素を確認してください。

公式ドキュメント

• What is Elastic Load Balancing?
• What is an Application Load Balancer?
• Listener rules for your Application Load Balancer
• Target groups for your Application Load Balancers
• What is a Network Load Balancer?
• Target groups for your Network Load Balancers
• What is a Gateway Load Balancer?
• Availability Zones for your Network Load Balancer
• HTTPS listeners for your Application Load Balancer
• Sticky sessions for your Application Load Balancer
• Target group attributes for your Network Load Balancer
• Target groups for your Gateway Load Balancer
• Target group health checks for your Application Load Balancer
• Update security groups for your Network Load Balancer
• Security groups for your Application Load Balancer
• Static IP addresses for AWS Global Accelerator
• Route 53 health checks
• Elastic Load Balancing pricing
• Amazon Route 53 pricing