すべてのプロダクト
Search
ドキュメントセンター

Server Load Balancer:ドメイン名とURL パスのマッチング用転送ルール

最終更新日:Jun 25, 2026

このトピックでは、ドメイン名とパスのマッチング、リライト、リダイレクトといった ALB 転送ルールの設定例について説明します。

設定例

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

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

パラメータ

説明

[転送条件]

パス完全一致とワイルドカードに設定し、 /* と入力します。

[転送操作]

リダイレクト を選択します。

  • [プロトコル]:HTTPS を選択します。

  • [ドメイン名]: ${host}

  • [ポート]: 既存の HTTPS リスナーのポート (443 など) を入力します。

  • [パス]: ${path}

  • [クエリ]: ${query}

  • [ステータスコード]: 301 を選択します。

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

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

シナリオ 2: パスベースのトラフィックルーティング

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

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

パラメータ

説明

[転送条件]

パス完全一致とワイルドカード に設定し、 /api/* を入力します。

[転送操作]

転送 を選択し、次に API サーバーグループを選択します。

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

パラメータ

説明

[転送条件]

パス完全一致とワイルドカードに設定し、/static/* を入力します。

[転送操作]

転送を選択し、次に静的アセットサーバーグループを選択します。

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

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

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

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

パラメータ

説明

[転送条件]

ドメイン名完全一致とワイルドカード に設定し、www.example.com を入力します。

[転送操作]

転送 を選択し、次に Web サーバーグループを選択します。

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

パラメータ

説明

[転送条件]

ドメイン名完全一致とワイルドカード に設定し、api.example.com を入力します。

[転送操作]

転送 を選択し、次に API サーバーグループを選択します。

シナリオ 4: 転送前のパスプレフィックス削除

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

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

書き換え

パラメータ

説明

[転送条件]

[ドメイン名]

完全一致とワイルドカード に設定し、www.example.com を入力します。

[パス]

正規表現 | 大文字と小文字を区別しない に設定し、^/api/(.*) を入力します。

[転送操作]

[書き換え]

  • [ドメイン名]:${host}

  • [パス]: /${1}

  • [クエリ]: ${query}

[転送]

ターゲットサーバーグループを選択します。

リダイレクト

パラメータ

説明

[転送条件]

[ドメイン名]

完全一致とワイルドカード に設定し、www.example.com を入力します。

[パス]

正規表現 | 大文字と小文字を区別しない に設定し、^/api/(.*) と入力します。

[転送操作]

[リダイレクト]

  • [プロトコル]: ${protocol}

  • [ドメイン名]: ${host}

  • [ポート]: ${port}

  • [パス]: /${1}

  • [クエリ]: ${query}

  • [ステータスコード]:301 を選択します。

結果www.example.com/api/aaa/bbb/... へのリクエストの場合、バックエンドサーバーはパス /aaa/bbb/... を受信します。

シナリオ 5: ネイキッドドメインから www へのリダイレクト

ネイキッドドメイン (example.com など) からのリクエストを www.example.com にリダイレクトします。これにより、SEO の向上と管理を容易にするためにエントリポイントが統一されます。

パラメータ

説明

[転送条件]

ドメイン名完全一致とワイルドカード に設定し、example.com と入力します。

[転送操作]

リダイレクト を選択します。

  • [プロトコル]: ${protocol}

  • [ドメイン名]: www.example.com を入力します。

  • [ポート]: ${port}

  • [パス]: ${path}

  • [クエリ]: ${query}

  • [ステータスコード]: 301 を選択します。

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

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

シナリオ 6: ワイルドカードドメインのマッチング

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

パラメータ

説明

[転送条件]

ドメイン名完全一致とワイルドカード に設定し、*.example.com を入力します。

[転送操作]

転送を選択し、次にターゲットサーバーグループを選択します。

結果a.example.comb.example.comtenant1.example.com など、マッチするすべてのサブドメインへのリクエストが同じサーバーグループに転送されます。

特定のサブドメインを別のサーバーグループに転送するには、そのドメインに完全一致するルールを作成し、ワイルドカードルールよりも小さい優先度番号を付与してください。ALB は、ドメインマッチングの特異性ではなく、優先度番号に基づいてルールを評価します。

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

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

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

パラメータ

説明

[転送条件]

HTTP ヘッダー を選択し、キーを X-Canary、値を true に設定します。

[転送操作]

転送 を選択し、次に新しいバージョンのサーバーグループを選択します。

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

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

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

転送ルールにおけるドメインマッチング

ALB は、転送ルールを優先度番号の小さい順に評価し、最初に一致したルールで停止します。ルールは、ドメインの具体性によって自動的にソートされません。この動作は、具体性に基づいてルールを自動的に優先する CLB とは異なります (例: 完全一致 > より限定的なワイルドカード > より広範なワイルドカード)。

たとえば、リスナーに次の 2 つのルールがあるとします。

優先度番号

一致条件

ルール 1 (優先度: 1)

ドメイン = *.example.com → サーバーグループ A に転送

ルール 2 (優先度: 2)

ドメイン = www.example.com → サーバーグループ B に転送

www.example.com へのリクエストは、ルール 1 の優先度番号が低いため、ルール 2 (完全一致ルール) ではなく、ルール 1 (ワイルドカードルール) に一致します。

ベストプラクティス:より具体的なルールが先に評価されるように、そのルールには、より一般的 (具体的でない) なルールよりも低い優先度番号を割り当ててください。たとえば、www.example.com のルールを優先度 1 に、*.example.com のルールを優先度 2 に設定してください。

一致タイプ

説明

完全一致およびワイルドカード一致

  • 一致の説明

    • 完全一致:リクエストされたドメイン名は、ルールで指定されたものと同一である必要があります。

    • ワイルドカード一致:リクエストされたドメイン名は、ルールで指定されたワイルドカードパターンと一致する必要があります。

  • 要件

    ドメイン名は 3~256 文字で、文字、数字、および次の特殊文字のみを含めることができます:.-?=~_+\^*!$&|()[]。ワイルドカードとしてアスタリスク (*) と疑問符 (?) を使用できます。

  • リクエストされたドメイン名:www.example.com

    • 完全一致:ルールが www.example.com に設定されている場合に一致します。

    • ワイルドカード一致:ルールが *.example.com または www.example.* に設定されている場合に一致します。

正規表現一致

  • 一致の説明

    リクエストされたドメイン名は、ルールで指定された正規表現と一致する必要があります。

  • 要件

    ドメイン名は 3~256 文字で、文字、数字、および次の特殊文字のみを含めることができます:.-?=~_+\^*!$&|()[]。正規表現で使用する場合、一部の特殊文字はメタ文字として扱われるため、エスケープが必要な場合があります。

  • リクエストされたドメイン名:www.example.com

    ルールが正規表現 ^www.example.com$ に設定されている場合に一致します。この一致では、大文字と小文字を区別しません。

転送ルールのパスマッチング

ALB のパス照合ルールは Nginx とは異なります。ALB は最長プレフィックス一致の原則をサポートしていません。たとえば、Nginx は location /api のような一般的な設定に最長プレフィックス一致方式を使用します。ALB で同じ効果を得るには、ワイルドカードを使用する必要があります。パスを /api/* (完全一致とワイルドカードの組み合わせ) のように設定できます。

リスナーに /api/*/api/v2/* の両方のルールが存在する場合、/api/v2/* ルールにより小さいルール番号を割り当て、/api/* ルールより前に配置する必要があります。そうしないと、/api/* ルールがすべてのリクエストに最初に一致してしまいます。

マッチタイプ

説明

完全一致およびワイルドカードマッチ

  • マッチングの説明

    • 完全一致:リクエストされたパスが、ルールで指定されたパスと完全に一致する必要があります。

    • ワイルドカードマッチ:リクエストされたパスが、ルールで指定されたワイルドカードパターンと一致する必要があります。

  • 入力要件

    パスはスラッシュ (/) で始まり、文字、数字、および次の特殊文字 ($-_.+/&~@:) のみを含む必要があります。アスタリスク (*) と疑問符 (?) はワイルドカードとして機能します。

  • リクエストパス:/example/text

    • 完全一致:ルールにパス /example/text が設定されている場合、リクエストは一致します。

    • ワイルドカード一致: ルールにパスとして /example/* が設定されている場合にリクエストが一致します。

正規表現一致

  • マッチングの説明

    リクエストされたパスが、ルールで指定された正規表現と一致する必要があります。

  • 入力要件

    正規表現には、英字、数字、および以下の特殊文字のみを含める必要があります:.-_/=?~^*$:()[]+|

  • リクエストパス: /api/v2/Users

    • 大文字と小文字の区別: 正規表現が ^/api/(.*)/Users$ に設定されている場合、リクエストは一致します。

    • 大文字と小文字を区別しない:正規表現が ^/api/(.*)/users$ に設定されている場合、リクエストは一致します。

書き換えとリダイレクトのための高度なパス設定

転送条件で正規表現を使用してパスを定義した場合、転送アクションの書き換えまたはリダイレクトのパスで、正規表現の置換を使用できます。

  • 注意事項

    • 転送条件の正規表現で、丸かっこ( )によって定義されるキャプチャグループの数は、転送アクションの書き換えパスまたはリダイレクトパスにある ${n} 変数の数と一致する必要があります。

    • 転送アクションの書き換えまたはリダイレクトのパスには、${1}${2}${3} を 1 つ以上含める必要があります。これらの変数を他の文字に置き換えないでください。

    • 書き換えまたはリダイレクトのパスでは、$ 文字は、次の変数を参照する場合にのみ使用してください:${host}${path}${port}${protocol}${query}、および ${1}${2}${3} などの正規表現キャプチャグループ変数です。その他の変数はサポートされていません。

  • 仕組み

    1. パス照合:クライアントが、転送ルール内の正規表現に一致するリクエストを送信します。

    2. 抽出と置換: システムは、丸括弧 ( ) で定義された最初の 3 つのキャプチャグループからコンテンツを抽出し、${1}${2}、および ${3} 変数に保存します。 これらの変数は、転送アクションの書き換えまたはリダイレクトパスでの置換に使用されます。

    3. パスの生成:システムは ${1}${2}${3} 変数をキャプチャした値に置き換え、書き換えまたはリダイレクトの最終パスを生成します。

    番号

    手順

    1

    転送ルールの転送条件と転送アクションを設定します。

    • 転送条件のパス:/app/(.*)/(.*)/settings

    • 書き換えまたはリダイレクトアクションのパス:/${1}/${2}

    2

    クライアントが、パスに一致するリクエストを送信します。

    • クライアントからのリクエストパス:/app/users/profile/settings

    • 転送条件で一致したパス:/app/(.*)/(.*)/settings

    3

    値を抽出して置換します。

    システムは、転送条件のパスに含まれる 2 つの (.*) キャプチャグループから usersprofile を抽出し、転送アクション用の ${1} および ${2} 変数にそれぞれ保存します。

    • ${1}users に置換されます。

    • ${2}profile に置換されます。

    4

    パスを生成します。

    バックエンドサーバーが受信するパス:/users/profile

  • 設定例

    コンソールで転送ルールを追加する際は、前述の注意事項と仕組みを参照してください。

    例 1:[転送操作][書き換え]および[転送]に設定

    この例では、パス /app/users/profile/settings/users/profile に書き換えた後、リクエストをバックエンドサーバーに転送する方法を示します。正規表現 /app/(.*)/(.*)/settings は 2 つのキャプチャグループを使用して usersprofile を抽出します。書き換え後のパスでは、/${1}/${2} を使用して最終パスを生成します。

    パラメーター

    説明

    転送条件

    パス

    正規表現 | 大文字と小文字を区別しない を選択し、正規表現 /app/(.*)/(.*)/settings を入力します。

    たとえば、クライアントがパス /app/users/profile/settings をリクエストした場合、ルールは一致します。キャプチャグループは usersprofile を抽出し、それぞれ ${1}${2} 変数に保存されます。

    [転送操作]

    [書き換え]

    • [ドメイン名]:${host}

    • [パス]:/${1}/${2}

    • [クエリ]:${query}

    [クエリ]は、URL のクエスチョンマーク (?) の後に続く部分です。たとえば、URL www.example.com/test/test1?x=1 の場合、[クエリ]は x=1 です。

    [転送]

    サーバーグループのリストから転送先のサーバーグループを選択します。

    例 2:転送アクションを「リダイレクト」に設定

    次の例では、パス /app/users/profile/settings/users/profile にリダイレクトします。例 1 と異なり、このリダイレクトは 301 ステータスコードを返し、ブラウザーのアドレスバーに表示される URL が変わります。

    パラメーター

    説明

    転送条件

    パス

    正規表現 | 大文字と小文字を区別しない を選択し、正規表現 /app/(.*)/(.*)/settings を入力します。

    たとえば、クライアントがパス /app/users/profile/settings をリクエストした場合、ルールは一致します。キャプチャグループは usersprofile を抽出し、それぞれ ${1}${2} 変数に保存されます。

    [転送操作]

    [リダイレクト]

    • [プロトコル]:${protocol}

    • [ドメイン名]:${host}

    • [ポート]:${port}

    • [パス]:/${1}/${2}

    • [クエリ]:${query}

    • [ステータスコード]:301

よくある質問

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

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

  • [転送条件]:ドメイン名を元のドメイン名 (例: 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. 複数条件の確認:単一の転送ルールに複数の条件を設定する場合、異なるタイプの条件は AND 演算子で結合され、同じ条件タイプの複数の値は OR 演算子で結合されます。詳細については、「リスナー転送ルールの設定」をご参照ください。

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

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

項目

書き換え

リダイレクト

ブラウザーのアドレスバー

変更されません (ユーザーには透過的です)

新しい URL に変更されます

仕組み

ALB はリクエストパスを内部で書き換えてから、リクエストをバックエンドサーバーに転送します。プロセス全体が単一のリクエストで完了します。

ALB は 3xx ステータスコードを返し、ブラウザーは新しい URL への 2 回目のリクエストを開始します。

ユースケース

プレフィックスの削除やバージョン番号の追加など、内部的なパスの調整。

HTTP から HTTPS へのリダイレクト、ネイキッドドメインから www へのリダイレクト、およびレガシー URL の移行。

「転送先」の指定要否

はい。書き換えアクションは、サーバーグループを指定する「転送先」アクションと共に設定する必要があります。

いいえ。リダイレクトアクションはスタンドアロンです。

関連ドキュメント

ALB のリスナー転送ルールの設定手順については、「リスナー転送ルールの設定」をご参照ください。