A CDN map can look reassuring and still send a meaningful share of your users over a weak route. If you are evaluating Fastly POPs, the useful question is not whether a dot exists near each market. It is whether your traffic reaches the intended edge, finds the right object in cache, avoids an expensive origin trip, and stays within its latency and cost budget during a real peak.
This guide turns Fastly's published footprint into an engineering decision. It counts the current listed markets, explains what Fastly means by a POP, shows how shielding changes the path, and gives you a repeatable bake-off against alternative CDN architectures.
How many Fastly POPs are live?
Fastly's network map currently lists 85 live service markets, with 14 markets marked as containing multiple POPs, as of June 30, 2026. That is a count of the named locations on the map—not a claim that Fastly has exactly 85 physical facilities, because Fastly distinguishes a logical POP from the sites and server clusters inside it.
The regional count from the current Fastly network map is:
| Fastly map region | Listed live markets | What to verify |
|---|---|---|
| North America | 26 | ISP and mobile-network routing outside the largest metros |
| South America | 9 | Latency and throughput beyond Brazil's main exchanges |
| Europe | 22 | Whether traffic stays in-region and reaches the expected metro |
| Africa | 3 | Performance outside Accra, Cape Town, and Johannesburg |
| Asia | 17 | Country-level routing, especially South and Southeast Asia |
| Australia and New Zealand | 8 | Path consistency outside Sydney and Melbourne |
| Total | 85 | Effective proximity, cache depth, and peak capacity |
Fastly also reports 622 Tbps of connected global capacity and marks Chicago, Los Angeles, New York, San Jose, Seattle, London, Madrid, Milan, Mumbai, New Delhi, Noida, Singapore, Tokyo, and Sydney as multiple-POP markets on that map. Four more cities—Budapest, Jakarta, Lagos, and Nairobi—are shown as coming soon, so they should not be counted as live capacity in a procurement scorecard.
This method is intentionally conservative. Marketing pages across the CDN industry variously count cities, facilities, server clusters, embedded nodes, and cache locations as “POPs.” A clean evaluation records the provider's unit and date beside every number.
How Fastly POPs route and cache traffic
Fastly defines a POP as a group of cache servers that forms one cache-storage cluster. Its documentation says a POP can combine multiple physical sites in the same metro, and clustering can cause one request to touch more than one site while remaining inside the same logical POP (Fastly's POP network guide).
That distinction matters in three ways:
- A metro dot is not a single box. Redundant sites can increase capacity and fault tolerance without increasing the visible POP count.
- The nearest city is not always the chosen path. Fastly routes to the POP with the best network proximity and can reroute around Internet problems. Geographic distance is only a starting hypothesis.
- A local edge does not guarantee a local hit. The request may miss cache, traverse another cache node within the cluster, reach a shield POP, or go to origin.
Fastly's “fewer, more powerful POPs” strategy is a deliberate contrast with providers that publish hundreds or thousands of edge locations. The architecture can provide deep cache and high throughput in a major market. It can also leave a regional audience more dependent on peering quality and the route into that market, which is why a provider-wide global average is not enough evidence.
What origin shielding changes
Without shielding, each edge POP can fetch a missing object directly from your origin. With Fastly shielding enabled, origin-bound requests converge on a selected shield POP first. Fastly documents three intended benefits: reducing origin load, improving the chance of a cache hit, and reusing warm inter-POP connections for misses and pass traffic (Fastly shielding guide).
The extra layer creates trade-offs you need to test:
- Your VCL or edge logic can execute once at the delivery edge and again at the shield. Logic that is not aware of the execution context can duplicate headers or mutate requests twice.
- A request can show a miss at the edge and a hit at the shield. A single aggregate cache-hit ratio can therefore conceal the user-visible outcome and the amount of inter-POP traffic.
- Fastly states that inter-POP traffic contributes to request count and billable bandwidth. Shielding may still reduce total origin cost, but it is not a free hop.
- The best shield is usually close to the origin, not the largest viewer market. A poorly chosen shield can add latency to every miss.
Treat the shield code, origin region, cache policy, and expected request path as part of the test configuration. A Fastly POP comparison that ignores shielding is comparing map dots while omitting the path your misses actually take.
Where the Fastly footprint deserves a closer look
The current map is dense in North America and Europe, with 48 of the 85 named markets in those two regions. Asia has 17 listed markets, including eight in India and nearby South Asian markets when Chennai, Hyderabad, Kolkata, Mumbai, New Delhi, Noida, and Patna are counted alongside the rest of the region. Africa has three live listed markets, while Lagos and Nairobi are still marked as planned.
That does not automatically make Fastly slow in a region. A high-capacity POP with strong local peering can outperform several small caches that backhaul misses, and Fastly says it places POPs near high-density Internet exchange points. It does mean that teams with material traffic in Africa, mainland China, or secondary Southeast Asian markets should demand country- and ASN-level evidence instead of accepting a global latency average.
Mainland China requires a separate workstream. Fastly's live map lists Hong Kong but no mainland China location. Regulatory delivery, licensed local infrastructure, third-party resources, and the path across the border cannot be answered by a generic “Asia coverage” row.
For every priority country, write down:
- Viewer share and revenue share.
- Top access networks or autonomous systems.
- Median and p95 time to first byte for a warm object.
- Throughput for a representative large object or media segment.
- Cache-hit outcome at the edge and shield.
- Error rate, route changes, and performance during the busiest hour.
The result is a weighted coverage model. A missing POP in a country that contributes 0.1% of traffic may not matter; an unstable path for the mobile carrier serving 35% of paying viewers does.
How to benchmark Fastly POPs against alternatives
Do not start with a vendor benchmark domain. Put the same production-like object behind every candidate and preserve the same cache directives, compression, TLS, and origin behavior. Otherwise you are measuring different applications and assigning the difference to the network.
1. Build a representative test set
Use at least three object classes: a small static asset, a typical API or HTML response if it is cacheable, and a large download or media segment. For HLS or DASH, test manifests and segments separately because their TTLs, sizes, and request frequency differ.
Run both cold and warm sequences. The cold sequence exposes DNS, connection setup, cache fill, shield, and origin behavior. The warm sequence shows what the delivery edge can do after the object is available.
2. Sample where your users actually are
Weight probes by real audience distribution rather than spreading them evenly around the world. Split results by country and access network. Keep median results, but make p95 latency, p95 throughput, and error rate the acceptance criteria; tail behavior is where a congested interconnect or distant fallback becomes visible.
Synthetic probes give you controlled repetition. Real-user monitoring tells you how actual devices, browsers, residential networks, and mobile carriers experience the path. Use both for at least one normal peak and, if relevant, a launch or live event.
3. Confirm which Fastly POP served each request
Inspect X-Served-By, X-Cache, X-Cache-Hits, and Age. Fastly's cache-checking documentation explains that shielded responses can include both shield and edge servers, while a Fastly-Debug: 1 request exposes additional path and TTL details (Fastly cache-checking guide).
For a controlled test object, a basic request might be:
curl -sS -D - -o /dev/null -H 'Fastly-Debug: 1' https://cdn.example.com/test-object.jpg
Do not enable or preserve debug details indiscriminately in production. Fastly warns that the inbound debug header is passed to origins by default, so restrict its use and strip it when your service does not need public diagnostics.
4. Record cache and origin outcomes
For each region, separate edge hits, shield hits, and origin fetches. Track the bytes and requests that reach origin, not only the CDN's headline hit ratio. A provider that produces a slightly slower warm hit but far fewer origin fetches may be the safer option for a fragile or expensive origin.
Also test purge time, stale-on-error behavior, range requests, large objects, signed URLs, and cache-key variation. The CDN caching guide explains why a nearby edge cannot help when cookies, query strings, or headers fragment the cache.
5. Normalize the bill
Fastly's public Full Site Delivery pricing includes 100 GB of free bandwidth and one million free requests, then bills paid bandwidth by region and requests separately. Its first paid bandwidth tier is currently $0.12/GB in North America and Europe, $0.19/GB in several other regions, and $0.28/GB in Africa, India, and South Korea (Fastly pricing).
Model the same delivered bytes, regional mix, request count, shield traffic, origin egress, support, and any negotiated discount for every candidate. The Fastly pricing guide covers the full rate-card calculation; keep this bake-off focused on how the POP footprint changes the result.
Fastly POPs versus alternative edge architectures
Raw counts are not directly comparable, but published architectures reveal what each alternative expects you to value.
| Network | Published footprint signal | Cache-path signal | What the buyer should prove |
|---|---|---|---|
| Fastly | 85 named live markets on the June 2026 map; 14 marked multi-POP | Large logical POPs, clustering, optional shield POP | Route quality, deep-cache benefit, shield cost, and regional price |
| Cloudflare | 337 cities across eight map regions | Every service runs in every data center on an anycast network | Whether the broad metro footprint improves your top ASNs and required product scope |
| Amazon CloudFront | Many metros contain multiple edge locations, plus regional edge caches | Edge POP checks local cache, then can use a larger regional cache before origin | AWS integration benefit, cache-tier behavior, price class, and total service cost |
Cloudflare's current network page publishes 337 cities and says its network connects with more than 13,000 service providers, cloud providers, and enterprise networks (Cloudflare global network). AWS publishes individual CloudFront POP counts within many metros and describes regional edge caches as a larger intermediate tier that retains less-popular objects longer (CloudFront locations and features). Those are different designs, not an automatic ranking.
A flat-rate alternative for global media
The bake-off above measures routing and cache behavior; the rate card decides what those measurements cost. Fastly prices bandwidth by region — $0.12/GB in North America and Europe, $0.28/GB in Africa, India, and South Korea — so a footprint decision and a pricing decision are entangled: the markets where you most need to verify the path are also the ones where delivery is most expensive to run. ZeroBuffer separates them, pairing 100+ edge locations across six continents with one $0.0049/GB rate everywhere, plus S3-compatible storage, origin shield, and included multi-rendition encoding. Run it through the identical weighted test — a flat rate is not evidence of a good path, and routing, cache behavior, playback metrics, and failure handling all still have to be measured on your own workload.
If one network wins everywhere, the decision is easy. If the winner changes by geography or asset type, consider splitting delivery by hostname or using a multi-CDN strategy—but include the added routing, cache, logging, and incident-response complexity in the score.
When Fastly is the right choice
Fastly belongs on the shortlist when your team values programmable cache behavior, rapid invalidation, detailed delivery controls, and high-capacity POPs in the markets that carry most of your traffic. It is especially credible when the benchmark shows strong paths to your actual networks and the value of custom edge logic exceeds the regional bandwidth premium.
Look harder at alternatives when your audience is concentrated outside Fastly's denser regions, your workload is straightforward high-volume media delivery, or finance needs one predictable global unit rate. A lower POP count is not the reason to leave; failing the weighted production test is.
Use a simple decision rule: choose the provider that passes every critical-region p95 and failure test at the lowest complete operating cost. Do not trade a measurable workload requirement for the largest number on a map.
Frequently asked questions
What is a Fastly POP?
A Fastly POP is a logical cluster of cache servers that serves a geographic market. One POP may span multiple physical sites, so POP, city, facility, and server count are not interchangeable.
How many Fastly points of presence are there?
Fastly's June 30, 2026 network map lists 85 live named markets, with 14 marked as multiple-POP markets. Because Fastly groups sites into logical POPs, report the map count and its definition instead of converting it into an unsupported facility total.
Does Fastly route users to the geographically nearest POP?
Not necessarily. Fastly routes toward the nearest POP in terms of network proximity and can reroute around Internet problems, so the selected POP can differ from the geographically closest city.
How can I tell which Fastly POP served a request?
Inspect the X-Served-By response header and correlate it with X-Cache, X-Cache-Hits, and Age. On an authorized test, Fastly-Debug: 1 exposes more path and TTL detail, but the header should be controlled because it can be forwarded to the origin.
Does Fastly have POPs in mainland China?
Fastly's current public network map does not list a live mainland China POP; it lists Hong Kong in its Asia region. Treat mainland China delivery as a separate regulatory and performance evaluation rather than assuming nearby regional coverage is equivalent.
Conclusion
Fastly's footprint is substantial, high-capacity, and intentionally built around fewer, denser POPs. That strategy can be an excellent fit, but the map cannot tell you whether a viewer reaches the right cache, whether a shield reduces or extends the miss path, or what regional billing does to the complete cost.
Run the same objects through Fastly and at least two architecturally different alternatives. Weight the results by your real audience, judge p95 behavior and origin impact, and keep only the candidates that pass every critical market. If a flat-rate media path meets those thresholds, test it before accepting regional delivery premiums or a long contract.
ZeroBuffer is built to be that flat-rate media path. Delivery is $0.0049/GB in every region — no regional premiums, no separate request fee — stepping down to $0.0035/GB above 750 TB, with origin shielding, instant purge, S3-compatible storage at $0.01/GB-month per replica, and multi-rendition encoding included at no extra charge. There are no contracts and no minimums, so it can enter the bake-off as a test workload rather than a procurement cycle. See the full rate card.