What actually breaks when a team moves a backup job from Amazon S3 to Backblaze B2, or a media archive from B2 to Wasabi? Almost never the upload itself. The upload works. What breaks is everything around it: the script that lists objects, the lifecycle rule that was supposed to move old files to cold storage, the invoice at the end of the month, and the cron job that quietly started failing three weeks ago. (Keyboard foam mod sound differences actually changes)
That gap between “S3-compatible” on a marketing page and “S3-compatible in your actual pipeline” is the whole story here. All three services speak the same basic language. They disagree on the grammar, the accent, and the bill.
Why “S3-Compatible” Is a Starting Point, Not a Promise
Backblaze B2 and Wasabi both expose S3-compatible APIs, which means most S3 SDKs and tools will connect once you swap the endpoint and credentials. That is genuinely useful. It is also where people stop reading and start assuming.
The compatibility layer covers the common verbs: put an object, get an object, list a bucket. It does not automatically cover every behavior your tooling depends on. Lifecycle transitions, storage class names, request signing details, and error codes can all differ. A tool that works flawlessly against S3 may throw unexpected errors against a compatible endpoint simply because it asked for a storage class that doesn’t exist there. (Cloud storage)
The practical lesson: test the full workflow, not the connection. Upload a file, list it, copy it, set a lifecycle rule, delete it, and check what the API returns at each step. That hour of testing saves weeks of silent failures. (Use claude writing practical workflow that actually works)
The Credential Model Trips Up More Teams Than Anything Else
This is the most common mistake, and it’s boringly administrative. AWS S3 leans on IAM: users, roles, policies, and SigV4 request signing. Backblaze B2’s native API uses a different structure entirely, built around an account ID plus application keys with their own capability flags. A workflow built on native B2 tooling, such as the b2 command-line tool, does not map one-to-one onto S3 tooling.
Wasabi sits closer to the AWS model, which is why teams migrating from S3 often find the credential step less jarring there.
What actually works in practice: decide early whether you’re standardizing on the S3 API everywhere or embracing each provider’s native tooling. Mixing the two inside one pipeline is where credential confusion breeds. If your team already lives in S3 tooling, force everything through the S3-compatible endpoint, even for B2, and document the endpoint and key rotation process in one place.
Egress Math Changes How You Design the Pipeline
Egress is the cost of getting your data back out, and the three providers handle it in ways that shape architecture rather than just billing.
| Provider | Egress model (verify current terms) | Workflow consequence |
|---|---|---|
| AWS S3 | Charged per GB, plus per-request charges for PUT, GET and LIST | Design to minimize reads; caching layers pay for themselves |
| Backblaze B2 | Historically free up to a monthly cap tied to stored data, then charged per GB | Large restore jobs need a calendar check as well as a budget check |
| Wasabi | Historically no egress fees, but with a minimum storage duration on objects | Deleting or rotating objects early can trigger charges |
That Wasabi minimum storage duration is the sneaky one. A workflow that uploads short-lived files and deletes them after a week looks cheap on paper and expensive on the invoice, because the minimum applies whether or not the object lived that long. Backup rotation schedules designed for S3’s per-request pricing can behave very differently here.
Backblaze’s free egress allowance has historically been expressed as a multiple of average stored data per month, with charges beyond that. A quarterly full restore can blow past the cap in a single afternoon. Teams that plan restores around the calendar rather than the incident tend to avoid surprises.
There’s also a CDN angle worth knowing. Backblaze has had arrangements where egress to certain CDN partners doesn’t count against you, which changes the design for anyone serving media through a fronting layer. If your architecture puts a CDN in front of storage, that detail can matter more than the per-GB rate.
Storage Tiers: Where the Workflows Really Diverge
AWS S3 provides several storage classes, including Standard, Intelligent-Tiering and the Glacier tiers; lifecycle rules can move objects between them automatically. That tiering is a genuine workflow feature rather than a pricing gimmick. Teams build entire cost strategies around “hot for 30 days, warm for 90, archive after a year,” and the lifecycle engine executes it without anyone touching a script.
B2 and Wasabi have far fewer tiers. Wasabi has positioned itself as hot storage only, without an archive tier. That’s not a flaw, it’s a different product philosophy, but it means the S3-style lifecycle transition pattern simply doesn’t translate. If your cost model depends on automated demotion to cold storage, that model needs rebuilding before you migrate, not after.
The related trap is lifecycle rules that reference storage class names. A rule that says “transition to GLACIER after 90 days” will not do anything useful on a provider with no glacier equivalent. Sometimes it errors. Sometimes it silently does nothing, which is worse, because you find out a year later when the archive bill never went down.
Versioning and Object Lock are closer to parity across all three, but “close” is doing heavy lifting in that sentence. Object Lock semantics, retention modes, and how they interact with versioning deserve their own test pass rather than an assumption of identical behavior.
Consistency and the Assumptions Buried in Your Code
Since December 2020, S3 has provided strong read-after-write consistency for all objects. That ended a long era of workarounds: sleep timers after uploads, retry loops around list operations, and code comments explaining why the read might not see the write yet.
If your codebase still carries those workarounds, they’re now harmless clutter on S3 and possibly load-bearing on other providers depending on their guarantees. That’s the kind of difference nobody documents in a migration plan. Audit for retry-and-sleep patterns before moving, and find out what each provider actually promises rather than assuming the S3 behavior travels with the API.
A Migration Checklist That Actually Catches Problems
Practical experience says the failures cluster in predictable places. Run this before committing to any move:
- Inventory every tool that touches storage, including the forgotten cron jobs and the one-off scripts in someone’s home directory.
- Test the full object lifecycle against the new endpoint: create, list, copy, version, lock, delete.
- Rewrite or delete any lifecycle rule that references a storage class the new provider doesn’t offer.
- Model the bill for your real access pattern, including one full restore and one early-deletion scenario.
- Check credential rotation and how keys are scoped, then document it where the on-call engineer will find it.
- Run a restore drill from the new provider before you trust it with anything you can’t lose.
Step six is the one people skip. A backup you’ve never restored from is a hypothesis, not a backup.
Where Each Provider Fits a Real Workflow
None of these is universally better. They fit different shapes of work.
AWS S3 fits teams that want deep tiering, mature policy tooling, and a huge ecosystem of integrations, and who can absorb egress and request costs as part of the design. It rewards teams willing to invest in cost engineering.
Backblaze B2 fits backup-heavy and archive-heavy workloads where reads are rare and predictable, especially when a CDN sits in front. The native API is worth learning if you go deep, but the S3-compatible path keeps tooling consistent.
Wasabi fits steady, hot data that stays put: media libraries, active working sets, anything read often and deleted rarely. The absence of egress fees rewards read-heavy patterns, and the minimum storage duration punishes churn.
The pattern to notice is that the right choice follows from your access pattern, not from a feature checklist. Teams that map reads, writes, deletes, and restores over a realistic year tend to pick correctly. Teams that compare headline prices per terabyte tend to pick twice.
If your storage decision is tangled up with a broader tooling migration, the same principle applies: compare by workflow, not by spec sheet. That’s the approach behind comparisons of note-taking apps that weigh local-first sync against hosted workflows, and it’s the same reasoning that guides teams choosing file-sync alternatives by use case when they outgrow a default without knowing what they actually need.
It’s also why a careful rollout beats a fast one. Rolling out a new storage backend is a lot like disabling an unwanted feature in an operating system without breaking your daily workflow: the change is small, the blast radius is not, and the people who plan the rollback are the ones who sleep well.
Conclusion
The 2027 version of this comparison isn’t really about which provider is cheaper per terabyte. It’s about which provider’s assumptions match the assumptions already baked into your scripts, your billing model, and your restore habits. S3 gives you tiering and deep tooling at the cost of egress and request charges. B2 gives you generous egress allowances and a distinct native API. Wasabi gives you hot storage without egress fees, provided you don’t churn objects faster than its minimum duration allows.
Pick by access pattern. Test the full lifecycle, not the connection. Run a restore drill before you need one. And re-verify every pricing and policy figure on the day you sign, because these terms move and old blog posts don’t.
Frequently Asked Questions
Can I use my existing S3 tools with Backblaze B2 and Wasabi?
Mostly yes, for common operations. Both offer S3-compatible endpoints, so SDKs and tools usually connect after you change the endpoint and credentials. The problems appear in edge cases: storage class names, lifecycle behavior, and error handling. Test your specific tools against the specific endpoint before trusting them in production.
Why did my lifecycle rule stop working after migration?
Because it probably referenced a storage class the new provider doesn’t offer. S3 has multiple tiers with automated transitions; B2 and Wasabi have far fewer. A rule that transitions objects to a cold archive tier may error or, worse, silently do nothing. Rewrite rules around what the destination actually supports.
Is Wasabi really free of egress fees?
Wasabi has historically advertised no egress fees, but with a minimum storage duration attached to objects. That means deleting or rotating data early can still cost you. The egress line on the invoice may be zero while the minimum-duration charge isn’t. Confirm the current policy before you build a workflow around it.
Does Backblaze B2 charge for downloads?
Historically, B2 has included free egress up to a monthly cap tied to how much you store, then charged per GB beyond it. The cap is generous for backup workloads and can be tight for a large one-time restore. Check the current allowance and plan big restores accordingly.
What’s the biggest mistake teams make when switching storage providers?
Testing the connection instead of the workflow. A successful upload proves almost nothing. The failures hide in listing behavior, credential scoping, lifecycle rules, and restore procedures. Run a full object lifecycle test and one real restore drill before committing.
Does S3 consistency behavior carry over to compatible providers?
Not automatically. S3 has offered strong read-after-write consistency for all objects since December 2020, which made a lot of old retry-and-sleep code unnecessary. Other providers may make different guarantees. Audit your code for consistency workarounds and confirm what each provider actually promises rather than assuming the S3 behavior travels with the API.
