我可以将 cloudfront 与 route53 流量策略一起使用吗？答案

【问题标题】：Can I use cloudfront with a route53 traffic policy?我可以将 cloudfront 与 route53 流量策略一起使用吗？
【发布时间】：2020-05-08 19:05:34
【问题描述】：

我的应用程序有 12 个实例，位于 elb 前面的 12 个差异区域中

我使用基于地理位置的 route53 流量策略来路由到不同的区域

我可以将云端分发指向该策略记录的来源吗？它会正常工作吗？以这种方式使用 cloudfront 和 route53 有什么注意事项吗？

【问题讨论】：

标签： amazon-web-services amazon-cloudfront amazon-route53

【解决方案1】：

在 12 个区域放置多个 Amazon EC2 实例是一项相当大的投资！大概您这样做是为了减少用户的延迟。

Amazon CloudFront 在 200 多个位置设有入网点，因此建议将其用于提供静态内容。这典型意味着内容在用户之间不会改变，例如图片、样式表和脚本文件。它允许您从 Web 服务器中卸载大量此类流量，这意味着您可以运行更少的 Web 服务器。

Amazon Route 53 geo-routing 用于将流量从特定国家发送到特定目的地（例如，来自德国的所有请求都发送到带有德语内容的服务器）。但是，鉴于您已将流量分配到多个区域，您最好使用基于延迟的路由，因为这会将流量引导至提供延迟最低为您的用户。

结合使用 Route 53 和 CloudFront 可能会提供一些优势，具体取决于它们的配置方式。

首先，您发布的 DNS 名称需要解析为 CloudFront，以便它可以从所有存在点提供内容。这是静态内容的理想选择。

接下来是如何为 CloudFront 所需的内容配置 origin 的问题。这可能是在 Route 53 中为基于延迟的路由配置的另一个 DNS 名称，这意味着 CloudFront 将从“附近”位置提取内容，而不是返回到单个来源。这对于缓存的内容并不重要，但它可以加快动态内容（即每个用户的不同内容）的交付。

我建议您对这些选项中的每一个进行测试，并确定哪些选项符合您的性能目标，同时还要考虑每个选项的费用。例如：

选项 1： Amazon CloudFront 和 ONE 源 - 这将是最低成本，但对于动态内容来说可能太慢了
选项 2： 没有 CloudFront，但有多个区域（如您当前使用的那样） - 这将是相当高的成本，但如果使用基于延迟的路由，则可以提供快速流量
选项 3： CloudFront + 多个区域 - 小心配置方式（它需要多级 DNS），但这可能比选项 #2 更快

您应该测试每个选项并将结果与您的特定速度/延迟目标进行比较。然后你应该比较每个选项的成本，看看它是否提供了所需的成本/收益比。

【讨论】：

内容是动态的，必须由网络服务器提供。所以我可以将云端源指向 Route53 流量策略，Route53 将通过地理或延迟为正确的端点提供云端服务？请求到达云端后，它会在 AWS 的网络上，并且使用这种方法对服务器的延迟会更低吗？或者像这样使用 route53 不会那样工作？我的理解是，如果在用户请求通过 AWS 的内部网络路由到 ELB 后，我的云端直接指向 ELB
所有的内容都是动态的吗？如果是这样，使用 CloudFront 不会提供太多优势，因为它总是需要返回源。即使有轻微的网络速度优势，也可能不值得。您当然可以测试这样的配置以确定它是否适合您的特定系统。