How CloudFront PoP Selection Works - DNS Routing and the Cache Hierarchy
This article explains the DNS-based routing that CloudFront uses to route user requests to the nearest PoP, the multi-layer cache structure of edge locations and regional edge caches, and the design factors that determine the cache hit ratio.
What Is a PoP (Point of Presence)
A CloudFront PoP is a group of cache servers distributed around the world. As of August 2026, at least 750 PoPs are deployed in at least 100 cities (in at least 50 countries). In addition, CloudFront's infrastructure consists of three types: regular PoPs (edge locations), regional edge caches (RECs) located between users and the origin, and embedded POPs installed inside the networks of carriers and ISPs. As of August 2026, embedded POPs number at least 1,140 across at least 300 cities. The role of a PoP is to cache content from origin servers (such as S3 buckets and EC2 instances) and deliver it from a location physically close to users, which reduces latency. When a user in Tokyo accesses an S3 bucket in Virginia in the United States directly, the round trip across the Pacific Ocean adds 150-200ms of latency. If the content is cached at a PoP in Tokyo, latency drops to 5-10ms. PoPs are not uniform in size. Large PoPs such as Tokyo, London, and Virginia consist of thousands of servers and can cache large amounts of content. On the other hand, PoPs in small cities have tens to hundreds of servers, and their cache capacity is limited. CloudFront dynamically adjusts PoP capacity according to traffic volume, and temporarily increases capacity during large events (such as sports broadcasts and product launches).
How PoP Selection Works - DNS-Based Routing That Directs Users to the Nearest PoP
The default mechanism that CloudFront uses to route user requests to the nearest PoP is DNS-based routing combined with network performance mapping. When a user accesses a CloudFront distribution URL (for example, d1234.cloudfront.net), DNS resolution happens first. CloudFront's DNS servers estimate the geographic location from the IP address of the user's DNS resolver and return the IP address of the optimal PoP based on latency and network performance measurement data. In this default path, each PoP is assigned a different IP address, and the same IP address is not shared by multiple PoPs. With DNS-based routing alone, the optimal PoP may not be selected when the location of the DNS resolver differs from the user's actual location (for example, when a company uses centralized DNS servers). To compensate for this, CloudFront also supports EDNS Client Subnet (ECS), which allows DNS resolvers to pass the user's actual subnet information to CloudFront's DNS and makes more accurate PoP selection possible.
Anycast Static IPs - An Opt-In Static IP Address Feature
While the default PoP selection is the DNS-based routing described above, Anycast, which selects the shortest path at the network level, is offered in CloudFront not as default behavior but as an optional additional feature. Anycast Static IPs, which became available in November 2024, is an opt-in feature that assigns a fixed list of static IP addresses to a distribution. When you enable this feature, multiple PoPs announce the same set of IP addresses, and BGP (Border Gateway Protocol) routing delivers packets to a PoP that is close in network terms. You use it when you want to register CloudFront's IP addresses in a firewall allow list, or when fixing the source IP addresses of delivery is a requirement. Because default distributions deliver content from rotating IP addresses, this static IP feature is strictly an optional choice, and it incurs an additional charge separate from standard pay-as-you-go pricing (as of August 2026).
Two-Layer Cache - Edge Locations and Regional Edge Caches
CloudFront's cache has a two-layer structure. The first layer is the edge locations (PoPs), which are closest to users. The second layer is the regional edge caches (RECs), which sit between the edge locations and the origin servers. There are 15 RECs worldwide (as of August 2026), and they have larger cache capacity than edge locations. The request flow is as follows. A user's request arrives at an edge location, and if the content is in the cache, it is returned immediately (a cache hit). If the edge location does not have it cached, it queries the REC. If the REC has it cached, the content is returned from there; if not, the REC fetches it from the origin server. The advantage of this two-layer structure is that it can greatly reduce the number of requests to the origin server. Unpopular content (the long tail) tends to be evicted from the cache at individual edge locations, but the large cache capacity of the REC increases the probability that it is retained. Because requests from multiple edge locations are aggregated at the REC, requests heading to the origin for the same content are combined into one, which lets you keep the origin server's load and scaling costs down.
Design Factors That Determine the Cache Hit Ratio
Depending on the design, CloudFront's cache hit ratio can be as low as 50% or as high as 99%. The biggest factor that determines the cache hit ratio is the design of the cache key. By default, CloudFront uses the full path of the URL as the cache key. However, if you configure it to include query strings, headers, and cookies in the cache key, even the same content gets different cache keys, so the cache is fragmented and the hit ratio drops. For example, when query strings contain tracking parameters (such as utm_source and utm_medium), a separate cache entry is created for each combination of parameters, even for the same page. If you use a CloudFront cache policy to specify the query strings included in the cache key with an allow list approach and exclude tracking parameters, the hit ratio improves dramatically. The TTL (Time to Live) setting is also important. If the TTL is too short, the cache is invalidated frequently and requests to the origin increase. For static assets (images, CSS, JS), the most effective strategy is to set the TTL to one year and include a hash in the file name (app.a1b2c3.js), so that when content is updated, the cache switches automatically through the new URL.
Origin Shield - Protecting the Origin With a Third Cache Layer
Origin Shield, introduced in 2020, is a feature that adds an additional cache layer between the RECs and the origin. When you enable Origin Shield, origin fetches from all RECs are consolidated into one Origin Shield location. If Origin Shield has the content cached, no request is sent to the origin. The biggest benefit of Origin Shield is mitigating the "thundering herd problem" of caches. This is the phenomenon in which, the moment the TTL of popular content expires, requests to the origin flood in simultaneously from PoPs around the world. Without Origin Shield, origin fetches occur simultaneously from 15 RECs, but with Origin Shield they are consolidated into one request. With the pay-as-you-go (on-demand) plan, Origin Shield is priced per request at $0.0090 per 10,000 requests (as of August 2026). Charges apply only to requests that pass through Origin Shield as an "incremental layer". When a cacheable request passes through a REC in the same Region as Origin Shield, Origin Shield is skipped and no charge applies (dynamic requests such as PUT and POST are always charged as an incremental layer). Considering the reduced load on the origin server and the lower scaling costs, it is a highly cost-effective investment in many cases. In particular, when the origin is a pay-as-you-go service such as a Lambda Function URL or API Gateway, the reduction in requests from Origin Shield translates directly into cost savings.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon CloudFront official page
- AWS Global Accelerator official page
- Amazon Route 53 official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.