500 Tbps and Counting: How Cloudflare’s Edge Became a Self-Defending Network
Cloudflare’s global network has crossed a significant threshold: 500 terabits per second (Tbps) of total provisioned external interconnection capacity. That figure represents the sum of every port facing transit providers, private peering partners, Internet exchanges, and Cloudflare Network Interconnect (CNI) across its 330+ cities. It is not peak traffic—daily utilization is a fraction of that number, with the headroom serving as DDoS budget.
The journey started in 2010 in a small Palo Alto office above a nail salon, with a single transit provider and a reverse proxy deployable by changing two nameservers. The first transit provider was nLayer Communications, now known as GTT, which provided both initial capacity and early lessons in balancing peering costs against performance.
Growth came city by city: Chicago, Ashburn, San Jose, Amsterdam, Tokyo. Each deployment meant negotiating colocation contracts, pulling fiber, racking servers, and establishing peering through Internet exchanges. Not every opening went smoothly—there were missing hardware shipments, customs strikes, and even dental floss as a temporary fix. In one month in 2018, Cloudflare opened 31 data centers in 24 days, spanning Kathmandu, Baghdad, Reykjavík, and Chișinău. When the 127th data center opened in Macau, the network was protecting 7 million Internet properties. Today, it protects more than 20% of the web.
From Caching to Core Security Infrastructure
As the footprint expanded, customer demands shifted beyond website caching. Enterprises needed to protect employees, replace aging Multiprotocol Label Switching (MPLS) circuits, and secure entire corporate networks. Rather than deploying traditional appliances, Cloudflare built systems to establish secure tunnels to private subnets and advertise enterprise IP space directly from its global network via BGP.
Threat scale grew in parallel. In 2025, Cloudflare mitigated a 31.4 Tbps DDoS attack that lasted 35 seconds, originating from the Aisuru-Kimwolf botnet and including many infected Android TVs. It was one of over 5,000 attacks blocked that day—and no engineer was paged.
A decade ago, countering an attack of that magnitude would have required nation-state resources. Today, the network absorbs it in seconds without human intervention. That capability is the product of operating at 500 Tbps scale: moving intelligence to every server so the network can defend itself.
Anatomy of an Automated Mitigation
When an attack hits, packets arrive at the network interface card (NIC) and immediately enter an eXpress Data Path (XDP) program chain managed by xdpd in driver mode. One of the first programs in that chain is l4drop, which evaluates each packet against mitigation rules in extended Berkeley Packet Filter (eBPF). Those rules come from dosd, a denial-of-service daemon running on every server in the fleet. Each dosd instance samples incoming traffic, identifies the heaviest hitters, and broadcasts that table to every other instance in the colocation facility. With a shared colo-wide view, all servers independently reach the same mitigation decision.
When dosd detects an attack pattern, the rule is applied locally via l4drop and propagates globally through Quicksilver, a distributed key-value (KV) store, reaching every server worldwide within seconds. Only packets that survive l4drop reach Unimog, the Layer 4 (L4) load balancer, which distributes them across healthy servers. For Magic Transit customers, flowtrackd adds stateful TCP inspection, tracking connection state and dropping packets that don't belong to legitimate flows.
The 31.4 Tbps attack followed exactly this path. No traffic was backhauled to a centralized scrubbing center, and no human intervened. Every server in the targeted data centers independently recognized the attack and dropped malicious packets at line rate—before they consumed a single CPU cycle of application processing. But the software story is incomplete without the infrastructure: none of it works if the ports aren't there to absorb the traffic in the first place.
A Distributed Developer Platform
Running code on every server was a natural consequence of controlling the full stack. If eBPF programs could drop attack traffic on every machine, customer application code could run there too. That insight led to Workers, and later KV and Durable Objects.
Cloudflare’s developer platform operates in every city where the network runs, not just in a handful of cloud regions. In 2025, Containers were added to Workers, enabling heavier workloads at the edge. V8 isolates and custom filesystem layers minimize cold starts. Customer code runs where users are—on the same servers that drop attack traffic at line rate via l4drop, so attack traffic never reaches the application.
Securing the Routing Layer
Cloudflare was an early adopter of IPv6 and Resource Public Key Infrastructure (RPKI). BGP hijacks cause real outages and security breaches, so the network signs Route Origin Authorizations (ROAs) for its prefixes and enforces Route Origin Validation on ingress. RPKI-invalid routes are rejected, even when that occasionally breaks reachability to networks with misconfigured ROAs.
Autonomous System Provider Authorization (ASPA) is the next step. RPKI validates who owns a prefix; ASPA validates the path traffic took to get there. RPKI is a passport check at the destination, while ASPA is a flight manifest check verifying every network the traffic passed through. A route leak—a passenger who boarded in the wrong city—would evade RPKI but not ASPA.
Ecosystem adoption of ASPA currently resembles RPKI in 2015. Cloudflare was among the first to deploy RPKI at scale; today, 867,000 prefixes in the global routing table have valid RPKI certificates, up from near zero a decade ago. The protocols chosen at this scale have real consequences for the broader Internet, and early adoption prevents hijacks and leaks in the meantime.
The New Traffic Mix: AI Agents
AI has changed the nature of web traffic. For most of the Internet’s history, traffic was human-generated clicks in browsers. Today, AI crawlers, model training pipelines, and autonomous agents account for more than 4% of all HTML requests across Cloudflare’s network—comparable to Googlebot. "User action" crawling, where an AI visits a page because a human asked it a question, grew over 15x in 2025 alone.
AI crawlers behave differently at the infrastructure level. Browsers load a page and stop; crawlers fetch every linked resource at maximum throughput without pausing. Distinguishing legitimate AI crawling from actual attacks is a genuine engineering problem. Detection systems combine verified bot IP ranges, TLS fingerprinting, behavioral analysis, and robots.txt compliance signals. At the TLS layer, a legitimate browser presents a ClientHello with a predictable set of cipher suites, extensions, and ordering matching its declared User-Agent. A crawler spoofing that User-Agent but using a stripped-down TLS library presents a different fingerprint—and that mismatch helps classification before the request reaches its origin.
From a Single Transit Line to 330+ Cities
What began above a nail salon is now a 500 Tbps network spanning 330+ cities across 125+ countries, where every server runs security services and the developer platform, not just cache. Sixteen years of architectural decisions have compounded, enabled by the 13,000+ networks and partners that peer with Cloudflare.
Network operators interested in peering can find interconnection details on PeeringDB. Those looking to embed Cloudflare infrastructure within their own networks can contact the Edge Partner Program at [email protected].
