Application Load Balancer のリスナー

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

リスナーの設定

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

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

ターゲットがロードバランサーの代わりにHTTPSトラフィックを復号化するようにする必要がある場合は、ポート 443 でTCPリスナーを使用して Network Load Balancer を作成できます。TCP リスナーでは、ロードバランサーは暗号化されたトラフィックを復号化せずにターゲットに渡します。Network Load Balancer の詳細については、「https://docs.aws.amazon.com/elasticloadbalancing/latest/network/ のユーザーガイド」を参照してください。

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

Application Load Balancer は、HTTPSリスナーによる HTTP/2 のネイティブサポートを提供します。1 つの HTTP/2 接続を使用して、最大 128 個のリクエストを並行して送信できます。プロトコルバージョンを使用して、HTTP/2 を使用してターゲットにリクエストを送信できます。詳細については、「プロトコルバージョン」を参照してください。HTTP/2 はフロントエンド接続をより効率的に使用するため、クライアントとロードバランサー間の接続が少なくなることがあります。HTTP/2 のサーバープッシュ機能は使用できません。

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

リスナールール

リスナーには、必ずデフォルトアクションがあります。これはデフォルトルールとも言います。デフォルトルールは削除できず、必ず最後に実行されます。新しいルールの作成は可能で、優先度、1 つ以上のアクション、および 1 つ以上の条件を構成できます。ルールの追加や編集はいつでも行うことができます。詳細については、「ルールの編集」を参照してください。

デフォルトのルール

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

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

ルールの優先順位

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

ルールのアクション

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

ルールの条件

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

ルールアクションタイプ

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

最も優先度の低いアクションが最初に実行されます。各ルールには次のアクションのうち、厳密に 1 つを含む必要があります。forward、redirect、fixed-response。またはそれは最後に実行されるアクションである必要があります。

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

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

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

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

[
  {
      "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 番目の Cookie を生成します。これには AWSALBTGCORS、元の維持 Cookie と同じ情報とこのSameSite属性が含まれます。クライアントは両方の Cookie を受け取ります。

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

[
  {
      "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
              }
          ]
      }
  }
]

[
  {
      "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
          }
      }
  }
]

リダイレクトアクション

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

URI は、次のコンポーネントで構成されます。

protocol://hostname:port/path?query

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

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

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

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

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

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

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

ルールの条件のタイプ

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

各ルールには、オプションで次の各条件を 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 文字と一致） ワイルドカード文字はヘッダー名ではサポートされていません。

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

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

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

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

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

ホストの条件

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

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

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

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

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

パスの条件

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

パスパターンは のパスにのみ適用されURL、クエリパラメータには適用されません。表示可能なASCII文字にのみ適用されます。制御文字 (0x00～0x1f および 0x7f) は除外されます。

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

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

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

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

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

クエリ文字列の条件

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

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

送信元 IP アドレス条件

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

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

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

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

HTTP ヘッダーと Application Load Balancer

HTTP リクエストとHTTPレスポンスは、ヘッダーフィールドを使用してHTTPメッセージに関する情報を送信します。HTTP ヘッダーは自動的に追加されます。ヘッダーフィールドはコロンで区切られた名前と値のペアであり、キャリッジリターン (CR) とラインフィード (LF) で区切ります。HTTP ヘッダーフィールドの標準セットは、2616 RFC の Message Headers で定義されています。また、アプリケーションによって自動的に追加され、広く使用される非標準HTTPヘッダーもあります。一部の非標準HTTPヘッダーにはX-Forwardedプレフィックスが付いています。Application Load Balancer では、次の X-Forwarded ヘッダーがサポートされます。

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

X-Forwarded-For

X-Forwarded-For リクエストヘッダーは、 HTTPまたはHTTPSロードバランサーを使用するときに、クライアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアント/サーバー間のトラフィックをインターセプトするので、サーバーアクセスログにはロードバランサーの IP アドレスのみが含まれます。クライアントの IP アドレスを確認するには、routing.http.xff_header_processing.mode 属性を使用します。この属性を使用すると、Application Load Balancer がターゲットにHTTPリクエストを送信する前に、リクエストの X-Forwarded-Forヘッダーを変更、保持、または削除できます。この属性に指定できる値は、append、preserve、および remove です。この属性のデフォルト値は append です。

Append

デフォルトでは、Application Load Balancer は、クライアントの IP アドレスを X-Forwarded-For リクエストヘッダーに格納し、このヘッダーをサーバーに渡します。X-Forwarded-For リクエストヘッダーがオリジナルリクエストに含まれていない場合、ロードバランサーはリクエスト値としてクライアント IP アドレスを持つリクエストヘッダーを作成します。それ以外の場合、ロードバランサーはクライアント IP アドレスを既存のヘッダーに追加し、 ヘッダーをサーバーに渡します。X-Forwarded-For リクエストヘッダーには、カンマで区切られた複数の IP アドレスを含めることができます。

X-Forwarded-For リクエストヘッダーは以下のような形式です。

X-Forwarded-For: client-ip-address

以下に、IP アドレスが 203.0.113.7 であるクライアントの X-Forwarded-For リクエストヘッダーの例を示します。

X-Forwarded-For: 203.0.113.7

アドレスが のクライアントのX-Forwarded-Forリクエストヘッダーの例を次に示しますIPv62001:DB8::21f:5bff:febf:ce22:8a2e。

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

ロードバランサーでクライアントポート保持属性 (routing.http.xff_client_port.enabled) が有効になっている場合、X-Forwarded-For リクエストヘッダーには、client-ip-address の後にコロンで区切って client-port-number が含まれます。ヘッダーは、次のような形式になります。

IPv4 -- X-Forwarded-For: client-ip-address:client-port-number

IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

の場合IPv6、ロードバランサーが既存のヘッダーclient-ip-addressに を追加すると、アドレスが角括弧で囲まれることに注意してください。

以下は、IPv4アドレスが でポート番号が 12.34.56.78のクライアントのX-Forwarded-Forリクエストヘッダーの例です8080。

X-Forwarded-For: 12.34.56.78:8080

以下は、IPv6アドレスが でポート番号が 2001:db8:85a3:8d3:1319:8a2e:370:7348のクライアントのX-Forwarded-Forリクエストヘッダーの例です8080。

X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Preserve

属性の preserve モードにより、HTTPリクエストの X-Forwarded-For ヘッダーがターゲットに送信される前に変更されることがなくなります。

Remove

属性の remove モードは、ターゲットに送信される前にHTTPリクエストの X-Forwarded-For ヘッダーを削除します。

次の表では、append、preserve、remove モードのいずれかを選択した際にターゲットが受信する X-Forwarded-For ヘッダーの例を示します。この例では、ラストホップの IP アドレスは 127.0.0.1 です。

を使用して X-Forwarded-Forヘッダーを変更、保存、または削除するには AWS CLI

routing.http.xff_header_processing.mode 属性で modify-load-balancer-attributes コマンドを使用します。

X-Forwarded-Proto

X-Forwarded-Proto リクエストヘッダーは、クライアントがロードバランサーへの接続に使用したプロトコル (HTTP または HTTPS) を識別するのに役立ちます。サーバーアクセスログには、サーバーとロードバランサーの間で使用されたプロトコルのみが含まれ、クライアントとロードバランサーの間で使用されたプロトコルに関する情報は含まれません。クライアントとロードバランサーの間で使用されたプロトコルを判別するには、X-Forwarded-Proto リクエストヘッダーを使用します。Elastic Load Balancing は、クライアントとロードバランサーの間で使用されたプロトコルを X-Forwarded-Proto リクエストヘッダーに格納し、このヘッダーをサーバーに渡します。

アプリケーションまたはウェブサイトは、X-Forwarded-Protoリクエストヘッダーに保存されているプロトコルを使用して、適切な にリダイレクトされるレスポンスをレンダリングできますURL。

X-Forwarded-Proto リクエストヘッダーは以下のような形式です。

X-Forwarded-Proto: originatingProtocol

次の例には、 X-Forwarded-Proto リクエストとしてクライアントから発信されたリクエストのHTTPSリクエストヘッダーが含まれています。

X-Forwarded-Proto: https

X-Forwarded-Port

X-Forwarded-Port リクエストヘッダーは、ロードバランサーへの接続にクライアントが使用した送信先ポートを識別するために役立ちます。