Back to posts

Cloudflare R2の使いどころ：画像とファイルの置き場

Published
CATEGORIES
Cloudflare
Tags
#Cloudflare #R2 #ストレージ

まず、このサイトの画像はR2に置いていない

このサイトは Astro で作っていて、ホスティングは Cloudflare Pages です。記事中の画像はリポジトリに一緒に入れて、ビルド時に astro:assets で最適化する形に寄せています。その最適化の組み立ては、Astroの画像最適化を標準の astro:assets に寄せるにまとめました。つまり、現時点では R2 は使っていません。

それでも使いどころを整理しておくのは、「リポジトリに置きたくないファイル」がブログ運営では必ず出てくるからです。配布用の大きな PDF、動画や音声、バックアップのアーカイブ。こうしたものの置き場として、同じ Cloudflare の中にある R2 は第一候補になります。この記事は、その線引きを決めるためのメモです。

R2は何者か

R2 は Cloudflare のオブジェクトストレージです。階層のあるファイルサーバではなく、「バケット」という入れ物に、キー（名前）を付けたオブジェクトを入れておくタイプのストレージで、Amazon S3 と互換性のある API を備えています。S3 向けの SDK やツールがそのまま使えるので、既存の資産や知識を持ち込みやすいのが特徴です。

もう一つの大きな特徴が、エグレス（データを外へ読み出す転送）料金がかからないことです。通常のクラウドストレージは「置く料金」に加えて「インターネットへ流す量」でも課金されますが、R2 はこの部分が無料になっています。この設計が、後述する「配布物置き」との相性の良さにつながります。

なお、バケットはデフォルトでは非公開です。置いただけでは誰もアクセスできず、公開するには後述の方法で明示的に口を開ける必要があります。

置き場の役割分担

自分のサイト向けに決めている線引きは、こうです。

置くもの置き場理由
記事内の写真・スクリーンショットリポジトリ＋astro:assetsビルド時にリサイズや形式変換が効く。記事と一緒にバージョン管理できる
OGP画像やファビコンなどサイトの部品リポジトリサイトのコードと一体のもので、単独で差し替える場面がほぼない
配布用の大きなPDF・資料R2（候補）リポジトリが膨らむ。画像のような最適化も不要で、差し替えはファイル側で吸収できる
動画・音声ファイルR2（候補）サイズが大きく、再生のたびに転送が発生する。エグレス無料が効く
バックアップやアーカイブR2（非公開）公開する必要がない。置き場をサイト本体と分けておきたい

原則は「迷ったらリポジトリ」。画像を R2 に逃がすと、ビルド時の最適化も、記事との一体管理も手放すことになります。R2 の出番は、リポジトリに置くこと自体が負担になるファイルに限る、というのが今の判断です。

料金の考え方：効くのは「配信しても増えない」こと

R2 の課金は、保管量（GB-月）と操作回数が中心です。操作は書き込み・一覧系の Class A と、読み取り系の Class B に分かれていて、エグレスは無料です。執筆時点で公式の料金ページを確認した無料枠は次のとおりです（料金は変わりうるので、導入前に公式ページで再確認してください）。

項目無料枠（月あたり）
保管（Standardストレージ）10 GB-月
Class A操作（書き込み等）100万回
Class B操作（読み取り等）1,000万回
エグレス（外向き転送）無料

個人ブログの規模なら、配布物を多少置いても無料枠に収まることが多いはずです。それ以上に大きいのは、「記事が読まれて転送量が増えたら請求が跳ねる」という心配をしなくて済む点です。アクセス数が読めない個人サイトにとって、配信量で料金が増えない設計は、金額そのもの以上に気が楽です。

公開方法は3択

バケットはデフォルト非公開なので、「どう見せるか」を選ぶ必要があります。大きく分けて3つです。

方法向いている用途注意点
カスタムドメインを接続して公開配布物など本番の公開ファイルCloudflare のキャッシュや WAF、アクセス制御が使える。本番用途はこれ
r2.dev サブドメインで公開動作確認・一時的な共有公式にも「本番用途ではない」と明記されている。キャッシュや WAF の細かい制御はできない
非公開のまま署名付きURLで渡す期限付きの配布、限定公開URL に有効期限（1秒〜7日）を付けられる。ただし発行処理がサーバー側に要り、カスタムドメイン経由では使えない

非公開＋署名付きURL は、「配布資料のダウンロードリンク」のような場面の選択肢です。URL を知っている人だけが、期限内にだけ落とせる形にできます。発行には R2 の API 認証情報を使うサーバー側の処理（Workers など）が要るので、静的サイト単体では完結しません。こうした認証情報の置き方については、Pages／Workersの環境変数と秘密情報の扱いで整理しています。

署名付きURL は、カスタムドメインを付けた公開バケットでは使えません。S3 API のドメイン経由でのみ発行できるので、「独自ドメインで公開したい」と「期限付きで渡したい」は両立しない、と覚えておく方が安全です。

出番があるケース、ないケース

最後に、個人ブログ目線での「本当に要るか」の切り分けです。R2 に逃がす価値があるのは、だいたい次の条件に当てはまるファイルです。

  • 1ファイルが数MBを超え、リポジトリの肥大化が気になる
  • 画像のようにリサイズや形式変換をしなくていい
  • 記事の文章と一緒にバージョン管理する必要がない
  • 読み取り（ダウンロードや再生）の回数が読めない

逆に、通常の記事画像まで R2 に出す必要はまずありません。astro:assets の最適化が効かなくなるし、画像 URL の管理という新しい手間が増えるだけです。「オブジェクトストレージがあるから使う」のではなく、「リポジトリに置くと困るものが出てきたら逃がす」。このサイトでも、大きな配布物を公開する予定が立った時点で、初めてバケットを作るつもりです。

参考

Tags Categories