Data transfer out to the internet is billed per GB from wherever it leaves AWS — an EC2 instance, an ALB, an S3 bucket serving objects directly. It's easy to overlook because there's no single "egress" line item to stare at; it's spread across whichever services are directly internet-facing.
The same bytes, served once
The core inefficiency is repeat work: if a hundred people request the same image, video segment, or API response within a short window, an origin serving that request directly pays the egress rate a hundred times over. A CDN sitting in front of the origin serves the cached copies from edge locations and the origin only sees a fraction of that traffic.
Every viewer re-fetching from the origin pays the same per-GB egress rate. A CDN serves repeat requests from cache at a lower rate and the origin stops seeing that traffic at all.
CloudFront's per-GB rate is typically lower than EC2-to-internet or ALB-to-internet transfer for the same traffic, and data transfer from an origin to CloudFront within AWS is usually cheaper still than transfer to the internet directly. The origin's egress bill and CloudFront's request/transfer bill are two different, smaller numbers instead of one large one.
Where this gets missed
- Static assets served straight from S3 or an origin server instead of through a CDN — the most common case, especially for sites that started small and never revisited the architecture as traffic grew.
- API responses that are cacheable but routed straight to the origin — not everything needs a CDN in front of it, but a response that's identical for every caller for some window of time is being re-computed and re-transferred for no reason.
- Cross-region architectures where "internet" egress is actually inter-region egress — check whether traffic between your own regions is routed in a way that avoids public internet pricing where a private path is available.
Checking whether it's worth doing
Cost Explorer's data transfer usage types, broken out by service, will show whether egress is concentrated in one place or spread thin. A CDN is worth adding when the same origin traffic is genuinely being re-requested — for traffic that's already unique per request (personalized responses, one-time downloads), a cache in front of it won't cache anything and won't move the number.