Cut your egress bill without leaving AWS: the hybrid path

TL;DR. The scariest line on your AWS bill — egress, the per-gigabyte fee to send your own data out to your users — is usually concentrated in one place: object storage (the media, downloads, images and assets you serve from S3). You can cut that line without touching your app, your compute, or your database. Keep everything on AWS, and move only the serving of those files to a zero-egress S3-compatible store (Cloudflare R2, Backblaze B2) — or just put a CDN in front of S3. Keep S3 itself as your source of truth and fallback. It’s reversible, it’s a config change rather than a rewrite, and it captures the single biggest saving for the least risk. Often it’s where I’d start — and sometimes where I’d stop.

You don’t have to leave to stop the bleeding

Most “cut your cloud bill” advice splits into two camps: optimize and stay (squeeze discounts out of AWS) or leave (migrate everything off). There’s a third path that’s lower-risk than either, and it’s the one most teams should try first:

Move the one layer that bleeds — the egress-heavy file serving — and leave everything else exactly where it is.

Your app servers, your database, your queues, your managed services: all stay on AWS, untouched. The only thing that moves is where your users download bytes from. Because that’s where the egress meter runs hardest, moving just that one layer captures most of the savings — with almost none of the risk people associate with “leaving the cloud.”

Why this is the low-risk move (and easy to sign off on)

This is the version a cautious owner, CFO or CTO can approve without losing sleep:

That combination — biggest saving, smallest blast radius, fully reversible — is why this is usually the first move, not the last.

The three ways to do it (least effort first)

1. Put a CDN in front of S3 (no data migration at all)

A CDN caches your files at the edge, so repeat requests are served from the cache and never touch S3 egress. Cloudflare’s free tier or bunny.net in front of your existing bucket removes most of the bill without moving a single byte. The only egress you still pay is the occasional cache miss fetching from S3 — small, if your files are cacheable. Lowest-effort option, and a fine place to stop for many sites.

Caveat: this helps for cacheable content (images, video, downloads, static assets). Truly dynamic, per-user responses don’t cache, so a CDN won’t fix egress that comes from your application rather than your files.

2. Mirror S3 to a zero-egress store, serve from there

Keep S3 as the canonical copy, replicate it to a zero-egress S3-compatible store, and point your CDN/app at the copy for serving:

S3 stays your source of truth; the cheap store is just the cheap serving path. You’ve decoupled “where the canonical data lives” from “where users pull it from” — and only the second one was costing you egress.

3. Migrate gradually, copy-on-read (no cutover)

You don’t have to move everything at once. Cloudflare R2 can pull objects from your S3 bucket on demand: the first time an object is requested from R2 and isn’t there yet, R2 fetches and copies it from S3 automatically (Cloudflare calls this Sippy), with a bulk copy tool (Super Slurper) handling the rest in the background. So your files migrate themselves as they’re used, S3 stays authoritative until each object is copied, and there’s never a flip-the-switch moment.

When the hybrid is enough — and when it isn’t

The hybrid is the right call when:

It won’t be enough when:

The honest framing: the hybrid move is the wedge. It captures the biggest, easiest saving with the least risk. If that’s all you needed, wonderful — stop there. If more of your bill is still bleeding afterward, you’ve now got a low-stakes proof that the approach works, and you can move the next layer when you’re ready.

Quick wins you can do this week

  1. Find your egress line and check how much of it is object-storage serving vs. application traffic (group your bill by usage type; see S3 egress cost).
  2. If it’s cacheable files, put Cloudflare’s free tier or bunny.net in front of the bucket — measure the drop before doing anything else.
  3. If egress is still high, stand up an R2 or B2 bucket, mirror a slice of your data, and serve it to a small percentage of traffic to prove the saving.
  4. Keep S3 as the source of truth throughout — you’re adding a cheaper path, not removing your safety net.

Want to know how much of your egress is the easy object-storage kind versus the harder application kind — send me your cloud bill and I’ll break it out and tell you whether the hybrid move alone gets you there, free, in 24 hours. Read by me, never shared. Or see the Cloud-Exit Assessment for the full picture.

Sources

Don't miss new posts

I publish honest, sourced breakdowns of cloud-exit economics — egress, storage, monitoring, reliability — and the occasional announcement. Leave your email and I'll let you know when something new goes up.

Double opt-in — you'll get one email to confirm. No spam, unsubscribe anytime. Read by me, never shared.