DEV Community

Juan Diego Isaza A.
Juan Diego Isaza A.

Posted on

Cloudflare R2 vs S3: which fits VPS hosting best?

If you’re debating cloudflare r2 vs s3, you’re probably feeling the same pain most VPS hosting users hit: object storage looks “cheap” until egress, latency, and operational friction show up on the invoice. This comparison is opinionated on purpose—because the right answer depends less on feature checklists and more on where your traffic comes from and how your app is deployed.

Pricing reality: egress is the whole game

Amazon S3’s durability and ecosystem are the default choice for a reason, but in VPS-hosted architectures the real bill often isn’t storage—it’s data transfer.

  • Cloudflare R2: the headline is zero egress fees (to the public internet) and easy pairing with Cloudflare’s network. For bandwidth-heavy workloads (public downloads, images, media), that’s a structural advantage.
  • Amazon S3: storage pricing is competitive, but egress and request costs can dominate, especially when you’re serving a lot of content directly to users.

My take: if your VPS (say on hetzner or digitalocean) is pushing lots of files out to end users, S3 egress can become the “tax” you keep optimizing around. R2 removes that entire category of anxiety.

Latency and architecture: where is your compute?

In VPS hosting, you usually care about two paths:

  1. VPS → object storage (backend reads/writes)
  2. User → object storage (public delivery)

S3 can be extremely fast when your compute is in the same AWS region and you design around it. But many VPS users aren’t in AWS at all—they’re on providers like linode, vultr, or hetzner for price/performance. In that setup:

  • Backend path: your VPS will traverse the public internet to reach S3. That’s workable, but adds latency variability.
  • Public path: if users download straight from S3, you often add a CDN anyway to control latency and reduce egress.

With cloudflare R2, you’re effectively buying into Cloudflare’s edge-native story. Even if your VPS isn’t “near” R2 in the traditional region sense, Cloudflare’s network can reduce the perceived distance for public delivery—especially when fronted by Cloudflare.

Opinionated rule of thumb:

  • If your app is AWS-centric compute: S3 is the path of least resistance.
  • If your app is VPS-centric compute with lots of public downloads: R2 is hard to ignore.

S3 compatibility and tooling: the practical difference

R2 speaks an S3-compatible API, which is huge because it means most existing tooling “just works” with minimal changes. But compatibility isn’t the same as identical behavior.

What I’ve seen matter in real VPS deployments:

  • Ecosystem depth: S3 wins. Every backup tool, data lake component, and third-party integration tends to assume S3 first.
  • Operational UX: R2 tends to be simpler when your goal is “store objects and serve them,” not “integrate with 15 AWS services.”
  • Lock-in shape: S3 lock-in is often ecosystem-based (you start using IAM patterns, eventing, lifecycle policies tied to AWS). R2 lock-in is network-based (it’s most compelling when you’re already leaning on Cloudflare for DNS/CDN/WAF).

If you’re on a VPS and want portable scripts you can run anywhere, both can be fine—as long as you keep your usage to the S3-compatible subset.

Actionable example: point an S3 client at R2 from a VPS

Here’s a concrete pattern: use the AWS CLI on your VPS to upload backups to R2. This works great on a cheap VPS from hetzner/vultr/linode where you want offsite object storage without paying egress later when restoring or serving.

# 1) Configure credentials (use R2 access key + secret)
aws configure

# 2) Upload a file to R2 (S3-compatible endpoint)
aws s3 cp ./backup.tar.gz s3://my-bucket/backups/backup.tar.gz \
  --endpoint-url https://<ACCOUNT_ID>.r2.cloudflarestorage.com

# 3) List objects
aws s3 ls s3://my-bucket/backups/ \
  --endpoint-url https://<ACCOUNT_ID>.r2.cloudflarestorage.com
Enter fullscreen mode Exit fullscreen mode

Notes that matter in practice:

  • Treat --endpoint-url as non-negotiable for R2.
  • For restore testing, simulate real conditions: download the object back to your VPS and measure time + cost. With R2, the cost surprise is less likely.

So which should you choose for VPS hosting?

Choose S3 when:

  • Your compute is already in AWS or you need deep AWS integrations.
  • You’re building a system where S3 is a foundational primitive (events, policies, cross-service workflows).

Choose Cloudflare R2 when:

  • Your VPS-hosted app is bandwidth-heavy (images, downloads, media).
  • You want predictable costs and fewer “egress optimization” contortions.
  • You already use Cloudflare for DNS/CDN/security and want a tighter loop.

Soft recommendation: if you’re running a performance-priced VPS on digitalocean or hetzner and serving public assets, it’s worth piloting R2 for a week with real traffic. Keep S3 as the “enterprise default” benchmark, but don’t pay the egress tax out of habit.


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)