AWSのサーバレスサービス(API Gateway+Lambda)で簡単にリダイレクトを設定する

ブランディング変更や事業組織再編などの理由でWebサイトのドメインを変更することがあります。 旧サイトで新規ドメインへのリダイレクトを設定しておくとユーザーに親切です。 また、ドメインが変わるとSEOの評価がリセットされてしまうため、リダイレクトを設定してGoogleに移管手続きを申請することでSEOの評価を引き継ぐことができます。

この記事では、AWSのサーバレスサービス(API GatewayとLambda)を利用してリダイレクトを設定する方法を解説します。

AWSサービスでリダイレクトを設定する方法はいくつかありますが、この記事で記載した方法が最も簡単でサーバレスサービスを利用するため運用コストが低いです。

目次

リダイレクト設定の全体像

リダイレクト設定は次の手順で行います。

STEP
Lambdaの設定

Lambda関数にリダイレクトを行うコードを設定します。コード内でパスの書き換えなども行うことができます。

STEP
旧ドメインの証明書の発行

旧ドメインでHTTPSリクエストを受けられるように証明書を発行します。

STEP
API Gatewayのリソース設定

API Gatewayの設定し、ユーザーからのリクエストにSTEP 1で作成したLambda関数を紐付けします。

STEP
旧ドメインをAPI Gatewayに紐付け(カスタムドメイン設定)

旧ドメインへのリクエストがAPI Gatewayに飛ぶようにカスタムドメインの設定を行います。

Lambdaの設定

ラインタイムにNode.jsを指定して、下記のコードをLambda関数に設定します。

export const handler = async (event) => {
    let proxyPath = event.pathParameters.proxy + "/";
    proxyPath = proxyPath.replace("blog/", "media/");
    const newDomain = "<New domain name>"
    
    const response = {
        statusCode: 301,
        headers: {
            Location: `https://${newDomain}/${proxyPath}`
        },
    };
    return response;
};

event.pathParameters.proxyには、API Gatewayのプロキシ統合機能を使用しているときに、リクエストのパスから抽出されたパラメータが含まれます(プロキシ統合機能については後述します)。 例えば、ユーザーがhttps://old-domain.com/blog/とアクセスしてきた場合、event.pathParameters.proxyblogとなります。

URLの末尾の”/”(Trailing Slash)はAPI Gatewayが無視するため、Lambdaにも渡されないので注意が必要です。

そのため、”/”を2行目で追加しています。もしリダイレクト先の末尾に”/”がない場合は、コードを調整してください。

また、/blog//media/に変更する例を3行目に記載しています。ドメインとともにパス構造が変わった場合にもこのように対応することができます。

旧ドメインの証明書の発行

旧ドメインのリクエストをHTTPSで処理するため、証明書が必要です。旧ドメインをカバーする証明書がない場合は、事前にACM(Amazon Certificate Manager)で発行をします。

ACMではDV証明書を発行できます。発行の手順は次の記事を参考にしてください。

API Gatewayのリソース設定

次に、ユーザーからのHTTPSリクエストを処理できるようにAPI Gatewayを設定していきます。

現在、AWSのAPI GatewayにはREST APIとHTTP APIの2種類ありますが、Mock機能を使う(後述)ため、REST APIを選択してください。エンドポイントタイプはRegionでもEdge最適化でもどちらでもOKです。

リソースの設定では//{proxy+}の設定をします。/{proxy+}が先ほど出てきたプロキシー統合です。下記の画像のように設定すると、/{proxy+}/以外のすべてのパスにマッチし、マッチしたパスはLambda上ではevent.pathParameters.proxyの変数でアクセスできます。

/だけは、/{proxy+}に含まれないため注意が必要です。(弊社で開発した時はこれにハマり、2時間ほど時間が溶けました…)

それでは、/の設定からしていきます。

/をリダイレクトするためのMock設定

/{proxy+}はLambdaでリダイレクトをしますが、/はAPI Gateway単体でリダイレクトを行います。こうすることでLambdaの呼び出し回数が削減でき、コストが減ります。

最初にメソッドを作成ボタンを押し、GETリクエストに対してMockが応答するようにします。

MockはAPI Gatewayで任意のレスポンスを返すことができる機能であり、主にフロントエンド開発中ににテストデータを受け取るために使用されます。

Mockのメソッドが作成できたら、最初に統合リクエストの設定を行います。Mockの場合、統合リクエストのステータスコードがそのままレスポンスのステータスコードになります。

今回は、301 Moved Permanently をレスポンスしたいため、マッピングテンプレートのstatusCodeを200から301に変更します。

次に、301のレスポンス用にメソッドレスポンスを作成します。ここでは、ヘッダーにLocationを追加しています。

リダイレクトは、ステータスコード301か302でLocationヘッダーが記載されている時に、ブラウザがLocationヘッダーのURLに遷移することで実現します。そのため、ここでLocationヘッダーを追加しています。

リダイレクト先のURLは次の統合レスポンスで設定します。メソッドレスポンスでヘッダーを追加していないと統合レスポンスで指定できません。

最後に統合レスポンスで301のステータスコードでLocationヘッダー付きでユーザーにレスポンスを返す設定をします。

Locationの値でリダイレクト先のURLを指定してください。 Locationヘッダーでは、ドメイン名ではなくフルのURLを指定してください。

Locationの値は'(quote)で囲む必要があります。ヘッダーのマッピングで静的な値を指定する時のAPI Gatewayルールです。

ここで動的な値が指定できないため、/以外の任意のパスに対してはLambdaでリダイレクトをする必要があります。

/{proxy+}をリダイレクトするためのLambda統合

ここから/以外のすべてのパスをリダイレクトするために/{proxy+}を設定します。

リソースを作成から下記のように設定します。 プロキシのリソースはONにする必要があります。

次に、Lambda関数と統合します。最初に作成したLambda関数を指定します。

これでリダイレクトの設定がすべて完了しました。API Gatewayのステージをデプロイし、リダイレクトされることを確認してください。

このテストはAWSから払い出されたAPI Gateway用のドメインで実行することに注意してください。

自社のドメインとAPI Gatewayの紐付けは次のカスタムドメイン設定で行います。

旧ドメインをAPI Gatewayに紐付け(カスタムドメイン設定)

最後にカスタムドメイン設定を行います。

旧ドメイン名とすでに発行済みのACMの証明書を指定すれば設定完了です。

これで終わりと行きたいところですが、もう1ステップ残っています。 旧ドメインの名前解決先をAPI GatewayのIPアドレスにする必要があります。

旧ドメインを管理しているのがRoute53の場合はALIASレコードを、そうでない場合はCNAMEレコードを追加し、旧ドメインがAPI GatewayのIPアドレスに解決されるようにすれば作業完了です。

Route53のALIASレコードについては、次の記事を参考にしてください。 CDN向けの記事ですが、API Gatewayの場合でもCNAMEレコードに対して、同様のメリットがあります。

まとめ

本記事では、AWSのAPI GatewayとLambdaを使用したリダイレクトの方法を紹介しました。これらのサービスはサーバレスと呼ばれるカテゴリーに属しており、運用が簡単になるメリットがあります。

API Gatewayのプロキシ統合(/{proxy+})は便利ですが、少々クセがあるため本記事の解説がお役に立てば幸いです。

よかったらシェアしてね!

CD

目次