API ステージを REST API のカスタムドメイン名に接続するためのルーティングルール - Amazon API Gateway
API Gateway ルーティングルールの条件タイプ制限事項

API ステージを REST API のカスタムドメイン名に接続するためのルーティングルール

ルーティングルールは、一致したときにアクションを呼び出す一連の条件です。例えば、ルールは、ヘッダー Hello:World を含み、REST API の production ステージへのベースパス users を含むカスタムドメイン名に受信リクエストをルーティングできます。

ルールは優先順位で評価され、ルーティングモードを ROUTING_RULE_THEN_API_MAPPING に設定すると、API Gateway は API マッピングを評価する前に常にすべてのルーティングルールを評価します。次のリストは、ルーティングルールが条件、アクション、優先順位をどのように使用するかを示しています。

条件

ルールの条件が満たされると、アクションが実行されます。API Gateway は、最大 2 つのヘッダー条件と 1 つのパス条件をサポートします。API Gateway は、ヘッダー条件とベースパス条件を一緒に評価します。

条件なしでルールを作成できます。API Gateway がこのルールを評価すると、アクションは常に実行されます。キャッチオールルールとして、条件なしでルールを作成できます。

ヘッダー条件の詳細については、「ヘッダー条件の一致」を参照してください。パス条件の詳細については、「ベースパス条件の一致」を参照してください。

アクション

アクションは、ルーティングルールに条件が一致した結果です。現在サポートされているアクションは、REST API のステージを呼び出すことのみです。

各ルールには 1 つのアクションを含めることができます。

優先度

優先度により、ルールが評価される順序 (低い値から高い値の順) が決定します。ルールに同じ優先順位を設定することはできません。

優先度は 1～1,000,000 に設定できます。優先度が 1 のルールは、API Gateway によって最初に評価されます。ルールを作成するときは、優先順位にギャップを追加することをお勧めします。これにより、ルールの優先度を切り替え、新しいルールを追加することができます。詳細については、「ルーティングルールの優先度を変更する」を参照してください。

API Gateway がルーティングルールを評価する方法の例については、「API Gateway がルーティングルールを評価する方法の例」を参照してください。

API Gateway ルーティングルールの条件タイプ

次のセクションでは、ルーティングルールの条件タイプについて説明します。API Gateway は、すべての条件が true の場合にのみルールに一致します。

ヘッダー条件の一致

ヘッダー条件を作成するときに、Hello:World などのヘッダー名とヘッダー glob 値を一致させることができます。API Gateway はリテラル一致を使用して、一致ヘッダー条件を検証します。条件は、それらの間で AND を使用して最大 2 つのヘッダーを使用できます。例えば、受信リクエストに Hello:World と x-version:beta が含まれている場合、条件は一致します。

ヘッダー名の一致では大文字と小文字は区別されませんが、ヘッダー glob 値は大文字と小文字が区別されます。Hello:World は hello:World と一致しますが、Hello:world とは一致しません。

制限されたヘッダー値のリストについては、「制限事項」を参照してください。

ヘッダー条件でのワイルドカードの使用

ワイルドカードはヘッダー glob 値でのみ使用でき、ワイルドカードは *prefix-match、suffix-match*、または *contains* である必要があります。次の表は、ヘッダー条件の一致にワイルドカードを使用する方法の例を示しています。

ヘッダー条件 ルーティングルールと一致するリクエスト ルーティングルールと一致しないリクエスト

x-version: a*

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: beta

  • x-version: users

x-version: *a

  • x-version: alpha

  • x-version: beta

  • x-version: account

  • x-version: backup

  • x-version: users

x-version: *a*

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: beta

  • x-version: users

x-version: *a* および x-version: *b*

  • x-version: backup

  • x-version: beta

  • x-version: account

  • x-version: alpha

  • x-version: users

x-version: b* および x-version: *a

  • x-version: beta

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: users

x-version: *

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: beta

  • x-version: users

なし

複数のヘッダー値の条件を作成する場合 (例: Accept:application/json,text/xml)、ヘッダー条件に *contains* を使用し、カンマ (,) 文字を使用して条件を作成しないようにすることをお勧めします。

API Gateway はヘッダー条件を文字通り一致させるため、セマンティック一致のルーティングが異なる場合があります。次の表は、ルーティングルールの結果の違いを示しています。

ヘッダー条件 ルーティングルールと一致するリクエスト ルーティングルールと一致しないリクエスト

Accept: *json

  • Accept:application/json Accept:text/xml

  • Accept:application/json,text/xml

Accept: *json*

  • Accept:application/json Accept:text/xml

  • Accept:application/json,text/xml

なし

ベースパス条件の一致

ベースパス条件を作成するときに、受信リクエストに指定したパスが含まれている場合、ルールは一致します。一致では大文字と小文字が区別されるため、パス New/Users は new/users と一致しません。

ベースパス条件は、1 つのベースパスに対してのみ作成できます。

制限されたベースパス条件のリストについては、「制限事項」を参照してください。

ベースパス条件を使用してベースパスを削除する

ベースパス条件を作成するときに、ベースパスを削除することを選択できます。ベースパスを削除すると、API Gateway はターゲット API を呼び出すときに着信する一致したベースパスを削除します。これは、API マッピングを使用する場合と同じ動作です。ベースパスを削除しない場合、API Gateway はベースパス全体をターゲット API に転送します。API マッピングを再作成する場合にのみ、ベースパスを削除することをお勧めします。

次の表は、API Gateway がベースパス削除条件を評価する方法の例を示しています。

条件 ベースパスを削除する 受信リクエスト 結果

ベースパスに PetStoreShopper/dogs が含まれている場合

 真

GET https://example.com/PetStoreShopper/dogs

API Gateway は、/ リソースの GET メソッドを呼び出します。

ベースパスに PetStoreShopper/dogs が含まれている場合

 False

GET https://example.com/PetStoreShopper/dogs

API Gateway は、PetStoreShopper/dogs リソースの GET メソッドを呼び出します。

ベースパスに PetStoreShopper が含まれている場合

 真

GET https://example.com/PetStoreShopper/dogs

API Gateway は、dogs リソースの GET メソッドを呼び出します。

ベースパスに PetStoreShopper が含まれている場合

 False

GET https://example.com/PetStoreShopper/dogs

API Gateway は、PetStoreShopper/dogs リソースの GET メソッドを呼び出します。

ベースパスに PetStoreShopper が含まれている場合

 真

GET https://example.com/PetStoreShopper?birds=available

API Gateway は、クエリ文字列パラメータ birds=available を使用して / リソースの GET メソッドを呼び出します。

ベースパスに PetStoreShopper が含まれている場合

 False

GET https://example.com/PetStoreShopper?birds=available

API Gateway は、クエリ文字列パラメータ birds=available を使用して /PetStoreShopper リソースの GET メソッドを呼び出します。

制限事項

  • ターゲット API とカスタムドメイン名は、同じ AWS アカウントに存在する必要があります。

  • 各ルールには、1 つのターゲット API を含めることができます。

  • プライベートカスタムドメイン名からプライベート API へのルーティングルールと、パブリックカスタムドメイン名からパブリック API へのルーティングルールのみを作成できます。パブリックリソースとプライベートリソースを混在させることはできません。

  • カスタムドメイン名に REST API と HTTP API の両方への API マッピングがある場合、ルーティングルールはサポートされていません。

  • 最大優先度数は 1,000,000 です。

  • ヘッダー制限:

    • 各 anyOf 条件に含めることができるヘッダー値は 1 つだけです。

    • ヘッダー名とヘッダー glob 値に使用できる文字は RFC 7230 で指定された a-z、A-Z、0-9、および次の特殊文字 *?-!#$%&'.^_`|~ です。

    • ヘッダーの glob 値にワイルドカードを使用できますが、ワイルドカードは *prefix-match、suffix-match*、または *contains* である必要があります。ヘッダー glob 値の途中で * を使用することはできません。

    • ワイルドカードヘッダー名はサポートされていません。

    • ヘッダー名は 40 文字未満にする必要があります。

    • ヘッダー glob 値は 128 文字未満である必要があります。

    • インフィックス一致のヘッダー glob 値は 40 文字未満である必要があります。

    • 以下のヘッダーは条件としてサポートされていません。

      • access-control-*

      • apigw-*

      • Authorization

      • Connection

      • Content-Encoding

      • Content-Length

      • Content-Location

      • Forwarded

      • Keep-Alive

      • Origin

      • Proxy-Authenticate

      • Proxy-Authorization

      • TE

      • Trailers

      • Transfer-Encoding

      • Upgrade

      • x-amz-*

      • x-amzn-*

      • X-Forwarded-For

      • X-Forwarded-Host

      • X-Forwarded-Proto

      • Via

  • ベースパスの制限:

    • ベースパスの長さは 128 文字未満にする必要があります。

    • ベースパスに含めることができるのは、文字、数字、および $-_.+!*'()/ の文字だけです。

    • ベースパスは、バックスラッシュ (/) 文字で開始または終了することはできません。