I've been complaining about CloudFront pricing for the better part of a decade. Not because it was expensive—though it often was—but because nobody could tell you what it would cost until the invoice arrived. Not customers. Not AWS sales. I'm half-convinced not even the CloudFront team knew.
In November, AWS quietly (not intentionally quietly, mind you; they just forgot it was re:Invent season and it got lost in the noise) launched flat-rate pricing bundles for CloudFront. I've been sitting on this take for two months because I wanted to see if I was missing something.
I wasn't.
The Numbers That Matter
Per distribution:
| Plan | Monthly Cost | Data Transfer | Requests | Break-even File Size |
|---|---|---|---|---|
| Free | $0 | 100 GB | 1M | 100 KB |
| Pro | $15 | 50 TB | 10M | 5 MB |
| Business | $200 | 50 TB | 125M | 400 KB |
| Premium | $1,000 | 50 TB | 500M | 100 KB |
That last column is the one AWS doesn't advertise: the average request size you'd need to max out both limits simultaneously. The Pro plan's 50 TB / 10M requests means you need 5 MB average responses to use what you're paying for. If you're serving software binaries or video chunks, that's realistic. If you're serving API responses or web assets, you'll hit the request ceiling long before you touch the bandwidth.
Now the math AWS hopes you won't do. Under pay-as-you-go pricing, 50 TB of data transfer out to internet from North America runs about $0.085 per GB. That's $4,250. The Pro plan offers the same 50 TB for $15.
That's not a "discount," that's a 99.6% price reduction for bandwidth-heavy workloads. I double-checked this math three times because it seemed like a typo.
Credit where it's due: this is genuinely good. I don't say that often about AWS pricing changes. Usually "simplified pricing" means "we moved the complexity somewhere you won't notice until the bill arrives, and the reworked pricing dimensions mean your bill just skyrocketed." This time? $15 for 50TB is just… a good deal. I'm as surprised as you are.
To put it in smaller terms: 10 TB/month on pay-as-you-go runs roughly $765 in egress alone (before WAF, DNS, and logging). The Pro plan covers that plus all the bundled services for $15. At 20 TB/month, traditional pricing approaches $1,565. Still $15.
Most AWS accounts that've been around longer than twenty minutes have a graveyard of CloudFront distributions. The one you created for a demo in 2019. The staging environment nobody decommissioned. The "temporary" test setup that has now outlived three engineers and two corporate reorgs. The one named "DO-NOT-DELETE-ASK-JENKINS" that nobody has touched since Jenkins was replaced by GitHub Actions in 2022, but everyone's too afraid to find out what breaks. This pricing only matters for the one or two distributions actually doing work. The rest can stay on pay-as-you-go at effectively zero cost, since they're serving traffic to an audience of exactly nobody.
The Cloudflare Elephant
Cloudflare Pro costs $25/month (or $20/month with annual commitment) and includes unlimited bandwidth. No caps. No throttling. CloudFront Pro is $15/month with 50TB and 10M requests.
On paper, Cloudflare wins. On your actual infrastructure, AWS wins—and they know it.
If your origin is S3 or EC2, you currently pay $0 in egress to CloudFront—data transfer within AWS is free. Switch to Cloudflare and you start paying AWS egress charges: roughly $0.09/GB. At 50TB/month, that's $4,500 in egress alone, every month, forever, unless you store static assets in their S3-alike. (I know, there are exceptions; this math is intentionally illustrating extremes.)
AWS can afford to offer 50TB for $15 because they know you're not leaving. The real price of CloudFront flat-rate isn't $15/month—it's $15/month plus the AWS ecosystem lock-in you've already accepted.
For greenfield projects with no AWS dependency, Cloudflare's unlimited bandwidth (until it isn't, but you'll get a sales call instead of a Surprise Invoice) is hard to argue with. For existing AWS shops, the math gets complicated fast.
What's Actually Included
Each plan bundles services that would otherwise require separate billing adventures:
- CloudFront CDN (obviously)
- AWS WAF with bot management (mandatory—you can't opt out; WebACL must be associated)
- DDoS protection (blocked attacks never count against your allowance)
- Route 53 DNS (with caveats—see below)
- CloudWatch Logs ingestion (but not storage or querying—those still cost money)
- TLS certificates via ACM
- CloudFront Functions (serverless edge compute)
- S3 storage credits (5GB Free / 50GB Pro / 1TB Business / 5TB Premium—offsets any S3 Standard storage in your account)
Route 53 gotchas:
- Hosted zone must be in the same AWS account as the CloudFront distribution. Cross-account Route 53 setups don't work with flat-rate plans.
- ALIAS records pointing to CloudFront or other supported AWS services don't count against your DNS query allowance, but CNAME records do.
- If you exceed DNS query limits, AWS can automatically transition your hosted zone back to pay-as-you-go without asking.
- DNSSEC KMS costs and health checks bill separately.
The WAF value: Pro tier gets 25 WAF rules versus 5 on free. Each rule normally costs $1/month. That's $25/month in WAF value for a $15 plan. If you were going to use WAF anyway, the Pro tier pays for itself in WAF rules alone.
The WAF catch: WAF is mandatory on flat-rate plans. AWS, in their infinite wisdom, has decided you need a Web Application Firewall whether you want one or not. Running a simple static site and consider WAF overkill? Too bad. You're getting it anyway (though you need not configure it with any rules). I'm sure this has nothing to do with WAF being a separate revenue stream they'd like you to get comfortable with.
The Limits Nobody Talks About
Each tier has quotas beyond requests and bandwidth:
| Limit | Free | Pro | Business | Premium |
|---|---|---|---|---|
| Cache behaviors | 5 | 10 | 50 | 100 |
| WAF rules | 5 | 25 | 50 | 75 |
| Route 53 records | 50 | 100 | 1,000 | 5,000 |
| DNS queries (non-ALIAS) | 1M | 5M | 20M | 100M |
| Request body inspection | 16 KB | 16 KB | 64 KB | 64 KB |
Cache behaviors are the sleeper constraint. If you have a complex site with different caching rules for /api/*, /static/*, /images/*, and a dozen other path patterns, you might hit the Pro tier's 10-behavior limit before you touch the request ceiling. Business tier jumps to 50, which is why some organizations will end up there even with modest traffic.
Tier-Locked Features
Not all features are available on all tiers:
| Feature | Availability |
|---|---|
| Geographic restrictions | Free and above |
| Rate limiting | Free and above |
| Common bot detection | Business and Premium only |
| Origin Shield (load reduction + performance) | Business and Premium only |
| Custom response headers (CSP, CORS) | Business and Premium only |
| Private VPC origins | Business and Premium only |
| Automatic origin failover (origin groups) | Premium only |
| Mutual TLS (mTLS) | Premium only |
That origin failover restriction is significant. The December 2021 us-east-1 outage is a concrete example where origin groups would have prevented P1 incidents for a lot of companies. If high availability matters, you're looking at Premium ($1,000/month) or staying on pay-as-you-go.
What's NOT Included
Lambda@Edge doesn't work with flat-rate plans. This is the one that's going to hurt.
If your architecture depends on complex edge transformations, request manipulation, or origin selection logic that lives in Lambda@Edge—and you'd be surprised how many architectures accidentally evolved this dependency without anyone noticing until the architect left—you're stuck on pay-as-you-go. No migration path. No "CloudFront Functions are basically the same thing." They're not. CloudFront Functions are a toy by comparison: 2MB memory, 10KB code, JavaScript only, no network access, no AWS SDK. If you're doing anything more sophisticated than header manipulation, Lambda@Edge is why, and flat-rate pricing is not for you.
Here's the uncomfortable reality: Lambda@Edge is basically unmaintained at this point. CloudFront Functions is AWS's "way forward," and flat-rate pricing makes that crystal clear. If you're dependent on Lambda@Edge capabilities, AWS isn't building a bridge for you—they're hoping you'll eventually accept the limitations of CloudFront Functions or stay on pay-as-you-go forever. Neither option is great.
I suspect this exclusion is load-bearing. Lambda@Edge workloads are unpredictable by nature—that's the whole point of running arbitrary code at the edge. AWS can't flatten pricing on something they can't model. Fair enough. But they could have been clearer about this being a fundamental constraint rather than burying it in a compatibility matrix.
I counted 23 features that won't work with flat-rate plans. Most are obscure, but a few will bite:
Compute & Logging:
- Lambda@Edge (covered above—this is the big one)
- Real-time logs (standard CloudWatch Logs only; no Kinesis streaming)
- Parquet format logs (extra cost)
Distribution Features:
- Continuous deployment and staging distributions
- Multi-tenant distributions
- Anycast IP list configuration
- Field-level encryption
- Dedicated IP/SSL (SNI only)
- Legacy cache settings (must use cache policies)
- Origin access identity/OAI (must migrate to OAC)
- IAM server certificates (must use ACM)
Security Features:
- Can't combine with Shield Advanced
- Can't combine with Firewall Manager
WAF Features Excluded:
- Targeted Bots (common bot detection is included at Business tier, but targeted/advanced bot mitigation is not)
- CAPTCHA (challenge only)
- Partner Managed Rules
- Account Creation Fraud Prevention
- Account Takeover Protection
- Rule Groups (must create individual rules)
The Shared Resources Trap:
If your CloudFront Functions or WAF WebACLs are shared across multiple distributions, you can't subscribe those distributions to flat-rate plans. Each plan requires dedicated, non-shared resources.
This means organizations that built reusable edge function libraries or centralized WAF rule sets face a choice: duplicate those resources per distribution (operational overhead) or stay on pay-as-you-go.
The One-Domain-Per-Plan Problem
The constraint that kills flat-rate for multi-tenant SaaS: one apex (root) domain per plan.
If you're running a platform where each customer gets their own subdomain (customer1.yourplatform.com, customer2.yourplatform.com), you're fine—subdomains under the same apex can share a plan.
But if you're serving customer-owned domains (customer1.com, customer2.com), each apex domain needs its own plan. Fifty customer domains? Fifty plans. And there's a hard cap: 100 plans maximum per AWS account. Beyond that, you need multiple AWS accounts or a different architecture.
For multi-tenant SaaS with custom domains, flat-rate pricing doesn't scale. Stay on pay-as-you-go or rethink your domain strategy.
Account-Level Restrictions
The limits nobody reads until they hit them:
- 100 plans maximum per AWS account (across all tiers)
- 3 Free plans maximum per AWS account
- AWS Free Tier accounts are ineligible entirely—you need a paid account
- Exceeding 500M requests OR 50TB/month? You can't self-serve. Contact AWS sales for custom pricing.
The Tier Differentiation Problem
Look at what actually changes between Business ($200) and Premium ($1,000): more requests, more cache behaviors and WAF rules, origin failover, mTLS, and Origin Shield for load reduction.
What doesn't differentiate them is more telling. Geographic restrictions and rate limiting are available on every plan, including Free. Common bot detection starts at Business. So the gap between Business and Premium boils down to high-availability architecture (origin failover) and mTLS. That's it.
Nobody choosing between self-service tiers cares about advanced CDN security features. By the time you're dealing with sophisticated bot attacks and need custom WAF rule sets, you're in enterprise territory with negotiated contracts and dedicated TAMs. You're not comparison shopping on a pricing page.
AWS got lost in the weeds here. They built differentiation for a customer that doesn't exist at these price points. (I could be wrong about this—maybe there's a thriving market of mid-sized companies who desperately need origin failover but won't spring for enterprise contracts. If so, they're not my clients so I don't know where they're all hiding.) The actual decision points are:
- Do I fit in Pro's cache behavior limits? (10 behaviors)
- Do I need more than 10M requests?
- Do I need origin failover? (Premium only)
- Do I need mTLS? (Premium only)
Everything else is a rounding error.
The "No Overages" Fine Print
AWS's marketing emphasizes "no overage charges," which is technically true but deserves an asterisk the size of us-east-1. When you exceed your allowances, AWS doesn't bill you more—they (potentially) degrade your performance. From the documentation: "AWS may take appropriate action, which may include reducing your performance (for example, serving your traffic from fewer or more distant edge locations)."
The operational nightmare that isn't being mentioned is there's no discernable signal when this happens. "We're being rate-limited by our CDN plan" and "CloudFront is just slow today" look identical from your monitoring. Your on-call engineer at 2 AM isn't going to intuit that the latency spike correlates with hitting a request cap on a pricing plan they didn't know existed. They're going to spend three hours checking origin health, reviewing recent deployments, and questioning their career choices.
It gets better. AWS says usage notifications "may be delayed." You'll get emails at 50%, 80%, and 100% of your allowance—eventually. Meanwhile, you might already be throttled. Build your own alerting against the CloudFront metrics. Don't rely on AWS to tell you in time, because they won't.
You won't get a surprise bill, so much as you'll get a surprise outage investigation that ends with "oh, we were throttled and nobody told us." That's worse. A bill is something that you can explain to finance. A P1 incident where the root cause is "we forgot about a pricing tier limit" is the kind of thing that ends up in postmortems with the word "embarrassing."
There is one bright spot: blocked DDoS attacks and WAF-rejected requests don't count against your allowance. If you get attacked, at least the malicious traffic won't eat your quota.
Who Should Switch Tomorrow
Obvious wins:
- Content-heavy distributions under 10M requests/month serving large files (software downloads, video, firmware updates)
- Organizations that have been meaning to adopt WAF but kept putting it off because the pricing was impossible to predict
- Teams whose finance departments have threatened violence over variable CDN bills (you know who you are)
- Existing AWS shops with S3/EC2 origins—the egress trap doesn't apply to you, so the Cloudflare comparison is irrelevant
- Simple sites with fewer than 10 cache behaviors and no edge compute ambitions
Test carefully first:
- Media streaming (ad beacons and playlist manifest requests add up faster than you'd think)
- Anything latency-sensitive that might spike past allowances and trigger silent throttling
- Sites with complex path-based caching (check cache behavior limits)
- Organizations with shared CloudFront Functions or WAF WebACLs across distributions
Stay on pay-as-you-go:
- Traffic regularly exceeding 500M requests/month (requires AWS sales conversation anyway)
- Lambda@Edge dependencies
- Enterprise customers with negotiated rates that already beat these numbers
- Distributions serving small files with high request counts—do the break-even math first
- Multi-tenant SaaS with customer-owned domains (one-domain-per-plan kills you)
- Multi-CDN architectures where you need failover flexibility
- Greenfield projects where Cloudflare's unlimited bandwidth makes more sense
- Anyone needing Shield Advanced, CAPTCHA, or Account Takeover Protection
The Bigger Picture
This isn't primarily a pricing play so much as it is an admission.
AWS is conceding that CloudFront's traditional pricing model was too complex for most customers to predict or manage. Under pay-as-you-go, your costs depend on which edge locations serve your traffic. Unless you know exactly where your users are, you can't predict that. Try whiteboarding a global architecture when the answer to "what will CDN cost?" is "depends on the ratio of Australian to European users, which we won't know until we launch." Your unit economic modeling will dress up what's realistically a shrug with a dollar sign.
There's a subtler shift here too: who eats the risk. On pay-as-you-go, you do—a traffic spike, a DDoS attack, a viral blog post, and suddenly you're explaining a five-figure invoice to finance. On flat-rate, AWS absorbs that variance. Complexity and fear of massive bill spikes were the two things that made CloudFront pricing a recurring nightmare, and flat-rate kills both.
They're competing directly with Cloudflare's "just tell me what it costs" simplicity. Bundling WAF, DNS, and edge compute into a single line item is AWS quietly admitting that their à la carte model created friction that pushed customers toward simpler alternatives.
This also repositions CloudFront against the enterprise CDN incumbents. Akamai typically runs 20-40% more expensive than CloudFront for equivalent traffic, with pricing negotiated on a case-by-case basis (good luck finding a pricing page on their website!). Fastly revamped their pricing last November—the old $50/month minimum is now legacy, replaced with a free tier (100 GB, 1M requests) and packages starting at $1,500/month. That's a hundred-to-one gap between CloudFront Pro at $15 and Fastly Basic at $1,500. For the mid-market customer who doesn't want to negotiate enterprise contracts but needs more than Cloudflare's one-size-fits-all approach, CloudFront just became the obvious answer.
As AWS principal product manager Cristian Graziano put it: "Plans do not require an annual commitment to get the best available rates." That's AWS acknowledging that their traditional commitment-based discounting was losing deals to simpler alternatives.
I've spent years arguing that AWS pricing complexity is a feature, not a bug, because it lets sophisticated buyers optimize in ways flat-rate models don't allow. That's still true for large enterprises with dedicated FinOps teams. For everyone else? This is AWS finally meeting them where they are.
The $15 Pro plan in particular feels like a loss leader designed to get smaller customers onto CloudFront and into the AWS ecosystem before they default to Cloudflare because the pricing page was easier to understand. And once you're on CloudFront with S3 origins, that $4,500/month egress penalty makes switching a lot less attractive.
Migration Gotchas
Historical usage affects eligibility. AWS looks at your recent CloudFront usage when you try to subscribe. If your traffic already exceeds a plan's allowances, you may be forced into a higher tier. You can't game this by subscribing to Pro when you're clearly a Business-tier customer.
Disabled distributions still incur charges. Disable a distribution but don't cancel the pricing plan? You keep paying. Cancel the plan explicitly, or you're buying nothing for $15-1,000/month.
You can't delete a distribution while subscribed. Cancel the plan first, then delete. Minor operational friction.
You can mix pricing models. Keep your experimental distributions on pay-as-you-go (where you pay nearly nothing for low traffic) and move your high-volume production distributions to flat-rate. You don't have to go all-in.
Upgrades are immediate; downgrades wait. Upgrade mid-cycle and you get prorated billing and immediate access to higher limits. Downgrade and it takes effect next billing cycle.
Changes must propagate first. Wait until distribution configuration changes have propagated to all edge locations before subscribing. Don't subscribe mid-deployment.
Unsupported features block subscription. Lambda@Edge, real-time logs, or any other unsupported feature? You must remove them before you can subscribe. The console will block you.
What I'd Do
I don't have a clean formula for this. Every client engagement I've done involving CloudFront has been its own special snowflake of traffic patterns and architectural constraints. But if I were looking at this for a client tomorrow, here's roughly how I'd approach it.
First, audit what you actually have. Pull the list of CloudFront distributions, their traffic patterns over the last 90 days (requests and data transfer), and their configurations. Most accounts have more distributions than anyone remembers. Figure out which ones matter.
Then check for blockers. Lambda@Edge? Shared Functions or WebACLs? Real-time logs? Shield Advanced? Any of these disqualify you from flat-rate, full stop. Don't waste time modeling pricing for distributions that can't migrate. Heck, some of my own distributions use some old patterns for setting TTLs and thus aren't eligible without headache. AWS actually made this part easier than I expected: the CloudFront console shows eligibility based on features and usage for each distribution. You can hover over any disabled tier to see exactly why you're ineligible—whether it's a specific feature, too many cache behaviors, or WAF rule limits. It also shows your historical requests and data transfer for the last six months. Credit where due—this saves you from building your own eligibility spreadsheet.
Calculate your average response size. This is the number that determines whether you're request-bound or bandwidth-bound. Under 400 KB and you're hitting request limits first. The break-even math shifts significantly depending on which constraint you're actually hitting.
Here's the part most people get wrong: model your p95 month, not your average. Flat-rate plans don't care about your typical month, they care about your worst month. If your p95 exceeds a tier's limits, you need the next tier up or you'll get throttled exactly when it matters most—during your traffic spike, during your launch, during the one month your CEO is actually paying attention.
Count your cache behaviors. This one's easy to overlook. Over 10? Pro won't work regardless of traffic. Check this before you do any math.
Check your origins. Private VPC origins mean Business tier minimum. Cross-account Route 53 means flat-rate won't work at all. These constraints aren't obvious from the pricing page.
Build your own alerting. I cannot stress this enough. CloudWatch metrics for requests and bytes transferred, with alarms at 50%, 80%, and 90% of your plan limits. AWS's "may be delayed" notifications are not a monitoring strategy.
Start with something non-critical. Migrate one distribution, watch the usage counters for a full billing cycle, validate that your modeling was correct. Then expand.
And document your upgrade path before you need it. If you hit limits, can you upgrade mid-cycle? (Yes, prorated.) What's the next tier cost? Who approves that spend? Have this conversation before you're in an incident.
The flat-rate plans don't require annual commitments, so the risk of trying them is low. The risk of not evaluating them—and continuing to overpay for predictable, bandwidth-heavy workloads—is higher than most teams realize.
Don't mistake this for AWS becoming simple. They've added a fourth pricing dimension to an already complex service. You now get to choose between pay-as-you-go, flat-rate tiers, enterprise agreements, and savings plans—while factoring in the implicit cost of ecosystem lock-in that makes all of this moot anyway.
AWS finally made CloudFront pricing predictable. They just made the decision about which pricing model to use more complicated. Somehow, that feels very on-brand.
