The Cost Case for CloudFront: When It Saves Money and When It Doesn't

CloudFront is usually introduced as a performance tool, but in practice it is a cost tool as well. The conclusion up front: for static, cacheable content with an origin inside AWS, putting CloudFront in front is almost always cheaper; for workloads that only serve small, uncacheable API responses, request fees can make it more expensive instead. The per-GB rates look close at first glance, but two things change the math entirely: the origin-to-CloudFront leg is free, and the always-free tier covers 1TB per month. Basic setup is covered in AWS Intermediate #7 CloudFront; this post focuses on the cost calculation. Prices are for us-east-1.

Side-by-side comparison #

The structure matters more than the rate gap #

The difference between $0.09 and $0.085 per GB is around 5%, and that alone would never justify the move. Three other factors decide the outcome.

First, transfer from your origin to CloudFront is free. Traffic from S3, EC2, or an ALB to CloudFront edge locations carries no transfer charge. Even on a cache miss, where the request goes all the way to the origin, you are billed once, on the CloudFront-to-internet leg. In effect, the entire $0.09/GB of direct transfer becomes $0.085/GB.

Second, the free allowances are different. Regular internet egress comes with 100GB free per month; CloudFront comes with 1TB of transfer and 10 million requests free, permanently. A site that pushes under 1TB a month sees its transfer bill drop to zero the moment CloudFront goes in front. Served directly, the 900GB beyond the free allowance would cost about $81.

Third, cache hits cut origin costs too. At a 90% hit ratio, the origin handles a tenth of the requests, which opens room to shrink EC2 instance sizes or counts. That saving never shows up in a transfer-rate comparison, but it shows up on the bill.

When request fees become the main cost #

CloudFront’s trap is the request fee. At roughly $0.01 per 10,000 HTTPS requests, workloads that serve large volumes of small responses find this line item overtaking the transfer charge.

Running the numbers shows the boundary. If 1MB images go out 10 million times a month, transfer is about 9.5TB at roughly $810, and request fees are about $10, within rounding distance. If 2KB JSON responses go out a billion times a month, transfer is about 2TB at $170, while request fees reach about $1,000 and become the main cost. Worse, if those API responses are uncacheable, there is no hit-ratio benefit either, so compared with direct serving you lose exactly the request fees.

Even then CloudFront is not pointless. It terminates TLS at the edge, reuses connections to the origin, cuts latency for distant users, and lets you attach WAF at the edge. But that is money spent on performance and security, not savings, so the business case must not be filed under cost reduction.

Invalidation and the smaller line items #

• Invalidation: the first 1,000 paths per month are free, then $0.005 per path. Invalidating with a single /* per deploy is effectively free, but a pipeline that purges thousands of individual files pays for it. Cache busting with hashed file names is the standard answer.
• Origins outside AWS: with an on-premises or third-party origin, the origin side’s bandwidth is billed by that provider. Free origin transfer applies to AWS origins.
• Regional rate differences: the numbers above are for North America and Europe edges. Asian and South American edges cost more, so if overseas traffic is significant, Price Class settings can exclude the expensive edges.

Decision order #

1. Start with monthly transfer volume: under 1TB, there is nothing to calculate; CloudFront wins because the always-free tier zeroes out the transfer bill.
2. Check whether the content is cacheable: static files, images, video, and versioned assets make the decision automatic, since the rate cut, free origin leg, and origin offload all apply.
3. Look at response size and request count: if the average response is a few KB and monthly requests run into the hundreds of millions, compute the request fees first. If they exceed the transfer savings, there is no cost case.
4. File uncacheable traffic under performance and security: CloudFront in front of a dynamic API is paid for with latency and WAF integration in mind, not savings.
5. Verify the hit ratio after rollout: if CloudFront reports a low cache hit ratio, review Cache-Control headers and the cache key (unnecessary query strings, cookies). A low-hit-ratio distribution is a setup that pays twice.

Summary #

• With an AWS origin, the origin-to-CloudFront leg is free, so cacheable content is almost always cheaper served through CloudFront than directly.
• The always-free 1TB is large enough that sites under 1TB a month pay nothing for transfer. Direct serving only gets 100GB free.
• High-volume small responses make the request fee (~$0.01 per 10,000 HTTPS requests) the main cost. For uncacheable APIs that is a net loss, justified only by performance and security.
• Invalidation bills per path, so use hashed file names instead; a low hit ratio means fixing the cache key before anything else.
• The full transfer-pricing picture continues in the next post. If your bill jumped unexpectedly, start with the 10 most common causes.