Server Load Balancer:ドメイン名とパスの照合に関する転送ルール

シナリオ 1： HTTP から HTTPS へのリダイレクト

HTTP リクエストを HTTPS にリダイレクトして、転送中のデータが暗号化されるようにします。これは、HTTP リスナー (ポート 80) に転送ルールを追加することで実現できます。

結果： ユーザーが http://www.example.com/page にアクセスすると、ブラウザは自動的に https://www.example.com/page にリダイレクトします。

このルールは HTTP リスナー (ポート 80) で設定してください。また、HTTPS リスナー (ポート 443) が作成され、有効な SSL 証明書に関連付けられていることを確認してください。完全な前提条件と手順については、「ALB を使用して HTTP リクエストを HTTPS にリダイレクトする」をご参照ください。

シナリオ 2： パスによるトラフィックのルーティング

単一のドメインに対して、異なるパスを持つリクエストを異なるサーバーグループに転送できます。例えば、API リクエストと静的アセットリクエストを別々のバックエンドに転送できます。

ルール 1： /api/* へのリクエストを API サーバーグループに転送します。

ルール 2： /static/* へのリクエストを静的アセットサーバーグループに転送します。

ALB は、転送ルールを優先度番号に基づいて順番に評価します。より具体的なパスルール (優先度番号が小さい) を、より広範なルールの前に配置して、ワイルドカードルールに先に一致しないようにしてください。例えば、/api/v2/* のルールは、/api/* のルールよりも低い優先度番号を持つ必要があります。

シナリオ 3： 複数のドメインの転送

単一の ALB インスタンスで複数のドメインをホストし、各ドメインへのリクエストをそれぞれのバックエンドサーバーグループに転送します。

ルール 1： www.example.com へのリクエストを Web サーバーグループに転送します。

ルール 2： api.example.com へのリクエストを API サーバーグループに転送します。

シナリオ 4： 転送前にパスプレフィックスを削除

リクエストをバックエンドに転送する前に、リクエストパスから特定のプレフィックスを削除しつつ、プレフィックス後の複数レベルのパスをキャプチャします。例えば、ALB が www.example.com/api/aaa/bbb/... へのリクエストを転送する際に、/api 部分をパスから削除し、/aaa/bbb/... のような後続の複数レベルのパスをキャプチャする必要があります。

書き換えは ALB 内部でパスを置き換えます。クライアントのブラウザのアドレスバーの URL は変更されません。リダイレクトは新しい URL をクライアントに返し、ブラウザのアドレスバーは新しい URL に更新されます。バックエンドがプレフィックスなしのパスを受け取るだけでよい場合は書き換えを使用します。クライアントが URL の変更を認識する必要がある場合はリダイレクトを使用します。

結果： www.example.com/api/aaa/bbb/... へのリクエストに対し、バックエンドサーバーはパス /aaa/bbb/... を受け取ります。

シナリオ 5： ベアドメインから www へのリダイレクト

ベアドメイン (例： example.com) から www.example.com へのリクエストをリダイレクトします。これにより、エントリポイントが統一され、SEO の向上と管理の簡素化が図れます。

結果： ユーザーが example.com にアクセスすると、ブラウザは自動的に www.example.com にリダイレクトします。プロトコルとポートは変更されません。

HTTP リクエストを HTTPS にリダイレクトする必要もある場合は、この設定をシナリオ 1 と組み合わせてください。

シナリオ 6： ワイルドカードドメインの照合

ワイルドカードドメインを使用してすべてのサブドメインを照合し、それらのリクエストを同じサーバーグループに転送します。

結果： a.example.com、b.example.com、tenant1.example.com などのすべての照合するサブドメインへのリクエストは、同じサーバーグループに転送されます。

特定のサブドメインを別のサーバーグループに転送するには、その完全なドメインに対するルールを作成し、ワイルドカードルールよりも低い優先度番号を割り当ててください。ALB は、ドメイン照合の具体性ではなく、優先度番号に基づいてルールを評価します。

シナリオ 7： HTTP ヘッダーによるカナリアリリース

HTTP ヘッダーを使用してカナリアリリースを実装します。これにより、特定のヘッダーを持つリクエストは新バージョンのサーバーグループに転送され、その他のリクエストは現行バージョンのサーバーグループに転送されます。

ルール 1 (カナリアルール、優先度高)： X-Canary: true ヘッダーを含むリクエストを新バージョンのサーバーグループに転送します。

ルール 2 (デフォルトルール、優先度低)： カナリアヘッダーのないリクエストは、現行バージョンのサーバーグループに転送されます。これは、リスナーのデフォルト転送ルールを使用して実装できます。

結果： クライアントリクエストに X-Canary: true ヘッダーが含まれている場合、トラフィックは新バージョンのサーバーグループに転送されます。このヘッダーのないリクエストは、現行バージョンのサーバーグループに転送されます。

カナリアトラフィックが最初に照合されるようにするには、カナリアルールがデフォルトルールよりも低い優先度番号 (優先度が高いことを示す) を持つ必要があります。Cookie とサーバーグループの重みに基づくカナリアリリースの方法については、「ALB を使用してカナリアリリースを実装する」をご参照ください。

ドメイン名のみを書き換える

リクエストされたドメイン名を別のドメイン名に書き換え、パスとクエリ文字列は変更しない場合、ルールを次のように設定します：

• 転送条件： ドメイン名を元のドメイン名 (例： old.example.com) に設定します。

• 転送操作： 書き換えを選択します。ドメイン名を新しいドメイン名 (例： new.example.com) に設定し、パスを ${path} に、クエリを ${query} に設定します。また、転送 を設定してサーバーグループを指定します。

パスにプレフィックスを追加する

パスにプレフィックスを追加する (例： /users/list を /v2/users/list に書き換える) には、ルールを次のように設定します：

• 転送条件： パスを正規表現 ^/(.*) に一致するように設定します。

• 転送操作： 書き換えを選択し、パスを /v2/${1} に設定します。また、転送 を設定してサーバーグループを指定します。

ルールを設定すると、ALB は /users/list へのリクエストを /v2/users/list に書き換え、バックエンドサーバーに転送します。

パスプレフィックスを削除する

このトピックの「ユースケース 4： パスプレフィックスを削除した後のリクエスト転送」をご参照ください。このユースケースでは、書き換えまたはリダイレクトアクションと正規表現一致を使用して、/api/* などのプレフィックスを削除するための完全な設定例を提供しています。

転送ルールの照合とルーティングのトラブルシューティング

転送ルールが期待どおりにリクエストをルーティングしない場合は、次のトラブルシューティング手順を使用してください：

1. ルールの優先度を確認する： ALB はルールを優先度番号の昇順で評価し、最初に一致したルールで停止します。より広範なルールが低い優先度番号を持つ (したがって先に評価される) 場合、より高い優先度番号を持つより具体的なルールは一致しません。

2. 照合タイプを確認する： 正しい照合タイプ (完全一致、ワイルドカード、または正規表現) を使用していることを確認してください。例えば、/api の完全一致は /api/users には一致しません。両方に一致させるには、/api/* のようなワイルドカードを使用する必要があります。

3. 複数の条件を確認する： 1 つの転送ルールに複数の条件を設定する場合、異なるタイプの条件は AND 演算子で結合され、同じ条件タイプの複数の値は OR 演算子で結合されます。詳細については、「リスナー転送ルールの設定」をご参照ください。

4. アクセスログを確認する： ALB アクセスログの host および request_uri フィールドを使用して、ALB が受信したリクエストの詳細が期待どおりであることを確認します。

書き換えとリダイレクトの比較