CloudFront + AWS Lambda@Edge 画像リサイズ：性能・コスト・運用まで完全ガイド

Q1. なぜ On-the-fly 画像リサイズが必要なのか？

元の画像は容量が大きく、サイズもバラバラなことが多いため、そのまま配信すると読み込み速度の低下、帯域幅コストの増加、UI 品質の低下を招きます。On-the-fly リサイズは、リクエスト時に画像を加工して配信するため、デバイスに合わせた最適化が容易に行えます。

Q2. Lambda@Edge を使うとコストが高くならないのか？

多くの場合、そうはなりません。キャッシュミス 5% を前提とすると、MAU 1 万規模のサービスでは CDN 帯域コストを月約 90 ドル削減できる一方、Lambda 実行コストは約 5 ドル程度に収まります。キャッシュが安定していれば、全体コストはむしろ減少します。

Q3. Lambda@Edge 使用時の注意点は？

1MB のレスポンス制限、30 秒の実行時間、グローバル配布によるログ分散など、運用の複雑性を考慮する必要があります。

Q4. 小規模サービスでも On-the-fly でコスト削減できるのか？

可能です。MAU 1,000〜100,000 規模でも、WebP/AVIF 適用とキャッシングにより 30〜50% の帯域削減が期待できます。

Q5. Lambda@Edge ではなく Managed CDN を選ぶ理由は？

リサイズ・フォーマット変更・モニタリングを運用負担なく即時適用でき、開発・運用リソースを大幅に節約できます。さらに AI 変換クエリや使用量ダッシュボードなど、管理性のメリットも多く存在します。

On-the-fly 画像リサイズとは？

On-the-fly 画像リサイズとは、画像がリクエストされた瞬間に、必要なサイズ（例：200×200）やフォーマット（WebP、AVIF など）に変換して返す方式です。複数のバリエーションを事前生成する必要がないため：

ストレージコスト削減
運用構成の簡素化
新しいデバイス・解像度への対応が容易

といった利点があります。

なぜ重要になったのか？

Netflix のようなサービスは、TV・スマートフォン・タブレットなど多様なデバイスで視聴されるため、同一コンテンツでも多様な画像サイズが必要になります。

過去には以下の2つの方法が一般的でした：

1) 大きい画像を配信してクライアント側で縮小する
2) 異なるサイズの画像を事前生成・保存しておく

1) 大きな画像を配信しクライアントが縮小する方式

常に元画像をダウンロードするため
→ 読み込みが遅い
→ 無駄な帯域消費

さらにブラウザ・アプリ側で縮小処理を行うため
→ 低スペック端末・低速ネットワークで体感性能が悪化

2) 複数サイズを事前生成して保存する方式

元画像＋複数バリエーションをすべて保存するため
→ ストレージが倍増

新しいレイアウトが必要になるたびに
→ 再生成のバッチが必要

運用が長期化するほど
→ どの画像サイズが必要か、管理が複雑化

こうした課題を解決するために、クラウド環境に適した新しい Best Practice として On-the-fly 方式 が登場しました。

Lambda@Edge のリサイズアーキテクチャ

リクエスト時に必要な画像だけを生成し、CDN にキャッシュする方式です。ストレージ・帯域・運用の負担を同時に抑えられるため、現代のクラウド環境では事実上の標準になっています。

従来方式 vs On-the-fly 方式

従来方式：
→ S3 に複数サイズを事前保存し、そのファイルを返す

On-the-fly 方式：
→ 元画像のみ保存
→ ?s=200x200&q=80 のようなパラメータに応じて生成
→ 結果を CloudFront にキャッシュ

この構造により：

ストレージは元画像中心でOK
配信は最適化済み画像のみ

が実現できます。

Lambda が毎回実行されるならコストが高くなるのでは？

そうではありません。ポイントは CDN のキャッシュ構造 にあります。

リクエストの種類：

Viewer Request：ユーザー→CDN へのリクエスト
Origin Request：CDN にキャッシュが無い場合の S3/Lambda へのリクエスト

キャッシュ視点で見ると：

Cache Hit：CDN に結果があるため Lambda は呼ばれない
Cache Miss：初回だけ Lambda が実行され、処理後 CDN に保存

つまり：

初回：Lambda 実行 + S3 取得 + キャッシュ保存
2回目以降（同じ URL）：CDN が即時応答（Lambda コストなし）

Miss 比率を下げるだけで、Lambda コストは全体のごくわずかになり、
多くのコスト削減は「軽い画像 + 帯域削減」から生まれます。

事例：Karrot（旧・당근マーケット）の On-the-fly 導入

Karrot は韓国を代表する UGC 中心のマーケットプレイスです。

1日のデータ量：

50万件の画像アップロード
2億件の画像リクエスト
16,000 GB のトラフィック

この規模で元画像そのまま配信すると：

CDN コストが急増
アプリの体感速度が悪化

Karrot は Lambda@Edge ベースの On-the-fly 方式を導入し、

トラフィック 20% 削減
重複保存画像の排除により数千ドル/月の削減

を実現しました。

小規模サービスではどうなのか？

UGC が多いサービスでは：

ユーザー1人あたり月数千リクエスト
数百MBの画像トラフィック

という状況が一般的です。

MAU	Requests /mo	Traffic	Savings (0.15$/GB)	Lambda Cost
1,000	3M	300 GB	$ 9 /mo	$ 0.5 /mo
3,000	9M	900 GB	$ 27 /mo	$ 1.5 /mo
5,000	15M	1,500 GB	$ 45 /mo	$ 2.6 /mo
10,000	30M	3,000 GB	$ 90 /mo	$ 5.2 /mo
50,000	150M	15,000 GB	$ 450 /mo	$ 26.2 /mo
100,000	300M	30,000 GB	$ 900 /mo	$ 52.4 /mo

この基準を MAU 1,000〜100,000 に当てはめると：

WebP/AVIF + リサイズ + キャッシュ → 30〜50% の帯域削減
Lambda コストは全体のごく一部

小規模でも画像比率が高いサービスなら On-the-fly は十分魅力的です。

Lambda@Edge vs Managed CDN

On-the-fly 画像最適化の実装方法は2つ：

CloudFront + Lambda@Edge を自前構築
Cloudinary/Fastly/Weekerp など Managed CDN を利用

1) Lambda@Edge（自前構築）

メリット：

CloudFront と密結合で動作
設計次第で高効率＆グローバルスケール

デメリット：

グローバルなコード配布
キャッシュ戦略・URL 設計が複雑
ログ分散でデバッグ困難
1MB 制限・30秒制限などの制約

2) Managed CDN

メリット：

リサイズ・フォーマット変更・サムネイルを URL パラメータで即利用
キャッシュ・インフラ・障害対応をすべて委任
ダッシュボード、ログ、分析が標準提供

デメリット：

料金体系（帯域/リクエスト/変換数）がサービスごとに異なる
特殊なカスタムロジックは制限される場合あり

選択基準：

インフラ管理が得意で大規模運用 → Lambda@Edge
開発に集中したい・運用負担を減らしたい → Managed CDN

Weekerp Image のポジション

Weekerp Image は 「既存ストレージはそのまま、運用はもっと簡単に」 をコンセプトにした Managed CDN です。

主な特徴：

1MB 制限なし
実行時間の制限なし
キャッシュ率・帯域幅・地域別リクエストのダッシュボード
自然言語による変換パラメータ（例：dog.jpg?ai="200pxにして"）
S3/GCP/Azure をそのまま接続可能（移行不要）

Lambda@Edge のメリットを維持しつつ、
運用負担を取り除くことに特化した Managed CDN です。

結論：どのチームにどの方式が合うのか？

On-the-fly 画像リサイズは、もはやオプションではなく、
多様なデバイスと高いユーザー期待に応えるための 基本戦略 に近い存在です。

まとめ：

画像トラフィックが多く複数デバイスに対応 → On-the-fly はほぼ必須
インフラ運用に強い大規模チーム → Lambda@Edge
素早く導入し、運用負荷を軽減したい → Managed CDN
UGC・画像中心 SaaS・EC・プラットフォーム → On-the-fly + Managed CDN が最適バランス