CloudFront Flat‑Rate Pricing: Switch or Stay Now?

On November 18, 2025, AWS introduced CloudFront flat‑rate pricing plans—bundles that include CDN delivery, AWS WAF and DDoS protection, Route 53 DNS, CloudWatch log ingestion, a TLS cert, serverless edge compute, and monthly S3 storage credits for a simple monthly fee with no overage charges. If your stack runs on AWS, CloudFront flat‑rate pricing can collapse a messy web bill into one predictable line item. But there are tradeoffs, limits, and a few sharp edges that matter before you flip the switch.

What just changed—and why developers should care

AWS now offers four CloudFront flat‑rate tiers per distribution: Free ($0), Pro ($15), Business ($200), and Premium ($1,000) per month. Each tier comes with a published monthly allowance and feature set. The headline allowances are straightforward: requests scale from 1 million (Free) to 500 million (Premium); data transfer to the internet is 100 GB on Free and a striking 50 TB on every paid tier. Security and ops are bundled: an AWS WAF web ACL is required and included, DDoS protections are on by default, Route 53 DNS can be attached and covered within tier limits, and CloudWatch ingestion for standard access logs and WAF logs is included.

Two more details punch above their weight. First, blocked DDoS and WAF‑blocked requests don’t count against your allowances, which means attack traffic won’t wreck your monthly math. Second, plans include S3 storage credits—5 GB on Free, 50 GB on Pro, 1 TB on Business, and 5 TB on Premium—usable against S3 Standard storage in your payer account, whether or not S3 is your origin. It’s a subtle nudge to keep more of your stack inside AWS.

There’s also an architectural reason the bundles can be so aggressive on price: when you serve AWS origins (S3, ALB, API Gateway) through CloudFront, data transfer from origin to CloudFront is already free; the plan then covers the transfer to viewers up to your tier’s allowance. Put simply, AWS is monetizing the edge and throwing in the plumbing.

CloudFront flat‑rate pricing, by the numbers

Here are the parts most teams ask about:

• Allowances: 10M/125M/500M monthly requests on Pro/Business/Premium; all three include 50 TB transfer to viewers.
• Notifications: usage alerts at 50%, 80%, and 100% of your allowance via email and console.
• What happens if you exceed the allowance? You won’t see overage charges, but AWS may reduce performance (throttle) or require a plan change. You can upgrade mid‑cycle and charges pro‑rate.
• Account quotas: up to 100 plans per account; up to 3 Free plans; one apex domain per plan. If you serve two separate apex domains, you’ll need two plans.
• DNS: attach the Route 53 hosted zone to have DNS costs covered within tier limits. ALIAS queries to CloudFront and certain AWS services don’t count against the monthly DNS query allowance.

Those are generous guardrails for most marketing sites, B2B apps, and a surprising chunk of content businesses. But not all workloads qualify—and not all features are available.

But there’s a catch: features you’ll lose on flat‑rate

The plans are designed around the mainstream CloudFront feature set and CloudFront Functions at the edge. If you depend on Lambda@Edge, you can’t subscribe that distribution to a plan. Same story for real‑time access logs, continuous deployment/staging distributions, anycast IP list, and several advanced AWS WAF capabilities (for example, partner‑managed rules, Account Takeover Protection, and CAPTCHA—use Challenge instead). Multi‑tenant distributions are also excluded. You can keep those features, but then you’re back on pay‑as‑you‑go for that distribution.

Translation: if your edge logic is heavy (image transforms, tokenization, custom auth not portable to CloudFront Functions), or you rely on those specific WAF modules, the plan savings could evaporate after you factor migration effort and reduced capability.

How much could you actually save?

Let’s get practical with two scenarios in the U.S./Canada region, where on‑demand CloudFront transfer is commonly priced at $0.085/GB after the first TB and request pricing kicks in after the free tier. Your rates vary by region and negotiated discounts, so run your own numbers, but the comparison is directionally solid.

Scenario A: SaaS marketing site. You push 15 TB to viewers and handle 8 million HTTPS requests per month. Pay‑as‑you‑go transfer alone runs roughly 14 TB × $0.085 = ~$1,190, plus minor request and logging costs. On flat‑rate Pro, the whole bill for that distribution is $15/month, well under 2% of the on‑demand transfer cost, and you’re getting WAF, DDoS, DNS, logs ingestion, and S3 credits bundled.

Scenario B: Content site with steady scale. You serve 45 TB and 120 million requests per month. Pay‑as‑you‑go transfer is roughly 44 TB × $0.085 = ~$3,740, plus request charges. On Business, you pay $200/month with headroom on requests (125M) and a 50 TB allowance. If you occasionally burst past 125M requests, you can upgrade mid‑month to Premium and pay a pro‑rated difference rather than accept possible throttling.

These are enormous deltas. The catch, again, is eligibility and feature parity. If you need a disallowed capability (say, Lambda@Edge) or you exceed allowances consistently, the calculus changes fast.

CloudFront vs Cloudflare and Akamai: when to consider switching

Here’s the thing: Cloudflare Pro ($25/month) and Business ($250/month) have long appealed to developers for simplicity and strong edge tooling. But Cloudflare doesn’t control your AWS origin egress fees. If your origin lives on AWS and you serve the internet through Cloudflare, you still pay AWS for data going from your origin to the internet. CloudFront sidesteps that by waiving origin‑to‑CloudFront transfer and then covering viewer transfer within your plan. For AWS‑centric shops, that’s the killer advantage.

When might Cloudflare or Akamai still be the better call?

• You’re multi‑cloud or hybrid and want provider‑agnostic edge and security.
• You need advanced bot management modules or WAF features not included in the plan.
• Your edge logic needs more than CloudFront Functions; you rely on a richer runtime like Cloudflare Workers or Lambda@Edge.
• You consistently break the 50 TB transfer allowance with spiky traffic that would risk throttling; an enterprise deal or pay‑as‑you‑go may be safer.

For many small and mid‑size teams running on AWS though, CloudFront’s flat‑rate Pro/Business tiers are poised to vaporize most CDN+WAF+DNS+logging spend.

Step‑by‑step: the 45‑minute Flat‑Rate Fit Test

If you want a fast, confident answer on whether to move a distribution to flat‑rate this week, run this checklist. Timebox each step; don’t overthink.

1. Pull 30 days of traffic. From your current CDN (or CloudFront), pull requests, transfer (by region if you can), and peak RPS. Note any DDoS or WAF‑blocked volumes.
2. Map features in use. Are you using Lambda@Edge, real‑time access logs, staging distributions, or multi‑tenant patterns? If yes, plan stays pay‑as‑you‑go until you re‑architect, or move a simpler distribution first.
3. Edge code audit. If you only need header rewrites or lightweight routing, prototype in CloudFront Functions. Heavier logic? Keep it where it is for now.
4. Choose a candidate domain. You get one apex domain per plan. Pick a single high‑impact apex (or subdomains under it) for the first migration.
5. Attach DNS smartly. If you use Route 53, attach the hosted zone to the plan to cover DNS costs. Prefer ALIAS records to avoid counting queries against allowances.
6. Lock down origins. Use S3 Origin Access Control for private buckets and VPC Origins for ALB/EC2 so your app only accepts traffic via CloudFront. This maximizes security and savings.
7. Pick the initial tier. If you’re well under 10M requests and 50 TB, start with Pro. If you’re near 100M–125M, choose Business to avoid nuisance upgrades.
8. Subscribe and stage. Create or update the distribution, subscribe to the plan, deploy behind a small canary audience, and watch error rates and cache ratios.
9. Set guardrails. Configure alerts for 50/80/100% usage notifications. Add CloudWatch alarms on 4xx/5xx and cache hit ratio.
10. Decide go/no‑go. If performance and logs look clean after a day of real traffic, route full traffic, then schedule a 2‑week review to confirm the savings are real.

People also ask: common plan questions

What happens if I exceed my plan’s monthly allowance?

You won’t get surprise overage fees. AWS may reduce performance (for example, throttle) or ask you to change pricing. Upgrading to a higher tier takes effect immediately and is pro‑rated for the rest of the month. If you consistently exceed allowances, pick the next tier as your baseline or return to pay‑as‑you‑go.

Can I run multiple domains under one plan?

A plan covers one CloudFront distribution and one apex domain. Subdomains are fine under that apex, but a second apex needs a second plan. You can have up to 100 plans per account and up to three Free plans.

Is the Free plan viable for production?

It’s great for prototypes and hobby sites: 1M requests and 100 GB data transfer, plus a small WAF and DNS allowance. For production, Pro is often the minimum once you want WAF visibility, DNS headroom, and reliable performance.

Do the plans include real‑time logs or Lambda@Edge?

No. The bundle includes standard access logs ingestion and CloudFront Functions, not real‑time logs or Lambda@Edge. If you rely on those, keep that distribution on pay‑as‑you‑go, or refactor.

What about DNS costs?

If you attach your Route 53 hosted zone to the plan, ALIAS queries pointing to CloudFront (and certain AWS services) don’t count against your monthly DNS allowance. Non‑ALIAS queries do, but each tier provides additional DNS query capacity.

Rollout timing, eligibility, and billing mechanics

The plans went live on November 18, 2025 and are available immediately for new or existing distributions—as long as your config avoids unsupported features and you attach a WAF web ACL. Upgrades are instant and pro‑rated; downgrades and cancellations apply at the next billing cycle. On the bill, CloudFront Flat‑Rate Plans appear as a single aggregated line item per tier with pro‑rata counts if you changed mid‑month. One more operational nuance: free‑tier AWS accounts can’t use CloudFront Flat‑Rate Plans, and if your historical usage exceeds a tier’s allowance, you may not be eligible to downgrade to that tier until usage drops.

Risks, edge cases, and how to de‑risk the move

Let’s be candid about the rough edges:

• 50 TB cap across paid tiers. Requests scale fast, but transfer caps at 50 TB. If you’re a media streamer or file‑heavy app, measure carefully. It’s fine to run multiple plans, but consider ops overhead.
• Unsupported features. If you depend on Lambda@Edge, real‑time logs, or staging distributions, don’t move that workload. Migrations to Functions are often straightforward for header rewrites and cache keys, but not for heavy compute.
• Non‑AWS origins. The “origin to CDN” savings assume AWS origins. With non‑AWS origins, you’ll still pay your provider’s egress to the internet.
• DNS attachment discipline. Attaching the wrong hosted zone or skipping ALIAS records can chew through DNS allowances. Follow the plan guidance and keep ALIAS wherever possible.
• Operational blind spots. Standard access logs are included, but if your SOC/SREs rely on real‑time logs, plan for an observability gap or keep pay‑as‑you‑go.

Let’s get practical: how to execute the switch

Here’s a simple implementation plan we’ve used with clients:

1. Pick one distribution with clean requirements (static assets or a marketing site) and measurable traffic.
2. Refactor edge logic to CloudFront Functions where needed (header rewrites, redirects, cache key shaping).
3. Attach WAF and baseline rules, then simulate common attacks to confirm blocks don’t count toward allowances.
4. Attach Route 53 with ALIAS to CloudFront and set DNSSEC if your tier supports it.
5. Lock down origins with Origin Access Control for S3 and VPC Origins for ALB/EC2 so only CloudFront can reach them.
6. Subscribe to the plan, canary 5% traffic, watch cache hit ratio and 4xx/5xx, then roll to 100% if clean.
7. Monitor usage with the built‑in 50/80/100% alerts and your own alarms; rehearse a mid‑cycle upgrade so the team knows the motion if you get close to caps.

If you want help mapping the workload and negotiating the tradeoffs, our cloud cost and performance services do this weekly for teams shipping at scale.

What to do next

• Audit one public site (requests, transfer, edge features) and run the Fit Test. If the math clears, move it this week.
• Plan your edge roadmap. If you’re on Lambda@Edge for light tasks, schedule a Functions refactor. Keep heavy compute where it belongs.
• Set guardrails. Create alerts, dashboards, and a runbook for upgrades and DNS attachment mistakes.
• Reinvest the savings. Use the S3 credits to standardize asset storage and cache policies—squeeze more out of the bundle.
• Benchmark alternatives. If you’re multi‑cloud or need richer edge compute, compare Cloudflare or stay pay‑as‑you‑go where flat‑rate doesn’t fit.

Want more operator‑level guides? Read our notes on managing fast‑moving vendor changes like our Cloudflare pricing changes guide and the Cloudflare containers pricing switch analysis. And if you’re cleaning up AWS housekeeping, don’t miss our AWS CDK Node.js support guide. When you’re ready to roll this out across multiple domains, talk to our team.

Zooming out: what this means for your roadmap

CloudFront’s flat‑rate plans are a strong signal: AWS wants your edge traffic—and it’s willing to compress margins across adjacent services to get it. For many AWS‑first teams, that means your best near‑term savings are no longer in EC2 instance tuning but at the edge. If you’re disciplined about feature tradeoffs and you keep a close eye on allowances, the new plans can de‑risk the bill while improving your security posture by making WAF and DDoS table stakes. If you’re not, you can end up with an accidental throttle during a launch or a surprise capability gap because you assumed Lambda@Edge would be there.

The smart play is to move the easiest distribution first, validate the savings with production traffic, then write the runbook so the rest of your portfolio can follow without drama. That’s the real win: predictability, on your terms.