Application Load Balancer のリスナー - Elastic Load Balancing
リスナーの設定リスナールールルールアクションタイプルールの条件のタイプ

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Application Load Balancer のリスナー

リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。Application Load Balancer の使用を開始する前に、最低 1 つのリスナーを追加する必要があります。ロードバランサーにリスナーがない場合、クライアントからのトラフィックを受信できません。リスナーに対して定義したルールにより、ロードバランサーが EC2 インスタンスなど登録したターゲットにリクエストをルーティングする方法が決まります。

コンテンツ

リスナーの設定

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

  • プロトコル: HTTP、HTTPS

  • ポート: 1 ～ 65535

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

ターゲットがロードバランサーではなく HTTPS トラフィックを復号化する必要がある場合は、ポート 443 に TCP リスナーを使用してNetwork Load Balancer を作成できます。TCP リスナーを使用すると、ロードバランサーは暗号化されたトラフィックを復号化せずにターゲットに渡します。の詳細については、「 Network Load Balancer のユーザーガイド」を参照してください。

アプリケーションロードバランサーはをネイティブサポートします。 WebSocketsHTTP 接続アップグレードを使用して、既存の HTTP/1.1 接続を WebSocket (wsまたはwss) 接続にアップグレードできます。アップグレードすると、リクエスト (ロードバランサーおよびターゲットへの) に使用される TCP 接続は、 WebSocket ロードバランサーを介したクライアントとターゲットの間の永続的な接続になります。HTTP リスナーと HTTPS リスナーの両方で使用できます WebSockets 。リスナー用に選択したオプションは、HTTP WebSocket トラフィックだけでなく接続にも適用されます。詳細については、Amazon CloudFront 開発者ガイドの 「 WebSocket プロトコルの仕組み」を参照してください。

Application Load Balancer は HTTPS リスナーで HTTP/2 のネイティブサポートを提供します。1 つの HTTP/2 コネクションで最大 128 のリクエストを並行して送信できます。プロトコルバージョンを使用して、HTTP/2 を使用するターゲットに要求を送信することができます。詳細については、「プロトコルバージョン」を参照してください。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 つを含む必要があります。forward、redirect、fixed-response。またはそれは最後に実行されるアクションである必要があります。

プロトコルバージョンが gRPC または HTTP/2 の場合、サポートされているアクションは forward アクションだけです。

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

クライアントリクエストを破棄し、カスタムの 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 アクションを使用して、1 つ以上のターゲットグループにリクエストをルーティングできます。forward アクションに複数のターゲットグループを指定する場合は、ターゲットグループごとに重みを指定する必要があります。各ターゲットグループの重みは、0～999 の値です。加重ターゲットグループを持つリスナールールと一致するリクエストは、それらの重みに基づいてこれらのターゲットグループに分散されます。たとえば、ターゲットグループを 2 つ指定し、それぞれ重みが 10 の場合、各ターゲットグループはリクエストの半分を受け取ります。2 つのターゲットグループ (1 つは重みが 10 で、もう 1 つは重みが 20) を指定すると、重みが 20 のターゲットグループは他のターゲットグループの 2 倍の数のリクエストを受信します。

デフォルトでは、加重ターゲットグループ間でトラフィックを分散するようにルールを設定しても、スティッキーセッションが優先されるとは限りません。スティッキーセッションが確実に優先されるようにするには、ルールのターゲットグループの維持を有効にします。ロードバランサーが最初にリクエストを加重ターゲットグループにルーティングすると、 AWSALBTG 選択したターゲットグループに関する情報をエンコードする名前の Cookie を生成し、Cookie を暗号化して、その Cookie をクライアントへの応答に含めます。クライアントは、受信した Cookie を、ロードバランサーへの後続のリクエストに含める必要があります。ロードバランサーが、ターゲットグループの維持が有効になっているルールに一致するリクエストを受信して Cookie が含まれている場合、リクエストは Cookie で指定されたターゲットグループにルーティングされます。

Application Load Balancer は、URL エンコードされた Cookie 値をサポートしていません。

CORS (クロスオリジンリソース共有) リクエストの場合、一部のブラウザは維持を有効にするために SameSite=None; Secure を必要とします。この場合、Elastic Load Balancing は 2 つ目のクッキーを生成します。このクッキーには AWSALBTGCORS、SameSite元のスティッキネスクッキーと同じ情報にこの属性を加えたものが含まれます。クライアントは両方の Cookie を受け取ります。

例 1 つのターゲットグループを使用した転送アクションの例

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

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]
例 2 つの加重ターゲットグループを使用した転送アクションの例

次のアクションは、各ターゲットグループの重みに基づいて、指定された 2 つのターゲットグループにリクエストを転送します。

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]
例 維持を有効にした転送アクションの例

複数のターゲットグループを含む転送アクションがあり、1 つ以上のターゲットグループでスティッキーセッションが有効になっている場合は、ターゲットグループの維持を有効にする必要があります。

次のアクションは、ターゲットグループの維持を有効にして、指定された 2 つのターゲットグループにリクエストを転送します。維持 Cookie を含まないリクエストは、各ターゲットグループの重みに基づいてルーティングされます。

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

リダイレクトアクション

クライアントリクエストを別の 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

クエリパラメータ 最大長は 128 文字です。

次の予約キーワードを使用して、元 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}」に相当します。

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

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

New EC2 experience
元のプロトコル、ポート、ホスト名、クエリパラメータを保持し、キーワード #{path} を使用して変更されたパスを作成する URL にリクエストをリダイレクトするルール。
Old EC2 experience
元のプロトコル、ポート、ホスト名、クエリパラメータを保持し、キーワード #{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 アドレス条件」を参照してください。

各ルールには、オプションで次の各条件を 1 つ含めることができます。host-header、http-request-method、path-pattern、および source-ip。各ルールには、オプションで次の各条件を 1 つ以上含めることもできます。http-header および query-string。

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

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

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

ルールは表示可能な ASCII 文字にのみ適用されます。制御文字 (0x00 ～ 0x1f および 0x7f) は除外されます。

デモについては、「Advanced Request Routing」を参照してください。

HTTP ヘッダー条件

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

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

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

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

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

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

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

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

ルールの作成時、または変更時に条件を指定できます。詳細については、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 のパスにのみ適用され、クエリパラメータには適用されません。表示可能な ASCII 文字にのみ適用されます。制御文字 (0x00 ～ 0x1f および 0x7f) は除外されます。

ルール評価は URI の正規化が行われた後にのみ実行されます。

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

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

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

  • & (& を使用)

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

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

プロトコルバージョンが grPC の場合は、パッケージ、サービス、またはメソッドに固有の条件を指定できます。

HTTP パスパターンの例

  • /img/*

  • /img/*/pics

grPC パスパターンの例

  • /package

  • /package.service

  • /package.service/method

パスパターンはリクエストのルーティングに使用されますが、変更はしません。例えば、ルールにパスパターン /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 ルール条件に 255.255.255.255/32 CIDR を指定することはできません。

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

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

例 のソース IP 条件の例 AWS CLI

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

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