What Is a PoP? CDN Nodes, Edge Servers and Points of Presence

A CDN PoP 40 km from your users can lose to one 400 km away. Light in fiber covers roughly 200 km per millisecond, so 400 km of clean fiber costs about 4 ms of round-trip time. A single transit hairpin through another metro can cost tens of milliseconds, and with TCP plus TLS 1.3 you pay that round trip at least twice before the first byte. So what is a PoP, and why does the pin on a provider's map say so little about the latency you will actually get?

This guide gives a precise definition of a point of presence and a PoP vs edge server vs node comparison table. It explains how PoP placement translates into latency, how many PoPs a CDN actually needs, and a scoring rubric for reading a provider's PoP map. It closes with the failure modes that happen inside a PoP, which is where most outages start.

What Is a PoP in a CDN?

A point of presence (PoP) is a physical network location where a CDN terminates user traffic. It is usually a cage or suite in a carrier-neutral data center, cross-connected to local ISPs, one or more internet exchanges, and transit providers. The PoP is the unit of geography and interconnection. Everything that actually serves bytes lives inside it.

Inside a PoP you find racks of CDN edge servers (the cache and TLS termination fleet), routers and switches, load balancers, and often control-plane agents. Each individual machine or service instance is a node. As of 2026, a regional PoP commonly runs 20 to 80 nodes. Hyperscale metro facilities can exceed 400.

PoP vs edge server vs node: what is a PoP made of?

Node roles matter more than the word suggests. Edge cache nodes answer users. Mid-tier nodes collapse duplicate misses regionally, and losing them can push origin traffic up 3 to 10 times. Origin shield nodes funnel the remainder to origin, which is how a well-tuned hierarchy keeps origin requests below 1% of edge requests for cacheable content. Control and routing nodes run health checks, config distribution and Anycast withdrawal.

How PoP Location Affects Latency

Effective latency to a CDN PoP is roughly three terms: fiber distance, path inflation, and handshake count. Distance is the only one the map shows. Path inflation comes from how your users' ISP reaches the PoP. Handshake count comes from protocol choices.

• Distance: about 1 ms of RTT per 100 km of fiber. Real routes are longer than great-circle, so budget for more.
• Path inflation: if the ISP has no peering with the CDN in that metro, traffic may exit via transit in another city and come back. This trombone often dwarfs the distance term.
• Handshakes: TCP plus TLS 1.3 costs two RTTs before the request. HTTP/3 over QUIC folds this into one. Resumed sessions with 0-RTT can cut it further, but only for idempotent requests.

What changed by 2026 is the handshake term. With HTTP/3 broadly deployed at the edge, a 20 ms RTT gap costs roughly 20 ms instead of 40 ms. That shrinks the penalty of a slightly farther PoP and raises the relative importance of peering, loss rate and server-side TTFB. PoP proximity still matters. It just no longer excuses a slow cache.

Anycast vs DNS steering

Which PoP a user lands on depends on steering. Anycast lets BGP pick, so the choice follows the ISP's routing policy, not geography. DNS-based steering maps the resolver, or the client subnet when EDNS Client Subnet is honored, to a PoP. Both can misroute. Anycast misroutes when an ISP prefers a cheap transit path. DNS misroutes when users sit behind a distant public resolver without ECS.

How Many PoPs Does a CDN Need?

There is no universal number, and PoP count is the weakest proxy on a vendor's datasheet. A provider with fewer, densely peered, well-provisioned CDN PoPs often beats one with many thin sites. The right question is whether the PoPs sit in the metros where your users' ISPs interconnect, with enough node density and NVMe capacity to hold your working set.

How to Read a Provider's PoP Map

PoP maps are marketing artifacts, and not all dots are equal. Before trusting one, score each dot in the regions you care about against five questions. This is the rubric we use internally when evaluating points of presence.

1. Is it a full PoP? Some markers are embedded caches inside a single ISP, partner capacity, or planned sites. An embedded cache is excellent for that ISP's subscribers and useless for everyone else.
2. Who peers there? Check whether the CDN's ASN is present at the local IXP and which eyeball networks it peers with. A metro dot served only by transit is a distance saving with a path-inflation risk.
3. Is it a cache or just a TLS terminator? Some edge sites terminate connections and backhaul to a larger cache elsewhere. Good for handshakes, bad for miss latency.
4. What tier sits behind it? Ask where misses go. A mid-tier in the same region protects origin; a miss that crosses an ocean does not.
5. What is the capacity? Ask for per-region egress capacity and storage, not site count. A 10 Gbps site will shed load onto neighbors during your launch.

Then validate empirically. Run synthetic tests from probes inside your top ten user ASNs, record which PoP answered (most CDNs expose it in a response header), and compare against the map. Mismatches are where your P99 is hiding.

Failure Modes Inside a CDN PoP

The PoP is the unit on the map, but incidents usually start at the node level. These are the patterns that recur in production postmortems.

Partial PoP degradation

A third of the edge servers in a PoP fail, but the site still passes health checks, so Anycast keeps attracting full traffic. The survivors saturate and P99 explodes while the dashboard shows the PoP as green. Fix it with latency-based health thresholds and weighted withdrawal that drains a fraction of prefixes instead of all or nothing.

Global purge stampede

A full purge empties every edge at once, and each PoP refetches the same objects in parallel. Without request coalescing and an origin shield, origin sees a multiplier equal to your PoP count. Use soft purges, stale-while-revalidate, and a single shield tier per region.

Cache key poisoning

An incomplete cache key or a missing Vary on a personalized response lets one user's page get stored and served to others. It is invisible in hit-ratio graphs. Audit cache key composition and sample stored objects from several nodes per PoP.

Hot-node skew

Consistent hashing across nodes can pin a viral object to a few machines. Their hit ratio looks great while their NICs saturate. Watch for nodes whose hit ratio deviates from the PoP average by more than 10 percentage points, or whose P99 TTFB exceeds twice their P50.

Choosing a CDN on Delivery Economics

Once you stop buying PoP counts, the comparison becomes node quality, peering in your markets, and cost per TB. In the high-volume league, Bunny.net and CDN77 publish clear regional pricing, Gcore bundles broad edge services, and Fastly remains strong for programmable streaming workflows. Each is a legitimate choice depending on the workload.

BlazingCDN competes in that set on predictable economics: NVMe SSD edge, one-hour onboarding, and stability and fault tolerance comparable to Amazon CloudFront at a significantly lower cost, which matters most for enterprises moving petabytes. It has maintained 100% uptime, offers flexible configuration, and scales quickly under demand spikes. BlazingCDN's volume pricing starts at $5 per TB ($0.005 per GB) and drops to $2 per TB ($0.002 per GB) at 2 PB+, for example $1,500 per month covers 500 TB and $4,000 per month covers 2,000 TB.

FAQ

What is a PoP in networking?

A PoP is a physical location where a network or CDN interconnects with other networks and serves users. For a CDN it contains edge servers, routers and peering links. It is the geographic unit, while nodes are the individual machines inside it.

What is the difference between a CDN PoP and an edge server?

A PoP is the site; an edge server is one machine in it that terminates TLS and serves cached content. One PoP typically hosts dozens of edge servers. PoP placement determines network path quality, while edge servers determine cache capacity and TTFB.

Does more PoPs mean a faster CDN?

Not reliably. Peering with your users' ISPs, node density and storage capacity usually matter more than site count. A farther PoP with direct peering can beat a closer one reached via transit.

How do I find which PoP served my request?

Most CDNs return a response header identifying the PoP or node, often with an airport code. Run requests from probes inside your key user networks and log that header. Compare the results against the provider's map to spot misrouting.

Are embedded ISP caches the same as PoPs?

No. Embedded caches sit inside one ISP's network and serve only that ISP's subscribers. They are valuable for heavy video traffic, but they do not help users on other networks.

Your Move This Week

Pick your ten largest user ASNs by traffic. From probes inside each, log which PoP answers, the RTT, and TTFB for a cached and an uncached object, then set that against your CDN's PoP map. If any ASN is served from a PoP more than one metro away, or shows a cached TTFB P99 more than twice P50, you have found either a peering gap or a hot node. Which one did you find, and did your provider's map predict it?