12

我参加了 AWS 培训，他们向我们解释说，一个好的做法是通过 Cloudfront 缓存所有动态内容，将 TTL 设置为 0，即使负载均衡器前面有一个 LB。所以它可能是这样的：

Route 53 -> CloudFront -> Application LB

我看不到这种架构的任何优势，而不是直接拥有（仅适用于动态内容）：

Route 53 -> Application LB

我不明白这一点，因为 Cloudfront 将始终将所有流量发送到 LB，因此您将拥有：

  • 两个 HTTPS 协商（客户端 <-> Cloudfront 和 Cloudfront <-> LB）
  • 完全没有缓存（它是动态内容，不应该被缓存，因为这就是“动态”的意思）
  • 您将没有客户端 IP，因为您的 LB 只会看到 Cloudfront IP（我知道这可以修复，以获得客户端 IP，但是您将遇到下一个项目符号的问题）。
  • 作为一项额外的工作，您需要能够经常更新您的 LB 安全组，以匹配 CloudFront IP（对于该区域），因为我猜您只想从您的 Cloudfront 获取流量，而不是直接从 LB 公共端点获取流量.

所以，可能，我错过了关于这个Route 53 -> CloudFront -> Application LB架构的一些重要的东西。

有任何想法吗？

谢谢！

4

4 回答 4

4

以下是在 ALB 之上使用云端的一些好处

  • 对于由 Elastic Load Balancing 中的 ALB 提供服务的 Web 应用程序或其他内容，CloudFront 可以缓存对象并将它们直接提供给用户（查看者），从而减少 ALB 上的负载。

  • CloudFront 还可以帮助减少延迟，甚至可以吸收一些分布式拒绝服务 (DDoS) 攻击。但是，如果用户可以绕过 CloudFront 并直接访问您的 ALB，您将无法获得这些好处。但是您可以配置 Amazon CloudFront 和您的 Application Load Balancer 以防止用户直接访问 Application Load Balancer ( Doc )。

  • 从 AWS 服务到 CloudFront 的出站数据传输费用为 0 美元/GB。CloudFront 产生的每 GB 成本通常比相同层级和区域的数据传输成本低 0.5 美分。这意味着您可以利用 CloudFront 的额外性能和安全性，将其放在您的 ALB、AWS Elastic Beanstalk、S3 和其他提供 HTTP(S) 对象的 AWS 资源之前，几乎无需额外费用 ( Doc）。

  • CloudFront 全球网络由 100 多个接入点 (POP) 组成，由于缩短了与查看者的物理距离，因此缩短了建立面向查看者的连接的时间。这减少了提供静态和动态内容 ( Doc ) 的整体延迟。

  • CloudFront 维护与源的持久连接池，从而减少重复建立与源的新连接的开销。通过这些连接，CloudFront 和 AWS 源之间的流量通过私有骨干网络路由，以确保可靠性和性能。这减少了提供静态和动态内容 ( Doc ) 的整体延迟。

  • 您可以使用地理限制（也称为地理封锁）来阻止特定地理位置的用户访问您通过 CloudFront 分配 ( Doc ) 分发的内容。

换句话说，您可以利用 ClodFront 的优势向您的源（ALB、Elastic Beanstalk、S3、EC2）添加新功能，但如果您不需要这些功能，最好不要在您的架构中进行此配置。

于 2021-06-03T03:48:53.687 回答
1
  • Cloudfront 使您能够更快地交付内容，因为 Cloudfront 边缘位置更靠近用户请求并通过 AWS 网络主干连接到 AWS 区域。
  • 您可以在云端终止 SSL 并使负载均衡器在端口 80 处侦听
  • Cloudfront 允许在 2 次点击中轻松应用地理位置限制。
于 2021-06-06T12:58:25.823 回答
0

我认为您可能希望在 ALB 前使用 CF 的另一个原因是您可以使用 WAF 获得更好的体验（当然，如果您已经在使用（或计划使用）WAF）。

尽管 WAF 对 ALB 和 CF 都可用，但 ALB 和 CF 对 WAF 使用不同的服务。原因是 Cloudfront 是一项全球服务，而 ALB 是每个区域一个。

这可能会带来更复杂的 ACL 管理和复制（并且可能会增加成本）。

于 2021-11-10T16:08:15.597 回答
-2

Cloudfront 确实是一个了不起的 CDN 内容交付网络服务，如 Akamai 等。现在，如果您的 Web 应用程序包含大量动态内容（例如媒体文件），即使您是静态代码，您也可以将它们放入 AWS 提供的另一个对象存储服务的 S3 存储桶中。

将动态内容添加到 S3 存储桶后，您可以通过将该存储桶视为源来创建 Cloudfront 分发，这种现象将跨 AWS 多个边缘位置缓存您的动态内容。在客户端交付将变得更快。

现在，如果我们谈论负载均衡器。所以它有它自己的目的来提供图像，你正在使用一个应用程序，你会得到一个不可预测的流量，所以在这里你的负载均衡器，我们正在考虑一个应用程序或经典负载均衡器，它接受来自 Route 53 的请求并将其传递给你的服务器。

对于高可用性和可扩展性，我们考虑这样的应用程序架构。

  • 我们为我们的 ec2 实例创建一个自动扩展组，并将它们放在负载均衡器后面，并根据我们的扩展策略示例：如果我的 cpu 或内存利用率超过 70%，则启动另一个实例或类似实例。

您也可以在负载均衡器上设置请求策略，以便为您的 ec2 服务器提供流量，可能是轮询或可用性。

我刚刚分享了推荐的 AWS 容错和高可用架构的最佳实践。我希望这可以帮助您更好地做出决定。如果我可以帮助您提供更多建议，请告诉我。

感谢和快乐的学习！

于 2018-12-06T18:14:21.440 回答