Cloud

What is a CDN? How CloudFront and Cloudflare Work Under the Hood

Understand how CDNs work at the edge: PoPs, Anycast vs GeoDNS, cache behaviors, Origin Shield, invalidation strategies, and a detailed CloudFront vs Cloudflare comparison with pricing.

A
Abhishek Patel9 min read

Infrastructure engineer with 10+ years building production systems on AWS, GCP,…

What is a CDN? How CloudFront and Cloudflare Work Under the Hood
What is a CDN? How CloudFront and Cloudflare Work Under the Hood

Edge Caching Is Simpler Than You Think

A CDN (Content Delivery Network) caches your content on servers distributed around the world so users get responses from a server near them instead of from your origin thousands of miles away. That's the one-sentence explanation, and it covers 80% of what you need to know. The other 20% -- cache invalidation, origin shield, edge compute, and the differences between CloudFront and Cloudflare -- is where things get interesting and where misconfigurations cost you money or performance.

Most developers add a CDN, point their domain at it, and move on. That works for static sites. For dynamic applications with mixed content, cache behaviors, and API routes, you need to understand how CDNs actually process requests. This guide covers the architecture, the two most popular CDNs in detail, and the scenarios where CDNs don't help at all.

What Is a CDN?

Definition: A Content Delivery Network (CDN) is a geographically distributed network of proxy servers and data centers that cache and serve content from locations closest to end users. CDNs reduce latency, decrease origin server load, and improve availability by serving cached responses from edge locations.

How CDN Requests Flow: Step by Step

Step 1: DNS Resolution to the Edge

When a user requests cdn.example.com, DNS resolves to the nearest CDN edge location. CloudFront uses GeoDNS (Route 53 returns different IPs based on the user's location). Cloudflare uses Anycast (all edge locations share the same IP addresses, and BGP routing sends the user to the nearest one).

Step 2: Cache Lookup

The edge server checks its local cache for the requested content. The cache key typically includes the URL path and query string, plus any headers you've configured (like Accept-Encoding). If the content is cached and not expired, it's returned immediately -- this is a cache hit.

Step 3: Origin Fetch (Cache Miss)

If the content isn't cached, the edge server forwards the request to your origin server (S3, an ALB, a custom server). The origin responds, the edge caches the response based on the cache headers, and returns it to the user.

Step 4: Subsequent Requests

Other users in the same region get the cached response without hitting your origin. The cache entry lives until the TTL expires or you invalidate it.

Pro tip: Monitor your cache hit ratio. A well-configured CDN should hit 90%+ for static content. If your ratio is below 70%, you likely have cache key misconfiguration, low TTLs, or too many unique query strings busting the cache.

Anycast vs GeoDNS

ApproachHow It WorksUsed ByFailover Speed
AnycastSame IP announced from every PoP; BGP routes to nearestCloudflare, FastlySeconds (BGP reconvergence)
GeoDNSDNS returns different IPs based on user locationCloudFront, AkamaiMinutes (DNS TTL)

Anycast is simpler and faster for failover. If an edge server goes down, BGP automatically routes to the next nearest server within seconds. GeoDNS requires waiting for DNS TTLs to expire. However, GeoDNS allows more granular control over which edge locations serve which users.

CloudFront: AWS's CDN

Architecture

CloudFront has 400+ Points of Presence (PoPs) across 90+ cities. It integrates natively with AWS services -- S3, ALB, API Gateway, Lambda@Edge, and CloudFront Functions. You create a "distribution" that defines your origin(s), cache behaviors, and edge settings.

Cache Behaviors

CloudFront's most powerful feature. Each behavior is a URL pattern (like /api/* or /images/*) with its own caching policy, origin, and headers. This lets you serve static assets from S3 with long cache TTLs while proxying API requests to your ALB with no caching.

# Terraform: CloudFront with multiple behaviors
resource "aws_cloudfront_distribution" "cdn" {
  origin {
    domain_name = aws_s3_bucket.assets.bucket_regional_domain_name
    origin_id   = "s3-assets"
  }

  origin {
    domain_name = aws_lb.api.dns_name
    origin_id   = "alb-api"
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  # Static assets: cached aggressively
  default_cache_behavior {
    target_origin_id       = "s3-assets"
    viewer_protocol_policy = "redirect-to-https"
    cached_methods         = ["GET", "HEAD"]
    allowed_methods        = ["GET", "HEAD"]
    default_ttl            = 86400
    max_ttl                = 31536000
  }

  # API routes: no caching
  ordered_cache_behavior {
    path_pattern           = "/api/*"
    target_origin_id       = "alb-api"
    viewer_protocol_policy = "https-only"
    allowed_methods        = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
    cached_methods         = ["GET", "HEAD"]
    default_ttl            = 0
    max_ttl                = 0
  }
}

Origin Shield

Origin Shield adds a centralized caching layer between regional edge caches and your origin. Without it, each regional edge independently fetches from your origin on a cache miss. With Origin Shield, all regional edges fetch from a single shield location, which fetches from your origin only once. This dramatically reduces origin load for popular content.

Cloudflare: Security-First CDN

Architecture

Cloudflare operates 300+ PoPs with an Anycast network. Unlike CloudFront, Cloudflare runs a full security stack at every edge: DDoS protection, WAF (Web Application Firewall), bot management, and DNS. The CDN is one layer in a broader security and performance platform.

Key Differences from CloudFront

  • DNS + CDN integrated -- Cloudflare is your DNS provider and CDN in one. The orange cloud toggle controls whether traffic proxies through Cloudflare's edge.
  • DDoS protection included -- unmetered DDoS mitigation on all plans, including free.
  • Workers -- serverless JavaScript/Wasm at the edge, similar to Lambda@Edge but with faster cold starts and a larger free tier.
  • Simpler caching model -- Cloudflare uses standard cache-control headers with page rules for overrides, less flexible than CloudFront behaviors but easier to configure.

CloudFront vs Cloudflare Comparison

FeatureCloudFrontCloudflare
PoPs400+ in 90+ cities300+ in 100+ countries
Pricing modelPer GB transferred + per requestFlat monthly (free tier available)
DDoS protectionAWS Shield Standard (basic), Shield Advanced ($3,000/mo)Included on all plans
WAFAWS WAF (separate service, per-rule pricing)Included on Pro+ plans ($20/mo)
Edge computeLambda@Edge / CloudFront FunctionsWorkers (generous free tier)
SSLACM certificates (free with AWS)Universal SSL (free, auto-provisioned)
OriginAWS-native integration (S3, ALB)Any HTTP origin
Best forAWS-heavy architecturesMulti-cloud or independent deployments

Cache Invalidation

The hardest problem in CDN management. When you update content, cached copies on edge servers still serve the old version until the TTL expires. Your options:

  • Cache busting with versioned URLs -- /app.v2.3.js or /app.abc123.js. New content gets a new URL, so caches don't need invalidating. This is the best approach for static assets.
  • Invalidation API -- tell the CDN to drop specific cached paths. CloudFront allows 1,000 free invalidation paths per month; additional invalidations cost $0.005 each. Cloudflare offers unlimited purge requests.
  • Short TTLs -- set low cache TTLs (60-300 seconds) for frequently changing content. This sacrifices cache hit ratio for freshness.

Watch out: CloudFront invalidations are not instant. They propagate to all edge locations over 5-15 minutes. If you need immediate updates, use versioned URLs instead of invalidation. Cloudflare purge is faster (typically under 30 seconds globally) but still not instantaneous.

When CDNs Don't Help

CDNs are not universal performance improvements. They don't help when:

  • Content is user-specific -- personalized dashboards, authenticated API responses, and user-specific data can't be cached at the edge (unless you use edge compute to personalize).
  • Users are in one region -- if all your users are in the US East, a CDN adds a hop without reducing latency.
  • Origin is the bottleneck -- if your database query takes 2 seconds, a CDN only caches the first slow response. The next cache miss is just as slow.
  • Cache hit ratio is low -- long-tail content with millions of unique URLs won't cache effectively. Each URL gets requested once, misses the cache, and expires before the next request.

Pricing Comparison

UsageCloudFrontCloudflare Pro
1 TB/month transfer~$85$20 (flat)
10 TB/month transfer~$850$20 (flat)
100 TB/month transfer~$6,000$20 (flat, Enterprise for this volume)
DDoS protectionBasic free, Advanced $3,000/moIncluded
WAF$5/rule/mo + request chargesIncluded on Pro+

Cloudflare's flat pricing is dramatically cheaper at scale. CloudFront's advantage is deep AWS integration -- native S3 origins, IAM-based signing, and Origin Access Control eliminate the need for public S3 buckets.

Frequently Asked Questions

What is a Point of Presence (PoP)?

A PoP is a physical location where a CDN has servers to cache and serve content. Each PoP contains multiple servers that handle DNS resolution, TLS termination, caching, and request routing. Larger CDNs have PoPs in hundreds of cities worldwide, ensuring most users are within 20-50ms of a cache server.

How do I know if my CDN is working?

Check response headers. CloudFront returns X-Cache: Hit from cloudfront for cache hits. Cloudflare returns cf-cache-status: HIT. If you see MISS, the request went to your origin. Monitor your overall cache hit ratio in the CDN dashboard -- it should be above 90% for static content.

Should I use a CDN for API responses?

It depends. Public, read-heavy API endpoints with the same response for all users (product catalogs, public data feeds) benefit from CDN caching. Authenticated or user-specific API endpoints generally shouldn't be cached at the edge unless you're using edge compute for personalization. Even for uncached APIs, a CDN can provide DDoS protection and TLS termination closer to users.

What is Origin Access Control in CloudFront?

Origin Access Control (OAC) lets CloudFront access a private S3 bucket without making the bucket public. CloudFront signs requests to S3 using its own identity, and the S3 bucket policy only allows access from that CloudFront distribution. This replaced the older Origin Access Identity (OAI) method and supports more S3 features including SSE-KMS encryption.

Can I use both CloudFront and Cloudflare together?

Technically yes, but it's almost never a good idea. Stacking two CDNs means double cache invalidation, confusing cache headers, and debugging nightmares. Pick one. If you're on AWS and want native integration, use CloudFront. If you want flat pricing, built-in security, and provider independence, use Cloudflare.

How does a CDN handle HTTPS/TLS?

The CDN terminates TLS at the edge, decrypts the request, serves from cache if possible, and re-encrypts if it needs to forward to the origin. Both CloudFront and Cloudflare provide free TLS certificates. The user's connection is encrypted to the edge, and the edge-to-origin connection can also be encrypted (and should be in production).

Start Simple, Optimize Later

Put your static assets behind a CDN with long cache TTLs and versioned filenames. That alone handles the biggest performance win. Once that's working, add cache behaviors for different content types, enable Origin Shield if your origin is getting hammered, and monitor your cache hit ratio weekly. Don't over-engineer caching rules on day one -- start with aggressive caching for static content and no caching for dynamic content, then selectively add caching where your metrics show it'll help.

A

Written by

Abhishek Patel

Infrastructure engineer with 10+ years building production systems on AWS, GCP, and bare metal. Writes practical guides on cloud architecture, containers, networking, and Linux for developers who want to understand how things actually work under the hood.

Related Articles

Enjoyed this article?

Get more like this in your inbox. No spam, unsubscribe anytime.

Comments

Loading comments...

Leave a comment

Stay in the loop

New articles delivered to your inbox. No spam.