Cutting a Client's CloudFront Bill by ~91% with AWS's New Flat-Rate Plans

A client came to us in shock over their CloudFront bill — $2,300/month during their peak sales period. Here’s how we got it down to $200/month.

AWS built an entire new pricing plan just to admit the old one was robbery.

A client reached out to us after opening their AWS invoice during their busiest sales month of the year and seeing CloudFront alone hit ~$2,300/month, with the vast majority of that coming from data transfer out to their customers. They weren’t looking for a full re-architecture — they just wanted to know: is this normal, and can anything be done about it?

Their system had been running since the early 202x — a few years old at this point. Back then, Amazon CloudFront only had one pricing model: pay-as-you-go, billed per GB of data transferred out plus per-request fees. That’s just how it was when their system was built, so that’s what they built on, and it stayed that way ever since — nobody on their side had a reason to revisit it, until a peak-season invoice made the cost impossible to ignore.

We took the case and started digging the same day.

🤔 Why this had been quietly building up

A $2,300/month CDN bill isn’t necessarily alarming for a growing production system — but it’s the kind of number that’s easy to just accept and stop thinking about, especially on infrastructure nobody actively works on day to day. It only becomes a “shock” when a peak sales month makes it spike and someone finally looks at the invoice line by line.

The timing worked in the client’s favor, though: AWS had just announced something new — CloudFront flat-rate pricing plans — Free, Pro, Business, and Premium tiers, each bundling CDN + AWS WAF + DDoS protection + Route 53 DNS + CloudWatch Logs ingestion into one flat monthly price with no overage charges. Importantly, it applies to existing distributions, not just brand-new ones, with no annual commitment required.

That mattered a lot here, since the client’s distribution predated all of this by years.

❗ Why pay-as-you-go quietly punishes older setups

Pay-as-you-go is fine when traffic is small or unpredictable. But once a distribution has run for years with steady, high-volume traffic — and then hits a seasonal peak on top of that — a few things stack up against you:

• You’re paying per GB, indefinitely, with no ceiling — the bigger the sales month, the bigger the bill, linearly, with no cap.
• Nobody goes back to re-evaluate the pricing model after launch, because “it’s already running, don’t touch it” is a very natural instinct for infrastructure that just works.
• The bill is really CloudFront + AWS WAF + Route 53 + CloudWatch, billed separately, so it’s not obvious how much is actually on the table until someone adds it all up — which is exactly what the client hadn’t done until the shock invoice.

🛠️ What we did, right away

Instead of proposing a big migration project, we treated it as a quick, measurable win: audit first, then act.

1️⃣ Pulled the client’s actual usage numbers

Before recommending anything, we pulled their real monthly numbers for data transfer and request count straight from CloudFront and Cost Explorer — including the peak-month spike, not just an average month. Each flat-rate tier publishes a monthly usage allowance (a soft baseline, not a hard cap):

Even counting their peak sales month, the client’s usage sat comfortably inside the Business tier’s 50 TB / 125 M-request allowance, with headroom to spare — so that’s what we recommended.

2️⃣ Checked for unsupported legacy features first

This is the part that actually took the most time. Flat-rate plans don’t support a handful of legacy CloudFront configurations, and a distribution running since 202x was a prime suspect for carrying some of these:

• Origin Access Identity (OAI) → migrated to Origin Access Control (OAC).
• Legacy ForwardedValues cache behavior config → migrated to cache policies + origin request policies.
• Real-time access logs, if in use → fall back to standard access logs.
• Dedicated IP/SSL, field-level encryption, IAM server certificates → none of these were in play here, thankfully.

We also had to make sure the distribution had an AWS WAF Web ACL attached, since that’s required to subscribe to a plan at all — conveniently, the Business tier already includes WAF at no extra cost, which was a nice side upgrade for the client’s security posture.

3️⃣ Switched the distribution and attached Route 53

Once the config was clean, switching an existing distribution to a plan is just a setting on the distribution (console, CLI, or the PricingPlanManager API) — no downtime, no new domain, no DNS cutover for the client’s end users. We also attached their Route 53 hosted zone to the plan, since Business covers the hosted zone fee and DNS queries too — as long as their records pointing at CloudFront use ALIAS, which don’t count against the DNS allowance at all.

4️⃣ Set up monitoring so the client never gets shocked again

One thing we made sure the client understood: the usage allowance isn’t a hard wall. AWS designed it to absorb normal spikes — a traffic spike up to 3x the monthly allowance in a given month doesn’t affect the account at all, and sustained overage is evaluated over 2-3 months before AWS adjusts anything (and even then, it’s a gradual traffic-shaping adjustment, not a surprise bill). We turned on the built-in usage notifications (50% / 80% / 100%) so the client gets an early heads-up long before their next peak season, instead of finding out from an invoice.

💡 Result and what we took away

~$2,300/month → ~$200/month, just by moving an existing, years-old distribution onto the Business flat-rate plan — no architecture changes, no CDN swap, no new vendor, and the fix shipped within days of the client’s first call.

A few takeaways from this one:

• A shocking invoice is often just an outdated pricing decision, not an architecture problem. The client didn’t need to change anything about how their system worked — just how it was billed.
• Measure before you migrate. Comparing real (peak-month-inclusive) usage against the published allowances is what let us confidently recommend Business over Premium.
• Legacy config is the real migration cost, not the plan itself. OAI → OAC and ForwardedValues → cache policies were things worth cleaning up regardless — the plan migration just gave the client a concrete reason to finally do it.
• A soft usage allowance with a grace period is a very different risk profile than a hard quota — worth explaining clearly to a client so “what if we go over during the next big sale?” isn’t a blocker.

If you’re running a CloudFront distribution that’s been around since the pay-as-you-go-only era — especially one that gets seasonal spikes — it’s worth 20 minutes to pull the usage numbers and check whether a flat-rate plan already pays for itself.

That’s the client’s specific story. Since writing it up, enough people have asked “okay but should I switch” that it’s worth zooming out and giving flat-rate plans the full physical exam — not just the happy path that worked for one client.

🗓️ Setting the scene

AWS quietly rolled these plans out in November 2025 — quietly as in “buried under an avalanche of re:Invent announcements,” which is a very on-brand way for AWS to launch something this significant. We gave it a couple of months to settle before writing any of this down, mostly to see if the internet would find a horrifying edge case first. It did, a little. We’ll get to that.

💰 The actual price tags

*The average file size at which pay-as-you-go pricing costs exactly the same as the flat rate — below it, pay-as-you-go is cheaper; above it, flat-rate wins.

The number that made us do a double-take: Pro, at $15/month, includes 50 TB of transfer — about 99.6% cheaper than the ~$4,250 that same 50 TB would cost at standard pay-as-you-go rates ($0.085/GB). That’s not a typo, and it’s not a rounding error either. It’s just AWS deciding that predictable revenue is worth more to them than nickel-and-diming you per gigabyte.

⚖️ The Cloudflare comparison everyone brings up

Cloudflare’s Pro plan ($25/month, or $20/month if you commit annually) advertises unlimited bandwidth, which sounds like an instant knockout on paper. Here’s the catch nobody mentions in the “just switch to Cloudflare” comments: if your origin lives on S3 or EC2, moving to Cloudflare means you’re now paying AWS egress fees to get your data out to Cloudflare in the first place (~$4,500/month for 50 TB at standard AWS rates). For anyone already living in the AWS ecosystem, that egress bill quietly cancels out most of the appeal. This is, not coincidentally, exactly the kind of lock-in math AWS is betting on when they price CloudFront this aggressively — they know leaving is its own toll booth.

✅ What’s actually in the box

CDN, AWS WAF with DDoS protection and bot management (traffic blocked by WAF doesn’t count against your usage allowance — free security, basically), Route 53 DNS, CloudWatch Logs ingestion (ingestion only — storage and querying are still billed separately, because of course they are), a TLS certificate via ACM, CloudFront Functions for free, and monthly S3 Standard storage credits (5 GB–5 TB depending on tier, applied account-wide, not just to whatever’s behind this distribution).

On Route 53 specifically: the hosted zone has to live in the same AWS account as the distribution. ALIAS records pointing at CloudFront don’t count against your DNS query allowance at all — CNAME records do. Blow past your DNS allowance and AWS will warn you, then quietly move the hosted zone back to pay-as-you-go if you don’t act. DNSSEC costs extra (AWS KMS charges), and the first 50 health checks per account are free.

📊 The limits, tier by tier

The sneaky one here is cache behaviors. A site with plenty of traffic but very few distinct URL patterns will breeze past every other limit — but a site with lots of different routing rules (per-path caching, per-content-type behavior) can hit Pro’s ceiling of 10 long before it ever gets close to the request limit. Traffic-light, routing-heavy sites, beware.

🔒 Features that only unlock at higher tiers

Business and up:

• Advanced bot management (including AI-bot classification)
• Custom response headers
• Custom origin request policies
• Private VPC origins
• Mutual TLS on the origin side (not the same as end-user mTLS — more on that below)
• Advanced DDoS Protection
• Uptime SLA

Premium only:

• Origin Shield (both halves of it — high-speed origin routing and origin load reduction)
• Automatic origin failover (origin groups)
• End-user mutual TLS (client-certificate authentication)

🚫 What’s not supported at all

Here’s the full guest list of things you have to remove before a distribution is even allowed to subscribe:

• Multi-tenant distributions
• Continuous deployment and staging distributions
• Anycast IP list configuration
• Real-time logs (the Kinesis-streamed kind)
• Targeted Bots (AWS WAF’s more advanced bot detection — not the same as “Bot management,” which is fine)
• Partner Managed Rules
• Account Creation Fraud Prevention
• Account Takeover Protection
• Shared WAF Rule Groups (you’ll need to break these out into individual rules)
• The legacy grab-bag: ForwardedValues, dedicated IP/SSL, field-level encryption, IAM server certificates, Origin Access Identity (OAI — migrate to OAC), and legacy cache settings

One thing worth clearing up, because it trips people up constantly: Lambda@Edge is not on this list. It still works on every tier — it’s just billed pay-as-you-go on top of your flat rate, unlike CloudFront Functions, which are free and included. So no, AWS isn’t secretly forcing you off Lambda@Edge; they’re just not letting it ride for free anymore. CAPTCHA gets a similar footnote — the CAPTCHA challenge action configured through a WAF rule is included starting at Pro, it’s only the JavaScript CAPTCHA API that’s billed separately.

The shared-resource trap: if a CloudFront Function, a KeyValueStore attached to one, or a WAF Web ACL is already shared across multiple distributions, none of those distributions can subscribe to a plan. Everything a plan touches has to be exclusively its own — no roommates.

The one-domain-one-plan trap: each plan covers exactly one apex domain. If you’re running multi-tenant SaaS where every customer gets their own domain (not a shared subdomain), 50 customers means 50 separate plans — and the account-wide ceiling is 100 plans, total.

🧾 Account-level limits

• 100 plans per account, maximum, across every tier combined.
• 3 Free plans per account, maximum.
• Accounts still on AWS Free Tier aren’t eligible to subscribe at all.
• Premium defaults to 500 M requests / 50 TB, but you can self-serve your way up (no sales call required) through published usage levels: 75 TB / 750 M ($1,450), 125 TB / 1.25 B ($2,250), 200 TB / 2 B ($3,500), 350 TB / 3.5 B ($6,000), all the way to 600 TB / 6 B ($10,000). Only past 6 billion requests or 600 TB/month do you actually need to talk to an AWS sales rep.

🤔 The pricing-tier identity crisis

Business ($200) and Premium ($1,000) are separated by a 5x price jump that, feature-wise, mostly comes down to three things: Origin Shield, origin failover, and end-user mTLS. Everything else is basically the same generosity, just with bigger numbers. In practice, four questions decide your tier: do you need more than 10/50 cache behaviors, will you blow past the request allowance, do you need origin failover, and do you need end-user mTLS. Answer those and the rest sorts itself out.

⚠️ “No overage charges” — read the fine print anyway

AWS’s claim of zero overage fees is technically true, which is the most AWS sentence we could possibly write. What actually happens if you sustain usage above your allowance for 2–3 months or more is that AWS may quietly adjust how your traffic gets served — fewer or more distant edge locations — instead of sending you a bigger bill. Scaled proportionally to how far over you are, and reversible the moment you upgrade. Your first traffic spike up to 3x the monthly allowance in any given month is fully absorbed, no questions asked — so a surprise viral moment won’t wreck you. You’ll get automatic notifications at 50%, 80%, and 100% of your allowance, but we’d still set up your own CloudWatch alerting on top — a heads-up you configured yourself beats a heads-up you’re hoping arrives on time.

✅ Switch now if you’re…

Serving large files (video, installers, firmware) without a request count in the stratosphere; an organization that wants WAF but has been scared off by unpredictable billing; running a simple site with few cache behaviors; or already living on AWS origins (S3/EC2), which sidesteps the Cloudflare-egress trap entirely.

❌ Stay on pay-as-you-go if you’re…

Running multi-tenant SaaS with a domain per customer (you’ll hit the 100-plan ceiling faster than you’d think); regularly pushing past 6 B requests or 600 TB a month; relying on multi-CDN failover; dependent on Shield Advanced, Firewall Manager, Targeted Bots, or Account Takeover Protection; or currently sharing Functions/WAF Web ACLs across multiple distributions and not ready to untangle that yet.

🔄 Migration gotchas worth knowing before you click “subscribe”

• AWS looks at your recent traffic history to decide which tiers you’re even eligible for — you can’t game it by picking a tier below what you’re actually using.
• Disabling a distribution does not cancel its plan. The meter keeps running until you cancel it explicitly.
• You have to cancel the plan before you’re allowed to delete the distribution.
• Mixing is fine — some distributions on flat-rate, others on pay-as-you-go, same account, no conflict.
• Upgrades take effect immediately and are prorated. Downgrades wait until the next billing cycle.
• Your distribution’s config has to finish propagating to every edge location before a plan subscription will go through.
• Anything on the unsupported list has to be removed first — the console won’t let you subscribe with a straight face while OAI or ForwardedValues is still attached.

🔭 The bigger picture

We read this less as a pricing strategy and more as a quiet confession: CloudFront’s old pricing model had gotten too complicated for customers to predict on their own. It’s also a direct shot at Cloudflare’s simplicity, and a repositioning against Akamai (generally pricier at comparable volumes) and Fastly (whose Basic plan runs about $1,500/month — roughly 100x CloudFront’s Pro price for a broadly comparable starting point).

AWS has confirmed these plans don’t require an annual commitment to get the best rate — a notable departure from how AWS usually likes to reward you for signing multi-year vows of loyalty.

Our conclusion: AWS hasn’t actually made CloudFront simpler to use — they’ve added a new layer of choice on top (now you’re picking between pay-as-you-go, flat-rate, enterprise agreements, and savings plans), while the ecosystem lock-in underneath stays exactly as sticky as it always was. Progress, sort of.

📚 References

• CloudFront flat-rate pricing plans – AWS Developer Guide
• AWS announces flat-rate pricing plans for website delivery and security
• Amazon CloudFront Premium flat-rate plan now supports configurable usage allowances
• Amazon CloudFront pricing
• Migrating from OAI to OAC
• Cloudflare pricing
• Fastly pricing