The CloudFront Bill That Didn't Add Up
The client runs a high-traffic mobile application with millions of daily active users in India, making real-time API calls. CloudFront fronts a dynamic backend: heavy reads and writes, minimal static content. When we pulled their Cost and Usage Report, the composition of the bill stood out immediately.
Request charges were 91% of the bill. Data transfer on 43 terabytes was 9%. That ratio was the first signal that something interesting was going on.
Most teams, when they think "CloudFront is expensive," think data transfer — gigabytes piling up at $0.109/GB. But this client had a negotiated data transfer rate of $0.01/GB, a flat deal arranged with their AWS account team after consistently crossing 10 TB/month. That agreement compressed $3,971 of data transfer cost down to $441. Without it, their monthly bill would have been $8,249.
The deal was saving them $3,530 every single month. Almost nobody on the team knew it existed.
This is the first principle of AWS CloudFront cost optimisation: your CUR and your invoice are not the same document. The CUR reflects list rates. Your invoice reflects whatever commercial terms you have negotiated. If you're doing cost analysis from CUR data without accounting for this, you're starting with the wrong numbers.
How AWS CloudFront Billing Actually Works
Before comparing CloudFront vs load balancer options, it helps to understand exactly what CloudFront charges you for — because it has two metering dimensions that behave very differently.
Requests are billed per 10,000 HTTP/HTTPS requests, segmented by method. Write requests (POST, PUT, DELETE, OPTIONS) are billed as HTTPS-Proxy requests and always forwarded to the origin. Read requests (GET, HEAD) are billed as Tier2-HTTPS, some may be served from cache, but you're charged either way. There is no volume discount on standard request pricing, regardless of scale.
Data transfer follows tiered regional pricing, but this is where negotiation becomes a real cost lever. Standard India rates run $0.109/GB for the first 9 TB and $0.085/GB for the next 40 TB. At 10 TB/month or more, AWS will negotiate. Customers at significant volume routinely secure flat rates 80–90% below list. It isn't advertised, but it happens regularly.
At scale, data transfer is a negotiable line item. Request pricing is not, by default. Most teams optimise for the wrong dimension, or don't realise the deal they already have.
For this client: 3.56 billion requests per month, averaging 1,331 per second. With only 5–10% of content cacheable, CloudFront was functioning less as a CDN and more as a globally distributed reverse proxy, absorbing DDoS traffic and terminating TLS at the edge.
CloudFront Cost Optimisation: Where Most Teams Look, and Where They Should
If you ask most engineers about CloudFront cost optimisation, they'll point to caching, increasing TTLs, improving hit ratios, and reducing origin load. That advice isn't wrong. It's just incomplete.
In high-scale, API-heavy architectures, caching is not the primary cost lever. Requests are.
This client had a 5–10% cache hit ratio. Even doubling it would have had a negligible impact on request charges, because CloudFront bills every request, whether it hits the cache or not. The only thing improved caching reduces meaningfully is origin compute cost — not edge request cost.
Effective AWS CloudFront cost optimisation at this scale comes from three places that rarely surface in documentation:
1. Eliminate unnecessary request classes. OPTIONS requests (CORS preflight) are billed as HTTPS-Proxy requests and always hit the origin unless explicitly cached. In mobile-heavy architectures, they can account for 10–20% of total request volume. Caching them at the edge isn't an advanced optimisation, it's table stakes.
2. Normalise request patterns upstream. Every unique query string variation is a cache miss and a billable request. Poorly structured APIs can quietly multiply request cardinality. Fixing this before traffic reaches CloudFront reduces both edge cost and origin pressure.
3. Treat pricing as part of your architecture. At scale, your effective cost model includes your commercial agreement with AWS, not just your configuration. Ignoring that is like ignoring a misconfigured load balancer.
As a rough guide: below ~1 billion requests/month, focus on architecture. Above that, CloudFront cost optimisation is as much a commercial conversation as it is a technical one.
CloudFront vs Load Balancer: Running the Numbers Honestly
So would ALB actually be cheaper? We modelled it from first principles using actual AWS pricing for ap-south-1. The examples AWS publishes use us-east-1 rates, which don't apply here, regional pricing matters.
ALB is $645/month cheaper. On a pure cost basis, the model says migrate.
But that is exactly where most cost analyses stop, and where the real work begins.
CloudFront vs ALB: The Comparison Most People Get Wrong
The CloudFront vs. ALB debate is usually framed as CDN versus routing layer. That framing breaks down the moment your workload is low on cacheable content.
In this case, CloudFront wasn't behaving like a CDN. It was acting as a globally distributed reverse proxy with three specific structural advantages: edge TLS termination, DDoS absorption before traffic reaches your region, and request filtering at the edge rather than at the origin. Understanding that reframes the entire CloudFront vs. ALB comparison.
Here are the three places where most cost analyses of CloudFront vs ALB go wrong:
They compare unlike pricing units. CloudFront charges per request. ALB charges per LCU-hour, a composite of connections, bytes processed, and rule evaluations. These are not equivalent. At high request rates with small payloads (typical of mobile APIs), ALB looks artificially inexpensive because LCUs are dominated by processed bytes, not request count.
They ignore data transfer asymmetry. CloudFront data transfer is negotiable at scale and often heavily discounted. ALB data transfer rides on EC2 egress pricing, which has far less flexibility. In this case, that difference alone turned a $4,000/month gap into a $645/month gap. The negotiated deal is almost the entire story.
They underestimate the security cost externalities. With CloudFront, malicious traffic is dropped before it reaches your AWS region. With ALB, that traffic enters Mumbai, consumes capacity, and can appear on your egress bill before Shield blocks it. During a sustained volumetric attack, that cost could erase a year's worth of $645/month savings in a single incident.
The CloudFront vs. ALB decision ultimately comes down to one question: Are you paying for distribution, or just for transit? If your workload benefits from global edge presence, latency reduction, DDoS absorption, and worldwide TLS termination, CloudFront is additive. If every request must hit the origin anyway and your users are geographically concentrated, CloudFront becomes an expensive pass-through, unless your pricing has been negotiated.
The Number That Changes the Entire CloudFront vs Load Balancer Comparison
The $645/month gap exists almost entirely because of the $0.01/GB data transfer deal. Without it, CloudFront's data transfer cost would be $3,971/month, making CloudFront $4,175/month more expensive than ALB.
Which surfaces an obvious follow-up question: if data transfer is negotiable, what about requests?
CloudFront request pricing is also negotiable at sufficient volume. This client processes 3.56 billion requests per month, consistently, across a full quarter of data. That's a baseline, not a spike, and it's exactly the kind of volume AWS account teams can work with.
A 25% reduction on CloudFront HTTPS request pricing would bring the monthly bill from $4,719 to approximately $3,649, making CloudFront $425/month cheaper than ALB, without changing the architecture, the security posture, or the deployment. One commercial conversation.
baseline
At this request volume, with an existing relationship that already produced one pricing deal, the commercial case is straightforward. The AWS account team has a clear incentive to keep this workload on CloudFront rather than lose it to a migration.
What an ALB Migration Actually Costs
Cost modelling typically measures what you pay AWS. It rarely accounts for what migration itself costs, or what you give up.
Security. CloudFront with AWS Shield Standard absorbs DDoS traffic at the global edge. Attack packets are dropped before they reach ap-south-1, before they touch the ALB, before they consume backend compute. With ALB alone, Shield Standard still operates, but regionally. Attack traffic enters Mumbai, occupies ALB capacity, and shows up on the egress bill before being blocked. A sustained volumetric attack could spike costs by more than $645/month in a single incident, erasing the annual savings in one event.
Performance. CloudFront terminates TLS at the nearest edge location globally. For a predominantly India-based user base, the delta is smaller; Mumbai ALB serves Indian users well. But any international traffic incurs full TLS round-trip latency to ap-south-1 on every request. If the product has growth ambitions beyond India, that is a regression that is hard to undo cheaply.
WAF position. CloudFront WAF evaluates requests at the edge. Blocked requests generate zero origin cost. ALB WAF evaluates at the regional load balancer; malicious traffic crosses the public internet to Mumbai before any evaluation occurs. The security outcome may be similar, but the resource profile is different.
Engineering effort. Ten CloudFront distributions. Each requires individual assessment: SSL certificates reconfigured, WAF rules rebuilt in a different format, CloudFront Functions evaluated for replacement, and DNS cutover coordinated across environments. A realistic multi-week project with non-trivial regression risk. At $645/month delta, break-even on that engineering investment is approximately eight months, before factoring in ongoing operational differences.
When to Choose CloudFront vs Load Balancer: A Decision Framework
The CloudFront vs. ALB decision isn't universal. The economics shift significantly as workload parameters change.
Content-heavy platform (60–70% cacheable). CloudFront's economics become dramatically stronger. Cache hits reduce origin load, which reduces backend compute requirements. At 100+ TB/month egress, a negotiated data transfer deal compounds into a structural advantage that ALB's EC2 egress pricing can't replicate. CloudFront wins clearly.
Write-heavy ingestion service (80–90% POST/PUT). CloudFront's caching offers no benefit. Every request hits the origin at full price. ALB is the right tool, with no meaningful trade-off.
Global SaaS with distributed users. CloudFront's edge network is genuinely additive, with global TLS termination, DDoS absorption everywhere, and consistent latency regardless of where connections originate. Cost comparisons at moderate volumes often favour CloudFront even before factoring in the performance premium.
Low-traffic internal tool. ALB's $17/month fixed cost means CloudFront can be marginally cheaper at low volume. Operational simplicity should drive the decision.
What We Actually Recommended
We told the client not to migrate. Not yet.
The $645/month gap is real, but the more productive path was commercial, not architectural. The first move: engage the AWS account team on request pricing, using the precedent of the existing data transfer deal. A 25% reduction, a reasonable ask at 3.56 billion requests/month, flips the CloudFront vs ALB comparison, making CloudFront cheaper without touching infrastructure.
The second move was configuration-level CloudFront cost optimisation: cache OPTIONS preflight responses at the edge to eliminate repeat HTTPS-Proxy charges for CORS requests, and extend TTLs on versioned static assets. Neither requires application changes. Together, they contribute another $150–$250/month.
Combined path: a realistic route from $4,719/month to approximately $3,300–$3,500/month, meaningfully cheaper than ALB, with a stronger security posture, zero migration risk, and no engineering disruption.
The broader lesson: never make an infrastructure migration decision on cost alone without separating your CUR from your invoice and understanding which line items are negotiable. In CloudFront's case, the most important cost variable doesn't appear in any dashboard. It lives in a commercial agreement that most engineering teams don't know exists.
.jpeg)
