ネットワーク・ 2026-05-23

Lambda@Edge と CloudFront Functions の使い分けを完全整理：選定フローと料金・性能・トリガー比較

Lambda@Edge と CloudFront Functions はどちらも CloudFront エッジで動く関数だが、ランタイム・実行時間・トリガー・料金がまったく違う。Lambda@Edge は Node.js／Python の本格 Lambda（Origin/Viewer 4 トリガー・SDK 可・最大 30 秒）、CloudFront Functions は ES5 限定の超軽量 JS（Viewer 2 トリガー・ネットワーク呼び出し不可・1 ms 以内）。本記事では仕組み・12 観点比較・選定フロー・料金（1/6 安い）・ユースケース別の使い分け・組み合わせ運用までを整理する。

#AWS #Lambda-Edge #CloudFront-Functions #CloudFront #エッジコンピューティング

「エッジで処理したい」と言われたとき、AWS には Lambda@Edge と CloudFront Functions という似て非なる選択肢がある。両者は「CloudFront エッジで関数を動かす」というゴールは同じだが、ランタイム・実行時間・トリガー・ネットワーク呼び出し可否・料金がまるで違う。試験でも現場でも判断を誤りやすいこの 2 つを、12 観点比較と選定フロー込みで一気に整理する。

1. 両者を一言で

サービス	一言で言うと
Lambda@Edge	Node.js／Python の本格 Lambda を、us-east-1 にデプロイして全エッジへ自動レプリケートし、4 種類のトリガーで動かす仕組み
CloudFront Functions	CloudFront 専用の超軽量 JS（ES5）ランタイムで、Viewer Request／Viewer Response の 2 点だけを 1 ms 以内に処理する仕組み

似ているのは「CloudFront エッジで関数を動かす」「Viewer/Origin の前後でリクエストやレスポンスを書き換えられる」という結果だけで、裏で動いているランタイム・対応トリガー・できる処理の上限がまったく別物である。

2. 仕組みの違い：軽量 JS ランタイム vs フル Lambda

両者は同じ「CloudFront エッジ」上で動くが、裏で動いている実行エンジンが完全に別物である。試験でも実装でも、この差を理解していないと「なぜ片方ではできて片方ではできないのか」を説明できない。

2-1. CloudFront Functions の実行モデル

CloudFront Functions は CloudFront プロセスに組み込まれた専用 JS エンジン で動く。Lambda のように関数ごとに隔離されたコンテナを起動するのではなく、CloudFront 本体のリクエスト処理パイプラインに直接組み込まれる イメージ。

クライアント
  ↓
[CloudFront エッジロケーション]
  ↓ Viewer Request
[CloudFront プロセス内蔵 JS エンジン]
  ↓ 1 ms 以内に終了
  ↓ キャッシュ判定
[オリジン or キャッシュ]
  ↑
[CloudFront プロセス内蔵 JS エンジン]
  ↑ Viewer Response
クライアント

起動時間・メモリ使用量が極小なので、毎秒 1,000 万リクエスト超 までスケール
コールドスタートが存在しない（Lambda のような VM 起動が不要）
ただしランタイムは ECMAScript 5.1 相当（let/const/async/fetch 不可）

2-2. Lambda@Edge の実行モデル

Lambda@Edge は 通常の Lambda 関数を us-east-1 にデプロイし、AWS が自動で各エッジへレプリケート する。実行時はエッジ近傍のリージョンで Lambda コンテナが立ち上がり、Node.js / Python の本格ランタイムで処理する。

クライアント
  ↓
[CloudFront エッジロケーション]
  ↓ Viewer Request → ① L@E（Node.js/Python）
  ↓ キャッシュ判定
  ↓ ミス時：Origin Request → ② L@E
[オリジン（S3 等）]
  ↑ Origin Response → ③ L@E
  ↑ キャッシュ保存
  ↑ Viewer Response → ④ L@E
クライアント

4 つのトリガー（Viewer Request / Origin Request / Origin Response / Viewer Response）
AWS SDK・外部 HTTP・ファイルシステムなど通常 Lambda と同等の機能
実行時間 Viewer 5 秒／Origin 30 秒、メモリ Viewer 128 MB／Origin 最大 10 GB
デプロイは us-east-1（バージニア）に固定、各エッジには AWS が透過的にレプリケート

3. 比較表：12 観点で並べる

Lambda@Edge vs CloudFront Functions（12 観点）

評価項目	Lambda@Edge	CloudFront Functions 推奨
ランタイム	Node.js / Python	JavaScript（ES5.1）
実行時間上限	Viewer 5 秒 / Origin 30 秒	1 ms 以内
メモリ	Viewer 128 MB / Origin 最大 10 GB	2 MB
コードサイズ	Viewer 1 MB / Origin 50 MB	10 KB
トリガー	Viewer/Origin 計 4 つ	Viewer 2 つのみ
リクエストボディアクセス	◎	×（ヘッダ・URL のみ）
ネットワーク呼び出し（HTTP/SDK）	◎	×
スケール上限	約 10,000 req/s／リージョン	10,000,000 req/s 超／拠点
コールドスタート	あり（数十 ms〜）	なし
料金（リクエスト 100 万回）	$0.60	$0.10（1/6）
料金（実行時間）	GB-秒課金あり	なし（リクエスト課金のみ）
無料枠	なし（通常 Lambda の無料枠は対象外）	月 200 万リクエスト

軽量・高頻度処理は CloudFront Functions、複雑処理・Origin 段処理は Lambda@Edge。

数字で並べると 性能・料金・スケールの差が一桁単位 で違うのが分かる。シンプルな処理を CloudFront Functions に寄せるだけで、コストとレイテンシが劇的に改善する。

4. トリガー位置の決定的な違い

「どのタイミングで関数が動くか」は、エッジ関数を設計するうえで最も重要なポイント。両者で対応トリガーが違うため、やりたい処理によっては片方しか選べない ケースが多い。

4-1. CloudFront のリクエストフローと 4 トリガー

クライアント
  ↓ ① Viewer Request（必ず実行）
[CloudFront エッジ]
  ↓ キャッシュ確認
  ↓ ヒット時：そのまま返却
  ↓ ミス時：オリジンへ
  ↓ ② Origin Request（オリジンへ送る前）
[オリジン（S3 等）]
  ↑ ③ Origin Response（オリジンから戻った直後）
  ↑ キャッシュ保存
  ↑ ④ Viewer Response（必ず実行）
クライアントへ

4-2. 対応トリガーの差

トリガー	Lambda@Edge	CloudFront Functions
Viewer Request	◎	◎
Origin Request	◎	×
Origin Response	◎	×
Viewer Response	◎	◎

CloudFront Functions は Viewer の入口・出口（クライアント側）でしか動かない。これは設計上の重要な制約。

4-3. トリガーが意味するもの

Viewer Request：すべてのリクエストで実行。キャッシュヒット／ミスに関わらず必ず動くため、URL リダイレクトや認証チェックに最適
Origin Request：キャッシュミス時のみ実行。A/B テストでのオリジン振り分け、リクエストヘッダのオリジン向け書き換え
Origin Response：オリジンから戻った直後。レスポンス本文の動的変換、画像最適化
Viewer Response：すべてのレスポンスで実行。セキュリティヘッダ（CSP/HSTS）の追加など

5. パフォーマンスとスケール特性

5-1. レイテンシの目安

処理	CloudFront Functions	Lambda@Edge
関数起動	0 ms（プロセス内蔵）	数十 ms〜数百 ms（コールドスタート時）
関数実行	< 1 ms	数 ms〜数秒
体感レイテンシ追加	ほぼゼロ	50〜200 ms 程度

ユーザー体感への影響は CloudFront Functions のほうが圧倒的に小さい。リダイレクトやヘッダ操作のような「全リクエストに乗る」処理は、Lambda@Edge で組むと TTFB（Time To First Byte）が悪化する。

5-2. スケール上限

CloudFront Functions：1 拠点あたり 1,000 万 req/s 超（実質無制限）
Lambda@Edge：1 リージョンあたり 10,000 req/s（要上限緩和、デフォルト 1,000）

大規模トラフィックでヘッダ書き換えだけしたいケースで、Lambda@Edge を選ぶと 同時実行数の上限に当たって throttling が発生する 事故がある。「全リクエストに必ず乗る軽量処理」は CloudFront Functions に寄せる のがセオリー。

5-3. コールドスタート

CloudFront Functions：コールドスタートなし（CloudFront プロセスに常駐）
Lambda@Edge：通常 Lambda と同じくコールドスタートあり。Viewer 段では 128 MB 固定 のためコールドスタートが比較的軽い

ただし Lambda SnapStart は Lambda@Edge では使えない点に注意。

6. コード制約とランタイム制限

両者で「書けるコードの自由度」がまったく違う。

6-1. CloudFront Functions の制約

ECMAScript 5.1 のみ（let/const/async/await/fetch などモダン JS 構文は不可）
外部モジュール不可（require/import 一切なし、純粋な JS で完結）
AWS SDK 不可
外部 HTTP 不可（ネットワーク呼び出し一切なし）
リクエストボディアクセス不可（ヘッダ・URL・Cookie のみ）
ファイルシステム不可
実行時間 1 ms 以内（超えると関数が打ち切られる）

つまり書けるのは「ヘッダや URL を読んで、ヘッダや URL を書き換える」レベルの軽量ロジックだけ。

6-2. Lambda@Edge の制約

Node.js / Python の通常 Lambda 同等
AWS SDK 利用可（DynamoDB / S3 / Secrets Manager 等を呼べる）
外部 HTTP 可（任意の外部 API を叩ける）
リクエストボディアクセス可（Viewer 段で 1 MB まで、Origin 段で 1 MB まで）
環境変数なし（通常 Lambda と違う点）
VPC 接続なし（プライベートリソースには直接届かない）
デプロイは us-east-1 のみ

通常 Lambda よりは制約があるが、外部 API 連携・複雑処理・SDK 呼び出しは普通にできる。

6-3. ProsCons まとめ

メリット

CloudFront Functions：超低レイテンシ・超低コスト・コールドスタートなし
CloudFront Functions：月 200 万リクエスト無料・スケール無制限
Lambda@Edge：AWS SDK・外部 HTTP・複雑処理可
Lambda@Edge：Origin Request/Response で本文操作・画像最適化可
Lambda@Edge：Node.js/Python の豊富なライブラリエコシステム

デメリット

CloudFront Functions：ES5 のみ・外部呼び出し不可・1 ms 制限
CloudFront Functions：Viewer トリガーのみで本文アクセス不可
Lambda@Edge：us-east-1 固定・環境変数なし・VPC 接続不可
Lambda@Edge：料金が約 6 倍・コールドスタートあり・スケール上限あり
Lambda@Edge：通常 Lambda の無料枠が対象外で課金が発生しやすい

7. 料金比較：1/6 の差は何で生まれるか

7-1. 単価

項目	CloudFront Functions	Lambda@Edge
リクエスト課金	$0.10 / 100 万リクエスト	$0.60 / 100 万リクエスト
実行時間課金	なし	GB-秒で課金（128 MB なら $0.00000625125/GB-秒）
無料枠	月 200 万リクエスト	なし（通常 Lambda 無料枠は対象外）
最小課金単位	リクエスト	1 ms 単位

7-2. 試算例：月 1 億リクエストの場合

シナリオ	CloudFront Functions	Lambda@Edge（平均 5 ms 実行・128 MB）
リクエスト課金	$9.80（200 万無料控除後）	$60.00
実行時間課金	$0.00	約 $4.00
合計	約 $9.80	約 $64.00

同じヘッダ操作を CloudFront Functions で書き直すだけで 月額 $54 削減（6.5 倍の差）。トラフィック規模が大きいほど差が広がる。

7-3. データ転送・周辺コスト

CloudFront 本体のデータ転送料は両者とも別途発生（変わらない）
CloudWatch Logs への関数ログは両者とも該当リージョン（L@E は us-east-1、CFF はリクエストが発生したリージョン）で発生
CloudFront リアルタイムログを有効にしている場合は別途 Kinesis Data Streams 課金

8. 選定フロー（フローチャート）

実務で迷ったらこの順に絞り込む：

Q1. やりたい処理は外部 HTTP / AWS SDK を呼ぶか？
  ├─ Yes → ★ Lambda@Edge 一択
  └─ No → Q2 へ

Q2. Origin Request / Origin Response でしか実装できない処理か？
  （オリジン振り分け、レスポンス本文の動的変換、画像最適化など）
  ├─ Yes → ★ Lambda@Edge 一択
  └─ No → Q3 へ

Q3. リクエスト／レスポンスボディの読み書きが必要か？
  ├─ Yes → ★ Lambda@Edge
  └─ No → Q4 へ

Q4. 実行時間 1 ms / メモリ 2 MB / コード 10 KB / ES5 で収まるか？
  ├─ Yes → ★ CloudFront Functions（コスト・性能で圧倒的有利）
  └─ No → ★ Lambda@Edge

Q5. 全リクエストに必ず乗る処理か（キャッシュヒットでも動く）？
  ├─ Yes → CloudFront Functions に寄せる
  └─ No（キャッシュミス時のみ）→ Lambda@Edge の Origin Request も可

3 つ以上の質問で CloudFront Functions が選ばれた場合、CFF に統一するのがコスト・性能の両面でほぼ確実に正解。「最初は Lambda@Edge で組んで、シンプルな処理だけ CFF に切り出す」リファクタもよくあるパターン。

9. ユースケース別の使い分け

9-1. URL リダイレクト（旧 URL → 新 URL の 301）

CloudFront Functions が正解。全リクエストに乗るので CFF の低コスト・低レイテンシが効く
Lambda@Edge でやると料金が 6 倍以上・TTFB も悪化

9-2. セキュリティヘッダ（CSP / HSTS / X-Frame-Options）の付与

CloudFront Functions（Viewer Response） が正解
全レスポンスに乗るので CFF 一択

9-3. キャッシュキー正規化（クエリ文字列の整理）

CloudFront Functions（Viewer Request） が正解
キャッシュヒット率を上げるための前段処理なので、軽量・高速が必須

簡易な署名検証なら CloudFront Functions（crypto オブジェクトが使える）
公開鍵を外部から取得する必要がある場合は Lambda@Edge（SDK 経由）

9-5. A/B テスト（ユーザー振り分け）

ヘッダや Cookie だけで判定 → CloudFront Functions
オリジンを別ホストへ振り分け → Lambda@Edge の Origin Request

9-6. 画像のリサイズ / フォーマット変換

Lambda@Edge（Origin Response） 一択
レスポンスボディを書き換える必要があるため CFF では不可能

9-7. 外部 API での認証チェック

Lambda@Edge（Viewer Request） 一択
外部 HTTP 呼び出しが必須なので CFF では不可

9-8. 動的コンテンツの生成（小規模）

Lambda@Edge（Origin Request または Origin Response）
レスポンス本文を生成・差し替える処理

9-9. ジオロケーションによる出し分け

ヘッダ（CloudFront-Viewer-Country）だけで分岐 → CloudFront Functions
国別 DB 呼び出しが必要 → Lambda@Edge

9-10. WAF の補完（簡易レートリミット・User-Agent ブロック）

軽量チェックなら CloudFront Functions
ただし AWS WAF との使い分けに注意（WAF で済むなら WAF が筋）

10. 組み合わせ運用パターン

CloudFront は 1 つのディストリビューションで両方を併用できる。実務では「前段は CFF・後段は L@E」の二段構えがコスト最適化の定石。

10-1. 二段構えパターン

クライアント
  ↓ Viewer Request
[CloudFront Functions] ← ヘッダ正規化・簡易認証・リダイレクト
  ↓
  キャッシュ判定
  ↓ ミス時
[Lambda@Edge] ← Origin Request：オリジン振り分け
  ↓
[オリジン]
  ↑ Origin Response
[Lambda@Edge] ← レスポンス本文の動的変換
  ↑
[CloudFront Functions] ← Viewer Response：セキュリティヘッダ付与
  ↓
クライアント

入口の軽量処理は CFF：全リクエストに乗っても安い・速い
重い処理は L@E：キャッシュミス時のみ動くので頻度が抑えられる
出口のヘッダ付与は CFF：全レスポンスに乗っても安い

10-2. 同一トリガーで両方は使えない

Viewer Request に CFF と L@E を同時にアタッチすることはできない（どちらかを選ぶ）。同様に Viewer Response も排他。Origin Request / Origin Response は L@E 専用。

10-3. デプロイ単位

CloudFront Functions：CloudFront コンソールから直接編集・デプロイ可能（数十秒）
Lambda@Edge：us-east-1 で Lambda 関数を更新 → バージョン発行 → CloudFront ディストリビューションに紐付けし直す（全エッジへの伝播に 5〜15 分）

CFF のほうが圧倒的にデプロイが速く、A/B テスト的に試しやすい。L@E は 本番反映が遅いことを設計時に織り込む 必要がある。

11. 運用ベストプラクティス

「キャッシュヒットでも動く処理」は必ず CloudFront Functions に寄せる — 全リクエストに乗るのでコスト・レイテンシで効く
Lambda@Edge は Origin 段に限定運用する — Viewer 段で SDK を呼ぶ必要が本当にあるかを再確認、可能なら Origin Request に移す
環境変数の代わりに Secrets Manager or Parameter Store を使う — 起動時に取得して init 外で保持し、コールドスタートを抑える
Lambda@Edge のログは us-east-1 ではなく実行リージョンに出る — エッジ近傍リージョンの CloudWatch Logs を見にいくこと（CloudWatch Logs）
CFF はテスト機能で本番反映前に検証する — マネコンのテストランナーで事前にイベントを流して動作確認
L@E は同時実行数の上限緩和申請を早めに行う — デフォルト 1,000 のため、本番大規模トラフィックでは事前に上限引き上げ
Origin Response で画像変換するなら S3 にキャッシュする設計に — 同じ URL のたびに再変換しないよう Cache-Control 設計を合わせる
デプロイは Terraform / CDK でコード化 — 特に L@E は手動更新でリスクが大きいので IaC 必須
CloudFront Functions のソースは Git で管理し、テストを書く — マネコン直接編集は事故のもと
WAF で済む処理は WAF に寄せる — レートリミットや IP ブロックは AWS WAF のほうが運用が楽

12. 関連用語

Amazon CloudFront — エッジ関数の基盤となる CDN
Lambda@Edge — フル Lambda のエッジ実行
CloudFront Functions — 超軽量 JS のエッジ実行
AWS Lambda — 親サービス（Lambda@Edge の本体）
Lambda 実行環境 — ランタイム選定
Lambda 同時実行数 — L@E のスケール上限と関係
Lambda レイヤー — L@E では使用不可
Lambda SnapStart — L@E では使用不可
Amazon S3 — オリジンとしての代表例
AWS WAF — エッジ関数とよく比較される選択肢
AWS Secrets Manager — L@E の設定値取得先
Parameter Store — L@E の設定値取得先（コスト重視）
Amazon CloudWatch Logs — エッジ関数のログ保存先

13. 関連サイト

AWS 公式

参考記事

Serverless Operations：CloudFront FunctionsのユースケースとLambda@Edgeとの違い

💡 学習中のひとこと

Lambda@Edge と CloudFront Functions は 同じエッジで動くが裏のランタイムが完全に別物 です。CloudFront Functions は CloudFront プロセスに組み込まれた ES5 専用エンジンで、1 ms 以内・コールドスタートなし・1/6 の価格で動きますが、外部 HTTP も SDK も使えず、Viewer 段のヘッダ／URL 操作専用です。Lambda@Edge は通常 Lambda と同じ Node.js／Python ランタイムで、SDK・外部 API・Origin 段の本文書き換えなど高機能ですが、料金は約 6 倍、デプロイは us-east-1 固定で全エッジ伝播に 5〜15 分かかります。実務では「軽量で全リクエストに乗る処理は CFF、複雑処理や Origin 段の処理は L@E」の二段構えが鉄板。試験でも「ES5・1 ms・ヘッダ操作」というキーワードが出たら CFF、「SDK・外部 API・Origin」というキーワードが出たら L@E と判別すれば外しません。

🎓 試験での出題傾向

試験	重要度	主な出題パターン
CLF	低	サービス名の識別
SAA	中	エッジ処理を含む構成設計、コスト最適化
DVA	高	適切なトリガー選択、コード制約の理解、Origin/Viewer の使い分け
SOA	中	監視・ログ・スケール上限緩和、料金最適化

判別キーワード：

「ES5 のみ」「1 ms 以内」「ヘッダ・URL 操作」「コールドスタートなし」「毎秒数百万リクエスト」 → CloudFront Functions
「Node.js / Python」「AWS SDK」「外部 API 呼び出し」「最大 30 秒」「us-east-1 にデプロイ」 → Lambda@Edge
「Origin Request / Origin Response でしか動かない処理」（オリジン振り分け、画像最適化、レスポンス本文変換） → Lambda@Edge 一択
「Viewer Request / Response の高頻度・軽量処理」（リダイレクト、ヘッダ追加、キャッシュキー操作） → CloudFront Functions
「同じ機能で 1/6 安く・10〜50 倍速い」「月 200 万リクエスト無料」 → CloudFront Functions の優位性問題

DVA では特に「この要件（外部 API 呼び出し or ヘッダ操作のみ）に対してどちらを選ぶか」がよく問われる。「外部呼び出し」「SDK」「ボディ操作」「Origin 段」のいずれかが含まれたら Lambda@Edge、そうでなければ CloudFront Functions と覚えると判断が早い。コスト最適化の文脈では CFF への置き換えが正解候補 になることが多い。