リスナールールのアクションタイプ - エラスティックロードバランシング

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

リスナールールのアクションタイプ

アクションは、リスナールールの条件が満たされたときにロードバランサーがリクエストを処理する方法を決定します。各ルールには、一致するリクエストの処理方法を指定するアクションが少なくとも 1 つ必要です。各ルールアクションには、タイプと設定情報があります。Application Load Balancer は、リスナールールに対して次のアクションタイプをサポートしています。

アクションタイプ
authenticate-cognito

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

authenticate-oidc

[HTTPS リスナー] OpenID Connect (OIDC) に準拠する ID プロバイダーを使用してユーザーを認証します。詳細については、「ユーザー認証を設定する」を参照してください。

fixed-response

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

forward

指定されたターゲットグループにリクエストを転送します。詳細については、「転送アクション」を参照してください。

redirect

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

アクションの基本
  • 各ルールには、、forwardredirectまたは のいずれかのルーティングアクションのみを含める必要がありfixed-response、最後に実行するアクションである必要があります。

  • HTTPS リスナーは、ユーザー認証アクションとルーティングアクションを持つルールを持つことができます。

  • 複数のアクションがある場合、優先順位が最も低いアクションが最初に実行されます。

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

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

fixed-response アクションはクライアントリクエストを削除し、カスタム HTTP レスポンスを返します。このアクションを使用して、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 アクションはリクエストをそのターゲットグループにルーティングします。forward アクションを追加する前に、ターゲットグループを作成し、それにターゲットを追加します。詳細については、「Application Load Balancer のターゲットグループを作成する」を参照してください。

forward アクションに複数のターゲットグループを指定する場合は、ターゲットグループごとに重みを指定する必要があります。各ターゲットグループの重みは、0~999 の値です。加重ターゲットグループを持つリスナールールと一致するリクエストは、それらの重みに基づいてこれらのターゲットグループに分散されます。たとえば、ターゲットグループを 2 つ指定し、それぞれ重みが 10 の場合、各ターゲットグループはリクエストの半分を受け取ります。2 つのターゲットグループ (1 つは重みが 10 で、もう 1 つは重みが 20) を指定すると、重みが 20 のターゲットグループは他のターゲットグループの 2 倍の数のリクエストを受信します。

加重ターゲットグループ間でトラフィックを分散するようにルールを設定し、ターゲットグループの 1 つが空であるか、異常なターゲットのみがある場合、ロードバランサーは正常なターゲットを持つターゲットグループに自動的にフェイルオーバーしません。

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

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

CORS (クロスオリジンリソース共有) リクエストの場合、一部のブラウザは維持を有効にするために SameSite=None; Secure を必要とします。この場合、Elastic Load Balancing は 2 番目の Cookie である AWSALBTGCORS を生成します。この Cookie には、元の維持 Cookie と同じ情報に加えてこの 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 } } } ]

リダイレクトアクション

redirect アクションは、クライアントリクエストをある URL から別の URL にリダイレクトします。必要に応じて、一時的 (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}」に相当します。

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