S3流量费每月上千?手把手教你迁移到R2,3步省90%费用(附真实案例)

引言

上个月底查看AWS账单的时候,我差点把咖啡喷到键盘上——存储费才$230,流量费居然$4,500!我赶紧翻看账单明细,发现罪魁祸首就是S3的出口流量费,$0.09/GB看起来不多,但50TB流量一跑,钱包就瘪了。 后来和几个做视频、图床服务的朋友聊,发现大家都在被S3流量费割肉。有个做SaaS的朋友说,他们公司每月10TB流量,S3账单$891,而存储费只要$15,算下来流量费占了98%。这不合理啊! 那换到Cloudflare R2呢?零出口流量费,同样的10TB流量,R2只收存储费$15。我第一反应是:不会是坑吧?R2这么便宜,是不是性能很差或者不稳定? 带着这些疑问,我花了两周时间研究R2,做了API兼容性测试,还实际迁移了几个项目。今天把经验分享出来,包括3个真实场景的成本计算、API兼容性实测、30分钟迁移教程,还有我踩过的坑。 说实话,不是所有场景都适合迁移到R2,但如果你的应用流量大(每月>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/百万次,Class B操作$0.36/百万次 R2还有免费额度:
• 10GB存储
• 100万次Class A操作(写入、列表)
• 1000万次Class B操作(读取) 对于个人博客或小项目,可能完全在免费额度内。

真实案例对比(别只看我算,看看数据)

我整理了3个典型场景的成本对比:

什么情况下别折腾迁移

说了这么多好处,我也得说说R2不适合的场景,不然你迁移了发现不合适,还得怪我:

1. 深度绑定AWS生态:如果你的应用重度使用Lambda、Athena、EMR这些AWS服务,迁移到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-style access keys 最爽的是,你只需要修改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',
});

其他的上传、下载、删除代码全部不用改,直接跑。我测试了两周,没发现兼容性问题。

哪些功能不支持(踩坑预警)

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都不支持。 我的建议:迁移前先列出你的应用用到的S3功能,对照Cloudflare官方文档的API兼容性列表检查一遍。 大部分应用其实只用基础功能,不会有问题。

工具兼容性实测

我测试了几个常用工具,结论是基本都能无缝切换:

一个我踩过的坑

说个我迁移时踩的坑。我有个应用用了S3的ListObjectsV2 API,带了StartAfter参数做分页。结果迁移到R2后,发现分页逻辑有点不一样,导致漏了部分数据。 后来排查发现,R2的分页行为和S3略有差异。我改成用ContinuationToken参数后就正常了。 教训就是:迁移后一定要做充分测试,不要只测正常流程,边界情况也要覆盖。

3种迁移方案对比:选择最适合你的方式

Cloudflare提供了两个官方工具(Super Slurper和Sippy),社区还有rclone等开源方案。选哪个?看你的场景。

方案1:Super Slurper(推荐新手,一次性迁移)

Super Slurper是Cloudflare官方的一键迁移工具,适合”我就想把数据全搬过去”的场景。 优点很明显:

• 傻瓜式操作,填几个表单就开始迁移
• 保留所有元数据(metadata、content-type等)
• 不删除源数据,零风险
• 免费用,只收R2的Class A操作费(很便宜)
• 2024年升级后,速度提升了5倍 缺点也要知道:
• 只能一次性迁移,不能增量同步
• 迁移期间如果用户上传新文件到S3,这些文件不会自动同步到R2
• 适合单个对象<50GB的场景(超大文件可能有问题) 适合谁:
• 数据量<10TB
• 可以接受短暂停机(或者业务还没上线)
• 迁移后完全切换到R2,不再用S3 我第一个迁移的项目就用的Super Slurper,100GB数据大概30分钟搞定。当时设置了凌晨3点维护窗口,用户基本没感知。

方案2:Sippy(零停机,渐进式迁移)

Sippy是Cloudflare推出的智能迁移方案,最大特点是不需要停机。 工作原理: 你把应用指向R2,当用户请求某个文件时:

1. R2先查自己有没有这个文件
2. 如果有,直接返回(超快)
3. 如果没有,从S3拉取,同时复制一份到R2,下次就直接从R2读了 这样数据是按需迁移的,访问量大的热数据先迁移,冷数据慢慢迁。 优点:

• 完全零停机,用户无感知
• 降低S3流量费(热数据迁移后,流量走R2)
• 可以边迁移边观察,不爽随时切回S3 缺点:
• 首次访问某个文件会稍慢(需要从S3拉取)
• 配置相对复杂,需要改应用配置
• 适合访问模式明确的场景(明显的热数据和冷数据) 适合谁:
• 生产环境不能停机
• 数据量巨大(>10TB),一次性迁移时间太长
• 想先测试R2稳定性再完全切换 我有个朋友做CDN加速服务,他们用Sippy迁移了50TB数据。一边服务用户,一边后台慢慢迁,用了两个月才完全迁完,但业务一点没影响。

方案3:rclone(极客之选,最灵活)

rclone是开源的云存储同步工具,功能最强大,但需要命令行操作。 优点:

• 完全免费开源
• 支持断点续传(网络不稳定也不怕)
• 可以定时同步(比如每天凌晨自动同步增量数据)
• 支持校验数据完整性(MD5、SHA256)
• 可以限速,不占满带宽 缺点:
• 需要命令行操作,有学习曲线
• 要自己写脚本管理迁移进度
• 传输过程中会产生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就够了。除非你的业务真的一刻都不能停,或者数据量特别大(>50TB),否则Super Slurper的简单性远比其他方案的灵活性值得。

实战:30分钟完成零风险迁移(以Super Slurper为例)

好了,理论讲完了,现在手把手教你操作。我以Super Slurper为例,保证你30分钟能搞定配置(传输时间另算)。

第一步:准备工作(5分钟)

1. 注册Cloudflare账号并启用R2 去Cloudflare官网注册账号,然后在侧边栏找到”R2 Object Storage”,点击启用。 注意:R2需要绑定信用卡,但有免费额度,小项目可能一分钱都不花。 2. 创建R2 bucket 点击”Create bucket”,填写:

• Bucket名称(建议和S3保持一致,方便管理)
• Location hint(如果有合规要求选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,复制保存好,只显示一次。 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,保存好。

第二步:执行迁移(15分钟配置)

1. 进入Data Migration界面 在R2控制台,点击右上角”Data Migration” → “Migrate Files”。 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天 你可以关闭页面,迁移在后台进行。可以随时回来查看进度。

第三步:验证迁移结果(10分钟)

迁移完成后,千万别立刻删除S3数据,先验证! 1. 检查对象数量 在R2控制台查看bucket,对比:

• S3对象数量:X个
• R2对象数量:X个 数量一致就好。如果不一致,检查是否有迁移失败的日志。 2. 抽查文件完整性 随机下载几个文件,对比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

第四步:切换应用到R2

验证没问题后,可以开始切换应用了。建议灰度发布,别一次性全切。 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即可

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 header,告诉CDN缓存多久:

// 静态资源(图片、视频)缓存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的自定义域名 默认的R2 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上传都算一次Class A操作:
• Part size太小 → 操作次数多 → 费用高
• Part size太大 → 失败重传成本高 我的建议:
• 文件<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/百万次
• Class B(读取):$0.36/百万次 在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绝对值得。 回顾一下迁移的三大收益:

1. 省钱是真的:零出口流量费能让你的云账单直接砍掉50-90%。SaaS应用年省$10,000+不是梦,视频平台年省$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(存储费)。省下的钱,他拿来招了个设计师优化产品,用户体验提升一大截。这就是成本优化的价值——不只是省钱,而是把钱花在更有价值的地方。 现在就行动:

1. 去R2计算器算算你能省多少钱
2. 用免费额度测试R2性能
3. 选择合适的迁移方案(Super Slurper/Sippy/rclone)
4. 灰度迁移,验证稳定性
5. 全量切换,享受省钱的快乐 如果迁移过程中遇到问题,欢迎留言讨论。祝你迁移顺利,账单大降!

发布于: 2025年12月1日 · 修改于: 2025年12月4日

Easton

技术开发