Leaving the hyperscaler — the actual math

Research
  • migration
  • egress
  • aws
  • wasabi
  • backblaze
  • cloudflare-r2

Three workloads, real numbers. List-price math comparing AWS S3 Standard against Wasabi, Backblaze B2, and Cloudflare R2, with Mover's migration cost factored in. Three different verdicts, three different payback windows.

A CTO at a mid-size SaaS gets the AWS bill, reads down to the line that says Data Transfer Out — Internet, and pauses. The storage bucket itself costs less than the engineering team's coffee budget. The egress costs more than two engineers. Reads grew. Storage didn't.

That bill is what brings most teams to this page. They've heard the line — the hyperscalers charge for getting your data out, the rest of the market doesn't — and they want to know if the math actually works out. Below is what a real move looks like with current list prices, on three workloads, with the migration cost factored in.

The single line item that drives the decision

Every cloud-storage bill has two big numbers. Storage at rest and data transfer out. Storage at rest is fairly competitive across providers; everyone is within a factor of two on the per-GB-month number. Egress is where the gap opens up. AWS S3 Standard charges around 9 cents per GB to send your data to the internet. Wasabi, Backblaze B2, and Cloudflare R2 each charge zero — or close to zero — for the same byte. A team reading their data more than a couple of times in a month is paying for the egress side many times over what they paid to put the data there.

The trick the hyperscalers play is making this expensive line item look incidental on a small bill, then watching it dominate the bill the moment your workload scales up reads. Backups, AI training datasets, CDN origin traffic, media libraries, analytics archives, anything that gets read more than it gets written — the read pattern is what makes the egress line item ugly.

Three workloads, three different verdicts

We've walked through hundreds of these migrations and the math splits along the read-to-storage ratio. Three shapes that cover most of what we see:

Workload 1 — storage-dominated, low egress

A research team holding 50 TB of archived experiment data on S3, reading maybe 5 TB out per month. The data is mostly sitting there; reads are occasional.

AWS S3 Standard — list price:

  • Storage: 50 TB × $0.023/GB/month ≈ $1,150/month
  • Egress: 5 TB out ≈ $450/month (first 10 TB at $0.09/GB after the free 100 GB)
  • Monthly total: ~$1,600

Wasabi:

  • Storage: 50 TB × $6.99/TB/month ≈ $350/month
  • Egress: $0
  • Monthly total: ~$350

Savings: ~$1,250/month, $15,000/year. Migration cost via Mover at $0.15/GB on a 50 TB pack: $7,499. Payback in under six months.

Storage-dominated workloads usually aren't where teams move first, because the absolute dollar gap is smaller. But the percentage saving is real, and the savings compound — Wasabi at this volume is more than four times cheaper just on storage.

Workload 2 — moderate egress, the typical app

A SaaS team running 10 TB on S3 as application data, with 20 TB egress per month — reads for end-user downloads, replication to a CDN origin, backups going off-cloud. Standard moderate workload.

AWS S3 Standard — list price:

  • Storage: 10 TB × $0.023/GB/month ≈ $230/month
  • Egress: 20 TB ≈ $1,750/month ($0.09/GB on the first 10 TB, $0.085/GB on the next 10 TB)
  • Monthly total: ~$1,980

Wasabi:

  • Storage: 10 TB × $6.99/TB/month ≈ $70/month
  • Egress: $0
  • Monthly total: ~$70

Savings: ~$1,910/month, $22,920/year. Migration cost: 10 TB at $0.15/GB = $1,499. Payback in under a month.

The 20× monthly bill reduction is what gets a CFO's attention. The math doesn't depend on volume discounts or contract negotiations — it's the list price.

Workload 3 — heavy egress, the CDN origin

A media or analytics team holding 5 TB of source assets that get read constantly — say 100 TB egressed per month because the assets feed a CDN, a download service, or an inference cache.

AWS S3 Standard — list price:

  • Storage: 5 TB × $0.023/GB/month ≈ $115/month
  • Egress: 100 TB ≈ $8,260/month (tiered down to $0.05/GB at the top tier)
  • Monthly total: ~$8,375

Cloudflare R2:

  • Storage: 5 TB × $0.015/GB/month ≈ $75/month
  • Egress: $0 (R2 charges zero egress for the data itself; Class A operations are $4.50/million, Class B $0.36/million)
  • Operations on a media workload at this scale: ~$50–$200/month depending on read pattern
  • Monthly total: ~$150–$300

Savings: ~$8,000/month, ~$96,000/year. Migration cost: 5 TB at $0.15/GB = $749. Payback in three days.

This is the workload where the math approaches insulting. The team is paying the equivalent of a senior engineer to AWS every month, just to send out a few terabytes of data the team already paid to store.

What about the things AWS gives you that Wasabi / B2 / R2 don't?

Three honest answers:

Regional flexibility. AWS has ~30 regions across every continent. Wasabi, B2, R2 each have fewer (B2 has US-East / US-West / EU-Central; Wasabi has ~15 regions across NA / EU / APAC; R2 is multi-region by default but the granular control isn't as fine as AWS). For most workloads this doesn't matter — pick the destination closest to your users and you're done. For latency-sensitive workloads that need a specific region not on the destination provider's list, this is a real constraint.

Ecosystem integration. S3 is the lingua franca of AWS — Athena, Glue, EMR, SageMaker, Redshift Spectrum, Lambda triggers on S3 events, the whole stack assumes the bucket is in S3. If you're using more than a couple of those, moving the data out of S3 means re-pointing the integrations. For pure storage workloads this is a non-issue; for analytics or ML pipelines, it's the real switching cost.

For workloads that need to keep speaking S3 protocols to outside consumers — trading partners pulling files from your bucket, third-party processors writing to it on schedule, customer-facing SFTP intake — you can run Files.com as the protocol layer in front of whichever cheaper backend you land on. The outside world keeps seeing the same SFTP / S3 / API endpoint; you change the storage underneath without breaking any of the partner integrations. That's a separate post and a separate buying motion, but worth knowing it's an option before you re-architect a B2B file workflow as part of the move.

Tiered storage tiers. S3 Intelligent-Tiering and Glacier are useful for workloads that have a clear cold tail. Wasabi's pricing is flat — there's no "Glacier-equivalent" cheaper-but-slower tier. If your data has a heavy cold tail, the all-flat-rate Wasabi number might not actually beat S3 Standard + a healthy Glacier setup. Worth modeling.

Everything else — the API, the SDKs, the IAM-ish access policies, the multipart-upload behavior, the SLA — Wasabi, B2, and R2 are all S3-API compatible. Your code that talks to S3 will mostly talk to any of them with a single endpoint change.

The teams that move are the teams that read more than they archive, run mostly on the storage-as-object pattern (not the storage-as-analytics-layer pattern), and have hit a number on their AWS bill that makes them want to look harder. If that's you, the move is almost always worth the math.

What the move actually involves

Three real steps, not the brochure version.

  1. Pick the destination. The provider comparison page covers the choices — Wasabi, Backblaze B2, Cloudflare R2, Filebase, each with its own pricing model and trade-offs. The S3-compatible API surface is similar across all four; the differences are in pricing model, region coverage, and the specific egress carve-outs.
  2. Run the dry run. Free, every time, before any data moves. Mover's dry run walks your S3 bucket, counts files, sums bytes, and tells you the exact migration cost and the exact destination storage cost — so you have the real number before you commit. Most surprises happen in this step (unexpected object counts, multipart-leftover bytes, lifecycle-policy artifacts) and they get caught here, not mid-migration.
  3. Run the migration. Mover handles the transfer end-to-end. Resumable, byte-perfect verification at the destination, structured audit log of every file. The actual move is the easiest part — what takes the time is making the cutover decision and re-pointing any production paths after the data is in place.

If the workload is read-heavy enough that you'd rather keep using the data the same way you're using it today — mounting it as a drive instead of going through SDK calls — ExpanDrive mounts Wasabi, B2, R2, and S3-compatible endpoints the same way it mounts S3. Same workflow, different provider underneath, dramatically smaller bill.

If the team is going to keep running the same file operation at scale on the new backend — automation, audit logs, IAM-grade access policies, compliance posture, multi-user governance — that's where Files.com picks up. Mover handles the move; Files.com handles the operation afterward. Same vendor across both, so there's no second integration to wire up when the team's ready.

The shortest version

If the answer to "how often do we read this data?" is "often," the answer to "should we move it off AWS?" is "run the math." The dry run is free and takes about five minutes. Start there.

Ready to move? Start with a free dry run.

Every Mover migration starts with a free dry run that prices the move to the dollar. No commitment, no sales call.