CloudFront Functions でリダイレクト設定の、管理・運用コストを最適化

はじめに

WebサイトのリダイレクトをVirtual Hostで設定している環境も多いと思います。
しかし、リダイレクトの数が多くなってくるといくつかの課題が生じます。
本記事では、CloudFront Functionsを利用したリダイレクト実装手順を紹介します。
そして、Virtual Hostで設定する方法との比較を通して、管理リスク、運用負荷、コストの観点からそのメリットを解説します。

従来のVirtual Host設定における課題

CDNがある環境で、オリジンサーバーのVirtual Hostを用いてリダイレクトを設定する場合、いくつかの課題が考えられます。

パフォーマンスへの影響: リクエスト毎に長大な設定ファイルが評価されるため、サーバーの応答速度に影響を与える可能性があります。特に正規表現を多用する場合は注意が必要です。
リソース負荷:サーバー内で設定する場合、リダイレクト設定のファイルやバックアップを保存するディスクの使用や、リダイレクト処理のCPU、メモリの使用があります。ルールが大量になると無視できない範囲になる可能性もあります。
スケール時の対応: サーバー台数を増やす場合、全ての設定を同期する必要があり、管理が複雑になります。
CDN 転送コスト: CDNを経由してオリジンサーバーのVirtual Hostでリダイレクトを行う場合、以下の通信が発生し得ます。
1. クライアントからCDNへのリクエスト
2. CDNからオリジンサーバーへのリクエスト
3. オリジンサーバーからCDNへのリダイレクトレスポンス (例: 301, 302)
4. CDNからクライアントへのリダイレクトレスポンス
5. クライアントからCDNへの新しいURLでのリクエスト (リダイレクト先)
このうち、特にクライアントとCDN間、およびCDNとオリジンサーバー間のデータ転送に対してCDNの転送料金が発生します。リダイレクトのレスポンス自体は小さいものの、リダイレクト先のコンテンツを取得するために再度クライアントからのリクエストが発生し、オリジンサーバーへのアクセスが必要な場合はその分の転送量も考慮に入れる必要があります。特に多段リダイレクトを設定している場合は、これらの通信が繰り返されるため、転送コストが増加する可能性があります。

これらの課題は、特に大規模なサイトや多数のドメインを管理する場合に顕著になります。

リダイレクト実装の選択肢と比較

CDN環境におけるリダイレクト実装には、いくつかの選択肢があります。

項目	Virtual Host (オリジンサーバー)	CloudFront Functions	Lambda@Edge
実行場所	オリジンサーバー	CloudFront エッジロケーション	CloudFront エッジロケーション (ビューワー向きイベントの場合)
レイテンシ	オリジンへのラウンドトリップが必要なため比較的大きい	エッジで処理されるため非常に小さい	エッジで処理されるため小さい
実行時間制限	サーバー設定に依存	1ms 未満(※)	ビューワー向き: 5秒オリジン向き: 30秒(※)
パッケージサイズ制限	なし (サーバーリソース依存)	10KB 以内(※)	ZIP 展開後: 50MB (ビューワー向き) その他: 250MB(※)
複雑な処理	可能	制限あり (軽量な JavaScript のみ、パッケージサイズ 10KB 以内、実行時間 1ms 未満)(※)	可能 (Node.js, Python)
コスト	EC2 インスタンス費用、データ転送量	関数実行回数、リクエスト数月間200万リクエストまで無料	関数実行時間、リクエスト数
管理の容易さ	設定ファイルの管理、サーバーメンテナンス	コード管理、CloudFront との連携	コード管理、IAM ロール、CloudFront との連携
コールドスタート	なし	ほぼなし	あり (影響を軽減する仕組みあり)

※ CloudFront Functions と Lambda@Edge のパッケージサイズと実行時間の制限について
https://aws.amazon.com/jp/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/

選定のポイント:

シンプルなリダイレクト: URLの書き換えやヘッダー操作など軽量な処理で済み、関数の実行時間が1ms未満で完了し、パッケージサイズが10KB以内に収まる場合は、CloudFront Functionsが最適です。低レイテンシかつ低コストで実現できます。
複雑な処理や外部アクセス: ネットワークアクセスやファイルシステムアクセス、より大きなコードベースを必要とするなど、複雑な処理が必要な場合はLambda@Edgeが適しています。
既存の構成への影響: オリジンサーバーに手を加えたくない場合や、CDNで一元的に管理したい場合は、CloudFront FunctionsまたはLambda@Edgeが良いでしょう。

今回はシンプルなリダイレクトを想定し、CloudFront Functions を採用します。
その低レイテンシかつスケーラブルな特徴、そして軽量な処理に特化している点が、CDN環境でのリダイレクト処理に最適だからです。

CloudFront Functionsでのリダイレクト実装手順

ここからは、CloudFront Functionsを使用してリダイレクトを実装する具体的な手順を説明します。

前提条件

リダイレクトを設定したいCloudFrontディストリビューションが既に作成されていること。
リダイレクト元のドメインとリダイレクト先のドメインが準備できていること。

今回の検証では、old.y-ishikawa-test.comを new.y-ishikawa-test.com にリダイレクトする設定を作成してみます。

1. CloudFront Functionsの作成

まず、リダイレクト処理を行うための関数を作成します。

AWSマネジメントコンソールから、CloudFront > 関数 > 「関数の作成」をクリックします。
ランタイムは cloudfront-js-2.0 を選択します (2025年5月現在、最新のものを確認してください)。

関数を作成をクリックし、リダイレクト処理を記述します。以下は、old.example.com へのアクセスを `https://new.example.com` へリダイレクトするサンプルコードです。

function handler(event) {
    var request = event.request;
    var headers = request.headers;
    var host = headers.host.value;
    var uri = request.uri;

    // リダイレクト元のホスト名を指定
    var oldHost = 'old.example.com';
    // リダイレクト先の URL を指定
    var newUrl = '[https://new.example.com](https://new.example.com)';

    if (host === oldHost) {
        var response = {
            statusCode: 301, // または 302
            statusDescription: 'Moved Permanently', // または 'Found'
            headers: {
                'location': { value: newUrl + uri }
            }
        };
        return response;
    }
    return request; // リダイレクト対象外の場合はリクエストをそのまま返す
}

恒久的なリダイレクトの場合は 301 Moved Permanently を、一時的な場合は 302 Found を使用します。

「変更を保存」をクリックします。

2. 関数のテスト

作成した関数が正しく動作するかテストします。

作成した関数の画面で「テスト」タブを選択します。
「新しいテストイベント」を選択します。
イベントタイプは「Viewer request」を選択します。
ステージは「Development」を選択します。

「JSONを編集」をクリックし、以下の内容で保存します。request.headers.host.value にリダイレクト元のホスト名を設定します。

{
    "version": "1.0",
    "context": {
    "distributionDomainName": "d111111abcdef8.cloudfront.net",
    "distributionId": "EDFDVBD6EXAMPLE",
    "eventType": "viewer-request",
    "requestId": "EXAMPLEntjQpEXAMPLE_SG5Z-EXAMPLEgNqNtGDEXAMPLE"
    },
    "viewer": {
    "ip": "192.0.2.1"
    },
    "request": {
    "method": "GET",
    "uri": "/path/to/page.html",
    "querystring": {
        "param1": { "value": "value1" }
    },
    "headers": {
        "host": { "value": "old.example.com" }
    },
    "cookies": {}
    }
}

「関数をテスト」ボタンをクリックします。
「出力」セクションで、レスポンスが期待通り statusCode: 301 (または 302) で、リダイレクト先の location ヘッダーが含まれていることを確認します。
- このテストにより、リダイレクト設定が正しく機能し、指定したURLへリダイレクトされることが確認できます。
同様に、リダイレクト対象外のホスト名でテストを行い、リクエストが変更されずに返されることも確認します。
- このテストにより、リダイレクト対象外のホスト名の場合は、リクエストがそのまま返されることが確認できます。

3. 関数の発行

テストが完了したら、関数を発行してCloudFrontディストリビューションで利用できるようにします。

作成した関数の画面で「発行」タブを選択します。
「関数を発行」ボタンをクリックします。
発行が完了すると、ARNが表示されます。

4. CloudFrontディストリビューションへの関連付け

発行した関数をCloudFrontディストリビューションのビヘイビアに関連付けます。

対象のディストリビューション > 「ビヘイビア」 > 対象のビヘイビアを選択 > 「編集」をクリック
「関数の関連付け」セクションで、「ビューワーリクエスト」の「関数の関連付け – Lambda@Edge / CloudFront Functions」ドロップダウンから「CloudFront Functions」を選択します。
「関数」で、先ほど発行した関数をドロップダウンから選択します。
「Save changes」をクリックし、ディストビューションのデプロイが完了するのを待ちます。

5. 動作確認

最後に、curlコマンドを使って、実際にリダイレクトが行われるか確認します。

以下のコマンドを実行します。

curl -I [https://old.y-ishikawa-test.com](https://old.y-ishikawa-test.com)

レスポンスヘッダーに HTTP/1.1 301 Moved Permanently (または 302 Found) と `Location: https://new.y-ishikawa-test.com` が含まれていることを確認します。

実行例

y-ishikawa@y-ishikawa1:~$ curl -I [https://old.y-ishikawa-test.com](https://old.y-ishikawa-test.com)
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Date: Sat, 30 Fri 2025 05:51:20 GMT
Content-Length: 0
Connection: keep-alive
Location: [https://new.y-ishikawa-test.com/](https://new.y-ishikawa-test.com/)
X-Cache: FunctionGeneratedResponse from cloudfront
Via: 1.1 xxxxx.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: KIX56-C2
X-Amz-Cf-Id: xxx

y-ishikawa@y-ishikawa1:~$

curlコマンドの実行結果から、ステータスコードとLocationヘッダーが正しく返却されていることが確認できます。

これで、CloudFront Functionsを利用したリダイレクト設定は完了です。

Virtual Host設定との比較

CloudFront Functionsを利用したリダイレクトと、従来のVirtual Hostによるリダイレクトを、管理リスク、運用負荷、コストの観点から比較します。

観点	Virtual Host (オリジンサーバー)	CloudFront Functions
管理のリスク	・設定ファイルの構文エラー・多数のVirtual Host設定による複雑化・SSH接続下での作業ミスによるサービス影響の可能性	・関数コードのバグ・IAM権限の設定ミス・CloudFrontの設定変更ミス
運用の負荷	・SSH接続下での作業に細心の注意(厳格な手順書等)を払う必要がある。・アラート発生時等、リダイレクト設定の影響を都度切り分ける必要がある。	・基本的にサーバーレスでインフラ管理は不要・作業ミスの影響範囲は、従来のやり方に比べ限定的
コスト	・EC2インスタンス費用 (数が多くなると、リダイレクト処理のためのスペック増が必要) ・リダイレクトのデータ転送費用が発生(※)	・CloudFront Functionsの実行回数に基づく課金 (100万リクエストあたり約$0.1) ・月間200万リクエストの無料枠あり・オリジンへの不要なトラフィック削減によるCDN転送料の削減

※ リダイレクト先が同一サーバー内であっても、異なるFQDNへのリダイレクトの場合などは、一度クライアントにリダイレクト指示が返り、再度外部からアクセスする形になる場合は、インターネット経由のトラフィックと見なされ転送料が発生する可能性があります。

SSH接続下での作業リスクをなくすことができる点、そしてエッジサーバーでリダイレクト処理を完結させることにより、オリジンサーバーへの不要なリクエストとそれに伴うCDNのデータ転送料を削減できる点が、CloudFront Functions の特に大きな利点となります。

まとめ

CloudFront Functions を利用することで、CDN環境におけるリダイレクト処理を効率的かつ低コストに実装できます。

従来の Virtual Host 設定と比較して、CloudFront Functions はCDN環境下での web サービスのリダイレクト処理を設定する際の有効な選択肢となります。
参考になったら幸いです。

参考ドキュメント

CloudFront Functions
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html
CloudFront 関数を使用して URL をリダイレクトする
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/example_cloudfront_functions_redirect_based_on_country_section.html
CloudFront Functions に対する制限
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cloudfront-function-restrictions.html
パッケージサイズと実行時間の制限
https://aws.amazon.com/jp/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/

CloudFront Functions でリダイレクト設定の、管理・運用コストを最適化

はじめに

従来のVirtual Host設定における課題

リダイレクト実装の選択肢と比較

CloudFront Functionsでのリダイレクト実装手順

前提条件

1. CloudFront Functionsの作成

2. 関数のテスト

3. 関数の発行

4. CloudFrontディストリビューションへの関連付け

5. 動作確認

Virtual Host設定との比較

まとめ

参考ドキュメント

【検証】Strands Agentsと法令検索APIを組み合わせて法令検索エージェントを作ってみる

2025年度版！AWS資格取得の順番について！

[アップデート] Amazon Athenaがクエリ結果をマネージドに管理できるようになりました！

Cursor & Atlassian MCPでConfluenceの設計書からAPI実装してもらう

DX開発事業部 presents 週刊生成AIニュース 2025年6月2日週

CloudFront Functions でリダイレクト設定の、管理・運用コストを最適化

はじめに

従来のVirtual Host設定における課題

リダイレクト実装の選択肢と比較

CloudFront Functionsでのリダイレクト実装手順

前提条件

1. CloudFront Functionsの作成

2. 関数のテスト

3. 関数の発行

4. CloudFrontディストリビューションへの関連付け

5. 動作確認

Virtual Host設定との比較

まとめ

参考ドキュメント

関連記事Related Articles

AWS CLI + SSM魔改造!? Session Managerで特定ユーザーをpsqlへ直結＆ファイル出力する方法

そのAuto Scaling、スケジューリングしませんか？Auroraリードレプリカをもっと賢く使う方法

簡単設定！AWS WAFで「このページは日本国内限定です」を実現する方法

【GenU】デプロイ時に有効化すべきセキュリティ関連のオプション設定

AWS運用を劇的改善！SSM Session Managerのメリット（セキュリティ・運用・監査）を徹底検証