Edge Server

An edge server is a computer that exists at the logical extreme of a network: the "edge". It "often serves as the connection between separate networks" (Cloudflare). In a CDN it is one of the machines inside a Point of Presence (PoP). It is a caching reverse proxy that keeps content "as close as possible to a requesting client machine, thereby reducing latency and improving page load times" (Cloudflare). It answers on the origin's behalf. Fastly describes the arrangement as "acting as a reverse proxy to your origin server (also known as Origin Pull)" (Fastly).

It is not the origin server. The origin server "stores the original, definitive version of your objects" (CloudFront). It is not the PoP. A PoP is "a grouping of cache servers that creates a single cluster of cache storage" (Fastly). The edge server is one machine in that cluster. It is not the CDN. The CDN is the whole network of PoPs. It is also only one kind of edge device: "an edge server is a type of edge device that provides an entry point into a network. Other edges devices include routers and routing switches" (Cloudflare). That is why vendor documentation usually writes "CDN edge server". If you take one thing away, remember this: the visitor's connection ends at the edge server. Everything it can answer from its own storage never reaches your origin at all.

How it works

• You do not pick the edge server. The network does, by one of two different mechanisms. Anycast is "the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations" (RFC 4786, section 2). With it, "the routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates" (section 3.1). That is Cloudflare's model: an anycast network where "the same content can be delivered from any of these data centers" (Cloudflare). CloudFront and Fastly select the PoP in DNS instead: "DNS routes the request to the CloudFront POP (edge location) that can best serve the request, typically the nearest CloudFront POP in terms of latency" (CloudFront). Fastly runs its own DNS service that "automatically routes your traffic to the nearest Fastly POP (in terms of network proximity)" (Fastly). Either way the metric is network distance, not straight-line geography.
• Inside a PoP, more than one machine touches the request. A PoP is a cluster, not a box. So the server that accepts your connection is not necessarily the server holding the object. On Fastly, "a request directed to a Fastly POP will be handled by two separate cache servers acting together in a process we call clustering" (Fastly). A randomly chosen delivery node accepts the request and forms the response. It then hands the request to a fetch node selected by consistent hashing over the cache key. Each object therefore has one primary storage server per PoP, instead of being duplicated on every machine. This is also why a PoP behaves as one cache. Requests spread across servers in the same PoP "have access to the same shared pool of cache storage" (Fastly).
• Cache lookup, then revalidation: expiry is not deletion. On a hit, the edge "delivers it immediately" (CloudFront). On a miss, the CDN "fetches that content from an origin server, and then saves a copy of the content for future requests" (Cloudflare). Content then "remains in the CDN cache as long as users continue to request it" (Cloudflare). When its TTL expires, the object is not thrown away. The next request triggers a conditional request to the origin. That request carries If-None-Match or If-Modified-Since, "either to get the latest version of the object or to get confirmation from the origin that the CloudFront edge cache already has the latest version" (CloudFront). What does remove an object is eviction: "an object that is seldom requested is evicted and is no longer available in the edge cache" (CloudFront). An evicted object cannot be served at all.
• The miss path is tiered, not a straight line to the origin. A CloudFront PoP "typically goes to the nearest regional edge cache to fetch it". Regional edge caches "have a larger cache than an individual POP, so objects remain in the cache longer" (CloudFront). All the PoPs in a region share one such cache. Some traffic skips that tier: dynamic requests, the proxy methods PUT, POST, PATCH, OPTIONS and DELETE, and same-Region S3 origins. An origin shield adds one more funnel. With Fastly shielding, "visitor requests from across the global network funnel through a single, designated shield POP" (Fastly). With CloudFront Origin Shield, "all requests from all of CloudFront's caching layers to your origin go through Origin Shield" (requests made in the same Region as the origin bypass it). At Origin Shield, concurrent misses for the same object "are consolidated with other requests for the same object, resulting in as few as one request going to your origin": this is request collapsing (CloudFront).
• Connection and protocol work stop here. The visitor's TLS session terminates at the edge. That means there are two connections, not one. Cloudflare's encryption mode "controls how Cloudflare manages two connections: one between your visitors and Cloudflare, and the other between Cloudflare and your origin server" (Cloudflare). That split is what lets the edge speak a newer protocol to visitors than the origin understands. HTTP/3 is "a mapping of HTTP semantics over the QUIC transport protocol" (RFC 9114, section 1.2). HTTP/2 is "an optimized mapping of HTTP's semantics to an underlying connection" (RFC 9113, section 1). Cloudflare states HTTP/3 "can be enabled by all Cloudflare customers without any changes to their origin" (Cloudflare). The edge can also compress on its own, "using both GZip and Brotli algorithms" (Fastly).
• It runs your code, not only your cache. The same machines are a function runtime. CloudFront "intercepts requests and responses at CloudFront edge locations and passes them to your function" (CloudFront Functions). Cloudflare Workers run on "a growing global network of thousands of machines distributed across hundreds of locations. Each of these machines hosts an instance of the Workers runtime, and each of those runtimes is capable of running thousands of user-defined applications" (Cloudflare). See edge function.

Why it matters for a CDN

Edge servers are where a CDN converts geography into performance. Their placement is deliberate: edge devices "are often placed inside Internet exchange points (IxPs) to allow different networks to connect and share transit". Cloudflare states that placing them in IXPs "allows them to connect directly with different Internet service providers (ISPs)". This reduces "the number of hops or network transitions required to deliver content" (Cloudflare). Without that, Cloudflare warns, traffic will "trombone" large distances in the worst case. For example, "when connecting to another device across the street, a connection may move across the country and back again" (Cloudflare). Distribution also buys resilience: "You also get increased reliability and availability because copies of your files … are now held (or cached) in multiple edge locations around the world" (CloudFront).

The edge is the security perimeter as well as the delivery tier. Edge servers "can be equipped with security tools like a web application firewall (WAF) or DDoS mitigation services to identify and block malicious traffic before it can reach the origin server" (Cloudflare). One of the stated goals of anycast service distribution is "constraint of distributed denial-of-service attacks or flash crowds to local regions around Anycast Nodes" (RFC 4786, section 3.2).

Finally, every hit is money. "These edge servers cache content in order to take the load off of one or more origin servers" (Cloudflare). So requests answered at the edge consume no origin capacity and no origin egress. That is why the number to watch is cache hit ratio per PoP rather than globally. Fastly notes that "POP variability is most notable in its effect on cache hit ratio". That is because "100 requests handled by 100 distinct servers in 100 distinct POPs will experience a much lower cache hit ratio than 100 requests handled by 100 distinct servers all participating in the same POP" (Fastly).

What CDNs do

• Cloudflare runs an anycast edge on which "every service runs in every data center" (Cloudflare network). So any machine can serve any request. CDN caching is free and on by default: "Cloudflare offers free CDN caching services, while paid CDN customers are able to customize how their content is cached" (Cloudflare). For debugging, "the Cf-Ray header identifies the data center processing the request when displayed as a response header … represented by a three-letter code corresponding to the data center's location" (Cloudflare). Opt-in: Keyless SSL lets you "benefit from Cloudflare, but without exposing their TLS private keys" (Cloudflare). It is available only as an Enterprise paid add-on.
• Fastly groups cache servers into a PoP per location and routes each request to the nearest PoP by network proximity (Fastly). X-Served-By "is set by Fastly by default on all responses that we process, and contains the identity of the cache server acting as the delivery node", in the form cache-{datacenter}{nodeid}-{datacenter}. With shielding or Next-gen WAF at Edge in play, "there may be more than one server identity listed, separated by commas" (Fastly). Opt-in: Shielding "may be enabled when adding or editing an origin server, and may be selected per-origin" (Fastly). Static compression pre-cache is available "only in CDN services" via the web interface, API or VCL. Dynamic compression post-cache is "enabled by adding the X-Compress-Hint header to the outgoing response" (Fastly).
• Amazon CloudFront calls its edge data centers "edge locations or points of presence (POPs)". These are "collections of servers in geographically-dispersed data centers where CloudFront caches copies of your files". CloudFront caches there by default: "each file stays in an edge location for 24 hours before it expires" unless the origin says otherwise (CloudFront). Opt-in: Origin Shield is "an additional layer in the CloudFront caching infrastructure", for which "you incur additional charges" (CloudFront). The Server-Timing response header is also opt-in, added by a response headers policy at a sampling rate you choose. Its cdn-pop metric "contains a value that describes which CloudFront point of presence (POP) handled the request". Its cdn-hit-layer metric reports whether the hit came from EDGE, REC (regional edge cache) or Origin Shield (CloudFront).

Watch out for

• The origin is still reachable. "A CDN does not render an origin server invincible, but when used properly it can render an origin server invisible, acting as a shield for incoming requests." Hiding the real IP "is an important part of setting up a CDN". Cloudflare states: "a CDN provider should recommend that the IP address of the origin server be changed when implementing a CDN strategy in order to prevent DDoS attacks from going around the shield and hitting the origin directly" (Cloudflare).
• The TLS private key normally lives on edge infrastructure. Terminating TLS at the edge means the edge holds the certificate's private key. Keyless SSL exists precisely to "keep private keys on your own infrastructure while using Cloudflare TLS". It is not a general answer. Availability is "No" on Free, Pro and Business, and a "Paid add-on" on Enterprise. Also, "TLS 1.3 is not supported for Keyless SSL" (Cloudflare).
• Invalidation is network-wide and irreversible. A purge has to reach every location that cached the object. "When you submit an invalidation request to CloudFront, CloudFront forwards the request to all edge locations within a few seconds, and each edge location starts processing the invalidation immediately. As a result, you can't cancel an invalidation after you submit it" (CloudFront). It also cannot reach caches you do not own: "if you invalidate the file, the user might continue to see the old version until it expires from those caches" (CloudFront). Those caches include the browser's own cache and a corporate caching proxy's cache.
• A cache is per PoP, and PoPs are not equal. An object cached in one PoP is not cached in the next. Also, "as objects become less popular, individual POPs might remove those objects to make room for more popular content" (CloudFront). Rare objects can therefore miss nearly everywhere. A healthy global hit ratio can hide wide per-PoP variation (Fastly).
• PoP and cache identifiers are a snapshot, not an API. Fastly warns that "cache nodes are moved in and out of service continually, and cache IDs may be reused … Data centers are also subject to decommissioning, and data center codes may also be reused". So an X-Served-By value "is therefore accurate at the moment it is generated but should not be compared to another value captured at a different point in time" (Fastly). Fastly says the same of its PoP list: it "may need frequent maintenance" if you branch on it (Fastly). Cf-Ray hides a sharper trap. With Argo Smart Routing or Tiered Cache, "the three-letter code in the Cf-Ray header will indicate the data center connecting to the origin, not the ingress data center" (Cloudflare).
• Expired object plus unreachable origin. "If your origin server is unavailable and CloudFront gets a request for an object that is in the edge cache but that has expired … CloudFront either serves the expired version of the object or serves a custom error page" (CloudFront). Which one you get is a configuration decision. Make it deliberately, rather than discovering it during an outage.

Best practice

• Read the vendor headers before theorising about routing or cache state. On Fastly, read X-Served-By plus X-Cache, which Fastly "appends … to all responses by default" as HIT or MISS (Fastly). On Cloudflare, read Cf-Ray. On CloudFront, read Server-Timing with cdn-pop and cdn-hit-layer. The trailing datacenter code names the PoP. Fastly's Amsterdam PoP "has the name AMS" (Fastly). So cache-ams21041-AMS was served from Amsterdam.
• Track cache hit ratio per PoP, not just globally. Warm cold regions ahead of a launch: the same object can be hot in one PoP and absent from the next.
• Enable a shield for each origin so misses converge and collapse into one origin fetch instead of every PoP fetching independently. Budget for it: on CloudFront Origin Shield, "you incur additional charges" (CloudFront).
• Lock the origin down to match the model. Change its IP when you onboard the CDN. Allow inbound traffic only from the CDN's origin-facing ranges. On CloudFront the com.amazonaws.global.cloudfront.origin-facing managed prefix list does this for a VPC-hosted origin, "preventing any non-CloudFront traffic from reaching your origin" (CloudFront).
• Control freshness with versioned file names and deliberate Cache-Control TTLs rather than routine purging. CloudFront is explicit: "if you want to update your files frequently, we recommend that you primarily use file versioning". That is because versioning works even when a user holds the old copy locally or behind a corporate proxy. Also, "you don't have to pay for invalidating files" (CloudFront).

One command shows all of these headers at once:

curl -sI https://example.com/image.jpg | grep -iE "(x-cache|x-served-by|cf-ray|x-amz-cf-pop|server-timing)"
# Fastly example:
# x-served-by: cache-ams21041-AMS
# x-cache: HIT
# Cloudflare example:
# cf-ray: 7a1b2c3d4e5f6a7b-AMS
# CloudFront example:
# x-amz-cf-pop: AMS1-C1