🔍 はじめに
CloudFront Functions（CFF）は、CloudFront の軽量エッジ処理機能として登場し、Lambda@Edge（L@E）よりも低レイテンシーかつ低コストで動作します。しかし、すべてのユースケースを CFF で代替できるわけではありません。
本記事では、Lambda@Edge でなければ対応できない代表的なケースと、CloudFront Functions で十分なケースを一覧でまとめます。
✅ Lambda@Edge でしか対応できないケース
| ユースケース | 説明 | CloudFront Function対応可否 |
|---|---|---|
| オリジンレスポンス処理 | オリジンからのレスポンス（S3やALBなど）に対するカスタム処理（例：HTML改変） | ❌ 非対応 |
| オリジンリクエスト改変 | S3キーの書き換え、カスタム認証、オリジンの動的切替 | ❌ 非対応 |
| レスポンス本文の編集 | HTMLやJSONの内容をLambdaで加工 | ❌ 非対応 |
| 外部APIとの通信 | 認証や検証のために外部サービスへHTTPアクセス | ❌ 非対応 |
| Node.js/Pythonライブラリの使用 | moment.js、axiosなどのモジュール活用 | ❌ 非対応 |
| 署名付きURL/Cookie生成 | 動的な署名付きリクエスト生成 | ❌ 非対応 |
✅ CloudFront Functions で代替可能なケース
| ユースケース | 対応可否 | 補足 |
|---|---|---|
| HTTP → HTTPS リダイレクト | ✅ 対応可 | シンプルなリダイレクトロジックに適用可能 |
| www あり・なしの統一 | ✅ 対応可 | Hostヘッダーのチェックとリダイレクト |
| クエリやCookieによる簡易ルーティング | ✅ 対応可 | 複雑なロジックは不可 |
| 特定ヘッダーの付与・書き換え | ✅ 対応可 | セキュリティ強化に有効 |
| User-Agent チェックによる制御 | ✅ 対応可 | Bot判定など |
🔄 判断フローチャート：CFFかL@Eか？
+------------------------------------+
| オリジンに対する操作が必要か？ |
+------------------------------------+
| Yes
v
+-------------------------------+
| Lambda@Edge を使用する |
+-------------------------------+
|
No
v
+-----------------------------------+
| ボディの書き換えが必要か？ |
+-----------------------------------+
| Yes
v
+-------------------------------+
| Lambda@Edge を使用する |
+-------------------------------+
|
No
v
+-----------------------------------+
| 外部APIとの通信が必要か？ |
+-----------------------------------+
| Yes
v
+-------------------------------+
| Lambda@Edge を使用する |
+-------------------------------+
|
No
v
+-----------------------------------+
| CloudFront Functions で十分対応可 |
+-----------------------------------+
⚙ 技術比較：Lambda@Edge vs CloudFront Functions
| 項目 | Lambda@Edge | CloudFront Functions |
|---|---|---|
| 実行タイミング | Viewer / Origin 両方対応 | Viewer のみ対応 |
| 使用言語 | Node.js, Python | 独自JavaScriptランタイム |
| 外部通信 | ✅ 可 | ❌ 不可 |
| 本文（Body）編集 | ✅ 可 | ❌ 不可 |
| 処理時間上限 | 最大 5秒（オリジン側は10秒） | 最大 1ms |
| ライブラリ使用 | ✅ 可 | ❌ 不可（組み込みJS関数のみ） |
| コスト | 高め | 非常に安価 |
| デプロイ速度 | 数分かかる | 数秒で即反映 |
🖼️ 補足：画像変換・バイナリ処理には Lambda@Edge 一択
CloudFront Functions はヘッダー操作やURL書き換えには非常に有用ですが、以下のような画像やバイナリレスポンスの加工処理には対応していません：
| 処理内容 | CloudFront Functions | Lambda@Edge |
|---|---|---|
| 画像リサイズ（width/heightクエリ付き） | ❌ 非対応 | ✅ 可 |
| WebP形式などのコンテンツネゴシエーション | ❌ 非対応 | ✅ 可 |
| サムネイル生成 | ❌ 非対応 | ✅ 可 |
| バイナリ本文の編集（画像/JSON） | ❌ 非対応 | ✅ 可 |
sharp などの画像処理ライブラリ利用 |
❌ 不可 | ✅ 可能（Node.js対応） |
🔄 よくあるユースケース例
-
example.jpg?width=300&height=200のような画像サイズ変更リクエスト - ユーザーエージェントによって WebP 形式を動的に返す処理
- 動的に生成したバイナリレスポンスのキャッシュ制御
🚀 AWS Image Handler を活用する選択肢
パフォーマンスや管理性の観点では、AWS Image Handler の導入も有力な選択肢です。
| 特徴 | 内容 |
|---|---|
| サーバーレス構成 | Lambda + S3 + API Gateway + CloudFront で構築 |
| 利用ライブラリ | 高速画像変換ライブラリ sharp を採用 |
| サンプル構成あり | CloudFormation テンプレートが公式提供されており導入が容易 |
| クエリパラメータで制御 |
width、height、format（webp/jpeg/png）などの指定が可能 |
| CloudFrontキャッシュ統合 | キャッシュ最適化により高速かつコスト効率の良い配信が可能 |
🎯 適したユースケース
- Webサイトやモバイルアプリ向けの画像最適化
- 各デバイス・回線状況に応じた動的変換・変形
- マーケティング用途でのサムネイル・バナー生成
✅ 結論
CloudFront Functions は軽量かつ高速で便利ですが、以下のようなケースでは Lambda@Edge を使う必要があります：
- オリジン関連の動的処理（リクエスト改変／レスポンス加工）
- HTMLやJSONなどのレスポンス本文の編集
- 外部API連携（REST API 呼び出し、認証処理など）
- 複雑な処理やライブラリ使用を伴うビジネスロジック