如何使用与现有分发相同的CNAME测试Cloudfront分配？

Question

我们的团队使用Cloudfront充当缓存+动态反向代理，以便：

  

example.com/foo

指向我们的Foo elasticbeanstalk环境和

  

example.com/bar

指向我们的Bar elasticbeanstalk环境。

现在，我们一直在努力对我们的一些example.com服务进行相当大的重新架构，现在我们希望example.com/foo转到我们的Foo2环境，以及其他一些内容，例如{{ 1}}到Baz，依此类推（同时保留一些现有规则，如example.com/baz到Bar）。

我们不想只是“翻转开关”并在生产中进行，并且希望事先测试我们的配置。因此，我们使用新行为设置了另一个发布，并为/bar和Foo2添加了良性示例应用程序。但当然 - 我们无法在此其他发行版上设置Baz CNAME，因为我们的CURRENT发行版已使用它。

当我们尝试通过编辑我们的example.com文件来“验证”来将/etc/hosts指向来自我们的新发行版的A记录中的一个IP地址时， Cloudfront似乎只是在幕后看到我们正在尝试请求主机example.com并将请求路由到我们的当前分发中的行为所指定的环境。

我们是否有办法测试和验证Cloudfront规则集对具有现有CNAME的分发的更改，而不更改应用于当前分发的行为和规则？

Answer 1

  

我们不想只是“翻转开关”并在生产中进行，   并希望事先测试我们的配置。

将CloudFront等服务用于多个阶段，例如测试，登台和生产以测试配置，建议的方法是首先使用AWS CloudFormation将基础架构配置编码为代码。

当您使用版本控制在代码中进行基础结构修改时（与源代码类似），您可以将更改应用于一个环境并进行测试，如果一切正常，您可以在其他环境中推送相同的更改。

  

我们是否可以测试和验证Cloudfront规则集更改   具有现有CNAME的分发而不更改行为   以及适用于当前分配的规则？

这是不可能的。对分发进行配置更改时，将应用规则，修改其行为。因此，如上所述，这将需要为每个环境分配多个分发来测试配置。

此外，除非您的应用程序代码使用程序中的域头（例如Host，Origin）（例如example.com），否则您可以使用AWS分配的域名测试应用程序到CloudFront（例如xxxxxx.cloudfront.net） ）

Answer 2

您可以将多个CNAME分配给单个分发。所有CNAME必须以逗号分隔。您只能测试HTTP连接，而不能测试HTTPS。您只能为给定的分发应用一个自定义域证书。

单个发行版最多可以有100个CNAME。检查以下链接中的限制。如果您需要更多，可以通过支持请求申请。

这将有助于测试而不会改变您的起源或行为中的任何内容。

希望它有所帮助。