CloudFront Flat‑Rate Pricing: The Migration Playbook

AWS just introduced CloudFront flat‑rate pricing—four plans with no overage charges that bundle CDN, AWS WAF, DDoS protection, Route 53 DNS, logging, serverless edge compute, and monthly S3 credits into one predictable monthly bill. Tiers start at Free ($0) and run through Pro ($15), Business ($200), and Premium ($1,000) per distribution. For traffic‑spiky sites and CFOs tired of surprise bills, this is a big shift. But there are catches—and you need a careful migration plan to avoid them. (aws.amazon.com)

What actually changed—and why it matters

Historically, CloudFront was pure pay‑as‑you‑go with separate line items for data transfer, requests, WAF, DNS, and logs. The new plans collapse those into a single monthly price per distribution and publish clear allowances: 1M requests/100 GB for Free, then 10M/50 TB, 125M/50 TB, and 500M/50 TB respectively for Pro, Business, and Premium. Exceed the allowance and you won’t pay more, but AWS may throttle performance or ask you to move to another plan. That predictability is the headline here. (docs.aws.amazon.com)

Timing matters. With AWS re:Invent 2025 running December 1–5 in Las Vegas, many teams will lock 2026 budgets this week. If you operate web apps, APIs, or media properties, flat‑rate plans can simplify forecasts and reallocate your cloud‑cost fire drills to actual product work. (reinvent.awsevents.com)

CloudFront flat‑rate pricing: who benefits, who doesn’t

If your workload has bursty traffic—product launches, retail peaks, PR hits, or DDoS headwinds—flat‑rate shifts operational risk away from you. It also bakes in security defaults that teams sometimes under‑provision when money gets tight (WAF and DDoS protection). For steady, low‑volume APIs with heavy edge customization, pay‑as‑you‑go might still fit, especially if you rely on unsupported features (more below). For a quick strategic take, see our earlier analysis, who should switch now.

Hidden traps: unsupported features that block your subscription

Here’s the thing—some CloudFront features are not eligible for flat‑rate plans. If your distribution uses any of these, you either refactor or stick with pay‑as‑you‑go:

• Lambda@Edge functions (use CloudFront Functions or pay‑as‑you‑go)
• Real‑time access logs (use standard access logs)
• Continuous deployment and staging distributions
• Multi‑tenant distributions and Anycast IP list configuration
• Specific AWS WAF items: CAPTCHA, targeted bots, partner managed rules, account takeover and account creation fraud protections, and rule groups
• Legacy CloudFront features like Field‑level Encryption and Dedicated IP/SSL

These aren’t footnotes—they’re migration gatekeepers. The official docs explicitly list them and require you to remove or replace each before you can subscribe a distribution to a plan. (docs.aws.amazon.com)

Mitigations that actually work

We’ve helped teams unwind edge logic before. In practice, your play is:

• Port simple header rewrites and URL normalizations from Lambda@Edge to CloudFront Functions. Keep function payloads small and stateless.
• If you require heavy request/response mutation, consider moving logic to origin (ALB/API Gateway) or to a separate, non‑plan CloudFront distribution that continues pay‑as‑you‑go.
• Replace real‑time access logs with standard logs plus CloudWatch dashboards for near‑real‑time visibility.
• For WAF features not supported in plans, replicate the intent with individual rules or accept pay‑as‑you‑go for that distribution.

The docs also call out quotas: up to 100 flat‑rate plans per AWS account, a maximum of 3 Free plans, and one apex‑level domain per plan. Plan accordingly if you operate many brands or sub‑companies. (docs.aws.amazon.com)

The 10‑minute sizing worksheet

Before you re‑architect anything, pick a target plan using data you already have. Open your last full month of CloudFront and WAF metrics and run this quick pass:

1. Requests: Sum total requests per distribution. Compare to allowances (10M, 125M, 500M). If you’re straddling thresholds—say 9–12M monthly—plan for growth and choose Business only if your roadmap pushes you over 125M within the next two quarters.
2. Data transfer: The paid plans all include 50 TB. If your distribution routinely exceeds 50 TB and you can’t dial down media size, you may need to keep pay‑as‑you‑go or split traffic across multiple distributions and plans.
3. WAF posture: Verify that your current rule sets map to the plan’s supported feature set. Swap rule groups for individual rules where possible.
4. Edge logic: Inventory Lambda@Edge functions and classify by rewrite/redirect/header tweaks vs. heavy transforms. Simple ones migrate to CloudFront Functions; heavy transforms don’t.
5. Domains: If you front several apex domains on one distribution, you might need multiple plans due to the one‑apex‑per‑plan rule.

You can monitor allowance usage and get 50/80/100% alerts in the console, which helps leaders avoid plan surprises mid‑month. (docs.aws.amazon.com)

A pragmatic migration plan (weekend‑safe)

Let’s get practical. This sequence keeps blast radius small and gives you rollback points.

1) Create a compatibility branch

Clone your distribution config into a new stack or environment. Disable unsupported features in the clone—not in prod. Introduce CloudFront Functions where you replaced Lambda@Edge. Unit‑test header/URL logic locally and in a staging distribution.

2) Mirror traffic and measure

Run a low‑risk path (robots.txt, image sprites, or a specific subpath) through the cloned distribution. Verify cache hit ratio, latency, and WAF pass/block behavior. Ensure standard access logs give you the observability you need.

3) Subscribe to the plan in staging

Attach the flat‑rate plan to the staging distribution and heat the cache. Watch for allowance burn rates and any throttling hints when you artificially spike requests. Track error budgets as you would for an origin change. (docs.aws.amazon.com)

4) Cut over with weighted DNS

Use Route 53 weighted records to shift 10% traffic, then 50%, then 100% over one to two hours during a known‑quiet window. Keep the original distribution warm for fast rollback. Document the exact steps; you’ll reuse them per brand/site.

5) Post‑cut validation

Confirm origin egress is still zero‑rated to CloudFront when applicable, check cache efficiency, and scan WAF for false positives. Review cost telemetry at day 1, day 7, and day 30 against plan allowances. If you chronically approach 80% before day 20, upgrade a tier. (aws.amazon.com)

“People also ask” quick answers

Does the plan cover origin egress?

Yes—when your AWS origins (S3, ALB, API Gateway) serve traffic through CloudFront, the plan’s monthly price covers data transfer from origin to CloudFront. You still need to manage origin efficiency, but the big surprise line item—inter‑service egress—shouldn’t appear. (aws.amazon.com)

What happens if we blow past the allowance?

You won’t get overage charges. You may see reduced performance (throttling) or be asked to move to a higher plan tier. Use the built‑in usage alerts to stay ahead of this and plan upgrades proactively. (docs.aws.amazon.com)

Can we keep Lambda@Edge?

Not on a flat‑rate plan. You’ll need to refactor to CloudFront Functions or keep pay‑as‑you‑go for that distribution. Many teams split into two distributions: one on a plan for static/media, one pay‑as‑you‑go for heavy edge compute. (docs.aws.amazon.com)

Are the Free plans unlimited?

No. Accounts are capped at three Free plans, and each plan covers one distribution with a single apex‑level domain. That makes Free perfect for prototypes, internal tools, and sandboxes—not production multi‑brand fleets. (docs.aws.amazon.com)

Cost strategy: pair this with other simplifications

Flat‑rate plans are part of a broader simplification trend many teams are pursuing—fewer line items, stricter guardrails, and default‑on protections. We’ve seen big wins when teams pair a CloudFront plan with VPC and egress simplification. If cost governance is a theme for 2026 planning, read our take on regional NAT gateways for blueprint‑level savings, and our API Gateway response streaming migration plan for cutting tail latency while you’re at it.

Architecture patterns that map well to plans

Based on real migrations, these patterns fit flat‑rate nicely:

• Static‑heavy, dynamic‑lite websites: Next.js/Remix frontends pushing most content to S3/CloudFront, with light API calls. Replace Lambda@Edge rewrites with CloudFront Functions and set strict cache policies.
• Global download portals: Signed URLs on large assets where your main concern is predictable cost during bursts.
• Marketing and campaign microsites: Seasonal spikes, low baseline. Plans eliminate the budgeting roulette around launch week.
• Media sites with smart cache keys: If you can keep unique object counts under control, 50 TB covers a lot of video at practical bitrates.

Patterns that usually do not fit: deep personalization at the edge with compute‑heavy transforms; complex canary/staging setups that depend on CloudFront continuous deployment; and workloads requiring WAF features excluded by plans (CAPTCHA, partner‑managed rules). (docs.aws.amazon.com)

Migrating off Lambda@Edge without breaking URLs

Two rules: keep it stateless; keep it tiny. CloudFront Functions run in tens of microseconds, which is perfect for header normalization, redirects, and A/B cookie flips. If you did HTML rewriting or SSR at the edge, move that to origin. Add cache policies that vary only on the headers you truly need; every additional vary key reduces hit ratio and eats allowance faster.

Governance and org‑wide rollout

Because plans are per distribution and capped per account, define a naming and tagging standard now. Example: org‑brand‑env‑planTier (e.g., acme‑shop‑prod‑cfx‑business). Give platform teams guardrails: when launching a new brand, default to Pro unless product, traffic forecasts, or security require Business. Revisit the tier every quarter just like you would a reserved instance portfolio.

What to do this week

• Inventory every CloudFront distribution and flag unsupported features. Create a refactor backlog for Lambda@Edge and WAF rule groups.
• Run the 10‑minute sizing worksheet on last month’s usage and select a target tier per distribution.
• Stand up a staging distribution and attach the target plan. Spike traffic to validate throttling behavior beyond allowance.
• Schedule a controlled cutover using weighted DNS.
• Lock cost guardrails: enable usage alerts, and calendar a 20‑day allowance check to decide whether to upgrade tiers before month‑end.

Budget note for finance partners

Flat‑rate converts variable CDN/WAF/DNS/logging into a fixed monthly line per distribution. It also zero‑rates origin egress to CloudFront for AWS origins and shields you from volumetric attack spikes. That makes it easier to forecast peaks around holidays and launches without holding back capacity just in case. Bring finance into the plan approvals—they’ll appreciate the stability. (aws.amazon.com)

Preparing for re:Invent discussions

If you’re in Las Vegas this week, expect pricing and security teams to be in every architecture conversation. Come ready with your distribution inventory, allowance estimates, and a short list of blockers. A crisp migration plan will make those meetings productive, not theoretical. (reinvent.awsevents.com)

Need help pressure‑testing the plan?

We’ve guided teams through CDN rewrites, cost audits, and migration cutovers all year. If you want a fast second opinion, explore our architecture and migration services, skim our recent work, and reach out via a short brief. You can also keep tabs on platform changes in our blog and related deep dives like who should switch now.

Final checklist before you flip the switch

• Confirm no unsupported features remain on the target distribution (especially Lambda@Edge, real‑time access logs, and WAF CAPTCHAs). (docs.aws.amazon.com)
• Verify request and data transfer headroom against plan allowances and set 50/80/100% alerts. (docs.aws.amazon.com)
• Assert origin egress is routed through CloudFront to take advantage of the plan’s coverage. (aws.amazon.com)
• Document rollback and test it once with weighted DNS.
• Schedule a post‑cut 20‑day allowance review and a 30‑day cost report.

Make the move for the right distributions, and you’ll ship with stronger defaults—WAF and DDoS on, logging in place—and fewer late‑night cost surprises. Spend that regained time on product work. That’s the real win.