CloudFront Functions と Lambda@Edge
CloudFront Functions と Lambda@Edge の実行地点、イベント、言語、制約を比較し、エッジでの軽量処理や認証応答に適した選択を学びます。
CloudFront Functions と Lambda@Edge
Amazon CloudFront のエッジ関数を使うと、CloudFront がビューワー（ブラウザーやアプリなどのクライアント）から受け取る要求や、ビューワーへ返す応答を配信ネットワーク上で加工できます。URLの書き換えやヘッダーの追加、簡単なアクセス判定、応答の生成などをエッジで行えば、不要な処理をオリジンに到達させずに済みます。
たとえば、期間限定の製品プレビューサイトにアクセスする要求をエッジで確認し、条件を満たさない要求には案内ページやアクセス拒否を返す構成を考えます。アクセス制御をCloudFront側で早く実行できれば、オリジンの処理や転送を減らせます。実際の利用者認証では、信頼できるアプリケーションが発行したトークンや署名を検証し、秘密情報の保管や更新も適切に設計してください。エッジ関数を置くだけで、認証・認可の仕組み全体が完成するわけではありません。
エッジで処理する主な選択肢は CloudFront Functions と Lambda@Edge です。どちらもCloudFrontの処理地点に関連付けて実行しますが、起動できるイベント、実行環境、機能、制限が異なります。
リクエストとレスポンスの4つのイベント地点
CloudFrontはビューワーから要求を受け、キャッシュを調べ、必要に応じてオリジンへ問い合わせてからビューワーに応答します。Lambda@Edgeはこの流れの4地点に関数を関連付けられます。
| イベント地点 | 発生する場所 | 典型的な目的 |
|---|---|---|
| ビューワーリクエスト（Viewer request） | CloudFrontがビューワーから要求を受け取った直後 | 認証・認可の判定、URIの書き換え、要求ヘッダーの調整 |
| オリジンリクエスト（Origin request） | キャッシュに有効な応答がなく、CloudFrontがオリジンへ要求を送る直前 | オリジン選択、オリジン向け要求の加工、キャッシュミス時の判定 |
| オリジンレスポンス（Origin response） | オリジンから応答を受け取った直後 | 応答ヘッダーやキャッシュ指示の調整 |
| ビューワーレスポンス（Viewer response） | CloudFrontがビューワーへ応答を返す直前 | セキュリティヘッダーの追加、応答内容の調整 |
ビューワーリクエストイベントはキャッシュ判定より前に起きます。そのため、キャッシュヒットになる要求でも関数を実行して、キャッシュされた内容を返す前に要求を確認できます。一方、オリジンリクエストとオリジンレスポンスは、CloudFrontがオリジンへ取りに行く処理に結び付いています。キャッシュミス時のオリジン処理だけに加えたいロジックには、この違いが重要です。
関数がビューワーリクエストに対して応答を生成すれば、その要求をオリジンまで転送せずに処理を終えられます。たとえば、不正なアクセス条件を満たさない要求へエラー応答を返す場合、オリジンのアプリケーションに同じ判定を実行させる必要はありません。キャッシュの前後どちらで処理するかを誤ると、認証前にキャッシュ済みコンテンツを返すなどの問題につながるため、関数を関連付けるイベントを設計時に確認します。
CloudFront Functions の特徴
CloudFront Functionsは、CloudFrontのビューワーリクエストまたはビューワーレスポンスで実行する軽量な関数機能です。JavaScriptランタイムで動作し、URLの書き換え、リダイレクト、ヘッダーやCookieの読み書き、要求の検査、ビューワーへの応答生成などを行います。
この機能は、CloudFrontで大量に発生する要求へ短時間で処理を加える用途に適します。たとえば、/current への要求を地域別のコンテンツパスに書き換える、レガシーなURLを新しいURLへ転送する、応答へセキュリティヘッダーを追加するといった処理です。適切に処理をエッジへ移すとオリジンを呼び出さずに済む要求が増え、オリジンの負荷や応答時間を抑えられる場合があります。
CloudFront Functionsは、利用可能なイベントがビューワー側に限られ、実行時間やメモリなども軽量処理向けの範囲に制限されています。ネットワークアクセスや長時間の処理を前提とする機能ではありません。JavaScriptランタイムで使える言語仕様やAPIにもバージョンごとの違いがあるため、特定の言語機能が必要ならAWSの現行ランタイム説明を確認してください。
Lambda@Edge の特徴
Lambda@Edgeは、AWS Lambda関数をCloudFrontディストリビューションに関連付け、ビューワー側・オリジン側の4イベント地点で実行する機能です。サポート対象のNode.jsまたはPythonランタイムを使って、CloudFront Functionsより広い処理を実装できます。
たとえば、オリジンリクエスト時に要求の属性に応じて異なるオリジンへ振り分ける、オリジンレスポンスをビューワー向けに加工する、ビューワー要求の認証情報を複数の条件で検証する、といった処理が候補になります。どの地点で動かすかによって対象イベントや呼び出し頻度が変わるため、必要な処理だけを適切な地点に置きます。
Lambda@Edgeは通常のLambda関数と同じ自由度ではありません。関数の作成リージョン、CloudFrontへ関連付ける公開済みバージョン、利用できるランタイム、実行時間、メモリ、環境設定などに専用の制約があります。特に、通常のLambdaで利用できる機能がすべてLambda@Edgeでも使えるとは限りません。エッジでコードを実行する効果と、デプロイ・制限・複製を含む運用負担を合わせて評価しましょう。
2つの機能を選び分ける
| 比較軸 | CloudFront Functions | Lambda@Edge |
|---|---|---|
| 実行イベント | ビューワーリクエスト、ビューワーレスポンス | ビューワーリクエスト／レスポンス、オリジンリクエスト／レスポンス |
| 主な言語 | JavaScript | Node.js、Pythonのサポート対象ランタイム |
| 適する処理 | 短時間のURL・ヘッダー変更、リダイレクト、簡易判定、応答生成 | より幅広い要求・応答処理、オリジン側での分岐や加工 |
| 実行環境の考え方 | 高頻度で起動する軽量なエッジ処理 | より多くの処理能力を必要とするエッジ処理。ただし通常のLambda固有機能とは制約が異なる |
| 料金の考え方 | 関数の呼び出し数など、CloudFront Functionsの料金条件に従う | 関数の実行回数や実行時間など、Lambda@Edgeの料金条件に従う |
選択では、まず必要なイベント地点を確かめます。ビューワー要求だけを処理できればよく、処理も軽量ならCloudFront Functionsが候補です。オリジン要求や応答も処理する必要がある場合、または対応する言語や実行環境の機能をより広く使いたい場合はLambda@Edgeを検討します。
次に、各機能の制限に処理が収まるかを確認します。関数の実行時間やメモリ、コードサイズ、対応ランタイム、キャッシュ時の挙動、デプロイ方法は選択を左右します。制限値や料金は変更される可能性があるため、固定値だけを暗記せず、設計時にはAWS公式のクォータと料金情報で現在の条件を確認してください。
エッジ関数で認証処理を行うときの考え方
ビューワーリクエストで資格情報を調べ、条件を満たさない要求にエッジから拒否応答を返すと、保護対象のコンテンツをキャッシュから返す前にアクセスを止められます。これにより、無効な要求がオリジンへ届くのを防ぎ、認証処理のためのオリジン負荷も減らせます。
ただし、受信したヘッダーが存在するかだけで認証済みと判断する設計は不十分です。クライアントが自由に設定できる値をそのまま信用せず、署名、有効期限、対象リソース、改ざん防止などの条件を確認します。また、公開される関数コードに秘密鍵や長期資格情報を埋め込んではいけません。認証の発行元、鍵の安全な管理とローテーション、キャッシュキーへの認証情報の扱いも設計に含めます。
複雑なユーザー管理、データベース参照、セッション更新などが必要なら、専用の認証サービスやアプリケーションで実施し、エッジでは署名済みの情報を効率よく検証する構成を検討します。CloudFront FunctionsとLambda@Edgeのどちらを使う場合も、個人別の応答を共有キャッシュしてしまわないよう、認証の実行タイミングとキャッシュポリシーを一緒に確認してください。
試験で押さえる選択軸
- 軽量なビューワー処理：URL書き換え、リダイレクト、ヘッダー操作、簡易な応答生成ならCloudFront Functionsを検討する。
- オリジン側のイベント処理：オリジンリクエストやオリジンレスポンスで加工する要件にはLambda@Edgeを検討する。
- キャッシュ前のアクセス判定：ビューワーリクエストで判定すれば、キャッシュヒットになる要求も配信前に確認できる。
- オリジン負荷の削減：エッジで処理を完了し、オリジンへ転送しない要求を増やせる場合に効果がある。
- 通常のLambdaとの違い：Lambda@Edgeには専用のリージョン、バージョン、ランタイム、実行時間などの制約がある。通常のLambdaと同一の実行環境として扱わない。
- 機能と料金の確認：実行イベントと処理内容を決めてから、現行の制限値、ランタイム、料金条件をAWS公式情報で確認する。
公式ドキュメント
重要ポイント
- ▸エッジ関数はCloudFrontを通るリクエストやレスポンスを配信地点で処理し、単純な処理をオリジンへ到達させずに済む
- ▸CloudFront Functionsはビューワーリクエストとビューワーレスポンスで動く軽量なJavaScript機能で、URLやヘッダーの変更、応答生成に向く
- ▸Lambda@Edgeはビューワーとオリジンのリクエスト・レスポンスという4地点で実行でき、Node.jsまたはPythonによる広い処理に向く
- ▸キャッシュヒット時もビューワーイベントは発生する一方、オリジンリクエスト・レスポンスイベントはオリジンへ取りに行く場合に関係する
- ▸エッジ関数には通常のLambdaとは異なる実行時間、メモリ、ランタイム、デプロイ方法などの制約があるため、要件と現行クォータを照らして選ぶ
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
VPC とネットワーク に関連するトピックを続けて確認できます。