使用CloudFront在原始服务器之间分割流量 - 此配置是否正确？

Question

我正在分阶段用新的网站替换旧网站。从用户角度来看，所有现有URL必须保持不变，但某些路径应该提供新页面。

我有两个原始服务器：遗留服务器（www.mysite.com）和新的EC2（www.ec2-loadbalancer.com） - 出于隐私原因，显然是模拟URL。

我创建了一个CNAME设置为www.mysite.com的AWS CloudFront分配。在这个发行版中，我创建了两个起源域：

• www.mysite.com
• www.ec2-loadbalancer.com

在CloudFront中，我已配置了一些行为，以便将/foo之类的路径发送到我的EC2负载均衡器原点，并将所有其他路径（例如，默认值）发送到www.mysite.com。

从DNS的角度来看，我添加了CNAME www.mysite.com条记录，该记录指向我的Cloudfront主机域（例如foo.cloudfront.net.）。此域的A记录指向旧版服务器的IP。

我今天推出了所有这些，它似乎有效，但我看到网站上出现间歇性403错误，并且在进行更改后两小时（之前没有“www”CNAME，所以TTL不应该有所作为），有些浏览器仍然从原始IP（而不是CloudFront）服务该站点。

我是否正确配置了这个？我无法通过A记录来确定如何执行此操作 - 该记录指向旧版服务器的IP，而CloudFront不允许我输入IP地址作为原点。我是否应该将www CNAME指向IP地址，而是在CloudFront上创建A记录点？我在这里有点迷失。

另一方面，它可能都是一个传播的东西，但我在发生变化后几个小时看到了40倍的错误。

Answer 1

我认为你应该创建一个A记录（对于指定的域名），其别名指向云端分布。它应该解决问题。

即。使用别名而不是IP地址，并将您的域指向cloudfront：

Answer 2

遗憾的是，您无法与我们分享域名以帮助调试，但至少dig是您的朋友。例如：

$ dig membership.theguardian.com
...
;; ANSWER SECTION:
membership.theguardian.com. 367 IN  CNAME   i.global-ssl.fastly.net.
i.global-ssl.fastly.net. 12 IN  A   151.101.128.67
i.global-ssl.fastly.net. 12 IN  A   151.101.64.67
i.global-ssl.fastly.net. 12 IN  A   151.101.0.67
i.global-ssl.fastly.net. 12 IN  A   151.101.192.67

...告诉您membership.theguardian.com指向CNAME的Fastly。您可以通过以下方式检查备用DNS服务器，例如8.8.8.8上的Google's DNS：

$ dig @8.8.8.8 membership.theguardian.com

...这样您就可以了解其他人如何解析您的域名。

  

从DNS的角度来看，我添加了www.mysite.com的CNAME记录   它指向我的Cloudfront主机域（例如foo.cloudfront.net。）。   此域的A记录指向旧版服务器的IP。

我不是一位DNS专家，所以我可能不会在这里理解你，但这听起来像引入了歧义？对我来说，这听起来像是有两个不同的记录用于同一个www.mysite.com域，其中一个指向CloudFront，另一个指向旧版服务器的IP。根据解决方法的不同，可以将浏览器发送给其中一个？！

• www.mysite.com应将仅指向CloudFront。我本人只是为此使用CNAME。
• 您应该为遗留服务器和EC2 Elastic Load Balancer提供明确的地址 - 我个人会给他们自己明确的域名，以避免混淆（例如legacy.mysite.com＆amp; beta.mysite.com） - 在CloudFront中，当您指示流量时（例如，将流量传递到www.mysite.com作为转发到旧服务器的方式时，仅指向那些明确的名称）。

祝你好运！