LightFile Proxyは、CloudFrontにおける画像最適化オプションの標準的な地位を目指している。ただしAWSも公式にDynamic Image Transformation for Amazon CloudFront（以下DIT）を提供していて、画像をWebPに変換してCloudFrontから配信するという一点では同じことができる。CloudFormationのテンプレートが公開されていて、自分のAWSアカウントに建てられる。ソフトウェア自体は無料だ。
ただしDITは自前でシステムを構築する感覚に近く、LightFile ProxyのようにSaaS感覚では利用できない。初期設定や運用で相応に手間がかかることになる。
ここではLightFile Proxyの優位性と、逆にDITが有利な場面も見ていく。DITはv8.1.1（2026年9月時点）を対象にした。
連載「詳説 LightFile Proxy」
AWS CloudFrontの後ろに置いて、既存のサイトを変えずに画像をWebPで配信する仕組みを説明する連載。
DITは対応できるオリジンの種類が少ない
DITには2つの構成がある。Lambda版はS3の画像を変換する。2025年11月に加わったECS版はコンテナで常駐し、HTTPSのWebサーバーもオリジンにできる。
| オリジン | DIT Lambda版 | DIT ECS版 | LightFile Proxy |
|---|---|---|---|
| S3バケット | ○ | ○ | ○ |
| HTTPSのWebサーバー | × | ○（正規CAの証明書が必須） | ○ |
| HTTPのWebサーバー | × | ×（http://を拒否） | ○ |
| Hostを付け替えて取得 | × | 仕組みが無い | ○ |
| Basic認証のかかったオリジン | × | 送信ヘッダの欄に自分で組み立てて入れる | ○（専用の設定。パスワードは暗号化して保管） |
弊社が本番で預かっているオリジンをこの表に当てはめると、半数以上はDITに載せられない。http://のWebサーバーだからだ。
HTTPS化すれば済むと思われるかもしれないが、その先にもう一段ある。HTTP系のオリジンの9割近くは「接続先とは別のHostを付けて取りに行く」形で使っている（(8)）。CDNの裏にホスティング事業者のサーバーやALBがあり、公開ドメインのHostで来たリクエストしか正しく扱えない、という構成だ。DITのECS版にHostを付け替える仕組みはない。
Basic認証のかかったオリジンも事情は似ている。DITのECS版にはオリジンへ送るヘッダを自由に書ける欄があるので、そこにAuthorizationヘッダを自分で組み立てて入れれば通せる（保存先はDynamoDBで、AWSのマネージドキーで暗号化される）。Lambda版にはその欄がない。LightFile Proxyはユーザー名とパスワードを入れる専用の設定があり、パスワードは公開鍵で暗号化して保管し、ノードだけが復号する。
LightFile Proxyはオリジンごとに送るHostを指定でき、TLSのSNIと証明書検証もその名前で行う。既存のサイトへ後付けすることを前提にしているので、オリジンを作り変えてもらわなくて済むようにしてある。
なお画像がS3にある場合も、弊社はS3のAPI経由ではなくHTTPで取りに行く設定を勧めている。同じバケットの画像でも、公開のWebアクセスで取るほうが応答は速く、オリジン側の負荷も軽い。S3のAPIは呼ぶたびに署名が要り、TLSも必須になるが、公開のWebアクセスならどちらも要らないためだ。S3オリジンの設定も用意してあるので、公開したくないバケットならそちらを使う。
建てただけではWebPにならない
DITは既定で自動WebPが有効になっていない。
Lambda版は自動WebPのパラメータが既定で無効だ。ECS版はオリジン、マッピング、ポリシーがどれも0件の状態で建ち、登録するまで全リクエストが404になる。さらに既存のCloudFrontへ組み込む作業は手動で、オリジン・ビヘイビア・キャッシュポリシー・関数の関連付けを自分で行う。
LightFile Proxyは自動WebPが常に有効で、クラスタ側のルーティングは弊社が設定して引き渡す。お客様の作業はCloudFrontにオリジンとビヘイビアを足す3手順で、やめるときは設定を戻すだけになる。
変換に失敗したときに画像が欠ける
DITは変換に失敗するとエラーを返す。CloudFrontは5xxを10分キャッシュするので、その間は画像が欠けたままになる。Lambda版には代替画像を設定する項目があるが、既定では有効になっていない。
LightFile Proxyは変換に失敗してもオリジナルを返す。応答が遅くなったときや止まったときは、CloudFrontのオリジングループで本来のオリジンへ迂回させる（(6)）。軽量化よりも、画像が表示され続けることを優先した作りにしてある。後付けの仕組みを入れたせいで画像が出なくなる、という事態を導入した人に背負わせたくないからだ。
URLに変換を指示する口を守る必要がある
DITはURLに変換の指示を書く方式なので、そこが外から叩ける口になる。ECS版にはURL署名の仕組みがなく、全クエリがキャッシュキーに入るため、クエリを少しずつ変えるだけで新しい変換を何度でも走らせられる。AWS自身がドキュメントで「アプリ層のレート制限はない」と書いていて、WAFの併用を強く推奨している。
LightFile Proxyは変換の指示をURLに書かない。変換するかどうかはAcceptヘッダで決まり、取りに行けるのは設定済みのオリジンだけになる。守る対象がひとつ減るぶん、導入するときに考えることも減る。
運用の手間は自分たちに残る
DITはテンプレートが無料で配られるが、動かし続ける仕事は利用者に残る。
ECS版が登場したv8.0.0から10か月で8回のリリースがあり、そのすべてに脆弱性対応が含まれていた。更新を追うのは利用者の仕事になる。大改版のときは既存スタックから更新できず、新しいスタックを建ててトラフィックを移すことになる。ECS版にはダッシュボードやアラームが付いてこないので、監視も自分で作る。障害時にAWSへ問い合わせるにはBusiness Support以上の契約が要り、テンプレート自体は "as is" で提供される。
LightFile Proxyは弊社のAWSアカウントで動かしていて、構築・更新・監視・障害対応は料金に含まれる。実装をTypeScriptからGoへ全面的に入れ替えたときも、稼働中のクラスタを止めずに切り替えた。
正直なところDITのほうがよい場面
- 加工が要るとき。 リサイズ、切り抜き、スマートクロップ、透かし。LightFile Proxyにはない
- 初回からWebPで届けたいとき。 DITは同期変換なので最初のエンドユーザーにも変換済みが返る（(3)）
- アクセスの波が大きいとき。 DITは自動で伸縮する。LightFile Proxyのノード数は固定で、増やすには依頼が要る
- 画像を社外のサービスに通せないとき。 DITは自分のアカウントで完結する
- 画像がS3にあって、小〜中規模のとき。 Lambda版のAWS原価は安い
加工が要件なら、そちらを選んだほうがよい。サムネイルを作り分けたい相手にLightFile Proxyを勧めることはしていない。
測っていないこと
両者を同じ条件で動かして速度を測ってはいない。 ここに書いたのは、DITの公式ドキュメントとソースコードから読み取れる違いと、それを弊社の本番構成へ当てはめた結果になる。どちらが速いかは測っていないので書けない。