我在想AWS的骨干网是否能在速度上超过公共互联网。这个想法应该是可以实现的。因为即使不缓存，CloudFront也会进行几项有用的操作，你可以看到整体性能有所提升：
- 最大程度地将流量带到离观众最近的AWS托管网络上，流量在AWS网络上的传输距离比公共互联网短。
- 通过创建两个TCP连接¹(一个从浏览器到CloudFront，另一个从CloudFront到源头)对浏览器和源之间的TCP交互进行分段处理。连接设置，TLS协商以及HTTP请求/响应的来回消息都得到了优化。
- (可选) 提供http/2 to HTTP/1.1网关/转换，允许浏览器在单个http/2连接上同时发出并发请求，同时将这些请求转换为多个独立的HTTP/1.1请求发送到源。
在区域向Internet发送流量的成本和CloudFront边缘向Internet发送流量的成本之间存在一些微小的套利机会。(从EC2/S3到CloudFront的流量不计费)在许多情况下，这些机会对您有利，例如低成本地区的观众访问高成本地区的桶，但它们几乎总是不对称的。伦敦观众和悉尼桶，直接访问该桶时为每GB $0.14，而通过CloudFront访问相同的桶为每GB $0.085。反之，悉尼观众访问伦敦桶时为每GB直接访问$0.09/GB，通过CloudFront访问则为每GB $0.14。伦敦观众/伦敦桶通过CloudFront为每GB $0.085，直接访问桶为每GB $0.09/GB。我长期以来的看法是，这些差异代表了互联网接入成本与AWS私有传输成本之间的比较。通过价格类别功能，您还可以配置CloudFront仅使用较低成本的边缘，但不能保证实际上只使用较低成本的边缘进行流量，而是保证如果未使用较低成本的边缘，则不会向您收取更高的价格。
还要注意，有两个(已知的)服务始终禁用缓存地使用CloudFront：
在存储桶上启用S3 Transfer Acceleration基本上就是一个没有启用缓存的零配置CloudFront分发。Transfer Acceleration与自行提供的CloudFront + S3安排相比只有三个显著区别：具体而言，它可以通过S3理解和接受的带签名的URL(使用S3加上您自己的CloudFront，您必须使用CloudFront带有不同算法的签名URL)和对于地理位置接近存储桶区域的用户，CloudFront网络被绕过，这也消除了该请求的Transfer Acceleration附加费。第三个区别是，它的成本几乎总是比您自己的CloudFront + S3更高。
AWS相信增值的价值足以使得Transfer Acceleration的功能比使用S3 + CloudFront表现更好。我有时会使用它来从直接连接到Bucket的安排中挤出一些优化，因为这是一个很容易的变化。
可以在
此页面上找到Transfer Acceleration速度测试并观察其工作原理。虽然这是上传而不是下载，但基本思路是相同的——它可以合理地描绘公共互联网和AWS“边缘网络”(CloudFront基础架构)之间的差异。
API Gateway优化的API也通过CloudFront进行路由以提高性能。虽然API Gateway提供了可选缓存，但它使用的是缓存实例而不是CloudFront缓存。后来，API引入了第二种类型的API端点，它不使用CloudFront，因为当您在同一实际AWS区域内进行请求时，将请求发送到其他硬件就没有必要了。这也使得在自己的CloudFront后面部署API Gateway更加明智，避免了对相同基础设施的不必要的第二次传递。
¹
两个TCP连接可能实际上是三个，这应该会进一步提高性能，因为每个连接之间的边界提供了一个内容缓冲区，可以实现更平滑、更快速的传输，并以有利的方式改变带宽延迟乘积。自2016年以来，CloudFront有两个层次的边缘位置，一个是外层的“全球”边缘(最靠近观众)，另一个是内部的“区域”边缘(在实际的AWS区域内)。这在
文档中有所记录，但文档非常高级，没有很好地解释其基础架构。经验性的观察表明，每个全局边缘都有一个分配给它的“主页”区域边缘，该区域边缘是其最近的AWS区域中的区域边缘。连接从观众，到外围边缘，到内部边缘，然后到源。文档表明，在某些情况下会绕过内部(区域)边缘，但观察结果表明这些情况是例外。
