S3 の転送料金が毎月数千ドル？R2 へ 3 ステップで移行し 90% 削減（実例付き）

AWS の請求書を見ると、保管料は $230 なのに転送料が $4,500——50TB の転送が走ると、財布が一気に軽くなります。動画や画像ホスティングをやっている知人に聞いても、みんな S3 の転送料に苦しんでいます。SaaS を運営する友人は、月 10TB の転送で S3 請求が $891。保管料は $15 だけなのに、転送料が 98% を占めているそうです。

Cloudflare R2 に替えると？出口転送料ゼロ。同じ 10TB でも R2 は保管料 $15 だけ。この記事では、実際のコスト試算、API 互換性の実測、30 分でできる移行手順、そして踏んだ落とし穴を共有します。アプリの転送が大きい（月 500GB 超）なら、年間数千〜数万ドルの節約につながります。

なぜ S3 から R2 へ？数字で見る

S3 の隠れコストの罠

AWS の価格設定は巧妙です。保管料 $0.023/GB は安く見えて、「お、手頃だ」と思いがち。でも転送が走ると、出口転送料 $0.09/GB が本丸になります。

計算してみましょう。動画サイトで 10TB 保管、月 50TB 転送（視聴・ダウンロード）の場合：

• 保管料：10TB × $23/TB = $230/月
• 転送料：50TB × $90/TB = $4,500/月
• 合計：$4,730/月

見ましたか？転送料が 95%。$0.09/GB 換算でも、小規模ユーザーは割引すらありません。

画像ホスティングをやる知人は月 20TB 転送で、年間 S3 請求 $20,676。「保管は $276、残り全部転送料。AWS に働いている気分」とぼやいていました。

R2 のコスト優位性

Cloudflare R2 の最大の武器は、出口転送料ゼロ。

値下げではなく、無料です。1TB でも 100TB でも $0。転送の大きいアプリにとっては救命縄です。

内訳：

• 保管料：$0.015/GB、つまり $15/TB（S3 より 35% 安い）
• 出口転送料：$0（S3 は $90/TB）
• 操作料：Class A $4.50/100 万回、Class B $0.36/100 万回

無料枠もあります：

• 10GB 保管
• Class A 100 万回（書き込み・リスト）
• Class B 1000 万回（読み取り）

個人ブログや小規模プロジェクトなら、無料枠内で収まることも。

実例比較（計算だけでなくデータを見る）

3 つの典型シナリオで比較しました。

SaaS アプリの行、見えましたか？同じ要件で R2 は年 $10,896 節約。スタートアップならジュニアエンジニア 1 人分の給与に相当します。

動画 PF はさらに年 $54,960。このお金を広告や採用に回した方が、よっぽど効きます。

移行をあきらめた方がよいケース

メリットばかりではありません。R2 が向かない場面も正直に書きます。移行して合わなければ、こちらのせいにされます。

1. AWS エコシステムに深く依存：Lambda、Athena、EMR などを多用していると、R2 移行でコード変更が多く、割に合わない。
2. 高度なコンプライアンス機能が必須：S3 の Object Lock、Legal Hold。金融・医療では必須のことも。R2 は現時点で未対応。
3. 転送が極小：月 100GB 未満なら節約は数十ドル程度。ビジネスに集中した方がよい。
4. データ所在地の要件が厳しい：S3 は 33 リージョン、R2 は location hint があるものの選択肢は少ない。特定国（中国、ロシアなど）保管が必要なら、R2 が要件を満たすか先に確認。

私の判断基準：月 500GB 超なら移行 ROI は十分。それ以下はコスト感度次第です。

R2 と S3 の API 互換性の実態（落とし穴付き）

R2 はどこまで互換か

いちばん気になるのはこれです。R2 に移行するとアプリが落ちる？コードをどれだけ直す？

実測の結論：R2 は S3 API の 80〜90% のコア機能を実装しており、日常使う操作はほぼすべてサポート。

Cloudflare は S3 API のうち最も使われる部分を実装しています：

• 基本操作：PutObject、GetObject、DeleteObject、ListObjects（使用の 99% を占める）
• 高度機能：Multipart Upload（大ファイル分割アップロード）、Presigned URLs、CORS 設定
• 権限管理：Bucket policies、IAM 形式のアクセスキー

うれしいのは、endpoint URL と credentials を変えるだけで、コードはほぼそのまま動くこと。

例：AWS SDK for JavaScript のプロジェクトでは、R2 移行で変えたのは 3 行だけ：

// 元の S3 設定
const s3 = new AWS.S3({
  region: 'us-east-1'
});
// R2 へ移行（endpoint と credentials のみ変更）
const r2 = new AWS.S3({
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  accessKeyId: R2_ACCESS_KEY_ID,
  secretAccessKey: R2_SECRET_ACCESS_KEY,
  signatureVersion: 'v4',
});

アップロード・ダウンロード・削除のコードは一切変更なし。そのまま動きました。2 週間テストして、互換性の問題は見つかりませんでした。

非対応機能（落とし穴注意）

R2 は S3 の完全代替ではありません。移行前に、アプリが以下を使っていないか必ず確認してください。

1. S3 Select（オブジェクトへの SQL クエリ）

S3 Select で S3 上直接 SQL を実行している場合、R2 非対応。先にダウンロードしてからクエリするか、別案が必要です。

2. Object Lock と Legal Hold（コンプライアンスロック）

金融・医療で WORM（Write Once Read Many）要件に使われることが多い。R2 は現時点で未対応。監査で必須なら移行を見送ってください。

3. Versioning（バージョン管理）

S3 のバージョン管理は R2 では限定的。バージョン巻き戻しに依存しているなら、十分にテストを。

4. 一部の高度クエリ・分析機能

S3 Inventory、S3 Object Lambda などは R2 非対応。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

移行前のおすすめ：アプリが使う S3 機能をリストアップし、Cloudflare 公式の API 互換性リストと照合。大半のアプリは基本機能だけなので、問題ないはずです。

ツール互換性の実測

よく使うツールを試しました。結論、ほぼシームレスに切り替え可能です。

注意点：rclone は v1.59 以上。古いバージョンは認証で問題が出ます。

私が踏んだ落とし穴

移行時の失敗談を 1 つ。ListObjectsV2 API で StartAfter パラメータを使ったページネーションを実装していたアプリがあり、R2 移行後にページングの挙動が微妙に違い、一部データが漏れました。

原因は R2 のページネーションが S3 と若干異なること。ContinuationToken に切り替えたら正常化。

教訓：移行後は十分にテストを。正常系だけでなく、境界条件もカバーしてください。

3 つの移行方式比較：自分に合う方法を選ぶ

Cloudflare 公式ツールが 2 つ（Super Slurper と Sippy）、コミュニティでは rclone なども。どれを選ぶ？シナリオ次第です。

方式 1：Super Slurper（初心者向け・一括移行）

Cloudflare 公式のワンクリック移行ツール。「とにかく全部 R2 に運びたい」向け。

メリット：

• フォーム入力だけで開始
• メタデータ（metadata、content-type など）を保持
• ソースデータは削除しない、リスク低
• 無料（R2 の Class A 操作料のみ、安い）
• 2024 年のアップグレードで速度 5 倍

デメリット：

• 一括移行のみ、増分同期なし
• 移行中に S3 へ新規アップロードされたファイルは R2 に自動同期されない
• 単一オブジェクト 50GB 未満向き（超大ファイルは注意）

向いている人：

• データ 10TB 未満
• 短時間の停止が可能（または未本番）
• 移行後は R2 に完全切替

最初の移行プロジェクトは Super Slurper。100GB で約 30 分。深夜 3 時のメンテナンス枠を取って、ユーザーはほぼ気づきませんでした。

方式 2：Sippy（ゼロダウンタイム・段階移行）

Cloudflare のスマート移行。停止不要が最大の特徴。

仕組み：

アプリを R2 に向けると、ユーザーがファイルをリクエストしたとき：

1. R2 にファイルがあるか確認
2. あればそのまま返す（高速）
3. なければ S3 から取得し、R2 にコピー。次回から R2 配信

データは按需で移行。アクセスの多いホットデータから先に R2 へ。

メリット：

• 完全ゼロダウンタイム、ユーザー無感知
• ホットデータ移行後は S3 転送料も削減
• 移行しながら様子を見て、問題あれば S3 に戻せる

デメリット：

• 初回アクセスは S3 取得分だけ遅い
• 設定がやや複雑、アプリ設定の変更が必要
• アクセスパターンがはっきりしている場面向き（ホット／コールドが明確）

向いている人：

• 本番停止不可
• データ量が巨大（10TB 超）、一括移行に時間がかかりすぎる
• R2 の安定性を試してから完全切替したい

CDN 加速サービスをやる友人は Sippy で 50TB を移行。ユーザーにサービスしながら 2 か月かけて完了。ビジネスへの影響ゼロでした。

方式 3：rclone（ギーク向け・最も柔軟）

オープンソースのクラウド同期ツール。最強だが CLI 操作が必要。

メリット：

• 完全無料・オープンソース
• 断点再開（回線不安定でも OK）
• 定期同期（毎日深夜に増分同期など）
• 整合性検証（MD5、SHA256）
• 帯域制限可能

デメリット：

• CLI 操作、学習コストあり
• 進捗管理用スクリプトを自分で書く
• 転送中は S3 出口転送料が発生（ただし AWS は 2024 年 3 月から移行離脱トラフィックを無料化）

向いている人：

• 技術力があり、移行プロセスを完全制御したい
• 継続同期が必要（S3 と R2 をしばらくデュアル運用）
• データ整合性を最優先

私は rclone が好きです。スクリプトで自動化でき、詳細ログも見られます。移行時のコマンド例：

rclone copy s3:my-bucket r2:my-bucket \
  --progress \
  --checksum \
  --transfers 32 \
  --s3-chunk-size 64M

--checksum で各ファイルの MD5 を検証。--transfers 32 で 32 並列、速度も十分。

クイック判断：どれを選ぶ？

判断フロー：

停止できる？
├─ はい → データ 10TB 未満？
│      ├─ はい → Super Slurper（最も簡単）
│      └─ いいえ → rclone（高速・制御可能）
└─ いいえ → Sippy（ゼロダウンタイム）
技術力あり＋完全制御 → rclone

大半の人は Super Slurper で十分。本当に 1 秒も止められない、または 50TB 超のデータ量でなければ、Super Slurper のシンプルさが他方式の柔軟性に勝ります。

実践：30 分でゼロリスク移行（Super Slurper 編）

理論はここまで。Super Slurper を例に、手順を追います。設定は 30 分以内（転送時間は別）。

ステップ 1：準備（5 分）

1. Cloudflare アカウント登録と R2 有効化

Cloudflare ダッシュボード で登録し、サイドバーの「R2 Object Storage」から有効化。

注意：R2 はクレジットカード登録が必要ですが、無料枠内なら小規模プロジェクトは $0 のことも。

2. R2 bucket を作成

「Create bucket」をクリック：

• Bucket 名（S3 と揃えると管理が楽）
• Location hint（コンプライアンスで EU 指定などが必要なら EU、それ以外は Automatic）

⚠️ 重要：Location hint と jurisdictional restrictions（管轄制限）は一度選ぶと変更不可。大半の場合 Automatic で十分。

3. AWS で読み取り専用 IAM ユーザーを作成

メインアカウントのキーは使わないでください。セキュリティリスクが大きすぎます。

AWS IAM コンソール → Users → Add User：

• ユーザー名：r2-migration-readonly
• Access type：Programmatic access
• Permissions：Attach existing policies directly → 「AmazonS3ReadOnlyAccess」

より安全なカスタムポリシー（特定 bucket のみ）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

作成後に Access Key ID と Secret Access Key が表示されます。必ずコピーして保存。1 回しか表示されません。

4. R2 API Token を生成

Cloudflare R2 → Manage R2 API Tokens → Create API Token：

• Token 名：migration-token
• Permissions：Object Read & Write
• 先ほど作成した bucket を選択

同様に Access Key ID と Secret Access Key が発行されます。保存しておいてください。

ステップ 2：移行実行（設定 15 分）

1. Data Migration 画面へ

R2 コンソール右上「Data Migration」→「Migrate Files」。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

2. Super Slurper を選択

Super Slurper と Sippy が表示されます。一括移行なら Super Slurper。

3. ソース bucket 情報（S3）

• Provider：Amazon S3
• Bucket name：S3 bucket 名（例：my-images）
• Bucket region：S3 リージョン（例：us-east-1、S3 コンソールで確認）
• Access Key ID：IAM ユーザーの Access Key
• Secret Access Key：対応する Secret Key

「Verify Connection」をクリック。成功すると緑のチェック。

4. ターゲット bucket 情報（R2）

• Bucket name：R2 で作成した bucket 名
• R2 Access Key ID：R2 API Token の Access Key
• R2 Secret Access Key：対応する Secret

5. 移行オプション

• Overwrite existing objects：既存ファイルを上書きするか（推奨：オン）
• Path prefix（任意）：S3 の特定フォルダだけ移行する場合（例：images/）

6. Review して移行開始

設定を確認し、「Start Migration」。

7. 転送完了を待つ

進捗表示：

• 転送速度
• 移行済みファイル数
• 残り時間の見積もり

所要時間の目安：

• 100GB → 約 30 分
• 1TB → 約 4〜6 時間
• 10TB → 約 2〜3 日

ページを閉じてもバックグラウンドで継続。いつでも進捗を確認できます。

ステップ 3：移行結果の検証（10 分）

移行完了後、すぐ S3 データを消さない。先に検証を。

1. オブジェクト数

R2 コンソールで bucket を確認：

• S3 オブジェクト数：X 個
• R2 オブジェクト数：X 個

一致していれば OK。不一致なら失敗ログを確認。

2. ファイル整合性の spot check

ランダムに数ファイルをダウンロードし、MD5 を比較：

# S3 ファイルの MD5
aws s3api head-object --bucket my-bucket --key test.jpg --query 'ETag' --output text
# R2 ファイルの MD5（rclone または直接ダウンロードで比較）
rclone md5sum r2:my-bucket/test.jpg

ETag が一致すればファイルは完全です。

3. ファイルアクセステスト

R2 の Public URL または API で数ファイルにアクセスし、正常にダウンロードできるか確認。

4. メタデータ確認

カスタム metadata が失われていないか：

aws s3api head-object --bucket my-bucket --key test.jpg
# R2 の metadata と比較

ステップ 4：アプリを R2 に切替

検証 OK なら切替開始。一気に全量切替せず、カナリア推奨。

1. アプリ設定を変更

環境変数で S3 を設定している例：

# 元の S3 設定
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=xxx
S3_SECRET_KEY=xxx
S3_REGION=us-east-1
# R2 設定へ
S3_ENDPOINT=https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=R2_xxx
S3_SECRET_KEY=R2_xxx
S3_REGION=auto  # R2 は auto で OK

2. カナリアテスト

まず 10% トラフィックで試し、エラーがないか確認：

• アプリログ
• エラー率
• ユーザーフィードバック

問題なければ 10% → 50% → 100% と段階的に。

3. 主要指標を監視

移行後は特に注意：

• API エラー率
• レスポンス時間
• 転送料金（大幅に下がるはず）

4. S3 バックアップを保持

S3 データは 30 日保持を推奨。R2 が安定してから削除。AWS は 2024 年 3 月から移行離脱トラフィック無料なので、削除コストもほぼゼロ。

自動削除するなら S3 ライフサイクルポリシー：

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Days": 30
      }
    }
  ]
}

30 日後に全オブジェクトを自動削除。

移行後の最適化と監視

移行完了はゴールではなく、最適化のスタート。R2 の性能とコスパを最大限に。

性能最適化：R2 をさらに速く

1. Cloudflare CDN 加速

R2 は Cloudflare グローバルネットワーク上にありますが、CDN 併用でさらに効果的：

• R2 bucket 設定 → Public Access → Connect Domain
• ドメインを接続（Cloudflare 管理のドメインが必要）
• CDN キャッシュが自動有効

ユーザーは最寄り CDN ノードから取得、体感速度が向上。

2. 適切な Cache-Control

アップロード時に Cache-Control ヘッダーを設定：

// 静的リソース（画像・動画）は 1 年キャッシュ
s3.upload({
  Bucket: 'my-bucket',
  Key: 'image.jpg',
  Body: fileBuffer,
  CacheControl: 'public, max-age=31536000, immutable'
});
// 更新頻度の高いコンテンツは 1 時間
s3.upload({
  // ...
  CacheControl: 'public, max-age=3600'
});

3. R2 カスタムドメイン

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

デフォルト URL は https://xxx.r2.cloudflarestorage.com/file.jpg と見苦しい。

カスタムドメイン設定後：https://cdn.yoursite.com/file.jpg

見た目もよく、CDN 性能も向上。

コスト最適化：削れるところは削る

1. コールドデータは Infrequent Access ストレージクラス

R2 の Infrequent Access（IA）は、アクセス頻度の低いデータ向け：

• 保管料が安い（$0.01/GB vs 標準 $0.015/GB）
• アクセス時に読み取り料（$0.01/GB）が追加

向き：履歴アーカイブ、バックアップ、コールドデータ。

2. Multipart Upload の part size 最適化

大ファイルアップロードでは part size が Class A 操作料に影響。part 1 つごとに Class A 1 回：

• part が小さすぎ → 操作回数増 → コスト増
• part が大きすぎ → 失敗時の再送コスト増

目安：

• 100MB 未満 → 単発アップロード
• 100MB〜1GB → part size 64MB
• 1GB 超 → part size 128MB

rclone 設定例：

rclone copy s3:bucket r2:bucket --s3-chunk-size 64M

3. Class A/B 操作料を監視

転送は無料でも操作料は発生：

• Class A（書き込み）：$4.50/100 万回
• Class B（読み取り）：$0.36/100 万回

R2 コンソールで月間操作回数を確認。Class A が異常に多いなら、重複アップロードや無効リクエストを調査。

監視設定：問題を早期発見

1. Cloudflare Analytics

R2 内蔵 Analytics で確認できること：

• リクエスト数
• 転送量
• エラー率
• 人気ファイル

R2 bucket → Analytics から閲覧。

2. 費用アラート

閾値を超えたら通知：

Cloudflare Dashboard → Notifications → Add → 「R2 storage usage」

例：「月額 $50 超でメール通知」。請求の想定外増加を防げます。

3. アプリ層監視

アプリ側で R2 の主要指標を監視：

• API エラー率（目標 0.1% 未満）
• 平均レスポンス時間（目標 100ms 未満）
• P99 レイテンシ（目標 500ms 未満）

Sentry、Datadog などの APM で異常を検知し、必要ならロールバック。

4. S3 請求との定期比較

毎月比較：

• 移行前の S3 請求
• 移行後の R2 請求
• 節約額（チームの食事代に回せます 😄）

私は Excel で月次記録。節約額が増えるたび、達成感が膨らみます。

まとめ：R2 移行は価値があるか？

結論：アプリの転送が月 500GB 超なら、R2 移行は間違いなく価値があります。

移行の 3 大メリット：

1. 節約は本物：出口転送料ゼロでクラウド請求を 50〜90% 削減。SaaS で年 $10,000+、動画 PF で年 $50,000+ も珍しくない。
2. 移行は思ったより簡単：Super Slurper なら 30 分で設定完了。API 互換 80〜90%、大半のアプリは endpoint 変更だけ。実測でも、想像よりずっと楽でした。
3. リスクは制御可能：移行でソースは削除しない。カナリアで段階切替、問題あればロールバック。AWS の移行トラフィックも無料、試行コストはほぼゼロ。

ただし R2 は万能ではありません：

• AWS エコシステム（Lambda、Athena など）に深く依存していると移行コスト高
• S3 の高度コンプライアンス（Object Lock）が必須なら R2 は未対応
• 転送が極小（月 100GB 未満）なら ROI は低い

まず R2 無料枠で性能・安定性を試し、問題なければ本格移行。 Sippy で段階移行すれば、リスクはさらに低く。

最後に小話。画像ホスティングをやる友人は、以前 S3 月 $1,800。R2 移行後は $18（保管料のみ）。浮いたお金でデザイナーを雇い、UX が大きく改善。コスト最適化の価値は、単なる節約ではなく、より価値のあるところへ投資できることです。

今すぐ動くなら：

1. R2 計算機 で節約額を試算
2. 無料枠で R2 性能をテスト
3. 移行方式を選ぶ（Super Slurper / Sippy / rclone）
4. カナリア移行で安定性を確認
5. 全量切替、節約を実感

移行で困ったことがあれば、コメントでどうぞ。スムーズな移行と、請求の大幅ダウンを祈っています。