两个CloudFront分配：
我尝试的选项是有两个单独的CloudFront Web分配，一个用于s3存储桶（A版本）中的静态站点，另一个用于存储s3存储桶（B版本）中的另一个静态站点。 我尝试使用Route53加权路由策略，其中为我的www.domain.com Route53logging添加了两条logging，一条指向CloudFront Distribution A，权重为0，另一条指向CloudFront Distribution B，权重为0. I想做A / Btesting。
将www.domain.com用作Prod分发A的备用CNAME。
将* .domain.com用作Prod分发的替代CNAME
我的内容总是从A获得。我希望它能从两个版本中得到相同的比例。
任何帮助吗？
您无法使用CloudFront执行此操作。
tl; dr：您的通配符与主机名不匹配，而在另一个分发版上configuration了特定的冲突主机名。
您在分发B上创build了通配符替代主机名，试图解决此限制：
如果另一个CloudFront分配中已经存在备用域名，即使您的AWS账户拥有其他分配，您也不能将备用域名添加到CloudFront分配。
当然，这是限制的原因，也解释了为什么分配B将永远不会看到您的请求，即使您的DNSconfiguration按预期工作。
规则的例外
但是，您可以添加通配符备用域名，例如* .example.com，其中包含（与之重叠）非通配符备用域名（如www.example.com）。 只要这两个分布是使用相同的AWS账户创build的，则重叠的域名可以处于相同的分布或分散的分布。
…没有提供你预期的例外。
当一个Web浏览器连接到一个端点时，浏览器到达的方式不会被保留下来 – 它是一个静态的Alogging，一个别名，一个CNAME，一个CNAME的整个级联，或者是你的hosts文件中的一个条目？ 服务器不知道，因为这些信息没有被保留下来……它知道你到达的IP地址，但是这是来自许多发行版共享的池，所以你的请求是如何发生到达特定的CloudFront边缘的遵循DNSlogging，您的“A”或“B” – 它们在CloudFront端可能甚至不是不同的IP地址）并不能用于确定哪个分配应该为您的请求提供服务。
CloudFront唯一的机制是确定哪个分配应该服务特定请求的唯一机制是传入http请求中的HTTP Host:头（也可能是SNI协商，但是这不会改变任何事情，无论CloudFront是否使用它） 。
处理一个请求属于一个特定的分配是由别的决定 – 它不可能是，因为没有其他可用的基础。
通过逻辑扩展，只有一个发行版可以与任何给定的传入请求Host:标题相关联，例如www.example.com （您的发行版“A.”）
另一个发行版（“B”） *.example.com实际上只能提供除 www.example.com 之外的所有其他发布请求（或者与发行版相关的任何其他更具体的替代域名匹配通配符），因为具有更多特定主机名关联（“A”）的同一帐户上的另一个分配将特定主机名称www.example.com为*通配符的例外。
从本质上讲，首先检查请求是否具有确切的主机名匹配，然后只有在不匹配的情况下，才会使用通配符分配请求。
我得到的一个解决scheme是：我尝试使用两种不同的服务。 在我的www.domain.com Route53logging中添加了两条logging，一条指向CloudFront Distribution A，权重为0，另一条直接指向位置B处的s3 Bucket（www.domain.com），重量为WRR工作。 但是，我不认为我们可以使用WRR的S3 / Cloudfront风格，因为两者之间的性能差别很大，所以A / Btesting对于S3版本是不公平的。 客户将从Cloudfront边缘服务器获得更好的响应时间。
我还有另一个select，即在53号线build立交通政策。我想我应该去这个。 是否有其他的select，我可以尝试和哪些是满足ABtesting要求加上是成本效益？