CloudFront 的 PoP 选择是如何运作的 - DNS 路由与缓存层级的机制
本文介绍 CloudFront 将用户请求路由到最近 PoP 的基于 DNS 的路由机制、边缘节点与区域边缘缓存构成的多层缓存结构，以及左右缓存命中率的设计因素。
什么是 PoP（Point of Presence）
CloudFront 的 PoP 是分布在全球各地的缓存服务器集群。截至 2026 年 8 月，750 个以上的 PoP 部署在 100 个以上的城市（50 个以上的国家）。此外，CloudFront 的基础设施不仅包括普通的 PoP（边缘节点），还包括位于用户与源站之间的区域边缘缓存（REC），以及设置在通信运营商和 ISP 网络内部的 embedded POP，共由 3 种构成。截至 2026 年 8 月，embedded POP 达到 1,140 个以上，覆盖 300 个以上的城市。PoP 的作用是缓存源站服务器（S3 存储桶或 EC2 实例等）的内容，并从物理上靠近用户的位置进行分发，从而降低延迟。如果东京的用户直接访问美国弗吉尼亚的 S3 存储桶，跨越太平洋的往返会产生 150-200ms 的延迟。如果内容已缓存在东京的 PoP 中，延迟会缩短到 5-10ms。PoP 的规模并不统一。东京、伦敦、弗吉尼亚这样的大型 PoP 由数千台服务器组成，可以缓存大量内容。另一方面，小型城市的 PoP 有数十到数百台服务器，缓存容量有限。CloudFront 会根据流量动态调整 PoP 的容量，在大型活动（体育直播、产品发布等）期间临时增加容量。
PoP 选择的机制 - 将用户引导至最近 PoP 的基于 DNS 的路由
CloudFront 将用户请求路由到最近 PoP 的默认机制，是基于 DNS 的路由与网络性能映射。当用户访问 CloudFront 的分配 URL（例如：d1234.cloudfront.net）时，首先进行 DNS 解析。CloudFront 的 DNS 服务器根据用户 DNS 解析器的 IP 地址推测地理位置，并依据延迟和网络性能的测量数据，返回最优 PoP 的 IP 地址。在这条默认路径中，每个 PoP 分配不同的 IP 地址，并不是多个 PoP 共享同一个 IP 地址。仅靠基于 DNS 的路由，当 DNS 解析器的位置与用户的实际位置不同时（例如使用企业的集中式 DNS 服务器时），有时无法选出最优的 PoP。为弥补这一点，CloudFront 还支持 EDNS Client Subnet（ECS），DNS 解析器将用户实际的子网信息传递给 CloudFront 的 DNS，从而能够进行更精确的 PoP 选择。
Anycast Static IPs - 选择加入的静态 IP 地址功能
默认的 PoP 选择是前述基于 DNS 的路由，与此相对，在网络层选择最短路径的 Anycast 在 CloudFront 中并不是默认行为，而是作为可选的附加功能提供。2024 年 11 月开始提供的 Anycast Static IPs，是一项为分配关联一组固定的静态 IP 地址的选择加入（opt-in）功能。启用该功能后，多个 PoP 会宣告同一组 IP 地址，通过 BGP（Border Gateway Protocol）路由，数据包会到达网络上较近的 PoP。当您希望在防火墙的允许列表中登记 CloudFront 的 IP 地址，或者固定分发来源的 IP 地址是一项要求时，使用该功能。由于默认的分配使用轮换的 IP 地址进行分发，这项静态 IP 功能只是一个可选项，并且在标准的按量计费之外还会产生额外费用（截至 2026 年 8 月）。
两层缓存 - 边缘节点与区域边缘缓存
CloudFront 的缓存采用两层结构。第一层是边缘节点（PoP），位于最靠近用户的位置。第二层是区域边缘缓存（REC），位于边缘节点与源站服务器之间。REC 在全球共有 15 处（截至 2026 年 8 月），拥有比边缘节点更大的缓存容量。请求的流程如下。用户的请求到达边缘节点，如果缓存中有内容，就立即返回（缓存命中）。如果边缘节点没有缓存，就向 REC 查询。如果 REC 有缓存就从那里返回，没有的话就去源站服务器获取。这种两层结构的优点是能够大幅减少对源站服务器的请求数。不太热门的内容（长尾）在单个边缘节点中容易被逐出缓存，但凭借 REC 较大的缓存容量，被保留的概率会提高。由于来自多个边缘节点的请求汇聚到 REC，针对同一内容发往源站的请求会合并为 1 个，从而能够抑制源站服务器的负载和扩展成本。
左右缓存命中率的设计因素
CloudFront 的缓存命中率根据设计不同，可能是 50%，也可能达到 99%。决定缓存命中率的最大因素是缓存键的设计。CloudFront 默认使用 URL 的完整路径作为缓存键，但如果设置为将查询字符串、标头、Cookie 包含在缓存键中，即使是相同的内容，缓存键也会不同，因此缓存会分散，命中率下降。例如，当查询字符串中包含跟踪参数（utm_source、utm_medium 等）时，即使是同一个页面，也会按参数的每种组合创建不同的缓存条目。如果在 CloudFront 的缓存策略中以白名单方式指定包含在缓存键中的查询字符串，并排除跟踪参数，命中率会大幅改善。TTL（Time to Live）的设置也很重要。TTL 过短会导致缓存频繁失效，对源站的请求随之增加。对静态资源（图片、CSS、JS）将 TTL 设为 1 年，并在文件名中包含哈希（app.a1b2c3.js），使内容更新时通过新的 URL 自动切换缓存，这种策略最为有效。
Origin Shield - 用第 3 层缓存保护源站
2020 年推出的 Origin Shield 是在 REC 与源站之间增设一个缓存层的功能。启用 Origin Shield 后，来自所有 REC 的源站获取都会汇聚到 1 个 Origin Shield 位置。如果 Origin Shield 中有缓存，就不会产生对源站的请求。Origin Shield 最大的效果是缓解缓存的“惊群问题”。这是指热门内容的 TTL 过期的瞬间，来自全球 PoP 的请求同时涌向源站的现象。没有 Origin Shield 时，15 个 REC 会同时发起源站获取，而有了 Origin Shield，就会汇聚为 1 个请求。在按量计费（按需）方案下，Origin Shield 按请求数计费，每 1 万次请求 0.0090 美元（截至 2026 年 8 月）。计费对象仅限于将 Origin Shield 作为“增量层”经过的请求。当可缓存的请求经过与 Origin Shield 位于同一区域的 REC 时，会跳过 Origin Shield 而不计费（PUT、POST 等动态请求始终作为增量层计费）。考虑到源站服务器负载的减轻和扩展成本的降低，在许多情况下这是一项性价比很高的投资。特别是当源站是 Lambda Function URL 或 API Gateway 这样的按量计费服务时，Origin Shield 带来的请求减少会直接转化为成本的降低。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。