R2とD1で実現する「エグレス料金ゼロ」とコスト最適化

Web運営の見えにくいコストを削って、アクセスが増えるほど儲かる構造へ

この記事の目次
  1. 「成功するほどコストが増える」エグレス料金の罠
  2. R2の最大の特徴は完全ゼロのエグレス料金
  3. D1は、構造化データをサーバーレスで扱う
  4. すべてをCloudflareへ移せば必ず安くなるというわけではない
  5. マーケターが見るべきなのは「何が安くなり、何の工数がなくなるのか」
  6. DOMOの視点
  7. まとめ
  8. 第5章の総括
  9. 覚えておきたい用語

Webサイトやシステムのインフラ費用というと、まず「毎月のサーバー代」を思い浮かべる人が多いでしょう。しかし、商品画像や動画を多く扱うECサイト、大量の画像やダウンロード資料を配信するメディアを運営している企業において、実際に請求書の金額を膨張させているのはサーバー代だけではありません。

ユーザーは、商品画像を閲覧し、動画を再生し、ホワイトペーパーやPDFカタログをダウンロードします。そのたびにデータがクラウドから外へ送り出され、サービスによっては、その転送量に応じて従量課金が発生します。特に見落とされやすいのが、クラウドからインターネット側へデータを送信する際にかかる「データ転送料(エグレス料金)」です。

アクセスが増え、サイトがバズり、多くのユーザーにコンテンツが届くことは、マーケティングやビジネスにとって最大の成功であるはずです。しかし、利用者が増えれば増えるほどデータ転送料が雪だるま式に跳ね上がり、インフラ費用に利益が削られてしまうとすれば、それは健全な成長モデルとは言えません。

この節で解説する「Cloudflare R2」は、こうしたクラウドストレージの歪んだコスト構造を打破するための切り札となるオブジェクトストレージです。さらにサーバーレスデータベース「Cloudflare D1」を組み合わせることで、画像や動画などの単純なファイルだけでなく、Webアプリで扱う複雑な構造を持ったデータまで含めて、インフラコストを劇的に最適化できます。

マーケターや決裁者が細かな技術仕様を覚える必要はありません。重要なのは、「自社ではどのデータが、どのように動き、アクセスが増えたときにどの費用が増加するのか」というコスト構造を理解する視点を持つことです。

「成功するほどコストが増える」エグレス料金の罠

アクセスが比較的少なく、内容もテキスト中心の小規模なコーポレートサイトであれば、毎月のクラウド費用はほぼ一定で、大きな問題にはならないでしょう。しかし、ビジネスが成長し、ECサイトやオウンドメディアの規模が拡大すると状況は一変します。

以下のように、容量が大きいデータの扱いが増えてくるからです。

  • ECサイトの場合: 高解像度の商品写真、利用イメージ動画、商品カタログ、PDF取扱説明書、ユーザー投稿画像
  • メディア、BtoBサイトの場合: 高画質記事画像、音声・動画コンテンツ、ホワイトペーパー、セミナー資料

こうした大容量ファイルをクラウドストレージに保存して配信する場合、一般的なクラウド(AWS S3など)では「データを保存している容量(GB)」だけでなく、「ユーザーへ向けてデータを配信した転送量(GB)」に対しても課金が発生します。それが「エグレス料金」です。

大容量のファイルを何万人、何百万人ものユーザーへ繰り返し配信するサービスでは、保存費用よりも、このデータ転送料の方が遥かに高額になるケースが珍しくありません。

「マーケティング施策が成功してPVや売上が伸びた結果、クラウドの請求書を見て青ざめる」。このジレンマから抜け出すためには、「サーバーが月額いくらか」だけでなく、自社のデータがどれくらい外部へ流れているかを把握する必要があります。

R2の最大の特徴は完全ゼロのエグレス料金

Cloudflare R2は、画像、動画、PDF、バックアップなどのファイルを安全に保存するオブジェクトストレージです。業界標準のAmazon S3と高い互換性を持つAPI(S3互換API)を備えているため、すでにS3向けに作られている既存のツールやプログラムを活かしながら、スムーズに移行・連携できる設計になっています。

そして、R2の最大の特徴であり、業界に衝撃を与えたのが、インターネットへのデータ送出にかかるエグレス料金が「完全無料(ゼロ)」という料金体系です。R2のStandardストレージでは、主に「データの保存容量(2026年9月時点で1GBあたり月額0.015ドル)」と、「APIによるデータの読み書き回数」に対してのみ料金が発生します。どれだけ多くのユーザーへ、どんな容量の画像や動画を配信しても、データ転送量そのものに対する追加課金は一切発生しません。

例えば、同じ100GBの画像データをサイト内に保存している場合でも、月に数百人にしか見られないサイトと、月に何百万回も閲覧される人気サイトでは、外部へ送り出されるデータ量は桁違いです。一般的なクラウドストレージではアクセス増加に伴って転送費用が膨らみ続けますが、R2であれば「どれだけ配信されたか」による追加コストに怯える必要はありません。

出典: Cloudflare Docs: R2 overview

出典: Cloudflare Docs: R2 pricing

D1は、構造化データをサーバーレスで扱う

R2が、画像や動画などの単純なファイルを保存する場所であるのに対し、「Cloudflare D1」は、構造化されたデータを保存し、要求に応じて取り出せるようにするものです。Cloudflare D1は、Cloudflareのグローバルネットワーク上で動作するサーバーレスのSQLデータベースというわけです。

整理しましょう。

  • R2: 画像、動画、PDF、音声など「大容量のファイルアセット」の保存
  • D1: 商品データ、記事情報、キャンペーン応募データ、ユーザー設定など「構造化データ」の保存

マーケターがSQLやデータベースの内部構造を理解する必要はありません。押さえておくべきなのは、D1を利用すれば、「常時起動」のデータベースサーバーを契約し、管理しておく必要がなくなる、という事実です。

従来のデータベース運用では、アクセスが少ない夜間や休日であっても、専用のデータベースサーバーを常に立ち上げて、維持費を払い続けるのが普通でした。D1では、読み込んだ行数、書き込んだ行数、保存データ量に応じた従量課金モデルが採用されており、処理が走っていない待機時間の費用はかかりません。さらに、データ転送料自体は、R2同様D1でも無料です。

Workersと直結して、エッジから超低遅延でデータを読み書きできるため、小規模なキャンペーンシステムやWebアプリのために専用のDBサーバーを維持、管理する手間とコストを大幅に省くことができます。

出典: Cloudflare Docs: D1 overview

出典: Cloudflare Docs: D1 pricing

すべてをCloudflareへ移せば必ず安くなるというわけではない

R2のエグレス料金ゼロ、という強烈なメリットを知ると、「今あるAWSのデータをすべてR2へ移せば大幅にコスト削減できるはずだ」と考えがちです。しかし、インフラコストの最適化はそれほど単純な話ではありません。

自社のデータ通信実態によっては、以下に挙げるように、移行しても期待したほどのコスト削減効果が出ない場合もあります。

  • もともと画像や動画の配信量が少ないサイト: 削減できるエグレス料金自体が小さいため、移行の手間に見合わないケース
  • 既存のAWS環境と深く連携している基幹システム: ストレージ単価だけで安易に移行すると、かえって移行工数やシステム間の通信で余計なコスト、運用負荷がかかるケース

また、R2はS3互換APIを提供しているものの、S3の持つすべての高度な機能(詳細な権限管理やライフサイクル機能など)と、100%完全な互換性があるわけではありません。

重要なのは、「安いからすべて置き換える」と単純に考えるのではなく、自社の現在の請求書の中で、何が一番コスト高の原因になっているかを正確に把握することです。

画像や動画の配信量が飛び抜けて多い領域(メディアの画像配信、ECの商品写真、PDF配布など)だけをピンポイントでR2へ移行させるなど、既存のクラウドと共存させる「ハイブリッドな適材適所」が、最も賢い選択肢となる場合も多いはずです。

マーケターが見るべきなのは「何が安くなり、何の工数がなくなるのか」

R2、D1、KVといった技術の名前と、その概要を知っただけでは、マーケティングの意思決定に直接役立つことはあまり多くないでしょう。マーケターやビジネス決裁者としては、これらの基盤を導入することで「何の費用が下がり、現場のどの運用作業をなくすことができるのか」というところまで理解することが重要です。

以下のように現状の問題ごとに整理して考えることができます。

  • 画像、動画のデータ転送料が重い: R2の導入による配信コストの抜本的な削減
  • 施策ごとにDBサーバーを立てる手間がかかっている: WorkersとD1の組み合わせによる、準備期間と維持費のゼロ化
  • アクセス急増に備えてエンジニアが監視、対応に追われている: サーバーレス化による、インフラのお世話工数そのものの解消

インフラコストは、クラウドの利用明細に記載されている数字だけではありません。エンジニアがインフラの設計、監視に割いている時間や、月末に請求予測を行う管理工数、トラブル対応の工数まで含めた「トータルの人件費」まで考慮したものが、真のコストなのです。

事業が伸びたときに、どの費用と運用負荷は増えずに済むのか、と問うてみることこそがインフラコスト最適化の要です。

DOMOの視点

クラウド単価ではなく、アクセス増加とともに何が増えるかを見極める

DOMOとしてインフラやストレージのコストを検討する際、「R2はエグレス無料なのでS3から乗り換えましょう」と単純な乗り換えを提案することはありません。最初に確認させていただくのは、「お客様の現在のインフラ請求書の中で、何に一番費用がかかっているか」というコスト構造の分析です。

  • データを大量に保存していること自体(ストレージ容量)
  • ユーザーへ大量に配信していること(データ転送量)
  • サーバーの常時稼働やスペック維持(コンピュート費用)
  • 障害監視や設定変更など、運用している人件費

このように、どこにコストの課題があるかによって、打つべき手はまったく異なります。

画像や動画、ダウンロード資料を大量に配信していて、データ転送費(エグレス料金)が利益を圧迫している企業であれば、R2の導入は極めて劇的なコスト削減効果をもたらすでしょう。一方で、転送量が少ないサイトであれば、無理に移行しても開発工数に見合うリターンは得られません。

単純に「安いサービスへ乗り換える」ことではなく、「事業がスケールしたときに、コストと運用が無理なく追いつくアーキテクチャを選ぶ」ことこそが、DOMOが提唱する開発基盤とインフラコスト最適化の基本姿勢です。

まとめ

Cloudflare R2とD1は、大容量ファイルと構造化データの保存、配信において、従来のクラウドが抱えていたコストと管理の無駄を取り除く可能性を備えた強力な基盤です。

  • エグレス料金ゼロのR2: データ転送料(外部送信費)がかからないため、画像や動画、PDFを大量に配信するECやメディアのインフラ費用を劇的に抑制
  • サーバーレスSQLデータベースのD1: 専用のDBサーバーを常時稼働させることなく、使った分だけの従量課金で軽量なデータ処理をWorkersと一体で実現
  • コスト構造を見極めて適材適所で使う: すべてのシステムを一括移行するのではなく、自社の請求書のどこが高騰しているかを分析し、部分的なハイブリッド構成から活用

自社のWebインフラにおいて、最初は見えにくいものの、アクセスが増えるほど膨らんでいるコストはないでしょうか。まずは現在のクラウド請求書の内訳の検討から始めましょう。

第5章の総括

技術を追うのではなく、事業の柔軟性を整える

この第5章では、Cloudflareの開発基盤(Developer Platform)について、以下の3つの節に分けて見てきました。

  • 28節: サーバーのお世話から解放され、施策を最速で公開する「Cloudflare Workers」
  • 29節: エッジでの配信と処理により、表示速度を極大化してCVRとSEOを引き上げる「Pages & Workers」
  • 30節: エグレス料金ゼロとサーバーレスDBで、アクセス増加に伴うインフラコストを最適化する「R2」と「D1」

Workers、Pages、R2、D1といったサービスは、一見するとエンジニアが好物の専門性の高い技術に見えるかもしれません。しかし、ビジネスの視点から捉え直せば、それらはすべてマーケティング施策を効率的に世に出すための手段にほかなりません。アクセス集中に耐え、事業が急成長してもコストが跳ね上がらない、柔軟性の高い事業の基盤を整えるものです。

開発基盤の進化を知り、課題解決のために適材適所で技術を選択することも、変化の激しいデジタルマーケティングを勝ち抜くための強力な武器となるでしょう。

覚えておきたい用語

  • Cloudflare R2: 画像、動画、PDFなどのファイルを保存できるCloudflareのオブジェクトストレージ
  • Cloudflare D1: Workersなどから利用できるCloudflareのサーバーレスSQLデータベース
  • オブジェクトストレージ: 画像や動画などのファイルを大量に保存するためのストレージ方式
  • エグレス料金: クラウドからインターネットなど外部へデータを転送するときに発生する料金
  • S3: Amazon Web Servicesが提供する代表的なオブジェクトストレージサービス
  • S3互換API: S3向けに作られたツールやプログラムから、似た方法でR2を操作できる仕組み
  • SQL: データベースに保存された情報を検索、追加、更新するための言語
  • サーバーレス: サーバーの台数やOSなどを直接管理せずにシステムを動かせる仕組み

この章のほかの記事