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

Serverless App Engine:ALB ゲートウェイルーティングのベストプラクティス

最終更新日:Jun 13, 2025

デフォルトでは、Serverless App Engine (SAE) アプリケーションはパブリックネットワークにアクセスできず、パブリックネットワークはプライベートネットワークにアクセスできません。この問題を解決するには、アプリケーションに Application Load Balancer (ALB) ゲートウェイルーティングを構成して、パブリックネットワークから SAE アプリケーションへの通常のアクセスを有効にすることができます。このトピックでは、ALB ゲートウェイルーティングの重要なパラメーター構成について説明します。

転送ルールの概要

SAE 側から ALB インスタンスのリスナーに複数の転送ルールを追加できます。転送ルールには、データリンク方向の観点から、インバウンド転送ルールとアウトバウンド転送ルールがあります。SAE 側では、ALB インスタンスのインバウンド転送ルールのみ構成できます。アウトバウンド転送ルールを構成する必要がある場合は、SLB 側で構成する必要があります。

転送ルールは、転送条件と転送操作の 2 つの部分で構成されます。リクエストが転送ルールで指定された条件に一致すると、転送ルールで指定された操作が実行されます。転送ルールでは、1 つ以上の条件と 1 つ以上の操作を指定できます。

  • Standard Edition および WAF-Enabled Edition の ALB インスタンスの場合、クライアントが ALB にリクエストを送信すると、ALB はインバウンド転送ルールを使用してリクエストデータを処理し、対応するバックエンドサーバーに送信します。バックエンドサーバーからのレスポンスデータは、クライアントに返される前に、ALBアウトバウンド転送ルール を介して処理されます。

    • インバウンド転送ルールを作成する場合、インバウンドの条件と操作のみ指定できます。

    • アウトバウンド転送ルールを作成する場合、インバウンドとアウトバウンドの両方の条件を指定できます。ただし、アウトバウンド転送ルールではアウトバウンドの操作のみ指定できます。

  • 転送ルールには、「転送」、「リダイレクト」、または「固定レスポンスを返す」タイプの転送操作が 1 つ含まれている必要があります。これにより、クライアントリクエストが中断されないことが保証されます。

アクセスパス

  1. SAE コンソール にログインし、左側のナビゲーションウィンドウで [名前空間] をクリックし、ターゲットリージョンを選択します。

  2. [名前空間] ページで、ターゲットの名前空間をクリックします。

  3. ターゲットの名前空間の [基本情報] ページで、左側のナビゲーションウィンドウの [ゲートウェイルーティング] をクリックし、[ゲートウェイルートの作成] をクリックします。

    このトピックでは、主要なパラメーターの構成のみを紹介します。ゲートウェイルーティングの作成の詳細な手順については、「Application Load Balancer (ALB) によるルート規則の構成」をご参照ください。

転送条件の構成

SAE 側では、[ドメイン名][アクセス ポート]、および [パス] の転送条件を構成できます。

ドメイン名の構成

構成ルール

説明

完全一致とワイルドカード一致

  • 一致の説明

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

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

  • 入力条件

    ドメイン名は 3 ~ 128 文字です。英大文字、英小文字、数字、特殊文字 .-?=~_+\^*!$&|()[] のみ使用できます。ワイルドカード文字としてアスタリスク (*) と疑問符 (?) をサポートしています。

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

    • 完全一致: www.example.com を入力すると、一致します。

    • ワイルドカード一致: *.example.com または www.example.* を入力すると、一致します。

正規表現一致

  • 一致の説明

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

  • 入力条件

    ドメイン名は 3 ~ 128 文字です。英大文字、英小文字、数字、特殊文字 .-?=~_-+\^*!$&|()[] のみ使用できます。

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

    大文字と小文字を区別しない: 正規表現 ^www.example.com$ を入力すると、一致します。

パスの構成

構成ルール

説明

完全一致とワイルドカード一致

  • 一致の説明

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

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

  • 入力条件

    / で始まる必要があります。英大文字、英小文字、数字、特殊文字 $-_.+/&~@: のみ使用できます。ワイルドカード文字としてアスタリスク (*) と疑問符 (?) をサポートしています。

  • リクエストされたパス: /example/text

    • 完全一致: /example/text を入力すると、一致します。

    • ワイルドカード一致: /example/* を入力すると、一致します。

    説明

    ALB のパス一致ルールは Nginx とは異なります。ALB は最長プレフィックス一致の原則をサポートしていません。

    たとえば、一般的な Nginx 構成は location /abc で、location は最長プレフィックス一致を使用して一致します。ALB では、最長プレフィックス一致はワイルドカードを使用して実装する必要があります。ALB で /abc/* (完全一致とワイルドカード) を構成することで、同じ効果を得ることができます。

正規表現一致

  • 一致の説明

    リクエストされたパスは、指定された正規表現と一致します。

  • 入力条件

    英大文字、英小文字、数字、特殊文字 .-_/=?~^*$:()[]+| のみ使用できます。

  • リクエストされたパス: /sys/aaa/HOST

    • 大文字と小文字を区別する: 正規表現 ^/sys/(.*)/HOST$ を入力すると、パスが一致します。

    • 大文字と小文字を区別しない: 正規表現 ^/sys/(.*)/host$ を入力すると、パスが一致します。

転送操作の構成の概要

転送操作の構成では、書き換えポリシーとリダイレクトルールを構成できます。

書き換えポリシーの構成

説明

転送操作で書き換えポリシーを構成できます。

  • 「転送」を選択すると、書き換えポリシーを構成できます。

  • 転送条件のドメイン名の構成については、「ドメイン名の構成」をご参照ください。

    リダイレクトされたドメイン名がデフォルトの ${host} の場合、元のドメイン名で動的に置き換えられます。

パスの構成

転送条件でパスの正規表現を構成した後、転送操作のパスは正規表現の置き換えをサポートします。転送ルールの追加方法については、「アプリケーション ( ALB ) のルーティング規則の構成」をご参照ください。

  • 注意事項

    • 転送条件の正規表現のかっこ () の数は、転送操作の書き換えられたパスにある $variables の数と一致する必要があります。

    • 転送操作の書き換えられたパスには、${1}${2}${3} のいずれか 1 つ以上が含まれている必要があり、これらの 3 つの変数を他の文字に置き換えることはできません。

  • 置き換えの原則

    1. URL の一致: クライアントがリクエストを送信し、リクエストが転送ルールで指定された正規表現と一致します。

    2. 抽出と置き換え: 正規表現の標準に従って、最初の 3 つのペアのかっこ () から抽出された内容は、転送操作の書き換えられたパスで置き換えるために、それぞれ ${1}${2}${3} に保存されます。

    3. 連結: 転送操作の書き換えられたパスの構成に従って、${1}${2}${3} の値を置き換え、最終的にそれらを連結して実際に書き換えられたパスにします。

    番号

    手順

    1

    転送ルールで転送条件と転送操作を構成します。

    • 転送条件のパス: /sys/(.*)/(.*)/aaa

    • 転送操作の書き換えパス: /${1}/${2}

    2

    クライアントリクエストが転送ルールのパスと一致します。

    • クライアントリクエストのパス: /sys/ccc/bbb/aaa

    • 一致した転送条件のパス: /sys/(.*)/(.*)/aaa

    3

    抽出と置き換え。

    正規表現の標準に従って、転送条件のパスにある 2 つの (.*) は、それぞれ cccbbb を抽出し、転送操作の書き換えられたパスにある ${1}${2} に格納します。

    • ${1}ccc に置き換えられます

    • ${2}bbb に置き換えられます

    4

    パスの連結。

    バックエンドサーバーが受信したパス: /ccc/bbb

説明

リダイレクトされたパスがデフォルトの ${port} の場合、元のパスで動的に置き換えられます。たとえば、転送条件のパスが /test/aaa の場合、転送操作で一致するパスは /test/aaa です。

クエリの構成

クエリの内容とは、URL の疑問符の後の部分を指します。リダイレクトされたクエリがデフォルトの ${query} の場合、元のクエリパラメーターで動的に置き換えられます。

例:

クライアントが URL www.example.com/test/test1?x=1 にアクセスする場合、クエリの内容は x=1 です。

リダイレクトポリシーの構成

リダイレクトポリシーを構成する必要がある場合は、プロトコル、ドメイン名、アクセス ポート、パス、クエリ、状態コードなどのパラメーターを構成する必要があります。

プロトコルの概要

  • HTTP リスナーは、HTTP リクエストを別の HTTP リスナーまたは HTTPS リスナーにリダイレクトすることをサポートしています。

  • HTTPS リスナーは、HTTPS リクエストを別の HTTPS リスナーにリダイレクトすることをサポートしています。

説明

リダイレクトされたプロトコルがデフォルトの $(protocol) の場合、元のプロトコルで動的に置き換えられます。

ドメイン名の概要

転送操作のドメイン名の構成は、転送条件と同じです。具体的な構成については、「ドメイン名の構成」をご参照ください。

説明

リダイレクトされたドメイン名がデフォルトの ${host} の場合、元のドメイン名で動的に置き換えられます。

アクセス ポートの概要

対応するプロトコルのリスニング ポートを構成します。たとえば、HTTP リクエスト (アクセス ポート: 80 ) が HTTPS (アクセス ポート: 443 ) にリダイレクトされる場合です。

説明

リダイレクトされたアクセス ポートがデフォルトの ${port} の場合、元のポートで動的に置き換えられます。

パスの概要

転送条件でパスの正規表現を構成した後、転送操作のパスは正規表現の置き換えをサポートします。転送ルールの追加方法については、「アプリケーション ( ALB ) のルーティング規則の構成」をご参照ください。

  • 注意事項

    • 転送条件の正規表現のかっこ () の数は、転送操作のリダイレクトされたパスにある $variables の数と一致する必要があります。

    • 転送操作のリダイレクトされたパスには、${1}${2}${3} のいずれか 1 つ以上が含まれている必要があり、これらの 3 つの変数を他の文字に置き換えることはできません。

  • 置き換えの原則

    1. URL の一致: クライアントがリクエストを送信し、リクエストが転送ルールで指定された正規表現と一致します。

    2. 抽出と置き換え: 正規表現の標準に従って、最初の 3 つのペアのかっこ () から抽出された内容は、転送操作のリダイレクトされたパスで置き換えるために、それぞれ ${1}${2}${3} に保存されます。

    3. 連結: 転送操作のリダイレクトされたパスの構成に従って、${1}${2}${3} の値を置き換え、最終的にそれらを連結して実際に書き換えられたパスにします。

    番号

    手順

    1

    転送ルールで転送条件と転送操作を構成します。

    • 転送条件パス: /sys/(.*)/(.*)/aaa

    • 転送操作リダイレクトパス: /${1}/${2}

    2

    クライアント リクエストは、転送ルール内のパスと一致します。

    • クライアント リクエスト パス: /sys/ccc/bbb/aaa

    • 一致した転送条件パス: /sys/(.*)/(.*)/aaa

    3

    抽出と置換。

    正規表現の標準に従って、転送条件パス内の 2 つの (.*) は、それぞれ cccbbb を抽出し、転送操作のリダイレクトパスにある ${1}${2} に格納します。

    • ${1}ccc に置き換えられます

    • ${2}bbb に置き換えられます

    4

    パスの連結。

    バックエンドサーバーが受信したパス: /ccc/bbb

説明

リダイレクトされたパスがデフォルトの ${port} である場合、元の リクエスト パス で動的に置き換えられることを意味します。たとえば、転送条件のパスが /test/aaa の場合、転送操作で一致するパスは /test/aaa です。

クエリの概要

クエリコンテンツとは、URL の疑問符の後の部分を指します。リダイレクトされたクエリがデフォルトの ${query} である場合、元の リクエスト の クエリパラメータ で動的に置き換えられることを意味します。

例:

クライアントが www.example.com/test/test1?x=1 という URL にアクセスする場合、クエリ内容は x=1 です。

状態コードの概要

ALB リダイレクトのデフォルト HTTP ステータスコードは 301 です。必要に応じて HTTP ステータスコードを指定できます。次の表に、ALB でサポートされている HTTP ステータスコードを示します。

ステータスコード

説明

301

恒久的なリダイレクトを示します。

302

一時的なリダイレクトを示します。

303

リクエストされたリソースが別の URL から取得できることを示します(別の場所を参照)。

307

リクエストされたリソースが一時的に別の場所に移動したことを示します(一時的なリダイレクト、メソッドは保持されます)。

308

リクエストされたリソースが新しい場所に永続的に移動したことを示します(恒久的なリダイレクト、メソッドは保持されます)。