A 2026 comparison of Cloudflare R2 and AWS S3 for solo SaaS — storage and egress pricing, S3 API compatibility, feature surface, and where the egress savings actually move the needle on your monthly bill.
Methodology. This comparison synthesizes the Cloudflare R2 and AWS S3 pricing pages and documentation as of May 2026. Prices verified against developers.cloudflare.com/r2/pricing and aws.amazon.com/s3/pricing. How we research.
For any solo SaaS that serves user-facing downloads — images, video, files, large assets — Cloudflare R2 is the right default in 2026. The zero-egress pricing alone is enough to dominate the monthly-bill math at almost any scale where storage and bandwidth start to matter. AWS S3 is still the right answer when you’re already deep in the AWS ecosystem, need advanced features like lifecycle policies, Glacier tiers, or Object Lock for compliance, or have so little egress that the headline savings don’t move your bill. For most greenfield SaaS work, the egress-fee story is decisive and R2 is the clear pick.
Object storage isn’t the part of a SaaS stack founders usually agonize over. You pick S3, wire it into your app with the AWS SDK, and move on. That default was uncontested for nearly two decades — AWS S3 launched in March 2006 and effectively defined the category. But in 2022 Cloudflare launched R2 with a single deliberately attention-grabbing pricing decision: zero egress fees. Four years later, that decision has reshaped how solo SaaS founders think about where their user-facing media lives.
This guide walks through every meaningful difference between R2 and S3 for solo SaaS founders, anchored to public pricing pages and product documentation. The conclusion is unusually clear, but the path to it is worth understanding because the trade-offs aren’t all in R2’s favor.
R2 is Cloudflare’s object storage service, launched in beta in 2021 and generally available in 2022. The product is S3-API-compatible — you can point an existing AWS S3 SDK at an R2 endpoint by swapping the URL — and runs on Cloudflare’s global network. The headline feature is $0 egress fees: no charge for outbound traffic to the internet or to other Cloudflare services.
R2 is integrated with the rest of the Cloudflare developer platform — Workers, Pages, D1, KV, Durable Objects, and Queues all share the same dashboard, authentication, and billing surface. For a solo SaaS building on Cloudflare’s edge stack, R2 is the natural object-storage layer.
S3 is the original cloud object storage service. Launched by AWS in March 2006, it predates every other major piece of public cloud infrastructure and effectively defined what object storage means in a modern context. The product has accumulated nearly two decades of feature work: storage classes (Standard, Infrequent Access, One Zone-IA, Glacier Instant, Glacier Flexible, Glacier Deep Archive), lifecycle policies, versioning, replication, Object Lock, S3 Select, Inventory, Storage Lens, and dozens more.
S3 is the default object store for anything running inside AWS — Lambda functions, ECS containers, EC2 instances, SageMaker training jobs — and the integration with the broader AWS ecosystem is unmatched. The trade-off has always been the pricing model, especially egress.
This is the single dimension that defines the comparison. According to aws.amazon.com/s3/pricing, S3 charges for outbound data transfer to the internet on a tiered scale starting around $0.09/GB for the first 10TB and tapering down to roughly $0.05/GB at higher volumes. R2 charges $0/GB for egress — that’s the headline.
The implications are easiest to see at concrete volumes. For a SaaS that serves 1TB of outbound traffic per month, the egress cost difference is roughly $50–$90/month favoring R2. At 10TB/month, the gap widens to roughly $500–$900/month. At 100TB/month, the gap is in the thousands. Storage costs themselves are a smaller piece of the equation; egress is what dominates the bill once a SaaS has any meaningful user-facing media surface.
The other side of this story is that AWS S3 doesn’t charge egress when the consumer is also in AWS — serving from S3 to a Lambda function or an EC2 instance in the same region is free. The egress cost only bites when data leaves AWS for the public internet. For a SaaS where the only S3 consumer is your own server-side code running on AWS, the egress numbers above don’t apply.
Verified against the R2 pricing page as of May 2026:
Verified against the S3 pricing page as of May 2026 (US East region, first tier):
R2’s per-GB storage is slightly cheaper than S3 Standard ($0.015 vs $0.023), but the difference at small scale isn’t the headline. The egress gap is.
Three realistic scenarios:
A small SaaS with light media usage — maybe a few hundred users uploading profile photos and exporting their data occasionally.
A growing SaaS serving meaningful user-facing content — a video platform, an image-heavy app, a download-driven product.
A scaled SaaS with serious media surface — this is where the egress fee story turns from interesting to existential.
These numbers assume internet egress, not within-AWS egress. If your S3 traffic stays inside AWS, the egress cost vanishes and the comparison flips. But for any SaaS serving content directly to user browsers, mobile apps, or third-party services outside AWS, the egress meter runs.
R2 is S3-API-compatible at the wire-protocol level. According to the R2 documentation, most existing S3 SDKs work against R2 by changing the endpoint URL and providing R2 credentials. The official AWS SDK works. The aws CLI works. Tools like rclone work. Application code that already speaks the S3 API typically requires only configuration changes to migrate.
The compatibility isn’t 100% — some less-common S3 features and headers aren’t implemented on R2 — but for the operations a typical SaaS performs (PUT, GET, presigned URLs, multipart upload, object metadata, lifecycle deletion by application code), R2 behaves like S3. This is the single most important fact about R2 from a migration standpoint. Vendor lock-in is roughly symmetric between the two products at the API level.
For object reads and writes at the API level, R2 and S3 are broadly comparable. Both are highly available, highly durable, and designed to scale to billions of objects. Where they differ is the network shape.
R2 is served from the Cloudflare global network, which means object reads are routed through Cloudflare’s nearest point of presence. For end-user-facing content, this gives R2 a baked-in edge presence without needing a separate CDN layer.
S3 is region-locked — an object stored in us-east-1 serves from us-east-1. To get edge performance, you typically pair S3 with CloudFront, which adds its own pricing and configuration overhead. For most SaaS workloads serving content to users worldwide, R2’s built-in edge presence removes a config layer.
Both R2 and S3 claim 99.999999999% (eleven nines) of object durability. Both store objects redundantly across multiple physical locations. From a durability standpoint, they’re equivalent for any reasonable solo SaaS use case. The risk of losing data on either is effectively zero compared to other failure modes in your stack.
S3 has accumulated nearly two decades of feature work. R2 has accumulated four years. The feature gap is real and shapes specific use cases.
For a typical solo SaaS, the missing features in R2 are usually ones you don’t need on day one. Lifecycle policies and Glacier matter for archival use cases. Object Lock matters for compliance-driven products. Versioning matters when your application doesn’t have its own versioning logic. If none of those apply to you, the R2 feature surface is more than sufficient.
Where the rest of your stack lives often decides this one without you needing to think hard about it.
If you’re heavily on AWS — running Lambda, using SQS, deploying via Elastic Beanstalk or ECS, integrating with CloudFront, using IAM for cross-service auth — staying in AWS is convenient. S3’s integration with the rest of the AWS surface is unmatched, and pulling your object storage out to another provider adds a credential boundary and a billing boundary you didn’t have before.
If you’re on the Cloudflare developer platform — building on Pages, Workers, D1, KV — R2 is the natural object storage. The shared dashboard, shared billing, and zero-cost data movement between Cloudflare services make the stack feel coherent. Our Vercel vs Cloudflare Pages comparison goes deeper on the hosting side of this trade-off.
If you’re on a vendor-neutral stack — Next.js on Vercel or Railway, Postgres on Supabase or Neon — the choice of object storage is independent of the rest of the stack. In that case the egress economics dominate, and R2 is the natural pick.
Migration in either direction is feasible. R2’s S3 compatibility means tools like rclone, the aws CLI, and Cloudflare’s own Super Slurper service can move data efficiently between buckets. Application code that uses the AWS S3 SDK typically requires only configuration changes (endpoint, credentials, region) to point at R2 instead.
The harder part of any migration isn’t the data movement — it’s any AWS-specific integration you’ve built. If your code calls S3 from Lambda using IAM role auth, S3 from CloudFront with origin access identities, or S3 from SQS event triggers, you’ll be unwinding those bindings. For a SaaS that uses S3 only via the SDK, migration is mostly mechanical. For a SaaS deeply intertwined with AWS services, migration is real engineering work.
Five common scenarios:
You serve content to user browsers, mobile apps, or downloads. Egress is the dominant cost line in your storage bill. R2 wins almost regardless of other factors.
Your app runs in Lambda or ECS, talks to other AWS services, uses IAM throughout. The ecosystem integration tax of leaving AWS is higher than the egress savings.
Compliance, audit, or archival use cases. S3’s mature feature surface covers patterns R2 doesn’t implement yet.
You don’t want to think about storage tiering, you don’t want surprise bandwidth bills, and you want a simpler pricing model. R2’s flat pricing fits.
Bandwidth-dominant workloads. The zero-egress story moves your monthly bill by hundreds or thousands of dollars at typical scales.
| Feature | Cloudflare R2 | AWS S3 Standard |
|---|---|---|
| Launched | 2022 | 2006 |
| Storage $/GB-month | $0.015 (Standard) / $0.01 (IA) | $0.023 |
| Egress $/GB | $0 | $0.05–$0.09 |
| Class A ops | $4.50/M | $5.00/M |
| Class B ops | $0.36/M | $0.40/M |
| S3 API compatibility | Compatible at wire level | Native |
| Durability | 11 nines | 11 nines |
| Lifecycle policies | Limited | Mature |
| Storage tiers | Standard + Infrequent Access | Standard, IA, One Zone-IA, 3 Glacier tiers |
| Object Lock | Not available | Yes |
| Versioning | Newer, less mature | Mature |
| Cross-region replication | Not built-in | Native CRR |
| Edge presence | Cloudflare global network | Region-locked + CloudFront ($) |
| Ecosystem integration | Cloudflare Workers, Pages, D1, KV | Lambda, ECS, CloudFront, SQS, IAM |
| Best for | User-facing media, bandwidth-heavy SaaS, Cloudflare stack | AWS-native shops, compliance-heavy archival |
For a greenfield solo SaaS in 2026 that serves any meaningful user-facing content, Cloudflare R2 is the right default. The zero-egress pricing dominates the monthly-bill math, the S3 API compatibility means you’re not locked in, and the built-in edge presence removes a CDN configuration layer. AWS S3 remains the right answer for AWS-native shops, compliance-driven workloads that need Object Lock or Glacier, and any case where the egress meter never actually runs because your S3 consumers all live inside AWS. The decision is unusually clear once you know which side of the egress question you’re on.
The practical advice: if you’re building a new SaaS this year on a vendor-neutral stack, put your object storage on R2 and call it done. The few hundred dollars a month you save once you start serving real traffic compound into the kind of runway extension that matters for solo founders. If you’re uploading files from a Supabase-backed app and looking at the storage layer, our guide to file uploads with Supabase Storage covers the closest-to-default pattern; pairing it with R2 for high-bandwidth assets is a common architecture.
For the broader hosting context, Vercel vs Railway covers two of the most common application-hosting choices for solo founders, and Vercel free tier limits walks through what you’ll pay if you stay on the Vercel side of the stack. The database layer is the other half of the storage decision — Supabase vs Firebase walks through the two most common managed options. And the broader tools roundup is in best SaaS tools for developers.
Object storage is one of those infrastructure decisions that doesn’t feel important at launch and then quietly shapes the next two years of your bill. In 2026, for solo SaaS, the answer is R2 unless something specific forces the other direction.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.