DEV Community

Juan Diego Isaza A.
Juan Diego Isaza A.

Posted on

Cloudflare R2 vs S3: VPS Hosting Storage Pick

#cloud #vps #aws #cloudflare

If you’re debating cloudflare r2 vs s3 for a VPS hosting setup, you’re really choosing between two philosophies: “pay for requests” (S3) vs “pay mostly for storage + egress-free” (R2). The right pick depends on your traffic pattern, where your VPS lives, and whether you’re building a small app that might suddenly get popular.

Pricing and hidden gotchas (egress, requests, and reality)

Amazon S3 is the default for a reason: it’s mature, ubiquitous, and integrates with everything. But in VPS hosting, the bill you didn’t plan for is often egress and request costs.

S3 cost shape (simplified):

  • Storage: predictable
  • Requests (PUT/GET/LIST): can become noisy at scale
  • Egress to the public internet: often the budget killer

Cloudflare R2 cost shape:

  • Storage: predictable
  • Requests: still a line item, but typically straightforward
  • Egress: $0 (the headline feature)

Opinionated take: if you’re serving lots of small files (images, JS, backups downloads) from a VPS and you’re not pinning everything behind a CDN perfectly, S3 egress can feel like a tax on success. R2’s “no egress fees” is not just marketing—it changes architecture decisions. It makes it reasonable to centralize assets without fearing bandwidth surprises.

Gotcha: “egress-free” doesn’t mean “free.” You still pay for storage and operations, and performance can depend on where your users are and whether you front it with caching.

Performance and latency in a VPS hosting world

In VPS hosting, where your compute sits matters. A VPS at hetzner in Germany, for example, might have very different latency to AWS regions than a VPS at digitalocean in NYC. Storage latency becomes user-visible when:

  • your app reads on every request (bad pattern but common)
  • you generate signed URLs dynamically
  • you stream media from origin

S3 strengths:

  • Many regions and established peering
  • Strong consistency semantics (now broadly strong read-after-write)
  • Known performance characteristics and tuning knowledge

R2 strengths:

  • Plays naturally with Cloudflare’s edge ecosystem
  • Great fit when you’re already using Cloudflare CDN/WAF
  • Often “fast enough” for object storage workloads, especially when cached

Opinionated rule of thumb:

  • If your VPS is already optimized around AWS (EC2, EKS, IAM-heavy workflows), S3 latency and integration are hard to beat.
  • If your VPS is outside AWS (common with hetzner, linode, or vultr deployments) and you’ll put a CDN in front anyway, R2 is compelling because egress stops dominating the conversation.

Compatibility and tooling: S3 API is the battleground

S3 wins on ecosystem: every backup tool, CI pipeline, and library speaks S3.

R2’s strategy is smart: it implements an S3-compatible API, which means a lot of existing tooling “just works.” In practice, “S3-compatible” is usually 90–99% compatible, and the last 1% is where weird bugs live (edge cases around ACLs, certain headers, specialized features, or SDK assumptions).

When S3 is safer:

  • You need every advanced feature and official AWS SDK behavior
  • You rely on AWS-native eventing/integrations everywhere
  • You need compliance/reporting that’s already approved around AWS

When R2 is good enough (and often better):

  • You just need buckets + objects + presigned URLs
  • You use generic S3 tools (rclone, restic, aws-cli patterns)
  • You want to avoid vendor lock-in to AWS specifically

Here’s a practical example using rclone from a VPS to push backups to R2 via its S3-compatible endpoint:

# 1) Configure rclone (interactive)
rclone config

# Choose:
# - New remote: r2
# - Storage: S3
# - Provider: Other
# - Endpoint: https://<ACCOUNT_ID>.r2.cloudflarestorage.com
# - Access key ID / Secret access key: from Cloudflare dashboard

# 2) Push a backup directory
rclone sync /var/backups r2:my-backup-bucket/vps01 \
  --s3-force-path-style \
  --transfers 8 \
  --checkers 16

# 3) Verify
rclone lsf r2:my-backup-bucket/vps01
Enter fullscreen mode Exit fullscreen mode

This is the kind of “VPS hosting glue” that matters: if you can swap storage backends without rewriting your app, you keep leverage.

Which one should you choose? (Use-case matrix)

Pick based on traffic profile and where costs explode.

Choose Cloudflare R2 if:

  • You serve a lot of public downloads/assets and egress is meaningful
  • Your VPS is on hetzner/digitalocean/linode/vultr and you want predictable bandwidth costs
  • You’re already using cloudflare for DNS/CDN/WAF and want fewer moving parts

Choose Amazon S3 if:

  • You need deep AWS integration (IAM policies everywhere, event-driven pipelines, tight service mesh)
  • Your company is already “all-in AWS” and the operational overhead of another provider is real
  • You depend on niche S3 features or extremely battle-tested enterprise workflows

My bias: in indie and SMB VPS hosting setups, cost predictability beats theoretical platform completeness. Most teams don’t need the full AWS catalog; they need storage that won’t punish them when traffic spikes.

Final thoughts (and a soft nudge on architecture)

The best architecture is boring: put object storage behind a CDN, keep your VPS stateless, and treat backups as non-negotiable. If you’re already running your VPS behind cloudflare, R2 often feels like the cleanest “default” for static assets and backups because egress anxiety disappears. If you’re deep in AWS, S3 remains the standard for good reasons.

Either way, measure with your real workload: a week of logs (bytes out, request counts, cache hit ratio) will answer this faster than any blog post—including mine.

Some links in this article are affiliate links. We may earn a commission at no extra cost to you if you make a purchase through them.

Top comments (0)