亚马逊AWS官方博客
利用 Amazon CloudFront 加速和保护动态工作负载，并降低动态工作负载的交付成本
无论您是从 Amazon Elastic Load Balancer（Amazon ELB）、Amazon Elastic Compute Cloud（Amazon EC2）实例、Amazon API Gateway 还是 Amazon Lambda 向互联网端用户传递动态内容，通过利用 Amazon CloudFront 作为您的内容分发网络（CDN），您可以提升性能和安全性，优化内容分发的成本。动态内容指的是每个用户甚至每个请求都是独特的网络对象，因此无法从缓存中获益。例如 API 调用和个性化内容，如在线购物车或定向广告。
本文从成本优化、性能和安全性架构角度介绍了 CloudFront 为您的动态工作负载带来的好处，并说明了最佳配置实践。
性能
内容分发性能指的是在客户端和服务器之间传输的 IP 数据包的低延迟和高吞吐量。对于静态内容而言，主要通过在接近用户的 CloudFront edge 位置缓存静态对象来实现。通过从边缘提供内容，我们减少了 IP 数据包在客户端和服务器之间传输时所需的网络距离。这样可以降低延迟、提高吞吐量，从而改善用户体验。虽然这对于不可缓存的动态内容并不适用，但在使用 CloudFront 时，仅有边缘缓存并不是提高性能的唯一因素。您应该考虑其他对静态和动态内容都有帮助的因素。
CloudFront 的静态内容性能优势之一是 Origin offload：当内容被缓存到 CloudFront 中时，大部分请求都会从边缘位置提供服务，而不是直接到达 Origin。虽然动态内容无法缓存，但通过利用 CloudFront 的持久连接特性，我们仍然能够实现 Origin offload。该特性允许用户发出的请求重用前一个请求所创建的面向 Origin 的 TCP 上游连接，从而避免了每个用户都必须进行一次 Origin TCP 和 TLS 握手的状况。通过 CloudFront Server-Timing 头部特性，我们可以测试和演示上游连接重用的有效性和对整体性能的影响。该头部特性使您能够在 CloudFront 的响应中获取一些诊断信息，包括 cdn-upstream-connect 指标。该指标给出了完成 Origin DNS 请求和与 Origin 建立 TCP 连接（如果适用，则包括 TLS）之间所需的毫秒数。数值为零（0）表示 CloudFront 重用了现有连接。因此，通过发送多个请求并分析 Server-Timing 头，我们可以看到有多少个请求重用了连接。借助 Curl 及其 write-out 功能，我们还可以从客户端端测量其他时间，例如下载时间，并了解连接重用对性能的影响。
为了进行测试，我们需要一个测试环境。为此，我们采用模拟 CloudFront 分发和 Amazon EC2 的动态工作负载，并在 CloudFront 分发后面运行一个 Nginx 服务器。我们还使用了一种名为 CachingDisabled 的管理缓存策略，该策略对于动态内容非常有用。最终，我们将运行测试并展示结果。请注意，实际的延迟数据是特定于测试客户端的。您可以使用 Github 上提供的测试系统，或仅使用其中的 Curl 脚本来测试启用了 Server-Timing 头部的 CloudFront 分发。测试系统采用了一些安全最佳实践，我们在本文的安全性部分中进一步讨论了这些实践。特别是，ALB 和 EC2 安全组仅允许来自 CloudFront 分发的请求，禁止任何直接来自互联网的请求。
 |
图 1 – 测试架构
首先，让我们通过运行测试脚本发送 10 个请求：
python3 timings.py -url https://d1234.cloudfront.net -n 10
 |
图 2 – 进行 10 次请求测试
从结果可以看出，在 10 次请求中有 6 次的上游连接时间为零。这意味着连接被重用，换句话说，连接已经预热了。在这个例子中，我们可以看到对于预热连接，下载时间平均减少了 39%。除了减少 TLS 和 TCP 握手的开销外，预热连接还具有更大的拥塞窗口（Congestion Window (CWND)），从而提高了吞吐量。如果我们发送更多的请求，比如 100 个，那么我们可以看到连接的重用率增加了：
python3 timings.py -url https://d1234.cloudfront.net -n 100
 |
图 3 – 进行 100 次请求测试
现在连接的重用率达到了 93%，而且随着请求量的增加，这个比率还可以进一步提高。连接的重用不仅降低了延迟（特别是对于像测试中使用的小文件），还可以减轻 Origin 的负担并降低其计算资源的使用。如果没有 CloudFront，所有终端用户的请求都会直接落在 ALB 上，这将导致每个用户都有一个新的连接，从而产生更多的 Load Balancer Capacity Units（LCU）并减少成本。
关于性能基准测试的说明
从测试结果可以看出，对于一些请求，连接的重用没有任何影响，它在大约进行了 10 次请求之后才开始显现出来。这使得只生成一个或两个探针请求的任何类型的合成测试对于由许多请求触发连接重用效果的生产流量都是不相关的。因此，我们建议使用生产流量进行性能基准测试。您可以将流量在被测试系统之间分为 50/50，或者在它们之间进行日常或每周的流量切换。请点击此链接了解 Snap 如何得出在 QUIC 性能测试中平等流量份额的结论。
利用 Origin Shield 提高连接的重用率
Origin Shield 是 CloudFront 的解决方案，用于将所有请求路由到单个区域边缘缓存，该缓存执行 Origin 获取。虽然 Origin Shield 旨在最大化缓存比例，但它也可以增加连接的重用率。这是因为请求落在已经创建的连接上的几率在 Origin Shield 中更高，而 Origin Shield 是唯一与您的 Origin 交互的缓存层。如果您想进一步提高连接的重用率，则建议在 CloudFront 分发中启用 Origin Shield。如果您的内容受众分布全球，那么通过启用 Origin Shield 并测试是否导致进一步的连接重用增加，可以将他们的请求分组到同一地区边缘缓存中。有关 Origin Shield 的更多信息，请参阅其他帖文。
Amazon 全球网络
Amazon 全球网络是亚马逊云科技拥有的高可用、低延迟网络，将 CloudFront 边缘位置与亚马逊云科技区域连接起来。由于亚马逊云科技完全拥有该网络，我们根据需求进行扩展，以确保具备足够的容量来承载客户流量。当您通过 CloudFront 提供动态内容时，流量会从公共互联网转移到 Amazon 全球网络，通过充当入口点的 CloudFront 边缘位置进入。每个 CloudFront 边缘位置也与每个区域的所有主要互联网服务提供商进行良好的互联，确保与最终用户网络的优质连接。在互联网上，通常存在多条路由可用于相同源和目的地的数据包传输。不使用自己网络的 CDN 可能会通过实时性能测量跨不同网络路径开展覆盖路由，并向客户额外收费。在 CloudFront 的情况下，这一功能已纳入其数据包路由机制中，考虑了亚马逊云科技网络的拥塞状况，仅通过无拥塞链路路由流量。即使特定边缘位置与区域之间的链路出现意外流量激增或网络中断，也会有备选路径接管流量，以应对主路径的影响。尽管这一方面并非总能带来更好的性能，尤其是当用户已经接近源站且网络连接没有拥塞问题时，但使用托管网络的能力始终是一个优势。这通常意味着更少的数据包丢失、更稳定的抖动以及整体上更好的使用体验质量。
其他性能改进技术
CloudFront 支持使用高性能协议，如 HTTP/2 和 HTTP/3，先进的 TCP 拥塞控制算法 TCP BBR，以及更快的 TLS 1.3 版本（支持会话恢复）。特别是，HTTP/3 采用基于 UDP 的 QUIC 协议，相较于 HTTP/1.1 和/2，具有更快的连接建立速度和更高效的带宽利用率，因为它对数据包丢失的依赖较少。启用了 HTTP/3 的 CloudFront 客户已经看到延迟降低多达 10%。在我们的另一篇文章中了解更多有关 CloudFront 中 HTTP/3 的好处。
安全性
您必须提升对动态内容的安全防范措施，因为 API 端点、登录服务等应用往往成为恶意流量攻击的目标。静态内容的请求通常可以从边缘位置快速响应，这有助于吸收分布式拒绝服务（DDoS）攻击。然而，对于动态内容的请求，无论是合法的还是恶意的，都会直接到达源服务器，除非我们能在事前检测到并应对恶意流量。CloudFront 以多种方式帮助您增强应用程序的安全性。
L3/L4 内联 DDoS 防护系统
当您使用 CloudFront 提供 Web 应用程序时，我们会通过完全内联的 DDoS 防护系统检查所有传入的数据包，而且这不会引入任何可观察到的延迟。我们能够实时减轻针对 CloudFront 分发的 L3/L4 层面的 DDoS 攻击。对于区域资源，我们采用了不同的检测逻辑：数据包不会进行内联检查，而是直接从互联网传输到应用程序。不过，我们会监控这些资源的流量情况，以便及时发现可能表明 DDoS 攻击存在的异常流量。每分钟，我们会对每个亚马逊资源的流量进行评估。因此，相比使用 CloudFront 时，检测和应对的速度可能会稍慢一些。
访问控制
CloudFront 要求源服务器使用公共 IP 地址。然而，CloudFront 还允许您仅允许来自 CloudFront IP 地址的流量进入，并阻止其他直接访问应用程序的流量。为此，您可以在 VPC 中保护源服务器的安全组配置中包含 CloudFront 管理的 IP 前缀列表。此外，我们建议配置 CloudFront 发送自定义的 HTTP 头，并要求源服务器（如 ALB）验证该头部的存在及其值，并在验证失败时拒绝请求。这样，您只会允许来自 CloudFront 分发的流量通过，并且您还可以配置用户访问控制，签名 URL 或签名 cookies 和 Geo Blocking。
实施周边保护
周边保护服务如 Amazon WAF 和 Amazon Shield Advanced，有助于减少可能使应用程序超负荷的不必要流量。通过采用 WAF Amazon WAF 速率限制规则、Bot Control、 ATP，以及 Shield 自动应用层 DDoS 缓解等功能，以及使用 CloudFront Functions 验证和授权请求，您可以有效地阻止边缘不需要的访问流量。然而，并非所有亚马逊云科技服务都直接支持 Amazon WAF 或 Shield Advanced。例如，Shield Advanced 不支持 API Gateway，而 Amazon WAF 不支持 Amazon Lambda URL。为了加强使用这些服务的应用程序的安全性，您可以将它们与 CloudFront 结合使用，并在 CloudFront 分发中应用 Shied Advanced 和 Amazon WAF 的保护。通过在 CloudFront 和服务之间实现 API 密钥或秘密头部，您可以使其变得非公开，同时在使用 HTTPS 向源站点传输时也难以拦截。
 |
图 4 – 周边保护
成本效益
CloudFront 可以降低数据传输出（DTO）的成本。您不需要支付从任何亚马逊云科技源站点到 CloudFront 的数据传输出费用，但是您需要支付 CloudFront 的数据传输出费用。换句话说，您通过 CloudFront 的数据传输出成本来替代从亚马逊云科技源站点的数据传输出成本，后者较低，而且如果您愿意进行最低流量承诺（通常为每月 10 TB 或更高）或使用 CloudFront Savings Bundle 成本还可能进一步降低。CloudFront 还提供免费套餐，其中包括每月 1 TB 的互联网数据传输出和每月 1000 万次 HTTP 或 HTTPS 请求免费。CloudFront 仅计算响应中的字节数，不包括交换 TLS 证书，而例如 Amazon EC2 则计算线路上的所有字节数，包括 TLS。正如我们所展示的，通过使用持久连接从源站点卸载可以降低 ALB LCU 的成本。值得注意的是，当保护的资源是 CloudFront 分发时，Shield Advanced 的数据传输出成本目前比应用于 Amazon EC2 或 ALB 时低一倍。最后，您订阅 Shield Advanced 服务将涵盖基本的 Amazon WAF 费用，包括 WebACL、规则和 Web 请求。
 |
图 5 – CloudFront 费用结构
请注意，CloudFront 的可选功能（如 Lambda@Edge、CloudFront Functions、实时日志、Origin Shield 和超过限制的失效请求）的流量费用未包含在内，将单独计费。
结论
本文主要介绍 CloudFront 在动态工作负载方面的多重好处。CloudFront 可以在多个方面帮助您：加速向用户传递内容，保护应用程序免受恶意流量的入侵，降低数据传输费用。在为特定的动态工作负载启用 CloudFront 时，请考虑测试性能改进、安全性和成本影响。