AWS コスト削減 ──
VR 動画配信サービスの通信費を大幅削減ソース:S3 + CloudFront ／ 配信:Bunny.net × Perma-Cache 構成

1. 請求書を分解する ─ 3 つの無駄を特定

まずは実物を見てもらうのが早いです。これは 2026 年 4 月の請求(サービス別料金)のスクリーンショットです。課税前 $1,305.58、税込 $1,436.14(¥160/$ 換算で 約 23 万円)。

ただ、このサービス名(名目)だけ見ても、「何の転送なのか」「なぜデータベースにこれだけかかるのか」までは分かりません。各費目の中身を辿ると、削るべき 3 つの無駄がはっきりしました。

2. EC2(Amazon Linux 2023)にて VR 動画サービスを複製＆改修

コスト削減を急いで本番に手を入れるのは危険です。そこで 旧本番には一切手を加えず、新しい EC2 に VR 動画サービスを丸ごと複製してから、新環境側で改修・検証していく進め方にしました。新旧が並走するので、問題があればいつでも旧へ戻せます(止めない・壊さない)。全体は次の 3 弾構成で、本章はその 第 1 弾 ── 基盤の複製と改修です。

• 第 1 弾(本章・基盤刷新):新 EC2(Amazon Linux 2023 / Graviton)へシステムを複製し、PHP / CakePHP / DB を刷新して EOL を一掃。
• 第 2 弾(配信最適化):動画・画像を S3 へオフロードし、CDN で配信(第 3 章以降)。
• 第 3 弾(切替・撤去):Elastic IP の付け替えで本番切替 → 数日監視 → 旧 EC2 / RDS / 余剰 EBS を削除して削減を確定。

新サーバーを Graviton + Amazon Linux 2023 で立てる

新サーバーは Amazon Linux 2023、CPU は Graviton(ARM / t4g)。旧世代の t2.small から、低単価で効率の良いインスタンスへ置き換えます。swap を確保し、ミドルウェアは nginx / PHP 8.2 / MariaDB 11.4 を導入。OS から言語・フレームワークまで、EOL だった構成を現行サポート版へ一気に引き上げました。

DB は RDS から複製し、EC2 同居のローカル MariaDB へ

データベースは RDS から全 DB を複製し、新 EC2 に同居させた ローカル MariaDB へ移しました。移行後は 全テーブルの行数を新旧で照合して一致を確認し、文字コードを utf8mb4 へ昇格。日次バックアップ + 復元テストも整備しています。

RDS を廃止できたのは、元々 Multi-AZ などのマネージド HA を使っておらず、本番 DB の実データも数 MB 規模だったため。冗長機能が活きていない RDS に延命料まで払う状態を、ローカル DB へ畳みました。失う自動バックアップ/PITR は上記の自前バックアップで代替しています(着手前はバックアップ自体が止まっていたため、むしろ復旧体制の再建にもなりました)。

アプリを CakePHP 3.6 → 4.6 / PHP 7.2 → 8.2 へ改修

複製したアプリは、CakePHP 3.6 → 4.6・PHP 7.2 → 8.2 という大型バージョンアップ。破壊的変更(テンプレート構成・認証・ルーティング・ORM / Query API・エラーハンドラ・画像処理など)を段階的に解消しました。API 認証(JWT)は、サポートの切れた旧プラグインを firebase/php-jwt + 自作アダプタへ置き換え。ここで肝心なのは、API の URL とレスポンスは一切変えていないこと ── 更新できない VR 再生クライアントに影響を出さないためです。

URL / API 契約は一切変えない

最大の制約は、インストール済みで更新できない VR 再生クライアントが参照する …/upload/… の URL と API レスポンスを 変えられないことでした。そこで 配信先の振り分けはサーバー内部(nginx)で行い、アプリが返す URL は据え置きに。これにより クライアントに影響を与えずに配信先を差し替えられる状態を作っています。この「疎結合にしておいた」判断が、のちの配信先の入れ替え(第 3 章以降)を無改修で可能にしました。

3. 配信先を 3 回変えた ─ S3+CloudFront → R2 見送り → Bunny.net

配信費(egress)が最大要因 ── これを下げにいったのですが、ここからが本件の試行錯誤でした。配信先は結果的に 3 回変わっています。

4. 最終構成 ─ Bunny × オリジン=CloudFront × Perma-Cache

辿り着いたのは、役割を明確に分けた 3 層構成です。一見すると遠回りに見える「Bunny のオリジンに CloudFront を挟む」形に、二つの利点があります。

[利用者 / VR アプリ]
        │  https://…/upload/…(従来どおりの URL)
        ▼
[Bunny.net CDN]    … 利用者への配信。低単価・Perma-Cache で永続保存
        │  (Bunny に無い場合のみ取得)
        ▼
[Amazon CloudFront] … 取得の窓口。AWS 無料枠(月 1TB)でほぼ $0
        │
        ▼
[Amazon S3]        … 動画/画像の唯一の正(永続保存の本体)

3 つの層の役割

動作(探索順)

利用者のリクエストは、上から順に探索されます。

1. Bunny エッジに HIT すれば即配信。
2. MISS でも Perma-Cache にあればそこから配信。
3. どちらにも無ければ CloudFront 経由で S3 から取得し、取得したものを Perma-Cache へ永続保存。以降このファイルはオリジンへ取りに行かない(取得は原則 1 回)。

なぜ S3 + CloudFront を併用するのか

配信そのものは Bunny に任せます。正直なところ、Bunny.net だけで完結させた方が構成はシンプルです。それでも裏側(オリジン)に S3 と CloudFront を残して併用しているのは、動画の正本を AWS 側(S3)に持っておく方が、バックアップとして信頼できると考えたからです。S3 を唯一の永続保存(正)とし、Bunny や CloudFront はあくまで使い捨てのキャッシュ ── データの拠り所を S3 ひとつに集約しておけば、キャッシュが消えても S3 から作り直せます。

ただし S3 を直接インターネットへ公開するのは避けたい(意図しないアクセスや余分な egress 課金を防ぐため)。そこで S3 はパブリックアクセスを閉じたまま、CloudFront だけが取得できる窓口にしました。保存は S3・取り出しは CloudFront と役割が分かれ、しかも CloudFront には AWS 無料枠(月 1TB)が使えます。この S3 + CloudFront のセットは、Bunny.net で障害が発生した際に nginx の設定を切り替えることで、そのまま 全動画を保持したフォールバック経路にもなります。

なぜオリジンを S3 直ではなく CloudFront にするのか

ここが構成の肝です。Bunny のオリジンに CloudFront を挟むことで、二つの利点が生まれます。

Bunny.net の設定

オリジンに CloudFront を指定する際は、Host ヘッダを配信ドメインに一致させるのが要点です(不一致だと CloudFront が 403 を返します)。

5. 動作確認(E2E)─ 760MB 動画で MISS→pull→HIT を実機確認

構成を組んだら、実データで端から端まで通します。あえて条件が厳しめのファイル ── まだ一度も取得されていない、日本語名 + スペース入りの 760MB 動画 ── を選び、探索のすべての分岐を 1 回で踏ませました。

MISS → pull → 200、Range → 206、再アクセスで HIT、そして Perma-Cache の実体生成まで一気通貫で確認できました。シーク再生に必須の部分取得(206)が効くこと、日本語ファイル名でも破綻しないことが分かり、本番投入の前提が揃ったことになります。

6. コスト試算 ─ 通信費の圧縮で月額を大幅削減

ここまでの構成変更を積み上げると、月額の見込みは次のようになります。「従来」は 2026 年 4 月の実請求、「新構成」は月 4TB 配信を前提とした試算です(¥160/$ 換算。実費はトラフィックで変動します)。

金額が下がる最大の理由は、単価そのものの差です。とくに 配信 egress と 保管は、配信元・保管先を変えるだけで GB あたりの単価が桁で変わります(いずれも目安)。

※ RDS の延命料(Extended Support・月およそ $229)と旧世代 EC2 は、単価ではなく 廃止・刷新で削っています。

7. 運用の形 ─ アップロード / 更新 / 削除 / バックアップ

コストと並んでもう一つの着地点が、日常運用が無理なく回る形にまとまったことです。アップロードから削除まで、それぞれが自動で完結します。

削除時のパージには 安全装置を入れています。認証情報が未設定なら無動作(no-op)、パージに失敗してもログを残すだけで 削除本体は止めません。取りこぼしは整理バッチで回収できるため、配信の更新・削除フローが運用で破綻しないようにしています。

8. フェイルオーバーと即ロールバック

• CDN(Bunny)障害時:サーバー設定の変更 1 箇所で、配信先を Bunny → CloudFront 直へ即時切替。CloudFront + S3 は全コンテンツを保持しているため、全動画の配信を途切れさせずに継続できます。戻しも即時。
• 切替先は常時検証済み:前述のとおり、平常時も Bunny は CloudFront 経由で取得しているため、フェイルオーバー先が日々の実トラフィックで動作確認され続けています。
• データ消失リスクなし:永続保存は S3 のみが正で、CloudFront / Bunny は使い捨てキャッシュ。消えても/消しても S3 から再生成されます。
• サーバー切替:本番サーバーの切替・切戻しは Elastic IP の付け替えのみ。DNS 変更を伴わず、即時ロールバックできます。

「安く配信する」だけでなく、止まらない・戻せる・消えないを構成の中に織り込んだことで、コスト削減と安定性を同時に成立させています。

9. 学び・はまりどころ

• 請求書は分解してから読む:名目(サービス別合計)では削りどころは見えない。各費目の中身(何の転送か / 何にかかる DB 費か)まで辿って初めて、転送・保管・延命料という輪郭が出る。
• CDN を入れれば自動でコストが下がるわけではない:キャッシュはオリジン往復を減らすが、利用者への配信 egress は CDN からも課金される。単価構造を見て「本丸が動くか」を確かめる。
• 規約のグレーは本番前に潰す:egress 無料などの目先のメリットがあっても、サポートが可否を明言しない状態は事業リスク。検証が通っても規約で止める判断はあり得る。
• オリジンに無料枠を挟む利点は二つ:Bunny のオリジンを CloudFront にすると、取得を無料枠で吸収しつつ、切替先を常時検証できる。
• URL を疎結合にしておくと差し替えが効く:配信先をアプリの URL に直書きせず、サーバー内部の振り分けにしておいたことで、配信基盤を入れ替えても無改修で済んだ。
• 長時間バッチはセッション切断で死ぬ:1.7TB 同期のような長時間処理は、SSH セッションが切れた瞬間に OS 側でプロセスごと掃除されることがある。リンガー有効化や systemd ユニット化で恒久化する(同期は冪等なら再開できる)。
• キャッシュは「上書きしない設計」で事故を防ぐ:固定の一意パスで管理し差し替えを新パスにすると、パージ不要で更新が反映され、キャッシュ運用の事故が起きにくい。