CloudFront Flat‑Rate Pricing: Who Should Switch Now

Primary keyword: CloudFront flat‑rate pricing. On November 18, 2025, AWS introduced CloudFront flat‑rate plans that roll CDN delivery, AWS WAF, DDoS protection, Amazon Route 53 DNS, CloudWatch Logs ingestion, serverless edge compute, and monthly S3 storage credits into a single fixed fee per distribution—with no overage charges. If you’ve ever watched a surprise traffic spike turn into a painful bill, this is a big deal.

What exactly changed—and what you get for a flat fee

AWS added four plan tiers that apply to a single CloudFront distribution and one apex domain: Free ($0/month), Pro ($15/month), Business ($200/month), and Premium ($1,000/month). Each plan includes a defined monthly allowance and the bundle of CDN + security + DNS + logging ingestion + serverless edge compute (CloudFront Functions) plus S3 storage credits. Critically, viewer‑to‑CloudFront egress is covered within the plan, and data transfer from AWS origins (S3, ALB, API Gateway) to CloudFront remains free—so you stop juggling multiple line items for the same site.

Concrete allowances and constraints matter for planning:

• Free: 1M requests, 100 GB transfer.
• Pro: 10M requests, 50 TB transfer.
• Business: 125M requests, 50 TB transfer.
• Premium: 500M requests, 50 TB transfer.

Two more notable details: requests blocked by WAF don’t count against your allowance, and there are no overage charges if you cross a plan’s limits. Instead, AWS can throttle or ask you to change plans. You’ll get emails at 50%, 80%, and 100% of allowance so you’ve got time to react mid‑month.

Is CloudFront flat‑rate pricing cheaper in practice?

Let’s do grounded math for U.S. traffic. Under pay‑as‑you‑go, the first 1 TB to the internet is free, then much of North America prices at $0.085/GB for the next 9 TB and $0.08/GB for the next 40 TB. If your site delivers 10 TB/month and ~10M requests, your rough egress line is: 9 TB × $0.085 = $765 (plus any request charges past 10M and whatever you pay for WAF, DNS queries, and logs). Under the Pro plan, the same traffic sits inside a $15/mo envelope—while also bundling WAF, Route 53 DNS, and CloudWatch log ingestion for standard access logs.

At 20 TB/month, pay‑as‑you‑go egress alone hovers around $1,565 before WAF/DNS/logs. The Pro plan is still $15. Even if your request volume pushes you toward Business for headroom (125M requests), the flat fee is $200/month versus thousands on a typical à‑la‑carte bill. The delta is so large that most public websites serving primarily North American and European traffic will model substantial savings.

Here’s the thing… the simplicity is real, but it’s not for every workload. The devil lives in feature gaps and organizational constraints.

The catches (read this before you switch)

Unsupported features that block plan enrollment

You can’t subscribe a distribution to a flat‑rate plan if it uses certain capabilities. The headline exclusions: Lambda@Edge, real‑time access logs, multi‑tenant distributions, Anycast IP allowlists, continuous deployment/staging distributions. If you rely on any of these, you either need to redesign using CloudFront Functions and standard logs—or keep pay‑as‑you‑go for that distribution.

Security/service constraints you must accept

Shield Advanced is not allowed on flat‑rate plans, and Firewall Manager won’t manage your CloudFront WebACL. You must associate a WAF WebACL with the distribution to enroll, and Free Tier accounts aren’t eligible. Also, plan‑attached resources (for example, a CloudFront Function or WebACL) are effectively single‑tenant to that distribution—you can’t share them broadly across other distributions that are on plans.

Allowances, throttling, and performance risk

There are no overages, which is the point. But if you exceed the monthly allowances, AWS reserves the right to reduce performance (for example, throttle) or require a pricing change. Translation: monitor like a hawk, especially the last week of the billing cycle for high‑variance traffic. The good news is that mid‑cycle upgrades are prorated; the bad news is downgrades only take effect next cycle, so pick conservatively if your traffic is spiky.

Observability trade‑offs

Standard access logs ingestion is included; real‑time access logs are not supported under flat‑rate. If your incident workflows or bot‑mitigation pipelines depend on real‑time logs, budget time to redesign. Also note that log storage and analytics (CloudWatch retention, Kinesis/Data Firehose, Athena/Glue) are still billable outside the plan.

The headline benefits—beyond predictability

Flat‑rate bundles do more than smooth bills. Three compounding wins:

• Hardening by default: a WebACL and always‑on DDoS protections at the edge mean fewer junk requests ever hit your origins. Less origin traffic reduces compute, database, and egress costs elsewhere.
• Origin egress simplicity: traffic from S3/ALB/API Gateway to CloudFront is already free; the plan now covers viewer egress to the internet within allowances. That removes double accounting headaches when forecasting.
• Operational clarity: a single, plan‑scoped surface area—CDN, WAF, DNS, logging, edge functions—means fewer cross‑team approvals to ship changes. It’s easier to standardize the “golden path” for websites and public APIs.

Who should switch to CloudFront flat‑rate pricing?

Based on the tiers and constraints, teams that win the most share a profile:

• Marketing and content sites with 1–40 TB/month, modest edge logic, and tolerance for standard logs.
• Product documentation/docs hubs and community portals where request volume is high but per‑request CPU needs are low.
• API gateways fronted primarily for caching and bot filtering, not heavy per‑request compute at the edge.
• Startups moving from mixed CDNs and struggling with unpredictable bills during launches or press spikes.

If you require Lambda@Edge (for complex rewrites, image processing, or heavyweight auth flows), real‑time logs, or Shield Advanced, keep pay‑as‑you‑go—or segment traffic so only compatible properties use flat‑rate plans.

Real‑world decision framework: the PlanFit 9

Here’s a quick, practical way I’d evaluate a property in under an hour.

1. Map the distribution: list the apex domain, subdomains, and whether you can dedicate a plan per apex. Plans are one‑apex‑per‑plan.
2. Feature audit: scan for unsupported features—Lambda@Edge, real‑time logs, multi‑tenant/staging, Anycast IP rules, Shield Advanced, or Firewall Manager integration. If present, decide to redesign or rule out.
3. Traffic snapshot: last 3–6 months of requests and egress by region. Note p95 and max. Spike shape matters more than average.
4. Bot picture: what’s your WAF posture? Since WAF is mandatory, baseline managed rules and custom rate limits now.
5. Observability plan: can you operate with standard logs + CloudWatch, or do you need real‑time?
6. Pick a candidate tier: start with Pro for most public sites; bump to Business or Premium if request ceilings demand it.
7. Allowance fit: check that p95 month stays within requests and 50 TB transfer; model upgrades on peaks. Remember, no overages but possible throttling.
8. Mid‑cycle policy: document who’s allowed to trigger a mid‑month upgrade and how to roll back next cycle.
9. Run a readiness test: simulate traffic and WAF rule impacts in a staging distribution configured to be plan‑compatible (CloudFront Functions instead of Lambda@Edge, standard logs on). Validate behavior under cache misses.

Migration checklist (step‑by‑step)

When the numbers look good, use this playbook:

1. Create a new, clean distribution configured for plan compatibility: CloudFront Functions for lightweight logic, no real‑time logs, standard access logs enabled, WebACL attached, Shield Advanced disabled.
2. Rebuild edge logic: port viewer‑request/response handlers from Lambda@Edge to CloudFront Functions where possible. If not feasible, stop—flat‑rate isn’t for this app.
3. Harden WAF first: enable a sane default managed ruleset, add rate‑based rules for obvious bursts, and test with sampled logs.
4. Attach Route 53 hosted zone: ensure the hosted zone meets plan requirements and is in the same AWS account.
5. Pick the plan tier and subscribe: start Pro unless your current requests already exceed 10M/month by a wide margin.
6. Swap traffic gradually: use lower TTLs and weighted records to shift 10%→50%→100%. Track cache hit ratio, 4xx/5xx rates, and WAF block rates.
7. Watch allowance burn: keep an eye on the console’s 50/80/100% alerts. If your forecast changes, upgrade mid‑cycle (it’s prorated). Downgrades apply next cycle.
8. Cost verification: compare one full month under flat‑rate against your historical pay‑as‑you‑go stack. Validate any ancillary charges (for example, CloudWatch storage).
9. Codify the pattern: capture IaC modules for “plan‑compatible” distributions and promote as the org standard.

People also ask

Can I keep Lambda@Edge on a flat‑rate plan?

No. Flat‑rate plans exclude Lambda@Edge. Use CloudFront Functions for lightweight logic. If you need full Lambda@Edge capabilities, keep pay‑as‑you‑go for that distribution or split your architecture.

What happens if I exceed my monthly allowance?

You won’t get an overage bill, but AWS can reduce performance (for example, throttle) or require a plan change. Practically, monitor burn rate and upgrade mid‑cycle if you’re running hot.

Does the plan include all logging costs?

No. The plan covers CloudWatch Logs ingestion for standard access logs (and WAF logs). Storage, queries, real‑time logs, Kinesis/Data Firehose delivery, and advanced metrics cost extra.

Can I share a WebACL or a CloudFront Function across distributions on plans?

Not broadly. Resources associated with a plan are effectively dedicated to that distribution. Plan for a per‑distribution WebACL and dedicated edge code.

Cost control in context: multi‑CDN and resilience

Flat‑rate is compelling, but don’t forget resiliency. If your risk model includes CDN vendor outages or routing incidents, keep a multi‑CDN playbook handy. Our resilience checklist from the Cloudflare world applies just as well here—think failover DNS, health checks, stale‑if‑error caching, and origin pool design. If you need an opinionated template, our guide on handling edge incidents is a quick primer: resilience playbook for 2025.

And if you’re reviewing edge costs more broadly—including compute at the edge—our analysis of a recent Cloudflare pricing shift is a useful comparison point for finance and platform teams exploring predictable spend: Cloudflare containers pricing switch.

Governance and billing mechanics to know

There are practical guardrails here:

• Quotas: up to ~100 plan subscriptions per AWS account; up to 3 Free plans.
• Eligibility: AWS Free Tier accounts can’t use flat‑rate plans.
• Billing changes: upgrades are prorated based on days remaining; downgrades take effect next billing cycle. Disabled distributions still incur plan charges until you cancel the plan.
• DNS nuances: attach the hosted zone for your distribution’s apex to wrap typical Route 53 costs; some extras (DNSSEC KMS, health checks) still bill separately.

What about SEO, Core Web Vitals, and edge features?

From a performance/SEO angle, the plan itself doesn’t change how CloudFront caches or serves content. The two variables that can influence metrics are: (1) throttling if you exceed allowance and don’t upgrade, and (2) porting complex logic from Lambda@Edge to CloudFront Functions. Keep your RUM and synthetic testing wired during rollout and after, and run a controlled ramp to avoid surprises. If you’re rebuilding a site alongside this switch, we can help with end‑to‑end performance engineering and implementation—see how we approach engagements on our What We Do and Services pages, and browse relevant work in our portfolio.

Edge cases and limitations you should flag for stakeholders

Be transparent about these during approvals:

• Real‑time analytics pipelines relying on CloudFront’s real‑time logs must change or stick with pay‑as‑you‑go.
• Security programs that standardize on Shield Advanced won’t fit flat‑rate without rethinking risk acceptance and compensating controls.
• Centralized WAF or edge‑code sharing patterns (common in platform teams) are constrained by the per‑distribution scoping of plan resources.
• If you deliver >50 TB/month per distribution, the transfer allowance is the first ceiling you’ll hit; model carefully and segment by property if needed.

What to do next (developers and business owners)

If you’re a developer or platform lead:

• Run the PlanFit 9 on your top three public properties this week.
• Stand up a plan‑compatible distribution in staging; port edge logic to CloudFront Functions and attach a baseline WebACL.
• Replay logs to validate cache behavior, WAF efficacy, and allowance burn under synthetic load.
• Define your mid‑cycle upgrade policy and rollback comms with SRE/FinOps.

If you’re a founder or CFO/COO:

• Ask for a FinOps memo with three models: status quo, Pro, and Business tiers. Validate assumptions on request volume and regional traffic mix.
• Condition approval on maintaining Core Web Vitals (p75 LCP/INP) and error budgets during the cutover.
• Schedule a 45‑day post‑migration review to confirm savings and operational health.

Want a second set of eyes? Reach out via our contact page—we’ve led similar edge migrations and can help you avoid the sharp edges.

Bottom line

CloudFront flat‑rate pricing is the most developer‑ and finance‑friendly change AWS has shipped for website delivery in years. If your distribution doesn’t require Lambda@Edge, real‑time logs, or Shield Advanced—and your monthly egress is under 50 TB—this is likely a straightforward win. Move thoughtfully: audit features, model traffic, port edge logic, and monitor allowances with a pre‑approved upgrade path. Teams that follow that path will land meaningful savings and a simpler operational surface without sacrificing performance or security.