Point of Presence (PoP)

A Point of Presence (PoP) is a single location at which a network keeps its own equipment. It uses that equipment to exchange traffic with other networks. For a CDN, that means the edge servers, routers, switches and interconnects. They serve one city or region. Amazon calls its PoPs “collections of servers in geographically-dispersed data centers”. It treats edge location as the same thing. Fastly defines a POP as “a grouping of cache servers that creates a single cluster of cache storage.” The term predates CDNs by decades. It became important in the United States during the court-ordered breakup of the Bell telephone system. At that time, a long-distance carrier needed a location at which to terminate service and connect into a local telephone network.

A PoP is not three things. It is not a single machine. Even a modest PoP is a set of servers plus the routing gear that reaches them. It is not the building. The data centre is the building. One large facility can host the PoPs of many different networks side by side. Each network gets its own cage. It is not the origin either. The origin holds the authoritative copy. A PoP holds a cache of it instead, and fetches what it is missing. If you read nothing else, remember three things. A provider’s PoP list is its map of where content physically meets users. PoP codes are usually built from the nearest airport’s IATA code. Routing, not geography, decides which PoP answers a given request. So a nearby PoP is not automatically a fast one.

How it works

A PoP is normally rack space in a colocation facility or at an Internet exchange point. It is not usually a building that the CDN owns. It does three jobs.

• Interconnect. Routers and switches peer with the surrounding networks. They advertise reachability for the CDN’s service addresses. Across the public Internet, that advertisement is carried by BGP. Within a single operator’s network, an interior gateway protocol does the same job.
• Serving. The edge servers terminate the client’s connection, answer from cache and run edge compute. In Fastly’s model, the machines of one PoP form a single shared pool of cache storage.
• Backhaul. The cross-connects and long-haul capacity join the PoP to the rest of the operator’s network. On a cache miss, they also connect to the origin.

Which PoP a client reaches is a routing outcome. DNS, anycast, or both steer the client to a site. The edge server there answers from cache. On a miss, it forwards the request upstream and caches the result on the way back. CloudFront documents the sequence plainly: “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,” and then “CloudFront checks its cache for the requested object. If the object is in the cache, CloudFront returns it to the user. If the object is not in the cache … forwards the request to your origin.” Read the hedges. Fastly says its DNS routes traffic to the nearest POP “in terms of network proximity”. RFC 4786 is the IETF best current practice for operating anycast services, and it is blunt about what that nearness is worth. It says: “Topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases, response times may see no reduction, and may increase.” Nearness is a statement about topology. It is not a promise about latency.

PoPs are identified by short codes. Those codes are vendor conventions, not a standard. Fastly’s are IATA airport codes. Its published POP list gives Ashburn as IAD, Frankfurt as FRA, Tokyo as NRT and Singapore as SIN. Cloudflare’s Cf-Ray response header ends in a three-letter code of the same kind. It identifies the data centre that processed the request. Others only build on the code. A CloudFront POP identifier such as PHX50-C2 is an airport code plus a site number and a server group, not a bare IATA code.

A PoP is also not the only edge tier, and “the PoP” is often two of them. CloudFront separates three kinds of infrastructure: embedded PoPs sited inside ISP networks closest to viewers, PoPs inside the AWS network that peer with ISPs, and regional edge caches. Regional edge caches sit between the PoPs and the origin. They hold content “not popular enough to stay at a POP”. Fastly reaches the same shape with shielding. Requests from the whole network “funnel through a single, designated shield POP” before the origin. So a request that cache cannot satisfy “will transit two POPs”.

Why it matters for a CDN

The PoP is the unit in which delivery capacity is placed, paid for and lost. So PoP layout, not merely PoP count, settles four things an operator cares about.

• Reach. A PoP is where content physically meets a user’s network. So presence in a metro is the difference between serving a visitor locally and hauling every byte across a continent.
• Cache efficiency. Each PoP caches independently and forwards its own misses. So layout sets the cache hit ratio an audience actually sees. Fastly gives this illustration: “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.” More PoPs is therefore not uniformly better.
• Blast radius. A PoP is a failure boundary. AWS states that “each PoP is isolated from the others, which means a failure affecting a single PoP or metropolitan area does not impact the rest of the global network.”
• Transit cost. Absorbing traffic at a PoP near its source lets an operator use better links. In RFC 4786’s words, that means “high-performance peering links rather than oversubscribed, paid transit circuits.”

What CDNs do

• Cloudflare. It announces its service addresses by anycast from its data centres and lets routing pick the site. Cloudflare is explicit that the winner need not be the closest one: requests “may be sent to data center locations that are not necessarily the closest geographically”. That is because, where performance and reliability conflict, its systems are “designed to prioritize a stable connection over a local one”. The site that processed a request is reported in the three-letter suffix of Cf-Ray. Its sites differ widely in size. Cloudflare’s engineering blog described the biggest data centres as having “a hundred times more servers than the smallest ones”.
• AWS CloudFront. It publishes 750+ PoPs in 100+ cities across 50+ countries. It also runs 1,140+ embedded PoPs inside ISP networks across 300+ cities, plus 15 regional edge caches. DNS steers each request to the POP that “can best serve the request, typically the nearest … in terms of latency”. The serving POP is exposed as the cdn-pop metric of the Server-Timing header. This metric appears only when the Server-Timing setting is enabled in a response headers policy.
• Fastly. It places POPs “near the highest density Internet Exchange Points around the world”. It names them with IATA codes. It treats each POP as one cache cluster that may span several physical sites. The delivering cache node is named in X-Served-By, “set by Fastly by default on all responses that we process”. Inside edge code, the current POP is read from server.datacenter for CDN services, or from the FASTLY_POP environment variable on Compute. Traffic can also be confined to a subset of POPs, for example North America and the EU only.
• Akamai. It runs Edge DNS from “thousands of name servers deployed across hundreds of points of presence (PoP) in over 40 countries”. Within any geography, it spreads those PoPs across multiple networks. This gives both geographic and network-level redundancy.

Watch out for

• “Nearest” is a routing outcome, not a latency result. RFC 4786 says topological nearness does not in general correlate with round-trip performance. Cloudflare’s own troubleshooting page says traffic may not reach the geographically closest data centre at all. Measure it yourself. Do not read performance off a coverage map.
• One code can name a metro, not a site. Fastly: “The largest POPs in densely populated metropolitan areas may span multiple sites … This is known as a metro POP.” A single request may be handled by servers in more than one site. The request still stays inside the same POP.
• PoP codes are not stable identifiers. Fastly warns that “cache IDs may be reused … Data centers are also subject to decommissioning, and data center codes may also be reused”. So a captured value “should not be compared to another value captured at a different point in time”. Fastly also warns that POPs are added and removed regularly. So service logic keyed on POP location “may need frequent maintenance”.
• A PoP header may not name the PoP that served the viewer. Cf-Ray is also sent upstream. Under Argo Smart Routing or Tiered Caching, its three-letter code indicates the data centre connecting to the origin instead.
• A PoP shortens the last hop, not the whole path. On a miss, the edge still has to reach the origin. So adding edge sites does nothing for origin fetch latency. Shield POPs and regional caches exist for that job instead.
• More PoPs can mean a worse hit ratio. Many small PoPs covering one metro fragment the local cache pool. This pushes load back onto the origin.
• Published counts go stale and disagree. AWS’s fault-isolation whitepaper still reports “over 410 PoPs”. The CloudFront features page it points to for current status says 750+. Date every figure you quote.

Best practice

• Read the serving PoP from the mechanism your provider documents. Know which are on by default: Fastly’s X-Served-By is set by default, Cloudflare’s Cf-Ray is present on responses, and CloudFront’s cdn-pop needs the Server-Timing setting switched on first.
• Treat a PoP code as a diagnostic label, never as a key. Fastly explicitly discourages constructing logic that acts on the cache ID. Both cache and data-centre codes are re-used.
• Measure from where your users are. RFC 4786 recommends that distributed services be “monitored from probes distributed representatively across the routing system, and, where possible, the identity of the node answering individual requests is recorded along with performance and availability statistics.”
• Judge a provider by interconnection, not by PoP count. Check that it is present at the exchanges, and inside the ISPs, that your audience actually uses. RFC 4786 asks that node placement weigh “likely traffic requirements, the potential for flash crowds or denial-of-service traffic, the stability of the local routing system, and the failure modes with respect to node failure or local routing system failure.”
• Prefer fewer, larger PoPs per metro for cacheability. Concentrate origin fetches through a shield or regional cache tier instead of adding more edge sites.
• Expect in-band identification to exist at all. RFC 4786 calls provision of in-band node-identification mechanisms “strongly recommended” for anycast services. That is why these headers exist. A provider that offers none makes PoP-level debugging guesswork.