具有基于地理位置的策略与 Cloudfront 的多区域部署

She*_*oli 3 amazon-ec2 amazon-web-services amazon-cloudfront amazon-route53

我有一个自定义源,即 EC2 实例上的 Web 应用程序。我如何决定是否应该选择:

  1. Cloudfront CDN

或者,

  1. 在不同区域部署多个实例并配置基于地理位置/邻近度的路由策略

造成混乱的原因是,两者都旨在根据请求的位置将请求路由到最近的位置(在Cloudfront的情况下为边缘位置,在使用 Route 53 进行基于地理位置的策略的多区域部署时,则为区域特定的 EC2 实例)起源于.

Mic*_*bot 7

没有理由不能两者兼得。

CloudFront 自动将请求路由到距离查看器最近的边缘位置,当无法从该位置或最近的区域缓存提供请求时,CloudFront 会对源域名进行 DNS 查找并从源获取内容。

到目前为止,我只说了显而易见的事情。但接下来是一个微妙但重要的细节:

CloudFront从靠近查看器的位置执行源服务器 DNS 查找- 这意味着,如果源域名是 Route 53 中基于延迟的记录集,指向两个或多个 EC2 区域中的部署,则请求 CloudFront使“查找”原点将被路由到最接近边缘的原点部署,根据定义,该原点部署也将靠近查看器。

因此,单个全局 CloudFront 部署可以使用基于延迟的后端 DNS 配置来自动、透明地选择最佳源。

如果 CloudFront 提供的缓存和传输优化无法为您提供所需的全局性能,那么您可以在 CloudFront 后面的多个区域中部署...始终要注意,多区域部署几乎总是一个更复杂的环境,取决于支持您的应用程序的数据库以及它们如何处理跨区域复制的读取和/或写入。

将 CloudFront 包含为前端也是多个区域部署之间容错的更好解决方案,因为 CloudFront 正确遵守源服务器 DNS 记录上的 DNS TTL,并且如果您配置了 Route 53 运行状况检查以将不健康的区域排除在外源域名上的 DNS 响应后,CloudFront 将快速停止向其发送进一步的请求。浏览器在这方面是出了名的不可信,有时会缓存 DNS 答案,直到所有选项卡/窗口都关闭。

如果 CloudFront 是您的前端,您可以根据需要将部分逻辑卸载到 Lambda@Edge。