DEV Community

Juan Diego Isaza A.
Juan Diego Isaza A.

Posted on

Cloudflare R2 vs S3: Which Object Storage for VPS?

#cloud #vps #s3 #cloudflare

If you’re running apps on a VPS, cloudflare r2 vs s3 isn’t a theoretical debate—it directly affects your bill, latency, and how painful egress fees become when your traffic grows. S3 is the default choice for a reason, but R2 is forcing a rethink, especially for bandwidth-heavy workloads.

1) The real difference: pricing model and “where the pain is”

Amazon S3 pricing is rarely just “storage per GB.” In practice, the surprise costs come from:

  • Egress (data transfer out): usually the biggest line item for public assets.
  • Request costs (PUT/GET/LIST): small per request, but high-volume apps feel it.
  • Cross-AZ / cross-region transfers: easy to trigger accidentally.

Cloudflare R2’s headline is simple: no egress fees (when used in typical Internet-facing patterns). That’s not marketing fluff—it changes architecture decisions. With S3, you often “design around egress” by pushing traffic through CDNs and keeping origin pulls optimized. With R2, you can be less defensive when serving large files, backups, AI datasets, or user uploads.

Opinionated take: if your product’s success means “more bandwidth,” R2’s egress model is fundamentally aligned with your incentives. S3 can still win on ecosystem and maturity, but you’ll pay for scale in a way that’s easy to underestimate.

2) Performance and latency: CDN adjacency beats raw benchmarks

On a VPS, object storage latency isn’t just about the storage vendor—it’s about network distance and where your compute lives.

  • If your VPS is on Hetzner in Germany and your bucket is in a far region, your app will feel it (uploads, signed URL flows, image transforms).
  • If you’re deploying on digitalocean (or Linode/Vultr), you might already be near an AWS region—making S3 latency perfectly fine.
  • R2 can shine when your traffic is already on Cloudflare’s edge. Serving objects near users (and avoiding egress charges) is its “native habitat.”

The less obvious point: many VPS-hosted apps aren’t CPU-bound; they’re I/O and network-bound. If object storage calls are in the request path (profile pictures, attachments, app exports), shaving 50–100ms matters.

Practical rule:

  • If your workloads are global and read-heavy, R2 + Cloudflare edge distribution is compelling.
  • If your workloads are region-specific and AWS-adjacent, S3 is predictably solid.

3) Compatibility and features: S3 is the standard, R2 is “S3-ish”

For VPS hosting, you care about how quickly you can integrate and how many tools “just work.”

S3 strengths

  • The broadest compatibility: every backup tool, SDK, and CI pipeline supports it.
  • Feature depth: lifecycle policies, replication options, event notifications, storage classes, and compliance knobs.
  • Enterprise credibility: boring in the best way.

R2 strengths

  • S3-compatible API for common operations.
  • Strong story for edge delivery and bandwidth-heavy public assets.
  • Cost predictability when your app grows.

Where you might hit friction with R2: very specific S3 features (some eventing and advanced lifecycle/replication patterns) and tooling assumptions that expect AWS-native IAM policies and services. For most VPS apps doing “store and fetch objects,” it’s fine. For complex pipelines (data lakes, multi-region replication, deep AWS integration), S3 is still the path of least resistance.

4) Actionable example: use the AWS CLI with R2 from a VPS

One reason R2 adoption is accelerating in the VPS crowd: you can often keep your tooling. Here’s a minimal, practical setup using awscli on your VPS to upload and fetch objects from an R2 bucket.

# 1) Install AWS CLI (example: Ubuntu)
sudo apt-get update && sudo apt-get install -y awscli

# 2) Configure credentials (use R2 access key + secret)
aws configure
# AWS Access Key ID:     <R2_ACCESS_KEY>
# AWS Secret Access Key: <R2_SECRET_KEY>
# Default region name:   auto
# Default output format: json

# 3) Upload a file to R2 (S3-compatible) using an R2 endpoint
export R2_ENDPOINT="https://<ACCOUNT_ID>.r2.cloudflarestorage.com"

aws s3api put-object \
  --bucket my-bucket \
  --key uploads/hello.txt \
  --body ./hello.txt \
  --endpoint-url "$R2_ENDPOINT"

# 4) Download it back
aws s3api get-object \
  --bucket my-bucket \
  --key uploads/hello.txt \
  ./downloaded-hello.txt \
  --endpoint-url "$R2_ENDPOINT"
Enter fullscreen mode Exit fullscreen mode

Tip: keep object storage out of your app server’s local disk. On VPS platforms (whether Hetzner for price/performance or digitalocean for convenience), local volumes are great until you need multi-instance scaling or reliable backups.

5) Choosing for VPS hosting: a blunt decision matrix

Here’s the opinionated guidance I’d use if I were deploying a typical VPS-hosted product today:

  • Choose Cloudflare R2 if

    • Your app serves lots of public downloads/media (egress dominates).
    • You want predictable costs as traffic scales.
    • You already use Cloudflare for DNS/CDN/WAF, or plan to.

  • Choose Amazon S3 if

    • You need AWS-native integrations (Lambda triggers, complex lifecycle rules, replication patterns).
    • Your data pipeline is already on AWS (or will be soon).
    • You need maximum third-party tool support with zero edge cases.

  • Hybrid is normal

    • R2 for hot/public assets and user downloads.
    • S3 for archival, analytics, or AWS-integrated workflows.

Soft note for teams running on VPS providers like digitalocean or Hetzner: if your bottleneck is bandwidth cost and you’re already comfortable operating outside AWS, trying cloudflare R2 for a single workload (like backups or media) is a low-drama experiment. If it works, you’ll feel it immediately in your monthly bill.

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)