Elastic Load Balancing
Application Load Balancer

Application Load Balancer のリスナー

Application Load Balancer の使用を開始する前に、1 つ以上のリスナーを追加する必要があります。リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。リスナーに対して定義したルールは、ロードバランサーが 1 つ以上のターゲットグループ内のターゲットにリクエストをルーティングする方法を決定します。

リスナーの設定

リスナーは次のポートとプロトコルをサポートします。

  • プロトコル: HTTP、HTTPS

  • ポート: 1 ~ 65535

アプリケーションがビジネスロジックに集中できるように、HTTPS リスナーを使用して、暗号化および復号の作業をロードバランサーに任せることができます。リスナープロトコルが HTTPS の場合は、リスナーに SSL サーバー証明書を少なくとも 1 つデプロイする必要があります。詳細については、「Application Load Balancer 用の HTTPS リスナーを作成する」を参照してください。

Application Load Balancer は WebSockets のネイティブサポートを提供します。WebSocket は、HTTP リスナーと HTTPS リスナーの両方で使用できます。

Application Load Balancer は、HTTPS リスナーに HTTP/2 のネイティブサポートを提供します。1 つの HTTP/2 コネクションで最大 128 のリクエストを並行して送信できます。ロードバランサーは、これらのリクエストを個々の HTTP/1.1 のリクエストに変換し、ターゲットグループの正常なターゲットにこれを分配します。HTTP/2 ではフロントエンド接続を効率的に使用するため、クライアントとロードバランサー間の接続数が減少します。HTTP/2 のサーバープッシュ機能は使用できません。

詳細については、Elastic Load Balancing ユーザーガイドの「リクエストルーティング」を参照してください。

リスナールール

各リスナーにはデフォルトのルールがあり、オプションで追加のルールを定義できます。各ルールは優先度、1 つ以上のアクション、および 1 つ以上の条件で構成されています。ルールの追加や編集はいつでも行うことができます。詳細については、「ルールの編集」を参照してください。

デフォルトのルール

リスナーを作成するときは、デフォルトのルールのアクションを定義します。デフォルトのルールに条件を定義することはできません。リスナーのルールに設定された条件のいずれも満たされない場合は、デフォルトのルールのアクションが実行されます。

デフォルトのルールの例を、コンソールに表示されるとおりに次に示します。


                    リスナーのデフォルトのルール。

ルールの優先順位

各ルールには優先順位があります。ルールは優先順位の低~高順によって評価されます。デフォルトのルールが最後に評価されます。デフォルト以外のルールは、優先順位をいつでも変更できます。デフォルトルールの優先順位は変更できません。詳細については、「ルールの順序変更」を参照してください。

ルールのアクション

ルールのアクションごとにタイプ、順序、およびアクションを実行するために必要な情報があります。詳細については、「ルールアクションタイプ」を参照してください。

ルールの条件

ルールのアクションごとにタイプと設定情報があります。ルールの条件が満たされると、アクションが実行されます。詳細については、「ルールの条件のタイプ」を参照してください。

ルールアクションタイプ

サポートされているルールのアクションタイプを以下に示します。

authenticate-cognito

[HTTPS リスナー] Amazon Cognito を使用してユーザーを認証します。詳細については、「Application Load Balancer を使用してユーザーを認証する」を参照してください。

authenticate-oidc

[HTTPS リスナー] OpenID Connect (OIDC) に準拠する ID プロバイダーを使用してユーザーを認証します。

fixed-response

カスタムの HTTP レスポンスを返します。詳細については、「固定レスポンスアクション」を参照してください。

forward

指定されたターゲットグループにリクエストを転送します。

redirect

1 つの URL から別の URL にリクエストをリダイレクトします。詳細については、「リダイレクトアクション」を参照してください。

順番の値が最も小さいアクションが最初に実行されます。各ルールには次のアクションのうち、厳密に 1 つを含む必要があります。forwardredirectfixed-response。またはそれは最後に実行されるアクションである必要があります。

固定レスポンスアクション

クライアントリクエストを破棄し、カスタムの HTTP レスポンスを返すには、fixed-response アクションを使用します。このアクションを使用して、2XX、4XX、または 5XX のレスポンスコードとオプションのメッセージを返すことができます。

fixed-response アクションが実行されると、そのアクションと、リダイレクトターゲットの URL がアクセスログに記録されます。詳細については、「アクセスログのエントリ」を参照してください。fixed-response アクションが正常に実行された数は、HTTP_Fixed_Response_Count メトリクスでレポートされます。詳細については、「Application Load Balancer のメトリクス」を参照してください。

例 AWS CLI の固定レスポンスアクションの例

ルールの作成時、または変更時にアクションを指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。次のアクションは指定されたステータスコードとメッセージの本文を含む固定レスポンスを送信します。

[ { "Type": "fixed-response", "FixedResponseConfig": { "StatusCode": "200", "ContentType": "text/plain", "MessageBody": "Hello world" } } ]

転送アクション

forward アクションを使用して、指定されたターゲットグループにリクエストをルーティングできます。

例 AWS CLI の転送アクションの例

ルールの作成時、または変更時にアクションを指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。次のアクションは指定されたターゲットグループにリクエストを転送します。

[ { "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a06" } ]

リダイレクトアクション

クライアントリクエストを別の URL にリダイレクトするには、redirect アクションを使用します。必要に応じて、一時的 (HTTP 302) または恒久的 (HTTP 301) としてリダイレクトを設定します。

URI のコンポーネントは次のとおりです。

protocol://hostname:port/path?query

リダイレクトのループを避けるために、次のコンポーネントを 1 つ以上変更する必要があります: protocol、hostname、port、または path。変更しないコンポーネントはすべて、元の値が保持されます。

プロトコル

プロトコル (HTTP または HTTPS)。HTTP から HTTP、HTTP から HTTPS、HTTPS から HTTPS にリダイレクトできます。HTTPS から HTTP にリダイレクトすることはできません。

hostname

ホスト名。ホスト名は大文字と小文字を区別せず、最大 128 文字の長さで、英数字、ワイルドカード (* と ?)、およびハイフン (-) で構成されます。

port

ポート (1~65535)。

パス

絶対パス (先頭は「/」で始まる)。パスは大文字と小文字が区別され、最大 128 文字の長さで、英数字、ワイルドカード (* と ?)、& (& を使用) および次の特殊文字 _-.$/~"'@:+ で構成されます。

query

クエリパラメーター

次の予約キーワードを使用して、元 URL の URI コンポーネントをターゲット URL で再利用できます。

  • #{protocol} – プロトコルが保持されます。プロトコルとクエリコンポーネントで使用する

  • #{host} – ドメインが保持されます。ホスト名、パス、クエリコンポーネントで使用する

  • #{port} – ポートが保持されます。ポート、パス、クエリコンポーネントで使用する

  • #{path} – パスが保持されます。パスとクエリコンポーネントで使用する

  • #{query} – クエリパラメーターが保持されます。クエリコンポーネントで使用する

redirect アクションが実行されると、そのアクションはアクセスログに記録されます。詳細については、「アクセスログのエントリ」を参照してください。redirect アクションが正常に実行された数は、HTTP_Redirect_Count メトリクスでレポートされます。詳細については、「Application Load Balancer のメトリクス」を参照してください。

例 コンソールを使用したリダイレクトアクションの例

次のルールでは、HTTPS プロトコルと指定されたポート (40443) を使用する URL にリダイレクトする永続的 URL が設定されますが、元のホスト名、パス、およびクエリパラメータは保持されます。この画面は「https://#{host}:40443/#{path}?#{query}」に相当します。


                        HTTPS プロトコルと指定されたポート (40443) を使用するが、元の URL の元ドメイン、パス、およびクエリパラメーターを保持する URL にリクエストをリダイレクトするルール。

次のルールでは、元のプロトコル、ポート、ホスト名、クエリパラメーターを保持する URL に恒久的ダイレクトをセットアップし、#{path} キーワードを使用して次の変更されたパスを作成します。この画面は「#{protocol}://#{host}:#{port}/new/#{path}?#{query}」に相当します。


                        元のプロトコル、ポート、ホスト名、クエリパラメータを保持し、キーワード #{path} を使用して変更されたパスを作成する URL にリクエストをリダイレクトするルール。

例 AWS CLI のリダイレクトアクションの例

ルールの作成時、または変更時にアクションを指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。以下のアクションは、HTTP リクエストと同じホスト名、パス、およびクエリストリングを使用して、HTTP リクエストをポート 443 上の HTTPS リクエストにリダイレクトします。

[ { "Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}", "StatusCode": "HTTP_301" } } ]

ルールの条件のタイプ

サポートされているルールの条件のタイプを以下に示します。

host-header

各リクエストのホスト名に基づいたルーティング。詳細については、「ホストの条件」を参照してください。

http-header

各リクエストの HTTP ヘッダーに基づいたルーティング。詳細については、「HTTP ヘッダー条件」を参照してください。

http-request-method

各リクエストの HTTP リクエストメソッドに基づいたルーティング。詳細については、「HTTP リクエストメソッド条件」を参照してください。

path-pattern

リクエスト URL のパスパターンに基づいたルーティング。詳細については、「パスの条件」を参照してください。

query-string

キーと値のペアまたはクエリストリングの値に基づいたルーティング。詳細については、「クエリ文字列の条件」を参照してください。

source-ip

各リクエストの送信元 IP アドレスに基づいたルーティング。詳細については、「送信元 IP アドレス条件」を参照してください。

各ルールには、以下の条件の 0 個または 1 つを含めることができます。host-headerhttp-request-methodpath-patternsource-ipおよび 0 個以上の以下の条件 http-headerquery-stringを含めることができます。

1 つの条件につき最大 3 つの一致評価を指定できます。たとえば、各 http-header 条件に対して、リクエスト内の HTTP ヘッダーの値と比較する最大 3 つの文字列を指定できます。いずれかのストリングが HTTP ヘッダーの値と一致すれば、条件は満たされます。すべての文字列が一致することを要求するには、一致評価ごとに 1 つの条件を作成します。

1 つのルールにつき最大 5 つの一致評価を指定できます。すべての文字列が一致であることを要求するには、一致評価ごとに1つの条件を作成します。

http-headerhost-headerpath-patternquery-string 条件に対する一致評価にワイルドカード文字を含めることができます。1 ルールあたりのワイルドカード文字は 5 つまでです。

HTTP ヘッダー条件

HTTP ヘッダー条件を使用して、リクエストの HTTP ヘッダーに基づいてリクエストをルーティングするルールを設定できます。標準またはカスタムの HTTP ヘッダーフィールドの名前を指定できます。ヘッダー名と一致評価では大文字と小文字は区別されません。次のワイルドカード文字は比較文字列でサポートされています。* (0 個以上の文字と一致) および ? (厳密に 1 文字と一致)ワイルドカード文字はヘッダー名ではサポートされていません。

例 AWS CLIの HTTP ヘッダー条件の例

ルールの作成時、または変更時に条件を指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。以下の条件は、指定された文字列の 1 つに一致するユーザーエージェントヘッダーを使用するリクエストによって満たされます。

[ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]

HTTP リクエストメソッド条件

HTTP リクエストメソッド条件を使用して、リクエストの HTTP リクエストメソッドに基づいてリクエストをルーティングするルールを設定できます。標準またはカスタムの HTTP メソッドを指定できます。一致評価は大文字と小文字を区別します。ワイルドカード文字はサポートされていません。したがって、メソッド名は厳密な一致である必要があります。

HEAD リクエストに対する応答はキャッシュされる可能性があるため、GET リクエストと HEAD リクエストを同じ方法でルーティングすることをお勧めします。

例 AWS CLIの HTTP メソッド条件の例

ルールの作成時、または変更時に条件を指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。以下の条件は、指定されたメソッドを使用するリクエストによって満たされます。

[ { "Field": "http-request-method", "HttpRequestMethodConfig": { "Values": ["CUSTOM-METHOD"] } } ]

ホストの条件

ホストの条件を使用して、ホストヘッダーのホスト名に基づいてリクエストをルーティングする (ホストベースのルーティングとも呼ばれます) ルールを定義できます。これにより、1 つのロードバランサーを使用して複数のドメインをサポートできます。

ホスト名では大文字と小文字が区別されず、最大 128 文字までの次の文字を含めることができます。

  • A〜Z、a〜z、0〜9

  • - .

  • * (0 個以上の文字と一致します)

  • ? (厳密に 1 個の文字と一致します)

少なくとも 1 つの「.」文字を含める必要があります。最後の「.」の文字の後はアルファベット文字のみ含めることができます。

ホスト名の例

  • example.com

  • test.example.com

  • *.example.com

ルール *.example.com は、test.example.com には一致しますが、example.com には一致しません。

例 AWS CLIのホストヘッダー条件の例

ルールの作成時、または変更時に条件を指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。以下の条件は、指定された文字列に一致するホストヘッダーを使用するリクエストによって満たされます。

[ { "Field": "host-header", "HostHeaderConfig": { "Values": ["*.example.com"] } } ]

パスの条件

パスの条件を使用して、リクエスト内の URL に基づいてリクエストをルーティングするルールを定義できます (パスベースのルーティングとも呼ばれます)。

パスパターンは URL のパスにのみ適用され、クエリパラメータには適用されません。

パスパターンでは大文字と小文字が区別され、最大 128 文字までの次の文字を含めることができます。

  • A~Z、a~z、0~9

  • _ - . $ / ~ " ' @ : +

  • & (& を使用)

  • * (0 個以上の文字と一致します)

  • ? (厳密に 1 個の文字と一致します)

パスパターンの例

  • /img/*

  • /js/*

パスパターンはリクエストのルーティングに使用されますが、変更はしません。たとえば、ルールにパスパターン /img/* がある場合、ルールは /img/picture.jpg のリクエストを /img/picture.jpg のリクエストとして、指定されたターゲットグループに転送します。

例 AWS CLI のパスパターン条件の例

ルールの作成時、または変更時に条件を指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。以下の条件は、指定された文字列を含む URL を使用するリクエストによって満たされます。

[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/img/*"] } } ]

クエリ文字列の条件

クエリ文字列の条件を使用して、キー/値のペアまたはクエリ文字列内の値に基づいてリクエストをルーティングするルールを設定できます。一致評価は大文字と小文字を区別しません。次のワイルドカード文字はサポートされています。* (0 個以上の文字と一致) および ? (厳密に 1 文字と一致)

例 AWS CLI のクエリ文字列の条件の例

ルールの作成時、または変更時に条件を指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。次の条件は、「version = v1」のキー/値ペア、または「example」に設定されたキーのいずれかを含むクエリ文字列を使用するリクエストによって満たされます。

[ { "Field": "query-string", "QueryStringConfig": { "Values": [ { "Key": "version", "Value": "v1" }, { "Value": "example" } ] } } ]

送信元 IP アドレス条件

送信元 IP アドレス条件を使用して、リクエストの送信元 IP アドレスに基づいてリクエストをルーティングするルールを設定できます。IP アドレスは CIDR 形式で指定する必要があります。IPv4 と IPv6 の両方のアドレスを使用できます。ワイルドカード文字はサポートされていません。

クライアントがプロキシの背後にある場合、これはクライアントの IP アドレスではなくプロキシの IP アドレスです。

この条件は、X-Forwarded-For ヘッダーのアドレスでは満たされません。X-Forwarded-For ヘッダー内のアドレスを検索するにhttp-header 条件を使用します。

例 AWS CLI の送信元 IP 条件の例

ルールの作成時、または変更時に条件を指定できます。詳細については、「create-rule」および「modify-rule」コマンドを参照してください。次の条件は、指定された CIDR ブロックの 1 つの送信元 IP アドレスを使用するリクエストによって満たされます。

[ { "Field": "source-ip", "SourceIpConfig": { "Values": ["192.0.2.0/24", "198.51.100.10/32"] } } ]