Case study · 2026
32 GB to 32 TB in nineteen days
A marketing site's video bandwidth went up a thousandfold and the cache headers did nothing. The fix was moving the bytes off Vercel's edge entirely, with a redirect the same afternoon and CloudFront for good.
Context
A marketing site on Vercel served ten testimonial videos straight from the Next.js public folder. It had cost 32 GB/month of bandwidth. Then it was 32 TB in nineteen days, and a four-figure overage bill for a page nobody had touched.
The problem
The obvious fixes had already been tried: drop preload="auto", add Cache-Control headers. Zero effect. Each video was receiving ~27,000 requests in twelve hours and moving 80–92 GB. That is not an audience; that is hotlinking, scraping, or both.
What I did
- Explained why headers can’t help: Vercel bills every byte that leaves its edge, first request or thousandth, human or bot. Browser caching only affects a returning visitor. A Next.js rewrite to a CDN makes it worse — Vercel proxies the whole file and bills it again.
- Shipped a middleware
301redirect (not a rewrite) for video paths to CloudFront, backed by S3 with Origin Access Control. - Added a WAF rate limit on video paths and a spend budget alert.
- Planned the permanent version: a
cdnUrl()helper, components pointing at CloudFront, middleware removed. - Kept delivery inside services covered by the existing AWS BAA rather than reaching for Cloudflare R2, which has no self-service BAA.
The trade-off
The redirect adds a hop for a few weeks but ships in thirty minutes. CloudFront’s pay-as-you-go is cheaper than Vercel; its flat-rate plan is a rounding error.
Outcome
Projected 97–99.7% reduction in delivery cost once the video bytes stop crossing Vercel’s edge. The redirect and the rate limit went out the same afternoon; the permanent version was scheduled for the next sprint.
What I’d do differently
Never ship video from the app origin — Vercel even has a conformance rule that says so. And set spend alerts before the month you need them.