Most people know Cloudflare does "CDN and security." Far fewer can name what actually happens to a request between a user's browser and their application: which services touch it, in what order, and why that order matters. That gap is worth closing, because once you can see the edge as a chain of distinct services rather than a single black box, you can use it deliberately. You turn on what you need, tune it with intent, and know exactly where each control sits. This is a tour of the Cloudflare edge, service by service, in the order a request meets them.
The mental model: one edge, many services
When a DNS record is proxied through Cloudflare, the anycast network puts the nearest edge location between the client and your origin. Every request to that hostname is then processed by a sequence of services at that location before it is ever forwarded to your servers. Your origin can be anything behind it: an AWS load balancer, an API gateway, an S3 bucket, an on-premises server, another SaaS. Cloudflare does not care what the origin is; it processes the request at the edge first and forwards only what survives. That single idea, the edge as a processing chain in front of an origin, is the key to everything else.
What happens to a request, in order
1. Authoritative DNS. It starts with name resolution. Cloudflare hosts your DNS records, and when an address record is proxied, that is the moment Cloudflare inserts itself into the path. Worth knowing: only address-resolving records (A, AAAA, CNAME) can be proxied. Mail and text records stay DNS-only, which is why your email keeps working exactly as before.
2. TLS termination. The edge terminates TLS, and the important mental shift is that there are two separate encrypted sessions, not one: client to edge, and edge to origin. You choose how strict the second leg is. Flexible, which encrypts only the first leg, should never be used in production. Full (strict), which encrypts both legs and validates the origin's certificate, is the baseline to aim for. Certificates are managed for you, which removes one of the more tedious recurring jobs in running a site.
3. DDoS mitigation. Autonomous protection across the network and application layers runs on every plan, always on. This is the first line that does not need configuring to work, and it absorbs volumetric and protocol attacks before they cost you anything.
4. WAF, rate limiting and bot controls. This is the security core: the web application firewall with Cloudflare's managed rulesets and your own custom rules, rate limiting for abuse-prone and expensive endpoints, and bot management from a simple on-off up to full scoring you can reference in rules. API-heavy platforms add API Shield here for mutual TLS, JWT validation and schema enforcement. This layer is where most of your ongoing edge work happens.
5. CDN cache. Cacheable content is served straight from the edge location, close to the user, without troubling your origin. Cache rules decide what is cacheable and for how long, which is both a performance lever and a way to keep dynamic, per-user paths from ever being cached by mistake.
6. Rules and transforms. A family of rules reshapes the request and response: redirects for HTTP-to-HTTPS or old-to-new paths, transform rules to add security headers or strip internal ones, origin rules to send certain paths to a different backend, cache rules for eligibility and TTL, and configuration rules to change settings per hostname. These interact and are order-sensitive, so they reward descriptive names and a request-path diagram.
7. Workers and Zero Trust. At the edge you can also run your own code as Workers, and enforce Zero Trust access before a request reaches an application at all. More on the access services below.
The origin, last. Only after all of that does the request reach your actual application, if it reaches it at all. A block, a challenge or a cache hit can end the journey earlier. That is the point: the origin does the least-exposed work, because the edge has already handled resolution, encryption, defence, caching and routing.
The core edge services, grouped
Read another way, those stages fall into four groups, and it helps to hold them as groups.
Performance: DNS, CDN and cache. Fast authoritative DNS, content served from the nearest location, and cache rules that control eligibility and TTL. This is the latency win, and it applies before any security processing.
Encryption: TLS and certificates. Managed certificates and TLS on both legs, with Full (strict) as the target so the origin leg is validated rather than merely encrypted.
Protection: WAF, DDoS, bots and API Shield. The security layer: autonomous DDoS, the WAF with managed and custom rules, bot management, and API-specific controls for the platforms that are mostly API.
Access: Zero Trust. Three services worth knowing by name. Access is an identity-aware reverse proxy that decides who or what can reach an application, which is how you replace a VPN for staff and contractors with per-application policy. Tunnel creates outbound-only connections from your environment to Cloudflare, so a private application can be reachable without ever exposing a public origin IP. Gateway applies secure web gateway policy to user and device traffic at the DNS, network and HTTP layers.
Beyond HTTP: routing, resilience and raw protocols
The edge is not only for web traffic. Load Balancing distributes requests across health-checked pools with failover and traffic steering, so a failed origin is routed around automatically. Argo Smart Routing uses Cloudflare's view of the internet to avoid congested paths between edge and origin, which helps most when your users and your origin are far apart. Magic Transit extends the protection to routed IP networks at the network layer, for organisations that own address space. And Spectrum puts the Cloudflare edge in front of non-HTTP TCP and UDP services, so the same protection model reaches protocols beyond the web.
Most platforms never need the last two. They are worth knowing exist, because they mark the boundary of what the edge can front: not just your website, but your network and your non-web services too.
Six deployment patterns, as real diagrams
The services above are the pieces. The useful question is how they fit together in a real deployment, so here are six common patterns, each as a vendor-stencil network diagram, from a standard front door to log delivery into Splunk and Microsoft Sentinel.
- AStandard app to an AWS ALB origin. Cloudflare in front of a single origin, handling DNS, TLS, DDoS, WAF and caching, with the origin locked down so clients cannot bypass the edge and reach the ALB directly.
- BMulti-region with Load Balancing. Traffic steered across health-checked pools in two AWS regions, failing over automatically, provided the health monitors reflect real ability to serve.
- CPrivate admin via Tunnel and Access. An admin app with no public ingress, reached through an outbound-only cloudflared tunnel, with Access enforcing identity, group, MFA and device posture first.
- DAPI security deployment. Edge controls plus API Shield (mTLS, JWT, schema, discovery) in front of an AWS API origin, while the application still enforces authorisation, because a valid token is not authorisation.
- ECloudflare to Splunk. Datasets streamed by direct Logpush into Splunk HEC as JSON, landing in an index that feeds dashboards, correlation and detections.
- FCloudflare to Microsoft Sentinel. Logpush to an Azure Blob container that the Cloudflare connector ingests into Sentinel, driving analytics rules, workbooks, hunting and playbooks.
All six patterns as full network diagrams, built with real AWS and Azure stencils, one page each. Opens as a standalone deck you can read or present.
The two planes, and why the distinction matters
One last idea that quietly matters more than any single service. Cloudflare has two planes, and they need different protection. The control plane is how you configure Cloudflare: the dashboard, the API, Terraform, your account and zone settings. The data plane is the edge processing your live traffic against that configuration.
A beautifully tuned data plane, every rule correct, every TLS leg strict, is undone in an instant if the control plane is weak, because anyone who reaches your dashboard or an over-scoped API token can simply turn the protection off. So the control plane earns single sign-on, multi-factor authentication, scoped tokens, audit logging and change approval, and the data plane earns the rules, TLS, DDoS and access enforcement. Least privilege applies to both. A common real-world attack is not defeating the WAF but disabling it, by flipping a proxied record to DNS-only or adding a broad skip rule, which is a control-plane event, not a data-plane one.
The takeaway
Cloudflare is not one thing, it is a chain of services that process a request at the nearest edge location before your origin ever sees it: resolve, encrypt, defend, cache, reshape, and route. Seeing it that way changes how you use it. You stop treating it as a magic box that is either on or off, and start treating it as a stack you configure deliberately, turning on the services you need, tuning them in the order requests meet them, and protecting the control plane as carefully as the traffic itself.
If you want help designing that edge deliberately, whether as a front door for an application you already run or as the platform you build on, that is the kind of work I do through Cyber Spartans.