我想知道 AWS 主干网的速度是否在某种程度上超过了公共互联网的速度。
这个想法是应该的。
您应该会看到整体改进，因为 CloudFront 会做一些有用的事情，即使在不缓存的情况下也是如此：
将流量带到 AWS 托管网络中，尽可能靠近查看器，流量在 AWS 网络上而不是公共 Internet 上穿越其大部分距离。
通过创建两个 TCP 连接¹来划分浏览器和源之间的 TCP 交互，一个从浏览器到 CloudFront，一个从 CloudFront 到源。对连接设置、TLS 协商、HTTP 请求/响应的来回消息传递进行了优化。
（可选）提供 http/2 到 HTTP/1.1 网关/转换，允许浏览器通过单个 http/2 连接发出并发请求，同时在到源的不同连接上将这些请求转换为多个 HTTP/1.1 请求.
在离开区域访问 Internet 的流量与离开 CloudFront 边缘访问 Internet 的流量之间的成本差异中存在一些小的套利机会。 （从 EC2/S3 到 CloudFront 的出站流量不计费）。在许多情况下，这些对您有利，例如低成本区域中的查看器访问高成本区域中的存储桶，但它们几乎总是不对称的。伦敦查看器和悉尼存储桶直接访问存储桶的费用为 0.14 美元/GB，但通过 CloudFront 访问同一存储桶的费用为 0.085 美元/GB。另一方面，访问 London 存储桶的 Sidney 查看器直接访问存储桶的费用为 0.09 美元/GB，通过 CloudFront 的费用为 0.14 美元/GB。伦敦查看器/伦敦存储桶通过 CloudFront 的价格为 0.085 美元，或者直接到存储桶的价格为 0.09 美元/GB。我的长期假设是，这些差异代表了与 AWS 私有传输成本相比的 Internet 访问成本。您还可以通过价格等级功能将 CloudFront 配置为仅使用成本较低的边缘，这并不保证实际仅使用成本较低的边缘进行流量，而是保证在成本较低的边缘不会向您收取更高的价格未使用。
另请注意，有两个（已知的）服务使用 CloudFront 和缓存总是禁用：
在存储桶上启用 S3 Transfer Acceleration 基本上是一种无需启用缓存的零配置 CloudFront 分配。与自配置 CloudFront + S3 安排相比，传输加速只有三个显着差异：具体来说，它可以传递 S3 理解和接受的签名 URL（使用 S3 和您自己的 CloudFront，您必须使用 CloudFront 签名 URL，它使用一种不同的算法），并且对于地理位置靠近存储桶区域的用户绕过 CloudFront 网络，这也消除了该请求的传输加速附加费。第三个区别是它几乎总是比您自己的 CloudFront + S3 花费更多。
AWS 显然认为这里增加的价值足够重要，以至于该功能的成本高于自己使用 S3 + CloudFront 是有意义的。有时，我会使用它从直接到存储桶的安排中挤出更多优化，因为它很容易进行更改。
找到传输加速速度测试on this page 并观察它的作用。这是上传，而不是下载，但它是相同的想法 - 它可以让您合理地描述公共互联网和 AWS“边缘网络”（CloudFront 基础设施）之间的差异。
出于性能原因，API Gateway 边缘优化 API 也会通过 CloudFront 进行路由。虽然 API Gateway 确实提供可选缓存，但它使用缓存实例，而不是 CloudFront 缓存。 API 随后引入了第二种类型的 API 端点，它不使用 CloudFront，因为当您在同一个实际 AWS 区域内发出请求时，通过额外的硬件发送请求是没有意义的。这也使得在您自己的 CloudFront 后面部署 API Gateway 更加明智，避免了不必要的第二次通过相同的基础架构。
¹两个 TCP 连接实际上可能是三个，这应该会进一步提高性能，因为每个连接之间的边界提供了一个内容缓冲区，允许更顺畅和更快的传输并改变带宽延迟乘积以有利的方式。自 2016 年的某个时间以来，CloudFront 有两层边缘站点，外部“全球”边缘（最靠近查看器）和内部“区域”边缘（在实际 AWS 区域内）。这是documented，但文档非常高级，并没有彻底解释基础。轶事观察表明，每个全球边缘都有一个分配的“主”区域边缘，它是其最近的 AWS 区域中的区域边缘。连接从观察者到外边缘，到内边缘，然后到原点。文档表明存在内部（区域）边缘被绕过的情况，但观察表明这些是例外。