Want to see a real system design implementation that cut AWS costs and scaled a project to millions of users? Here's exactly what we built, why we built it, and the numbers behind it from our own project, over the last six months.
The problem: one origin, serving the world
Our stack serves large static content (images, video, PDFs) out of a single Amazon S3 bucket. Simple, standard, and it worked fine at small scale. The origin server for that bucket sits in US East (N. Virginia).
The trouble started once traffic grew. Every single request,no matter where in the world it came from went straight to that one bucket in Virginia. Two problems showed up almost immediately:
Origin overload: Every request, cacheable or not, was a full round trip to the same bucket. As traffic climbed, so did the load on that single origin.
Latency in Asia-Pacific: Users physically farthest from us-east-1 felt it the most video buffered, images loaded slowly, and the experience on our portal noticeably lagged for that region specifically.
That combination an overloaded origin and a geography problem is what sent us looking for a real fix, not a patch.
The fix: put CloudFront in front of S3
The solution was Amazon CloudFront, AWS's content delivery network (CDN), sitting between users and our S3 bucket.
Here's the part that matters, and it surprises people the first time they hear it: CloudFront doesn't hit your origin on every request . Instead:
- A user requests a file.
- CloudFront checks the nearest edge location first.
- Cache hit - the file is already there → it's served immediately, with no trip back to Virginia at all.
- Cache miss - the file isn't cached yet → CloudFront pulls it from the S3 origin once, serves it to that user, and caches a copy at the edge location.
- Every request after that - from that same user or anyone else nearby gets served straight from the cached copy.
In other words, only the first request for a given file ever really touches the origin. Everyone downstream gets it fast, and the origin barely notices.
What that actually buys you
Putting a CDN in front of an origin gives you four concrete things, not just "it's faster":
- Latency reduction: content is physically closer to the user, so round-trip time drops.
- Scalability / origin offload: the origin only serves cache misses, not every request, so it scales independently of read traffic.
- Availability: a distributed edge network is far more resilient than a single origin server taking every hit directly.
- Cost efficiency: fewer origin requests and less direct S3-to-internet egress, plus CloudFront's own pricing model, changes the cost equation (more on that below).
The scale behind CloudFront's edge network
This is what makes the latency fix possible in the first place. As of 2026, Amazon CloudFront runs:
- 750+ Points of Presence (edge locations)
- 15 Regional Edge Caches sitting between your origin and those edge locations
- Spread across 100+ cities in 50+ countries
That's the global network doing the work. An Asia-Pacific user isn't reaching across the Pacific to Virginia anymore; they're hitting a cache a few hundred miles away.
The cost question: which CloudFront pricing model?
Adding a CDN solves latency and origin load. It doesn't automatically solve cost that depends on which CloudFront pricing model you run it on, and this is where we spent real time evaluating options.
AWS currently offers two models side by side:
- Flat-rate plans: a fixed monthly price bundling the CDN with WAF, DDoS protection, Route 53 DNS, CloudWatch logging, a TLS cert, and edge compute, with no overage charges. The Pro tier is $15/month for 50TB of transfer and 10M requests.
- Pay-as-you-go: the classic model. You pay per GB transferred, per 10,000 requests, and separately for every extra feature (WAF, DNS, logging) you turn on, with the first 1TB of transfer and 10M requests each month free.
We ran our actual numbers 100GB in S3, ~2M requests/month, ~2TB of data transfer/month through both models to see which one actually made sense.
| Item | Pay-as-you-go | Pro plan (flat-rate) |
|---|---|---|
| S3 storage (100GB) | $2.30 | ~$1.15 (50GB credited) |
| CloudFront transfer (2TB, 1TB free + 1TB billed) | $85.00 | included, up to 50TB |
| CloudFront requests (2M, within free tier) | $0 | included, up to 10M |
| Route 53 DNS | ~$1.30 | included |
| CloudWatch Logs | ~$1.50 | included |
| AWS WAF (10 rules) | ~$16.20 | included |
| Total | ~$106.30/month | ~$16.15/month |
That's roughly $90/month, or ~$1,082/year, saved an 85% reduction just from choosing the right pricing model, with zero change to the architecture itself.
Two things drove that gap:
- The free tier is a cliff, not a slope. Pay-as-you-go's free tier covers exactly 1TB of transfer. Past that line, every extra 100GB adds about $8.50, linearly. At 2TB, we were a full terabyte past the edge.
- WAF pricing adds up fast on its own. AWS WAF bills $5 per Web ACL, $1 per rule/month, and $0.60 per million requests. A realistic 10-rule setup already costs more than our entire flat-rate Pro plan bill before counting DNS or logging.
And the gap only grows with scale, since the flat plan's bill doesn't move until usage passes 50TB or 10M requests:
| Monthly transfer | Pay-as-you-go | Pro plan (flat) |
|---|---|---|
| 500GB | ~$21.30 | $16.15 |
| 1TB | ~$21.30 | $16.15 |
| 2TB | ~$106.30 | $16.15 |
| 5TB | ~$361.30 | $16.15 |
Results, six months in
Since rolling this out, we've scaled to millions of users without the origin-overload or Asia-Pacific latency problems that started this whole effort and we cut our CDN-related AWS spend by 50% compared to the direct-S3 setup we started with. The concrete example above 85% cheaper by picking the right CloudFront pricing tier is one real, checkable piece of where that savings came from; the rest comes from fewer origin fetches and less direct S3 egress once caching took over.
Takeaways if you're building this yourself
- If you're serving static assets (images, video, PDFs) at any real scale, put a CDN in front of your origin. Don't wait until the origin is visibly struggling.
- Watch your geography. If your origin is in one region and users aren't, that's exactly where a CDN's edge network pays for itself.
- Don't assume "pay-as-you-go" is automatically cheaper than a flat-rate plan. Price both against your real traffic especially once WAF, DNS, or logging are in the mix.
- Re-check the comparison as you scale. The cheaper option at 500GB/month isn't necessarily the cheaper option at 2TB/month.
Cost figures above are illustrative estimates based on AWS list pricing (us-east-1) at the time of writing, not an official AWS quote. WAF and logging costs will vary with your actual rule count and log volume.
Top comments (0)