CDN architecture cloudflare cloudfront akamai fastly CDN Architecture: Why Cloudflare, CloudFront, Akamai, and Fastly Are Actually Running the Internet

Let's talk about the infrastructure layer that nobody thinks about until it breaks.

A content delivery network is, in its most literal description, a reverse proxy network. Servers distributed across hundreds or thousands of geographic locations sit in front of your origin, terminate your users' TCP and TLS connections as close to them as possible, serve cached responses where they can, and forward everything else to you over paths that are at least somewhat warmer than the raw public internet. That description is accurate and gives you essentially no intuition for why CDNs matter.

Here is a better frame. As of May 2026, W3Techs estimates Cloudflare is deployed on 22.7% of all websites globally. Cloudflare claims its network carries roughly 20% of all internet traffic. Akamai, the company that invented the CDN category in 1998, reports more than 4,300 edge points of presence across 700 cities. AWS CloudFront set a record peak of 268 terabits per second in November 2025. When Fastly had a one-hour outage on June 8, 2021, Reddit, Twitch, Spotify, GitHub, the UK government homepage, Amazon, HBO Max, and the New York Times all went down simultaneously.

That is not a caching layer. That is infrastructure.

Let's get into how it actually works.

The Problem That Forced CDNs to Exist

In the mid-1990s, Tim Berners-Lee at MIT described what he called the "World Wide Wait." The web was growing faster than any single data center could serve it. Static files had to travel from origin servers across the public internet to users, traversing multiple autonomous systems with unpredictable latency, congestion, and the BGP routing eccentricities we covered in an earlier paper. Popular content got more expensive to serve as it got more popular, which is exactly backwards from what you want.

Tom Leighton was an applied mathematics professor at MIT running the Algorithms Group at MIT's Laboratory for Computer Science. His PhD student was Danny Lewin, a former Israeli Defense Forces officer who had come to MIT from IBM Haifa in 1996. Leighton and Lewin developed consistent hashing, a technique for distributing content across a large number of servers such that any node can determine where a given piece of content lives without central coordination. They entered the problem in the 1998 MIT $50K Entrepreneurship Competition. They did not win. They incorporated Akamai Technologies on August 20, 1998.

Akamai delivered its first live traffic in February 1999, a single pixel on a Disney page, and handled March Madness for ESPN and a Star Wars trailer the following month. The company went public on October 29, 1999, with shares opening at $26 and trading above $145 by end of day. Danny Lewin was killed on American Airlines Flight 11 on September 11, 2001, at 31 years old. Tom Leighton became CEO in 2013, received the Marconi Prize in 2018 and the IEEE John von Neumann Medal in 2023. Leighton and Lewin were both inducted into the National Inventors Hall of Fame in 2017.

Every CDN in existence, Cloudflare, CloudFront, Fastly, Google Cloud CDN, Edgio before it liquidated, operates in a problem space that Akamai defined in 1998. The original solution was elegant and the industry has spent 27 years building increasingly baroque structures on top of it.

What a CDN Is Actually Doing

A CDN is simultaneously several things that used to require separate products.

It is a reverse proxy. Every request to your domain hits the CDN first. The CDN terminates TLS, reads the HTTP request, decides whether it has a cached response, and either serves the cache or proxies to your origin. Your users' TCP connections never touch your origin servers.

It is a TLS termination point. The CDN handles certificate management, OCSP stapling to avoid extra round trips during TLS handshakes, and protocol negotiation. Most CDNs support HTTP/3 (QUIC) at the edge while downgrading to HTTP/2 or HTTP/1.1 to origin, meaning your users get the latest protocol regardless of what your origin supports.

It is a DDoS absorber. A multi-terabit volumetric attack directed at your IP addresses hits the CDN's anycast network first, distributed across hundreds of PoPs, each processing their local share of the flood. The CDN's aggregate capacity dwarfs what any single origin could withstand.

It is a WAF. Cloudflare WAF, AWS WAF on CloudFront, Akamai's App & API Protector, and Fastly's Next-Gen WAF (acquired from Signal Sciences) all process every request through rule sets, anomaly detection, and increasingly machine learning models before the request reaches your code.

It is a compute platform. Cloudflare Workers, Fastly Compute, Lambda@Edge, and CloudFront Functions all let you run code at the edge, before your origin is ever consulted, for routing decisions, authentication, A/B testing, image transformations, and a hundred other things that used to require a full application server.

The CDN providers themselves are not describing their products as "caching layers" anymore. Cloudflare describes itself as a security and connectivity cloud. Akamai describes itself as a distributed cloud. This is not just marketing repositioning. The caching layer is table stakes. What they are competing on is the stack built on top of it.

PoP Placement: The Topology Wars

A Point of Presence is a cluster of servers in a data center, typically rented space at a carrier-neutral colocation facility or, in some cases, hardware sitting inside an ISP's network. The goal is the same in both cases: minimize the distance and hop count between the server and the user.

The three major providers have made genuinely different bets about what PoP topology looks like, and the differences have real operational consequences.

Akamai's strategy is density. More than 4,300 edge PoPs across 700 cities, integrated with roughly 1,200 network partners. Many of those PoPs are not in carrier-neutral facilities at all. They are racks Akamai has placed inside ISPs through the Akamai Accelerated Network Partner program, sitting on the ISP's network, directly serving that ISP's subscribers. The practical result is that an Akamai user in most cities is served from a PoP that is either inside their ISP or one BGP hop away. The latency advantage is real. The operational complexity is also real: routing 1,200 ISP relationships requires a DNS-based traffic management system sophisticated enough to be its own engineering discipline.

Cloudflare's strategy is every service everywhere. More than 330 cities, and every Cloudflare PoP runs every Cloudflare service. CDN, WAF, Workers, R2 object storage, 1.1.1.1 resolver, Magic Transit, Zero Trust WARP. Cloudflare claims 95% of the world's internet-connected population is within 50 milliseconds of a Cloudflare data center, most within 20ms. Every PoP is connected via anycast BGP, which means Cloudflare is advertising the same IP prefix from hundreds of locations simultaneously. Users reach the closest PoP because BGP naturally routes to the nearest advertisement. Cloudflare AS13335 peers with roughly 12,000 networks, which is why a Cloudflare BGP misconfiguration affects such a large fraction of internet traffic.

AWS CloudFront uses a hybrid approach: around 750 traditional PoPs in over 100 cities plus about 1,140 embedded PoPs inside ISP networks across 300 cities. The embedded PoPs function similarly to Akamai's ISP partnerships, placing AWS hardware inside ISP infrastructure for last-mile caching. In November 2025, CloudFront hit 268 Tbps peak, driven by major game delivery.

Fastly deliberately runs fewer PoPs. Around 80 larger deployments. The argument is that cache hit ratios are better on large nodes because the long-tail content that would miss on a small cache node has a much better chance of hitting on a large one. This trades geographic density for cache efficiency. The bet has technical merit and produces real consequences in major events, as we will discuss.

Netflix Open Connect is worth mentioning because it is arguably the most extreme version of embedded caching in existence. Netflix ships 2U servers to qualifying ISPs free of charge. The ISP provides rack space, power, and connectivity. The appliance, running a tightly tuned FreeBSD and NGINX stack, peers directly into the ISP's network over BGP and serves Netflix content to that ISP's subscribers entirely within the ISP's network. Netflix's control plane decides which appliance serves each client. The result is that a Netflix stream for most subscribers in most cities never leaves the ISP's network at all.

Routing: Anycast vs DNS

The difference between anycast and DNS-based routing is not a niche implementation detail. It determined who survived the summer of 2021 intact.

DNS-based routing (Akamai's original approach): a user's DNS resolver queries for your hostname, which resolves through a chain of CNAMEs to Akamai's authoritative nameservers. Akamai's mapping system inspects the resolver's IP address, applies EdgeScape geolocation data and real-time network telemetry, and returns an A record pointing to the optimal edge server cluster.

The advantages are real: fine-grained per-customer steering, easy multi-cluster failover at the DNS layer, different answers for different ISPs in the same city. The vulnerability is structural: if the DNS tier fails, the entire CDN appears unreachable even if every edge server is healthy. This is not a theoretical risk. It is exactly what happened on July 22, 2021.

Anycast routing (Cloudflare, AWS Global Accelerator): the CDN announces the same IP prefixes from hundreds of PoPs simultaneously via BGP. BGP routing naturally steers traffic to the nearest announcement. If a PoP fails, BGP withdraws the announcement and traffic reroutes. The DNS layer is not in the critical path. The vulnerability is different: BGP policy misconfiguration can withdraw announcements from PoPs that are healthy and functioning, which is exactly what happened on June 21, 2022.

Both failure modes are real. The honest answer is that neither architecture is safer in absolute terms; they have different failure surfaces.

Caching: The Hierarchy Nobody Talks About Enough

A CDN cache is not a single layer. It is a hierarchy, and understanding the hierarchy explains most of the operational decisions around cache configuration.

The structure is: user connects to an edge PoP, which checks its local cache first. On a miss, the edge PoP checks an intermediate regional or parent cache. On a miss there, it checks the origin shield, which is a designated PoP whose job is to be the single point of contact between the CDN and your origin. On a miss at the shield, a single request goes to your origin, the response is cached at all levels, and subsequent requests hit cache.

The purpose of the origin shield is collapsing concurrent cache misses. On a popular event with 10,000 concurrent users requesting the same uncached content, the shield turns those 10,000 parallel origin fetches into one. Without origin shield, a sudden traffic spike can overwhelm an origin server with what looks like a volumetric attack but is actually just a lot of people clicking at the same time. CloudFront calls this Origin Shield. Fastly calls the equivalent configuration a Shield PoP. Cloudflare calls it Tiered Cache with an upper tier.

For a well-tuned static-content deployment, edge cache hit ratios of 85 to 95 percent are routine. Every cache miss is a request your origin has to handle, so the difference between 85% and 95% is a 3x difference in origin load at the same traffic volume. Cache invalidation is where the complexity lives.

TTL-based invalidation is the simplest approach: content expires after a set time and is refetched. Works well for content that changes on a predictable schedule. Falls apart for anything with real-time update requirements.

Surrogate keys are how Fastly solved this with Varnish. The origin tags responses with arbitrary keys in the Surrogate-Key header. Fastly's Instant Purge API accepts a key and invalidates every cached object with that key, globally, in under 150 milliseconds. This lets the New York Times cache aggressively while still being able to update a story instantly across every edge server in the world. Cloudflare implements the same concept as Cache Tags on Enterprise plans. Akamai's Fast Purge achieves global invalidation in about 5 seconds.

The Vary header deserves a special mention. If your origin returns Vary: User-Agent, the CDN must store a separate cached object for each unique User-Agent string it sees. User-Agent strings are approximately infinitely varied. Your cache just became useless. Sophisticated CDN deployments normalize cache keys before lookup, stripping or rewriting Vary headers to something sensible like Vary: Accept-Encoding.

CloudFront vs Global Accelerator: Not the Same Thing

This confusion comes up constantly and it is worth resolving once clearly.

CloudFront is a Layer 7 CDN. It understands HTTP. It terminates TLS at the edge. It can cache responses. It can modify request and response headers. It can run code (Lambda@Edge and CloudFront Functions). It routes traffic based on HTTP paths and host headers. It is the right tool for web applications, APIs, video streaming, and static asset delivery.

CloudFront's cache hierarchy has two tiers: edge locations (750+ in 100+ cities) and Regional Edge Caches (13 locations globally). An edge location miss checks the Regional Edge Cache before going to origin. Origin Shield is an optional third tier, a single designated REC that collapses all cache misses from all RECs into single origin fetches for a given distribution.

Lambda@Edge runs in the 13 Regional Edge Caches (not the edge locations). This means Lambda@Edge functions have full Node.js and Python environments, up to 3GB memory, and up to 30 seconds of execution time on origin-triggered events. They are also deployed from us-east-1 regardless of where they run and carry container-style cold start penalties measured in hundreds of milliseconds. CloudFront Functions are the lightweight alternative: sub-millisecond execution, JavaScript only, 10KB code limit, no network access, running in the edge locations rather than the RECs. Different tools for different jobs.

Global Accelerator is not a CDN. It operates at Layer 4. It does not understand HTTP. It does not cache anything. What it does is allocate two static anycast IP addresses and route TCP and UDP connections from those IPs to your regional endpoints over the AWS backbone rather than over the public internet.

The critical difference: CloudFront terminates your users' connections at the edge and manages the origin connection separately. Global Accelerator extends your origin's network connection to the edge, the TCP session itself runs from the user all the way to your origin, just with a faster path for the last-mile portion.

When do you want each one? Cacheable HTTP content or any workload where TLS termination and HTTP-level features add value: CloudFront. Non-HTTP protocols (gaming UDP, MQTT, custom TCP), workloads that need static IPs for enterprise allowlisting, or situations where you need fast multi-region failover without HTTP semantics: Global Accelerator. For complex AWS deployments you will frequently use both, with different hostnames and different routing policies for different traffic types.

Cloudflare's Architecture

Cloudflare's network has three design decisions that make it structurally different from its competitors.

The first is anycast everywhere. Every PoP advertises the same prefixes. BGP does the routing. Cloudflare AS13335 peers with roughly 12,000 networks, which means it has direct peering relationships covering an enormous fraction of the internet and purchases relatively little transit. This is how Cloudflare can offer flat-rate pricing without per-gigabyte bandwidth charges. When your traffic is mostly peering rather than transit, the marginal cost per byte drops dramatically.

The second is V8 isolates instead of containers for edge compute. Cloudflare Workers runs customer JavaScript, TypeScript, and WebAssembly inside V8 isolates, the same isolation primitive that separates Chrome tabs from each other. A single process runs hundreds of isolates simultaneously. Isolate startup is roughly 5 milliseconds, compared to hundreds of milliseconds for container-based runtimes. The trade-off is that you cannot run arbitrary binaries, have no POSIX filesystem, and are limited to 128MB per isolate with a 30-second CPU time cap on paid plans. What you get in return is that cold starts are essentially invisible to users. Workers launched in 2017. Every Cloudflare PoP runs Workers. You deploy to 330+ cities simultaneously.

The third is an expanding definition of what a CDN should do. Cloudflare Tunnel lets your origin server make outbound-only encrypted connections to Cloudflare's network, exposing no inbound ports. Your origin can sit behind NAT with no public IP address and still serve traffic globally. This is the foundation of Cloudflare's Zero Trust product. Argo Smart Routing uses the Cloudflare backbone and real-time congestion data to route proxied requests over the best-available path rather than the BGP shortest path, which Cloudflare claims delivers roughly 30% reduction in TTFB. R2 is S3-compatible object storage with zero egress fees, a direct challenge to AWS S3's per-gigabyte egress pricing.

On DDoS, Cloudflare's track record at this point is more useful than any theoretical description. In June 2022 they stopped a 26 million requests-per-second HTTP attack from the Mantis botnet. In February 2023 they stopped 71 million rps. In October 2023, using the HTTP/2 Rapid Reset vulnerability (CVE-2023-44487), attackers generated 201 million rps, roughly three times Cloudflare's previous record. Cloudflare absorbed it. In October 2024 they absorbed 3.8 Tbps and a separate 5.6 Tbps Mirai-variant attack. In June 2025, a 7.3 Tbps attack lasting 45 seconds delivered 37.4 TB of total data. These are not edge cases. This is what the network absorbs on what is, for Cloudflare, a moderately bad Tuesday.

Akamai's Architecture

Twenty-seven years after founding, Akamai is a genuinely different company from the one that served a Disney pixel in 1999. The CDN business is still there and still enormous. But per Tom Leighton: "Over the same period, annual revenue from Akamai's security business has grown from less than $25 million to $2.2 billion, delivering the majority of the company's revenue." FY2025 total revenue was approximately $4.2 billion. The CDN is now the minority.

Akamai's core technical differentiator remains its ISP relationships. More than 1,200 network partners with hardware placed inside ISP infrastructure means that for many users in many locations, their content is served from a PoP that is physically inside their ISP's data center. The latency advantage over a competitor serving from a carrier-neutral colo is real, typically 5 to 15 milliseconds, which is small in absolute terms and significant for latency-sensitive workloads.

SureRoute is the underrated piece of Akamai's architecture. For non-cacheable content, the edge PoP cannot serve from cache and must forward to origin. Rather than accepting whatever path BGP offers, SureRoute "races" requests along multiple paths simultaneously, discards duplicates, and uses the fastest response. Akamai's documentation is refreshingly direct about the motivation: "addressing one of the major limitations of BGP." BGP selects the path with the fewest autonomous system hops, which is frequently not the fastest path. SureRoute is an explicit acknowledgment that the public internet's routing substrate is inadequate for performance-sensitive workloads.

Prolexic, acquired in March 2014 for $370 million, provides DDoS mitigation that operates independently of the CDN. Prolexic uses BGP anycast to redirect customer traffic into scrubbing centers, drops attack traffic, and returns clean traffic over GRE tunnels or direct connectivity. In 2023 Akamai launched the sixth-generation Prolexic platform with roughly 20 Tbps of dedicated mitigation capacity. This serves customers who need DDoS protection for infrastructure that does not run through the Akamai CDN at all.

The Linode acquisition in February 2022 for approximately $900 million gave Akamai a distributed cloud platform it has been building out as Akamai Connected Cloud since 2023. In late 2025, Akamai announced Akamai Inference Cloud with NVIDIA, deploying GPU capacity for AI inference across more than 4,200 edge locations. The bet is that inference workloads at the edge are the next major CDN revenue stream.

Akamai pricing is enterprise-only. There is no public price list. Annual traffic commit contracts, custom per-feature pricing, and a sales process that filters for large organizations. This is a deliberate strategy: Akamai does not want the long tail of small customers that Cloudflare's free tier attracts. The trade-off is that Akamai is structurally unable to respond to Cloudflare's pricing pressure the way a publicly-visible price list would force.

Fastly's Architecture

Fastly was founded in 2011 by Artur Bergman on a simple observation: Varnish, the open-source HTTP accelerator, was genuinely better at caching than what the CDN incumbents were selling, but deploying custom Varnish Configuration Language to a distributed CDN required the kind of vendor engagement that took weeks. Fastly would let customers write and deploy VCL themselves, in seconds.

VCL is not a typical web configuration language. It is a small, purpose-built language with hooks into every stage of the HTTP request lifecycle: cache lookup, miss handling, pass behavior, delivery. A sufficiently motivated Fastly customer can implement essentially any caching logic they can express in conditional logic, regex, and header manipulation. This gave Fastly a developer-focused customer base that the traditional CDN incumbents, with their account-manager-mediated configuration workflows, could not serve. GitHub, Stripe, Vimeo, Reddit, the New York Times, and Shopify became Fastly customers not because they wanted a CDN, but because they wanted a programmable edge.

Instant Purge is Fastly's most operationally distinctive feature. Using surrogate keys, an origin can tag every cached response with arbitrary identifiers. A single API call purges every object with a given tag, globally, in under 150 milliseconds. This changes what is safely cacheable. If you can invalidate instantly, you can cache aggressively with short-ish TTLs as a backup and use programmatic purge for actual updates. The New York Times can cache a story and push an update to every edge server globally in the time it takes to finish typing this sentence.

Fastly's edge compute product, Compute@Edge, takes a different path from Cloudflare Workers. Rather than V8 isolates running JavaScript, Fastly runs WebAssembly via the Wasmtime runtime. Language-agnostic: Rust, Go, JavaScript, and AssemblyScript all compile to Wasm. Fastly is a founding member of the Bytecode Alliance. The bet is that Wasm's broader language support and stronger isolation semantics make it a better long-term foundation for edge compute than V8.

Fastly's financial situation is the honest thing to address here. FY2024 revenue was $543.7 million with 7% year-over-year growth. Security revenue was $103 million. Total customers: 3,638 as of Q3 2024. Top-10 customer concentration was 33% of Q3 2024 revenue, which means Fastly lives and dies by whether GitHub, Stripe, and a handful of others renew and expand. 2025 guidance was $575 to $585 million. Cloudflare grew at 28% on a much larger base in the same period. Fastly is a well-engineered platform with a genuinely differentiated architecture that has so far failed to convert technical differentiation into revenue scale.

Edge Compute: What Runs Where

Four edge compute runtimes exist across the major providers. They are not interchangeable.

Cloudflare Workers (V8 isolates): ~5ms cold start, JavaScript/TypeScript/WebAssembly, 128MB memory cap, 30-second CPU limit on paid plans. No POSIX. No arbitrary binaries. Persistent state via Workers KV (eventually consistent), Durable Objects (strongly consistent, single-instance), R2 (object storage), and D1 (SQLite at the edge). Runs in all 330+ PoPs. Deploy once, runs everywhere.

Fastly Compute (WebAssembly via Wasmtime): sub-millisecond steady-state startup, Rust/Go/JS/AssemblyScript, broader language support than Workers. Persistent state via KV Store and Config Store. Runs in Fastly's ~80 PoPs.

CloudFront Functions (JavaScript): sub-millisecond execution, 10KB code size limit, no network access, no persistent state, runs only at viewer request and viewer response triggers. Best for cache key normalization, simple header manipulation, URL rewrites.

Lambda@Edge (Node.js, Python): container-style runtime in 13 Regional Edge Caches, not the edge locations. Up to 3GB memory, up to 30 seconds for origin triggers. Cold starts measured in hundreds of milliseconds. Deployed only from us-east-1. Must be Lambda functions that happen to run at CloudFront, not the other way around.

The practical decision: anything that runs on every request needs sub-millisecond startup, which means Workers or CloudFront Functions. Anything that needs persistent state or full language runtimes runs in Workers (via Durable Objects) or Lambda@Edge (at the cost of cold starts and REC-only deployment). Fastly Compute is the right choice if you need Rust or Go and cannot work with JavaScript.

Common use cases: authentication and JWT validation before the request hits origin, A/B testing via header injection before cache key calculation, geo-based routing to different backends, image format negotiation (serve WebP where supported, JPEG elsewhere), cache key normalization to strip irrelevant query parameters, and bot scoring using TLS fingerprinting data available at the proxy layer.

Multi-CDN Architecture

Large organizations do not use one CDN. They use several.

The arguments are straightforward. CDN outages are not theoretical. Any single CDN is a single point of failure for everything behind it. Different CDNs have different performance characteristics in different geographies. Negotiation leverage requires plausible alternatives.

The implementation options are:

DNS-based switching: use a managed DNS service (Route 53, NS1, Cloudflare DNS with another CDN as origin) with health-checked failover. When CDN A fails health checks, DNS shifts new queries to CDN B. The limitation is DNS TTL caching, which means failover speed is bounded by whatever TTLs propagate through the resolver infrastructure. For an unplanned CDN outage you might be looking at several minutes before traffic meaningfully shifts.

Real-time traffic management: NS1 and Citrix ITM monitor per-CDN performance using real-user measurement data and shift DNS weights in near-real-time based on actual performance. Response time weight adjustments happen faster than cold DNS failover. Traffic can flow to multiple CDNs simultaneously in configurable ratios.

Multi-CDN at the application layer: for sufficiently sophisticated organizations, individual resources are distributed across CDNs based on content type, geography, or cost. Static assets on CDN A, video on CDN B, API on CDN C.

The operational headaches are real. Purge must fan out to every CDN independently, and they all have different APIs. Log formats differ across providers, requiring normalization before aggregation. SSL certificates must be valid at each CDN. Cache coherence across providers requires either very short TTLs or disciplined surrogate-key-based purging.

The organizations that have gotten multi-CDN right typically have dedicated CDN engineering teams. Disney+, Hulu, Netflix (Open Connect primary with third-party backup), and major media companies all run multi-CDN with varying degrees of sophistication in the switching layer.

The June 8, 2021 Fastly outage is the instructive case. Amazon was barely affected not because Amazon is special but because Amazon has multi-CDN architecture with DNS failover. The New York Times restored service relatively quickly. Organizations whose entire web presence ran behind Fastly as a single CDN spent the outage explaining to users why they could not load the site.

The Outages: A Pattern, Not a Series of Accidents

The string of major CDN outages since 2021 is long enough to constitute a structural pattern rather than bad luck.

June 8, 2021: Fastly. Per Fastly's own postmortem: "a customer pushed a valid configuration change that included the specific circumstances that triggered the bug, which caused 85% of our network to return errors." The bug had been introduced in a May 12 deployment and sat dormant for 27 days. At 09:47 UTC, one customer's valid configuration change triggered it. Detection in one minute. 95% of traffic recovering within 49 minutes. Down for that window: Reddit, Twitch, Spotify, GitHub, Stack Overflow, the UK government homepage, Amazon, HBO Max, Hulu, Vimeo, the New York Times, the Guardian, Pinterest.

July 22, 2021: Akamai. From Akamai's official statement: "At 15:46 UTC today, a software configuration update triggered a bug in the DNS system, the system that directs browsers to websites... The disruption lasted up to an hour. Upon rolling back the software configuration update, the services resumed normal operations." The DNS routing layer that makes Akamai's fine-grained steering possible is exactly the layer that failed. When it failed, websites using Akamai's Edge DNS service became unreachable not because the edge servers were down but because DNS could not direct users to them. Down for that window: Steam, American Airlines, Delta, Southwest, PlayStation Network, HSBC, FedEx, Fidelity, Fox News, AirBnB.

June 21, 2022: Cloudflare. Per Cloudflare's postmortem: a change to standardize BGP community attributes across 19 of Cloudflare's highest-traffic data centers inadvertently withdrew those PoPs from anycast at 06:27 UTC. 19 PoPs is about 4% of Cloudflare's location footprint. Those 19 PoPs handle approximately 50% of Cloudflare's global HTTP traffic. First PoP restored at 06:58 UTC; all 19 restored by 07:42 UTC. Among the affected: Amsterdam, London, Frankfurt, Ashburn, Los Angeles, Singapore, Sydney, Mumbai, São Paulo.

November 2, 2023: Cloudflare (Flexential power failure). Cloudflare's largest data center cluster in the Pacific Northwest, co-located in a Flexential facility in Hillsboro, Oregon, lost utility power at 08:50 UTC. Emergency generators failed to start in time. UPS batteries lasted 4 minutes instead of their rated 10. Network equipment lost power at 11:43 UTC. The data plane, the cache serving actual traffic, stayed up. The control plane did not. Dashboard, API, Stream, Workers analytics, raw log delivery, Zero Trust, and WARP were down or severely degraded for roughly 36 hours. Full restoration on November 4 at 04:25 UTC. Cloudflare declared Code Orange (crisis mode) and spent the following months hardening the facility against a recurrence. In March 2024 the same facility had another power failure. This time, with Code Orange remediations in place, critical services restored in minutes.

November 18, 2025: Cloudflare. The most technically interesting recent outage and the one that illustrates the control-plane problem most precisely. The trigger was a ClickHouse database permission change at 11:05 UTC, added to make underlying table access explicit. That change caused a query generating Cloudflare's Bot Management feature file to return duplicated rows, doubling the file size. The Bot Management module in Cloudflare's FL2 proxy has a runtime limit on feature file size. The doubled file exceeded that limit. The FL2 proxy panicked. The feature file regenerated every 5 minutes. Because only some cluster nodes had received the database permission change, global error rates oscillated, which led Cloudflare engineers to initially suspect an ongoing DDoS attack (a hyper-volumetric Aisuru botnet attack was happening simultaneously, which was not helpful for diagnosis). Impact began at 11:28 UTC. Customers on the older FL proxy did not get 5xx errors but received a bot score of zero for all traffic, meaning any rule blocking based on bot score returned false positives globally. Workers KV patched to bypass the core proxy at 13:04 UTC. Main impact resolved by 14:30 UTC. Full restoration at 17:06 UTC. CEO Matthew Prince posted a public apology within 24 hours.

The pattern across all five incidents: the failure is in the control plane, not the data plane. The edge servers are not crashing. The cached content is not corrupting. The configuration management system, the DNS update process, the BGP policy rollout, the feature file generator, the database permission change, whatever is responsible for propagating configuration to the global fleet of edge servers, fails and propagates a bad state globally before any human can stop it.

This is the specific and peculiar vulnerability of a CDN architecture: the control plane is necessarily global and necessarily fast, because that is what allows you to roll out security rules and configuration changes to 330 cities simultaneously. But "global" and "fast" are also the exact properties that make a bad change catastrophic. A CDN is the most critical piece of infrastructure to operate carefully and the one where the blast radius of a configuration error is the largest.

CDN Security: What Is Actually Happening

The WAF at the edge is, in principle, a good idea. Rules run at hundreds of edge servers simultaneously, close to users, before the request reaches origin. But the WAF is only as good as the rule set, and rule sets require maintenance.

Cloudflare, Akamai, and Fastly all publish managed rule sets (OWASP Top 10 patterns, CMS-specific rules, CVE-specific rules) and let customers add custom rules. WAF rules can fire false positives, which means a legitimate request gets blocked at the edge. This is annoying for a web application and catastrophic for an API where every blocked request represents a failed transaction.

Bot management is where the interesting engineering is happening. TLS fingerprinting (JA3 and JA4) assigns each TLS client a fingerprint based on the cipher suites, extensions, and elliptic curves it advertises in the ClientHello. Automated scripts often have distinctive fingerprints that differ from real browsers. HTTP/2 fingerprinting does the same thing at the HTTP/2 layer (SETTINGS frame parameters, HEADERS frame ordering). Browser environment probing in JavaScript checks for canvas API behaviors, font rendering, WebGL capabilities, and dozens of other attributes that real browsers and headless browsers handle differently.

Cloudflare has publicly disclosed blocking 416 billion AI bot requests between July 1, 2025 and December 2025. Cloudflare Radar's 2025 Year in Review reported that non-AI bots generated half of requests to HTML pages globally, 7% above human-generated traffic. AI bots, excluding Googlebot, added another 4.2% of HTML requests.

There are two CDN-specific attack classes worth understanding.

Cache poisoning: an attacker manipulates the cache by exploiting unkeyed headers or request inconsistencies. If the CDN uses a URL path as the cache key but your origin also varies responses based on an unkeyed X-Custom-Header, an attacker can poison the cache with a crafted response that gets served to all subsequent requests for that URL. Mitigation is explicit cache key normalization: define exactly what constitutes a unique cache key and strip everything else.

Cache deception: the inverse. An attacker tricks the CDN into caching an authenticated response. Visiting /account/profile/styles.css where /account/profile returns the user's account page and the CDN caches based on the .css extension is the classic example. The attacker gets the victim's authenticated page cached at a predictable URL. Mitigation requires explicit path-based caching rules rather than relying on file extension heuristics.

The trust problem is the uncomfortable one nobody in the vendor community likes to discuss. By terminating TLS, the CDN sees every unencrypted HTTP request, every response body, every cookie, every credential transmitted over your domain. For the majority of traffic on the public internet, the CDN provider is a trusted intermediary with full visibility into the content. The concentration of this trust in three or four companies is a meaningful systemic risk that is difficult to mitigate without accepting significant performance and operational trade-offs.

The Uncomfortable Truth About CDN Concentration

CDNs solved a real problem. The web at scale cannot be served from origin data centers across the raw public internet. Edge caching, TLS termination, DDoS mitigation, and WAF are all genuinely valuable. The engineering at Cloudflare, Akamai, Fastly, and CloudFront is legitimately impressive.

CDNs also created a new problem: they converted a distributed resilience property of the internet into a centralized infrastructure dependency. When 20 to 25 percent of internet traffic flows through a single provider's network, an outage at that provider is an internet event. The internet was designed around the principle that no single component failure should take down the whole system. CDNs have been progressively undermining that property for 27 years.

This is not an argument against CDNs. It is an argument for being deliberate about how you use them.

If your business requires more than about four hours of CDN availability per year, you need multi-CDN failover and you need to practice it. DNS-based failover with a sub-60-second TTL and a health-check-driven fallback is not exotic engineering. It is table stakes for anything that matters.

If you are rolling out configuration changes to your CDN, you need canary deployment patterns. The mechanism that lets you push WAF rules to 330 cities in 30 seconds is the same mechanism that caused every incident in the section above. Stage changes to a small fraction of traffic before global rollout. Verify. Expand. This is not different from how you should deploy application code and it is, inexplicably, not the default.

If you are using a CDN for edge compute, you are now running business logic on infrastructure where a Kubernetes deployment or a cron job gone wrong at the CDN provider propagates to your business logic globally in seconds. Understand the failure modes of the compute runtime you chose before you move authentication or business-critical routing logic to the edge.

CDNs are essential infrastructure that is terrible, essential, and not going anywhere.

Welcome to the edge, where the traffic is fast and the blast radius is enormous.