🔍 はじめに

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 呼び出し、認証処理など）
複雑な処理やライブラリ使用を伴うビジネスロジック

📝 参考