CloudFront vs Cloudflare CDN

CDNs aren’t where most teams differentiate, and that’s the point — picking the wrong one is rarely fatal, picking the right one quietly removes a class of problems. AWS CloudFront and Cloudflare are the two serious general-purpose CDNs in 2026. Both will cache your assets well. The choice is about what else you want from your edge — security, edge compute, DNS, and how tightly you’re coupled to one cloud.

We’ve deployed both on production work — CloudFront for AWS-native enterprise platforms, Cloudflare for SaaS and consultancy sites (including the pdpspectra.com you’re reading). Here’s how the choice actually plays out.

The thirty-second framing#

CloudFront is AWS’s CDN. ~600 PoPs, deep integration with the AWS ecosystem (S3, ALB, API Gateway, Lambda@Edge, CloudFront Functions). Pay-as-you-go pricing tied to your AWS bill.
Cloudflare is a full edge platform — CDN + DNS + DDoS protection + WAF + Workers + R2 (object storage) + D1 (SQLite at edge) + Pages + Stream + Email Routing. ~300 PoPs but with different geographic strengths. Generous free tier; tiered paid plans.

CloudFront is “a CDN as one of AWS’s many services.” Cloudflare is “the edge IS the product.”

What’s actually different#

Dimension	CloudFront	Cloudflare
PoPs	~600	~300 (but different geographic mix)
Free tier	1 TB/month outbound (always free)	Generous (10M+ requests/month)
Pricing model	Per-GB transferred + per-request	Tiered subscription + workload-based
DNS	Route 53 (separate AWS service)	Cloudflare DNS (integrated)
WAF	AWS WAF (separate service)	Cloudflare WAF (integrated)
DDoS protection	AWS Shield (extra for advanced)	Included on all plans
Edge compute	CloudFront Functions (lightweight JS), Lambda@Edge	Workers (full V8 isolate runtime — see our piece)
Object storage at edge	Origin Shield (S3)	R2 (S3-compatible, no egress fees)
Origin options	S3, ELB, EC2, MediaStore, custom	Any origin (HTTP/HTTPS, with Tunnel for private origins)
Cache key flexibility	Cache policies (improving)	Strong via Workers
Real-time logs	CloudWatch (with delay)	Logpush, Stream Analytics
TLS certificates	ACM (free for CloudFront)	Free SSL (auto-managed)
mTLS support	Yes	Yes
Cache invalidation	Per-path, costs $$$ above free quota	Free, fast

Where CloudFront wins#

Deep AWS integration. S3 origin with proper signed URLs, ALB origin in your VPC, API Gateway origin with custom auth — all native. For an AWS-native architecture, CloudFront is the path of least friction.

Pay-as-you-go. No subscription tier to navigate. Use 100GB this month, pay for 100GB. For variable workloads or unpredictable traffic, this scales naturally.

Lambda@Edge for serious compute. Lambda@Edge runs full Node.js/Python at the edge — handles things like JWT validation against external auth providers, complex header manipulation, multi-step rendering logic. More powerful than CloudFront Functions or Cloudflare Workers in raw capability (though slower and more expensive per request).

Origin Shield. A regional cache layer in front of your origin. Reduces origin hits at scale. Real value for high-traffic sites with expensive origin requests.

Native CloudWatch metrics. All your CDN observability ends up in the same place as the rest of AWS. One Datadog/CloudWatch integration covers everything.

Where CloudFront hurts:

DNS is a separate service (Route 53).
WAF is a separate service (AWS WAF) with its own pricing model.
Pricing is complex — separate line items for data transfer, requests, invalidations, SSL, Origin Shield. Easy to be surprised by the bill.
DDoS protection beyond basic Shield is a paid Shield Advanced tier (~$3k/month).
Cache invalidation is metered after the free tier.

Where Cloudflare wins#

Bundled platform. CDN + DNS + WAF + DDoS protection + edge compute + free SSL + analytics — all in one product, one dashboard, one bill. For a small team, this is one less integration surface.

Free tier is genuinely useful. Real production sites run on Cloudflare’s free tier. The pdpspectra.com you’re reading this on uses it.

Workers are a real edge compute platform. V8 isolates start in microseconds; you can build real applications at the edge (auth gateways, image manipulation, edge caching logic). See our Workers vs Lambda piece.

R2 with no egress fees. Cloudflare R2 is S3-compatible object storage with zero egress fees. For workloads that serve a lot of bandwidth (video, large files, public datasets), this is potentially a huge cost difference vs S3.

DDoS protection is included. Even on the free tier, you get unmetered DDoS protection. No “we got attacked and the bill blew up” risk.

One-click features. “Turn on bot management” is a toggle. “Add rate limiting” is a toggle. “Enable HTTP/3” is a toggle. AWS equivalents require service-by-service configuration.

Cache invalidation is fast and free. Purge by URL, by tag, by everything — included.

Where Cloudflare hurts:

The platform is opinionated. If you want to do something Cloudflare didn’t anticipate, you’ll fight the abstraction.
The number of features means the dashboard has a lot of surface area to learn.
Origin connection options are flexible but configuring private-origin access requires Cloudflare Tunnel (which adds an agent).
Auto-injection features (Email Obfuscation, Web Analytics) can quietly add scripts to your site if you don’t disable them — we hit this in our own perf audit.
Cloudflare’s paid tier pricing jumps significantly between Free → Pro → Business → Enterprise.

When you should default to which#

Default to CloudFront if:

You’re already deep in AWS (most enterprises)
You’re using Route 53 for DNS and don’t want to migrate
You need Lambda@Edge’s full Node/Python runtime for complex edge logic
Your traffic is mostly internal API responses (low egress, high origin requests)
Your security team has standardized on AWS WAF / AWS Shield

Default to Cloudflare if:

You’re a small team and want one tool to manage edge concerns
You’re shipping a SaaS, marketing site, or content-heavy product where bandwidth matters
You want serious DDoS protection included
You’re building edge-compute heavy workloads (Workers + R2 + D1)
You’re cloud-neutral or multi-cloud and want a CDN that doesn’t pick a winner

You can also run both in some architectures: Cloudflare in front (DNS, WAF, DDoS, edge logic) → CloudFront in front of S3 for asset delivery. We’ve shipped this for one client where the cost of S3 egress through Cloudflare’s free tier vs through CloudFront tipped the math. Adds operational complexity; only worth it if the math is clear.

DNS is part of the decision#

Both options come with DNS:

Route 53 is AWS’s DNS. Granular routing policies (weighted, latency, geolocation, failover), tight integration with AWS Health Checks. Paid per zone + per million queries. Best when you’re using AWS Health Checks for failover or doing complex multi-region routing.
Cloudflare DNS is the fastest authoritative DNS in most benchmarks. Free on all plans. Less granular routing logic than Route 53, but enough for most workloads. Integrates seamlessly with Cloudflare CDN and Cloudflare Tunnel for origin connection.

For most teams, whichever CDN you pick determines DNS by gravity — co-locating CDN + DNS reduces ops surface.

Patterns that bite#

A few production patterns we’ve seen go wrong:

CloudFront with origin requests that go through public internet. If your CloudFront origin is an ALB in your VPC, traffic goes out to the internet, back into AWS. Use Origin Access Control (or VPC Origin) to keep traffic on AWS backbone.

Cloudflare auto-injection without realizing it. Email Obfuscation, Web Analytics, Rocket Loader — these inject scripts. Audit your live page after enabling Cloudflare; turn off what you don’t need. (We hit this and wrote about it after our own perf audit found the auto-injections were costing us LCP time.)

Forgetting to purge cache on deploy. With long cache TTLs (the recommended 1 year for static assets), you need explicit cache purges on deploy. Both CDNs support it; wire it into your CI pipeline.

Different CSP / CORS headers between origin and edge. Both CDNs let you set response headers at the edge. If your origin also sets them, the resolution is “last wins” which can be confusing. Pick one place to set security headers and stick with it.

Cache key including auth headers. Caching responses keyed by Authorization header by accident = different users get different cached responses. Test thoroughly.

What we deploy by default#

For client work:

CloudFront when the client is AWS-native and the workload is API-shaped with private origin in VPC. Default for hospital and banking platforms with strict VPC isolation.
Cloudflare for marketing sites, SaaS frontends, and consultancy work. Default for content-heavy projects, projects with bursty/unknown traffic, and projects where the bundled feature set saves real ops time.
Cloudflare DNS + CloudFront CDN as a hybrid in two specific cases: very high S3 egress costs (use R2 instead) or where the team strongly prefers Cloudflare’s DNS UX.

The pattern of patterns#

CDN choice rarely makes or breaks a product. The differences matter, but they don’t override the gravity of “where does your stack already live.”

The teams that get the most from their CDN aren’t the ones obsessed with the choice. They’re the ones who configured caching headers properly, set up sane cache invalidation, monitored real user latency, and remembered to purge on deploy.

The CDN follows your cloud. The discipline of how you use it matters more. If you’re sizing edge infrastructure for a new platform, our cloud infrastructure team has shipped both. Tell us about the workload.