在AWS Application LB之上添加AWS Cloudfront有什么好处?

时间:2018-12-06 16:22:02

标签: amazon-web-services web-architecture amazon-cloudfront aws-application-load-balancer

我参加了一次AWS培训,他们向我们解释了一个好的做法是,即使您在负载均衡器的前面有一个LB,也要通过Cloudfront缓存所有动态内容,并将TTL设置为0。所以可能像:

Route 53 -> CloudFront -> Application LB

我看不到这种架构的任何优势,而是直接拥有(仅针对动态内容):

Route 53 -> Application LB

我不明白这一点,因为Cloudfront会将所有流量始终发送到LB,所以您将:

  • 两个HTTPS协商(客户端<-> Cloudfront和Cloudfront <-> LB)
  • 完全不缓存(它是动态内容,不应缓存,因为这是“动态”的含义)
  • 您将没有客户端IP,因为您的LB仅会看到Cloudfront IP(我知道可以固定为具有客户端IP,但是下一个项目符号会出现问题)。
  • 作为一项额外的工作,您需要能够经常更新LB安全组,以匹配CloudFront IP(针对该区域),因为我想您只想从Cloudfront而不是直接从Cloudfront获得流量。 LB公共端点。

因此,可能我缺少有关此Route 53 -> CloudFront -> Application LB体系结构的重要信息。

有什么想法吗?

谢谢!

3 个答案:

答案 0 :(得分:2)

以下是将 Cloudfront 置于 ALB 之上的一些好处

<块引用>
  • 对于由 Elastic Load Balancing 中的 ALB 提供的 Web 应用程序或其他内容,CloudFront 可以缓存对象并为其提供服务 直接面向用户(查看者),减少 ALB 的负载。

  • CloudFront 还可以帮助减少延迟,甚至可以吸收一些分布式拒绝服务 (DDoS) 攻击。但是,如果用户可以 绕过 CloudFront 并直接访问您的 ALB,您不会得到这些 好处。但是您可以配置 Amazon CloudFront 和您的应用程序 负载均衡器防止用户直接访问应用程序 负载平衡器 (Doc)。

  • 从 AWS 服务到 CloudFront 的出站数据传输费用为 0 美元/GB。 CloudFront 的成本通常低半美分 每 GB 比同一层和区域的数据传输。这是什么 意味着您可以利用额外的性能和 通过将 CloudFront 置于您的 ALB、AWS Elastic 之前来确保它的安全性 Beanstalk、S3 和其他 AWS 资源为 几乎没有额外费用 (Doc)。

  • 由超过 100 个接入点 (POP) 组成的 CloudFront 全球网络减少了建立面向观众的时间 因为与观众的物理距离缩短了。 这减少了服务静态和动态的整体延迟 内容 (Doc)。

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

  • 您可以使用地理限制(也称为地理封锁)来防止特定地理位置的用户访问 您正在通过 CloudFront 分配 (Doc) 进行分配。

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

答案 1 :(得分:1)

  • Cloudfront 使您能够更快地交付内容,因为 Cloudfront 边缘站点更靠近请求的用户,并通过 AWS 网络主干连接到 AWS 区域。
  • 您可以在 cloudfront 终止 SSL 并使负载均衡器在端口 80 侦听
  • Cloudfront 允许通过 2 次点击轻松应用地理位置限制。

答案 2 :(得分:0)

Cloudfront确实是Akamai等出色的CDN内容交付网络服务。现在,如果您的Web应用程序具有很多动态内容(例如媒体文件),甚至是静态代码,您也可以将它们放到AWS的S3存储桶中,另一个对象存储服务。

一旦将动态内容包含在S3存储桶中,就可以通过将存储桶视为源来创建Cloudfront发行版,此现象将在AWS多个边缘位置缓存您的动态内容。而且它将很快在客户端交付。

现在,如果我们谈论负载均衡器。因此,使用正在使用的应用程序在其中获得无法预测的流量来提供映像是有其自身目的的,因此在这里,我们正在考虑的负载均衡器是一个应用程序或经典的负载均衡器,它正在接受来自Route 53的请求并将其传递到您的服务器。 / p>

为了获得高可用性和可伸缩性,我们考虑采用这种应用程序架构。

  • 我们创建一个由ec2实例组成的自动扩展组,并将其置于负载均衡器之后,并按照我们的扩展策略示例进行操作:如果我的cpu或内存利用率超过70%,则启动另一个实例或类似实例。

您还可以在负载均衡器上设置请求策略,以通过Robbin或可用性来向ec2服务器提供流量。

我刚刚分享了推荐的AWS容错和高可用性架构的最佳实践。希望这可以帮助您更好地决定现在。 请让我知道是否可以为您提供更多建议。

感谢和快乐的学习!