What actually drives the bill up when your object storage grows from a few terabytes to a few petabytes? For most teams, it is not the storage itself. It is the data leaving. That single fact explains why the Cloudflare R2 vs S3 vs Backblaze B2 decision has turned into one of the most consequential architecture calls in modern cloud design, and why it deserves more thought than a quick price comparison.
Why This Comparison Is Harder Than It Looks
On paper, all three services store objects behind an S3-compatible API. That compatibility is the common denominator that lets most S3 SDKs and tools work with minimal changes. But compatibility is partial, not binary. Bucket policy behavior, Object Lock variants, and newer S3 features are not implemented identically across providers, so any migration claim needs feature-by-feature verification rather than a checkbox.
That is the first trap. Teams assume “S3-compatible” means “drop-in replacement,” then discover during cutover that presigned URL behavior or ACL handling differs. The second trap is pricing. Every figure in this space moves, so treat any number you read, including in this article, as a prompt to check the vendor’s official page on the day you decide.
The Egress Question Comes First
Architecture decisions should start with data flow, not storage cost. AWS S3 charges for data transfer out. Cloudflare R2 has historically advertised zero egress fees. Backblaze B2 has offered free egress up to a multiple of stored data, historically three times average monthly storage, plus free egress through partner CDNs.
If your workload is read-heavy, such as a media site, a public dataset, or an AI pipeline that repeatedly pulls training data, egress dominates the math. If your workload is write-heavy and rarely read, such as compliance archives or cold backups, egress barely matters and storage price and retrieval behavior take over.
A practical way to frame it:
| Workload pattern | What dominates cost | What to scrutinize |
|---|---|---|
| Public media, downloads, streaming | Egress volume | Free-egress terms and CDN integration |
| AI training and analytics | Repeated reads | Egress plus request pricing |
| Backup and archive | Stored volume, retrieval | Minimum storage duration, retrieval fees |
| Regulated records | Immutability, residency | Object Lock support, region options |
The mistake people make is modeling only month one. Model month twelve, when the dataset has grown and read patterns have shifted.
Consistency: The Decision That Bites Later
Consistency sounds academic until a pipeline reads a file it just wrote and gets nothing back. AWS moved S3 to strong read-after-write consistency for new objects, overwrites, and deletes in December 2020. R2 and B2 publish their own guarantees, and those statements should be checked against your specific access pattern rather than assumed.
Why does this matter architecturally? Because eventual consistency forces defensive code. You add retries, polling loops, and “wait a few seconds” hacks that quietly become permanent technical debt. If a provider offers strong consistency for the operations you depend on, you can delete that scaffolding. If it does not, you must design for it from day one, not patch it in after the first production incident.
The same logic applies to durability and availability claims. AWS publishes S3 Standard durability of eleven nines and designed availability of 99.99%. R2 and B2 publish their own targets. These numbers are not apples-to-apples because methodologies and SLAs differ. A nine is not a nine when the definitions diverge, so read the SLA text, not the marketing badge.
Storage Classes and Tiering
S3 offers a broad tiering model: Standard, Intelligent-Tiering, and the Glacier family, among others. R2 has historically kept things simpler with Standard and Infrequent Access. B2 has its own tiers. Class names and availability change, so verify before you commit a lifecycle policy.
Tiering is where architecture and finance meet. A well-designed lifecycle rule moves objects automatically as they age. A badly designed one creates retrieval bills that surprise everyone. Watch for minimum storage durations: if a tier requires objects to sit for 30 or 90 days, a pipeline that deletes and rewrites frequently will pay penalties instead of saving money.
For teams building out broader infrastructure, the same layering logic shows up in how cloud storage architecture actually works with objects and erasure coding, which is worth reading before you design lifecycle rules around assumptions about redundancy.
Immutability, Compliance, and Object Lock
S3 supports Object Lock for WORM (write once, read many) workloads and is widely used for compliance data. Whether R2 and B2 support equivalent immutability, and to what degree, must be verified per vendor. This is a common fork in the road for regulated industries.
If your auditors require provable immutability, do not accept “we support versioning” as an answer. Versioning protects against accidental deletion. Object Lock protects against deliberate tampering and satisfies retention rules. They are different controls, and only one of them survives an audit conversation.
Large Objects, Multipart Uploads, and Ingestion Design
All three providers support multipart uploads, but part-size limits, minimum part sizes, and maximum object sizes differ. For video pipelines, database dumps, or VM images, those limits shape your ingestion architecture directly.
In practice, teams hit this when a single upload job works fine at 5 GB and fails at 500 GB. The fix is usually chunking strategy and retry logic tuned to the provider’s part-size rules. Design the uploader to be provider-agnostic from the start, and a future migration becomes a configuration change instead of a rewrite.
Event Notifications and Compute Integration
S3 integrates with EventBridge, SNS, SQS, and Lambda. R2 has Workers integration and event notifications, with feature availability expanding over time. B2 has its own event notification and partner integrations. If your pipeline is event-driven, meaning an upload triggers processing, this integration surface matters as much as storage price.
The architecture question is where compute lives relative to storage. Pulling an object across the network to process it costs latency and, potentially, egress. Running compute close to the bucket, such as Workers functions at the edge, changes the economics. That pattern connects to how cloud-native computing architecture works when you are deciding whether processing belongs in a function, a container, or a batch job.
Data Residency and Region Choice
S3 offers many regions. R2 has historically used automatic global placement with location and jurisdiction hints added over time. B2 offers regions such as US and EU. Region choice affects latency, compliance, and cost simultaneously.
For European teams handling personal data, residency is not optional. Confirm where objects physically rest and whether the provider offers contractual commitments beyond a dropdown in a dashboard. Latency follows the same rule: an object stored far from its consumers costs milliseconds on every request, and those milliseconds compound across millions of reads.
Migration Reality Check
S3-compatible APIs plus tools like rclone make cross-provider moves feasible. The friction points are predictable: egress costs when leaving the old provider, and API differences such as presigned URL behavior and the ACL versus bucket-policy split.
A migration plan that actually works looks like this:
- Inventory every API call your application makes, including those outside the main code path.
- Test the target provider against that list in a staging bucket, including error responses.
- Measure egress from the source provider before committing to a cutover date.
- Run dual-write for a defined window, then verify object counts and checksums.
- Keep a rollback path for at least one billing cycle.
Skipping step one is the most common mistake. A single forgotten presigned URL generator can break an entire upload flow on cutover day.
How the Decision Fits the Wider Stack
Object storage rarely sits alone. It feeds CDNs, APIs, and disaster recovery plans. If your buckets back an API tier, the gateway layer shapes how requests reach storage, and understanding how modern cloud API management gateways work helps you avoid routing storage traffic through bottlenecks. If buckets hold recovery copies, the design of cloud disaster recovery architecture determines whether a restore takes minutes or days.
A useful habit: draw the data flow diagram before comparing prices. Where does data enter, where does it get read, and where does it leave the provider’s network? The answers usually make the choice obvious.
Practical Guidance for 2027 Planning
Treat 2027 planning as scenario work, not prediction. Pricing and free-egress terms change frequently, so build a model with variables rather than fixed numbers. Durability and availability figures are not comparable across vendors, so compare SLA language. And S3 compatibility is partial, so verify features one by one. (What is Amazon S3?)
A balanced default for many teams: choose the provider whose egress model matches your read pattern, confirm the three or four features you truly depend on, and keep the storage layer abstracted behind a thin interface so the next migration is a config change.
Conclusion
The Cloudflare R2 vs S3 vs Backblaze B2 decision is not a pricing spreadsheet exercise. It is a question about how your data moves. Start with egress, verify consistency and immutability claims against your actual workload, test compatibility feature by feature, and abstract the storage layer so you are never locked in. Teams that do this work up front spend their time building products. Teams that skip it spend their time explaining invoices.
FAQ
Is Cloudflare R2 really free of egress fees?
R2 has historically advertised zero egress fees, which is its main differentiator. Terms can change, so confirm the current policy on the official pricing page before you build a cost model around it. Also check whether operations and request pricing apply to your workload.
Can I use my existing S3 tools with R2 or B2?
Mostly yes. Both expose S3-compatible APIs, so common SDKs and tools work with minimal changes. However, compatibility is partial. Bucket policies, Object Lock variants, and newer S3 features may behave differently, so test every operation your application depends on before migrating.
Which provider is best for compliance and WORM storage?
S3 supports Object Lock for WORM workloads and is widely used for regulated data. Whether R2 and B2 offer equivalent immutability, and to what degree, needs verification per vendor. If auditors require provable immutability, get the retention guarantees in writing rather than relying on versioning alone.
Does consistency actually matter for object storage?
Yes, especially for pipelines that read objects right after writing them. S3 moved to strong read-after-write consistency for new objects, overwrites, and deletes in December 2020. If a provider offers weaker guarantees, you must build retries and polling into your code, which becomes permanent complexity.
How do I migrate between providers without downtime?
Use the S3-compatible API and tools like rclone, inventory every API call first, measure source egress costs, then run dual-write for a defined window. Verify object counts and checksums before cutting over, and keep a rollback path for at least one billing cycle.
Are durability numbers comparable between providers?
No. AWS publishes eleven nines of durability for S3 Standard, and R2 and B2 publish their own targets, but methodologies and SLAs differ. Compare the actual SLA language and understand what is guaranteed versus what is designed for, rather than comparing headline figures directly.
The cheapest storage is the one you never have to migrate under pressure. Budget for the exit before you budget for the ingress, and the 2027 decision becomes far less consequential than the marketing pages suggest.
Exit cost includes more than egress: it also includes the engineering hours spent rewriting presigned URL logic, re-testing lifecycle rules against a new tier model, and re-validating immutability controls with auditors. Put a number on those hours in your model alongside any per-gigabyte figure. A provider that saves a few thousand dollars a year but costs two engineer-weeks per migration is not cheaper. Write the exit runbook while the integration is fresh, store it next to the architecture diagram, and revisit it whenever pricing or feature terms change. That habit, more than any single vendor comparison, is what keeps the 2027 decision reversible.
