先に要点
- エッジで動くコードの主要 3 選択肢は 「 Cloudflare Workers 」 「 CloudFront Functions 」 「 Lambda@Edge 」。CloudFront 系 2 つは AWS、Workers は Cloudflare のサービス。役割と性能と料金がそれぞれ違う ので、「書きたい処理の重さ」 と 「どのクラウドにオリジンがあるか」 で素直に選ぶのが基本。
- Cloudflare Workers: V8 isolates ベースのフルランタイム。「cold start ほぼ無し」 「 KV / D1 / R2 / Durable Objects などストレージと統合」 「 Cloudflare 全エッジで動く」 が強み。エッジで本格的にアプリを書きたい場合の第一候補。
- CloudFront Functions: 軽量・低料金・低レイテンシ。「 ヘッダ書き換え」 「 URL リライト」 「 簡単な認証」 程度の超軽量処理 専用。実行時間 1ms 以下、ランタイムは制限的な JavaScript。「まず試して書ければこれが最強」 と覚える位置づけ。
- Lambda@Edge: フル Node.js / Python が動くが、料金とレイテンシは Functions の数倍〜10 倍。CloudFront のキャッシュ 4 ポイント(Viewer Request / Origin Request / Origin Response / Viewer Response)に挟める。「複雑なロジックが必要」 「 Lambda 互換が要る」 ときの後段選択肢。
- 判断軸: AWS 中心ならまず Functions、書けない処理だけ Lambda@Edge」 「 Cloudflare 中心 or オリジンが他クラウド / オンプレなら Workers。「どこに住むか」 でほとんど決まる。料金面では Workers と Functions が安く、Lambda@Edge は富豪向け。
「エッジで処理を動かそう」 と思ったとき、最初に当たるのが 選択肢が複数あって違いが分からない 問題です。Cloudflare Workers、CloudFront Functions、Lambda@Edge はどれも 「エッジロケーションでコードを実行する」 サービスですが、得意分野と料金感がまるで違います。
ざっくり言うと、書きたい処理の重さ」 と 「 どのクラウドにオリジンがあるか の 2 軸でほぼ決まります。この記事では 3 サービスの仕組み・性能・料金・典型ユースケースを並列で整理します。CloudFront 基礎は Amazon CloudFront とは？ も併読してください。
3 サービスを一覧で
まず特徴を表で並べます。「どこに住んでいるか」 「 何が動くか」 「 料金感」 を一望できると判断が早くなります。
| 項目 | Cloudflare Workers | CloudFront Functions | Lambda@Edge |
|---|---|---|---|
| 提供元 | Cloudflare | AWS | AWS |
| 実行モデル | V8 isolates(フルランタイム) | 専用 JS ランタイム(超軽量) | Node.js / Python(Lambda 互換) |
| 典型実行時間 | ~10 ms 〜 数秒 | ~1 ms 以下 | ~10〜100 ms 〜 5 秒 |
| Cold Start | ほぼ無し | 無し | あり(数百 ms〜) |
| 使える機能 | fetch / Web Crypto / KV / D1 / R2 / Durable Objects / Queues | 標準 ECMAScript の一部、ヘッダ書き換え程度 | フル Node.js API、ファイル I/O 制限あり |
| 料金感(目安) | 月 10M req まで $5、超過は $0.50/M | 0.10 USD / 100万リクエスト(WAF 等含まず) | 0.6 USD / 100万リクエスト + 実行時間課金 |
| 典型ユースケース | API バックエンド、認証、エッジロジック、画像変換 | ヘッダ書き換え、リダイレクト、簡易認証 | 複雑な認証、画像処理、A/B テスト、Edge SSR |
ここで重要なのは Cloudflare Workers と CloudFront Functions は別物 という点。名前が似ていますが、「Functions は超軽量、Workers はフルランタイム」 と レイヤが違います。
それぞれの仕組み
各サービスがどう動くかを 1 ブロックずつ整理します。
Cloudflare Workers
Cloudflare Workers は V8 isolates という仕組みで、「コンテナや VM を起動せず、V8 のサンドボックス内でコードを直接実行」 します。
仕組みの本質
「 関数ごとに OS プロセスや VM を立てず、1 つの V8 プロセスの中で複数の関数を別 isolate として走らせる」。Cold Start が事実上ない(初回呼び出しでも 1 ms 程度)のが最大の特長。
使える言語と SDK
JavaScript / TypeScript が一級、Rust / C++ などから WebAssembly 経由でも実行可能。Hono や itty-router のような Workers 向けフレームワークがあり、Express ライクに API を書ける。
CloudFront Functions
「 CloudFront Functions」 は AWS の 超軽量エッジ関数。CloudFront のキャッシュ層に挟む ミニマルな JavaScript ランタイム。
仕組みの本質
「 CloudFront のエッジロケーションで、リクエスト/レスポンスの軽量処理を 1 ms 以下で実行」。Lambda@Edge より 6 倍速く、料金は 1/6。ただし機能は限定的(fetch も無し、ファイル I/O 無し、外部 API 呼び出し無し)。
挟めるポイント
「 Viewer Request」 「 Viewer Response」 の 2 ポイント。「オリジンと通信する手前」 もしくは 「クライアントへ返す直前」 のヘッダ書き換え用途。
使える言語と機能
限定的な JavaScript(ECMAScript の一部)。外部 API 呼び出し / ファイル I/O / DNS / setTimeout は不可。「ヘッダの読み書き」 「 URL のリライト」 「 簡易的な認証検証(JWT 署名検証くらいまで)」 が中心。
向いている用途
「 ヘッダにセキュリティポリシーを追加」 「 言語/地域に応じてリダイレクト」 「 簡易な署名付き URL の検証」 「 URL ルーティングの正規化」。「コードが書ければこれが最強」 と覚える位置づけ。
Lambda@Edge
「 Lambda@Edge」 は CloudFront に挟める フル Lambda。「Node.js / Python のフル機能が使える代わりに、料金とレイテンシは Functions の数倍」。
仕組みの本質
「 通常の Lambda をエッジロケーション(リージョンキャッシュ)で実行」。Cold Start があり、レイテンシも数十 ms オーダー。ただし Lambda の機能ほぼフル(外部 API 呼び出し / DynamoDB アクセス / S3 操作 / Secrets Manager)。
挟めるポイント
「 Viewer Request」 「 Origin Request」 「 Origin Response」 「 Viewer Response」 の 4 ポイント。CloudFront Functions(2 ポイント)より柔軟。
用途で選ぶ — 判断フロー
「どれを選ぶか」 は次のフローで決まります。
判断フローを通せば、「まず候補が 1〜2 個に絞れる」 はずです。
典型ユースケース別の選択肢
具体的なユースケースで、どれが向くかを並べます。
| ユースケース | 推奨 | 理由 |
|---|---|---|
| セキュリティヘッダ(CSP / HSTS)追加 | CloudFront Functions / Workers | 超軽量で十分。Functions が最安 |
| 地域に応じたリダイレクト | CloudFront Functions / Workers | 軽量処理、両方できる |
| 署名付き URL 検証(JWT) | CloudFront Functions / Lambda@Edge | JWT 署名検証だけなら Functions、外部 IdP 問い合わせなら Lambda@Edge |
| A/B テスト振り分け | Workers / Lambda@Edge | 状態管理が要るなら Workers + Durable Objects |
| 画像リサイズ / 変換 | Lambda@Edge / Workers(画像 API 経由) | Sharp 等の重い処理は Lambda@Edge、Cloudflare Image Resizing を併用するなら Workers |
| API バックエンド全体 | Cloudflare Workers | Cold Start ほぼ無し + Hono 等で開発体験良し |
| Edge SSR(Server-Side Rendering) | Lambda@Edge / Workers + Next.js Edge | フレームワーク次第。Vercel / Cloudflare Pages の選択肢も |
| WAF 機能(独自実装) | Workers / Lambda@Edge | マネージド WAF を使うのが本来推奨だが、独自ルールが要るなら |
料金の感覚 — 大量リクエスト時の差
少量なら無料枠で済みますが、「数千万リクエスト/月」 になると差が大きく出ます。
「小規模なら Workers / Functions が圧倒的に安く、Lambda@Edge は処理量が必要な場合だけ」 が現実的な感覚です。
Cloudflare Workers と CloudFront Functions に関するよくある質問
Q. 名前が似ているけど、Cloudflare Workers と CloudFront Functions は競合ですか?
A. 提供元も価格帯も性能も違うので、直接の競合とは言いづらい。Workers はフルランタイムでアプリを動かす想定、Functions は超軽量なヘッダ書き換え用と レイヤが違います。「Workers vs Lambda@Edge」 の方が比較として近いです。
Q. Cold Start が無いと宣伝されている Workers、本当に無いんですか?
A. ほぼ無いです。V8 isolates の仕組み上、「関数ごとに VM やコンテナを起動しない」 ので、初回呼び出しでも数 ms 程度。大量にデプロイされた Workers のうち、特定の Worker が長時間呼ばれていなくても、初回起動が数 ms で済む のが Lambda 系との大きな違い。
Q. CloudFront Functions で fetch() が使えないのは不便?
A. 用途が限定されている代わりの利点と考えるのが現実的。「fetch が要るような処理は Lambda@Edge へ」 と分担すれば、「Functions は超低料金で軽量処理に専念」 できる設計になります。「fetch を使いたい」 と思った時点で Functions ではなく Lambda@Edge か Workers の検討 に切り替える判断軸として使えます。
Q. Lambda@Edge は高いと聞きましたが、コスト最適化はできますか?
A. キャッシュヒット率を上げる」 「 同じ処理を CloudFront Functions に降ろせないか検証」 「 Origin Request/Response を Viewer Request/Response にできないか検討 の 3 つが定番。Origin 系トリガーは キャッシュミス時だけ呼ばれる ので、キャッシュヒット率を上げると劇的にコストが下がります。
Q. Workers の D1 は本番で使えますか?
A. ベータ卒業して GA(General Availability) していますが、「大規模・低レイテンシな OLTP」 には適しません。「小〜中規模のアプリで SQLite で足りる用途」 なら有用。既存の RDBMS 資産がある 場合は、「オリジン側に MySQL / PostgreSQL を置いて Workers から呼ぶ」 構成の方が現実的です。
Q. エッジで動かす意味があるのはどんな処理?
A. レイテンシが UX を直接左右する処理」 「 オリジン到達前にフィルタしたい処理」 「 地域別に挙動を変えたい処理。「計算量が少なくユーザーに近い場所で実行する価値があるか」 が判断軸。「重い処理 / DB 集約処理 / Bach 系」 はエッジに置く意味が薄いので、「オリジンで動かす方が素直」 です。
Q. AWS と Cloudflare を併用するパターンはありますか?
A. よくあります。「Cloudflare を最前段に置いて DDoS 防御 + 世界配信」 「 オリジンは AWS(ALB + ECS + RDS)」 「 必要なら CloudFront を後ろに挟む」 のような 多層構成。「Cloudflare Workers でフィルタリング → AWS でビジネスロジック」 のように 役割分担 で組み合わせるのも実用的です。
まとめ
エッジで動くコードの主要 3 選択肢は、Workers = フルランタイム / Functions = 超軽量 / Lambda@Edge = フル Lambda と覚えれば判断が早くなります。「書きたい処理の重さ」 と 「どのクラウドにオリジンがあるか」 の 2 軸で素直に選ぶのが基本。
「Cloudflare 中心ならまず Workers、AWS 中心ならまず Functions、Functions で書けない処理だけ Lambda@Edge」 という階段で考えると、「過剰なツール選択」 を避けつつ実装できます。「エッジでアプリ全体を完結させたい」 なら Workers + ストレージ統合が現代的、「既存 AWS スタックの前段を強化したい」 なら Functions + Lambda@Edge の組み合わせが鉄板です。
参考リンク
- Cloudflare: Cloudflare Workers
- Cloudflare Docs: Workers Platform
- AWS Docs: CloudFront Functions vs Lambda@Edge
- AWS Docs: Lambda@Edge Developer Guide
- AWS: CloudFront Functions Pricing